During this week's TR Dojo episode, I share five tips for improving Linux security, such as not logging in as root and using keyring. And, every time I talked about Linux security, the discussion always turns to an argument of how much more secure Linux is over Windows. With plenty of people on both sides.
In this discussion, I'd like to get the honest feedback of IT pros supporting both Linux and Windows machines. Have you found the Linux machines you support to be more secure than the Windows machines you support? Take the poll and let me know?
Original post and poll:
http://blogs.techrepublic.com.com/itdojo/?p=2187
Discussion on:
View:
Show:
Hi Bill,
I just want to let you know how much I appreciate your thoughtfulness in including the transcript.
I am deaf and would have missed the valuable tips you shared -- without the transcript.
Thanks again!
Ari
I just want to let you know how much I appreciate your thoughtfulness in including the transcript.
I am deaf and would have missed the valuable tips you shared -- without the transcript.
Thanks again!
Ari
No video player. Where is the video? (using Firefox 3.6.12)
If you're using NoScript or Adblock, you may need to add exceptions for TechRepublic to see the video player.
Yes. I have found Linux more secure than Windows. However, I have found less "normal people friendly" tools for helping end users be responsible for their environment in Linux than Windows.
On the other hand, security is based a lot on the behavior of the end user. Some are too complacent, others are just naturally spaced out and careless, others just don't care and a relative few just love to take risks and short cuts.
Classifying end users by their security risk affinity and routinely enacting active measures to protect them and sometimes to protect the rest of the organization against the riskier of those end users always pays off.
BTW, is that an iSeries (AS/400) behind you in the background picture for your video making you appears as in a data center? In an old story, I had to once break into an S/34 (predecessor of the AS/400). After reading the vendor manuals located next to the machine, I found the MSO password in memory encrypted as a 2's complement set of bytes.
One lesson: Don't keep your most secret information and how to get around security barriers physically next to the machine, unless the machine is in a secure data center where EVERYONE (including repair vendors) are vetted and watched.
On the other hand, security is based a lot on the behavior of the end user. Some are too complacent, others are just naturally spaced out and careless, others just don't care and a relative few just love to take risks and short cuts.
Classifying end users by their security risk affinity and routinely enacting active measures to protect them and sometimes to protect the rest of the organization against the riskier of those end users always pays off.
BTW, is that an iSeries (AS/400) behind you in the background picture for your video making you appears as in a data center? In an old story, I had to once break into an S/34 (predecessor of the AS/400). After reading the vendor manuals located next to the machine, I found the MSO password in memory encrypted as a 2's complement set of bytes.
One lesson: Don't keep your most secret information and how to get around security barriers physically next to the machine, unless the machine is in a secure data center where EVERYONE (including repair vendors) are vetted and watched.
I was just listening to a talk from a physical security auditor which also included "so I opened the operations manual and there was the administrator's password published right beside the machine it was supposed to protect"
Red Hat = Much more secure than Windows
Ubuntu = Probably not much difference.
No machine is any more secure than the guy or gal who has root.
Ubuntu = Probably not much difference.
No machine is any more secure than the guy or gal who has root.
Security through obscurity. Linux has about 1% of Internet activity. The cyber criminals go after the fattest target.
...agree
On servers it has a much higher market share. Maybe even more than any other.
The thing is, and this bears repeating, linux is not an OS. Linux is a building block for an OS. You can make that as secure or insecure as you want.
And security through obscurity isn't security, lest anyone go with that approach.
On servers it has a much higher market share. Maybe even more than any other.
The thing is, and this bears repeating, linux is not an OS. Linux is a building block for an OS. You can make that as secure or insecure as you want.
And security through obscurity isn't security, lest anyone go with that approach.
Obscurity is based on how many attacks a system attracts.
Security is based on what percentage of received attacks are successful.
Obscurity is short lived; it is committing a crime and running from the police hoping they don't catch you. Hoping you where not caught on camera or clear in the memories of witnesses.
Security is long lived; it is commiting a crime in full view of cameras, witnesses and police then walking up to the police, waving diplomatic papers and walking away without them able to touch you.
Obscurity only has any value for the attacker and then it's only a very short term value. If your defense places a high value on obscurity against attackers; what do you do when that thing is no longer obscure?
Back the the OS noise.
Linux based OS on the desktop may have 1% of the desktop market. This number alone is debatable since it reflects only the measurable retail market. It does not reflect true usage figures including non-retail measurable distribution.
This is all on the desktop though. We're talking OS potential for security which includes non-desktop. So we also have the server market where *nix based systems are a majority and Debian, Red Hat, CentOS and other Linux based OS are common.
Here's the question; if it's simply "obscurity" keeping all these Linux based systems safe, where are the reports of servers constantly being breached due to software related vulnerabilities? Why are reports of *nix system breaches where it has the majority not as frequent as reports where Windows has the majority? (And, what do you think is running inside all the firewalls and other network hardware you need to protect your Windows users?)
(or, maybe it has something to do with system architecture)
In the end, obscurity has little value in relation to security. I don't care if I'm seeing a hundred attempts a minute on my severs; I only care about what percentage of those are potentially successful. I don't care how obscure my system is before the attacker knows about it. I care about how secure it is after the attacker knows about it.
Security is based on what percentage of received attacks are successful.
Obscurity is short lived; it is committing a crime and running from the police hoping they don't catch you. Hoping you where not caught on camera or clear in the memories of witnesses.
Security is long lived; it is commiting a crime in full view of cameras, witnesses and police then walking up to the police, waving diplomatic papers and walking away without them able to touch you.
Obscurity only has any value for the attacker and then it's only a very short term value. If your defense places a high value on obscurity against attackers; what do you do when that thing is no longer obscure?
Back the the OS noise.
Linux based OS on the desktop may have 1% of the desktop market. This number alone is debatable since it reflects only the measurable retail market. It does not reflect true usage figures including non-retail measurable distribution.
This is all on the desktop though. We're talking OS potential for security which includes non-desktop. So we also have the server market where *nix based systems are a majority and Debian, Red Hat, CentOS and other Linux based OS are common.
Here's the question; if it's simply "obscurity" keeping all these Linux based systems safe, where are the reports of servers constantly being breached due to software related vulnerabilities? Why are reports of *nix system breaches where it has the majority not as frequent as reports where Windows has the majority? (And, what do you think is running inside all the firewalls and other network hardware you need to protect your Windows users?)
(or, maybe it has something to do with system architecture)
In the end, obscurity has little value in relation to security. I don't care if I'm seeing a hundred attempts a minute on my severs; I only care about what percentage of those are potentially successful. I don't care how obscure my system is before the attacker knows about it. I care about how secure it is after the attacker knows about it.
Perhaps you should do your homework before embarrassing yourself.
Additionally, please explain how exactly Linux uses obscurity for security when all of the source code is open to the public.
Additionally, please explain how exactly Linux uses obscurity for security when all of the source code is open to the public.
I can't give an unbiased opinion on this right now. I've a Windows machine that's randomly decided it doesn't recognize our VPN gateway or mail server. I've a second Windows machine giving BSOD every time the user logs in thought not admin or a test user account; BSOD and rebooting before it's even able to give me a minidump or usable Event entry.
What I would give for a c:\documents and settings\logs\ right now just to at least see the error codes.
By contrast, my *nix servers are running like a rock; even my Debian 6 installs are stable and ticking along without a user login taking out the entire system.
If stability is part of security, I'm not feeling it from Windows the last few days.
What I would give for a c:\documents and settings\logs\ right now just to at least see the error codes.
By contrast, my *nix servers are running like a rock; even my Debian 6 installs are stable and ticking along without a user login taking out the entire system.
If stability is part of security, I'm not feeling it from Windows the last few days.
If that crap happens to my computer, I hand it to someone else
If I can't fix it in house, I hand it to someone else.
In my case I'm venting mostly but with the possibility that someone will make a helpful suggestion. I'm also stacking frustration with these two machine on top of almost a week's frustration with two HP printers and "Universal Printer Driver" hell.
In my case I'm venting mostly but with the possibility that someone will make a helpful suggestion. I'm also stacking frustration with these two machine on top of almost a week's frustration with two HP printers and "Universal Printer Driver" hell.
I've been getting some instability from Windows Vista x64 since the last update(we'll see tomorrow) I don't run servers anymore, but when a desktop has these problems it is just as bad.
I do know that you don't want to use anything but the basic HP drivers for printers, but I bet you already know that - I forget what a "Universal" driver is, so please forgive me.
It seems like any updates for Vista are unstable for every other update cycle. Redmond issues an update to fix vulnerabilities, then the next cycle fixes the stuff messed up by the last cycle. This goes on and on ad nauseum.
I do know that you don't want to use anything but the basic HP drivers for printers, but I bet you already know that - I forget what a "Universal" driver is, so please forgive me.
It seems like any updates for Vista are unstable for every other update cycle. Redmond issues an update to fix vulnerabilities, then the next cycle fixes the stuff messed up by the last cycle. This goes on and on ad nauseum.
It's one big blob driver for all printer models. Manage one driver that all hardware models know how to talk to and reduce development cost and time; in theory.
You should still be getting an entry in the system log with some details about what is happening here.
If you want to see & read the blue screen, go into the computer properties. In the advanced properties, select the Startup and Restart option. Clear the checkbox to Automatically reboot the machine after a failure/critical error. Do whatever it takes to invoke the failure and the machine should end up sitting at the BSOD waiting for someone to restart the box.
If you want to see & read the blue screen, go into the computer properties. In the advanced properties, select the Startup and Restart option. Clear the checkbox to Automatically reboot the machine after a failure/critical error. Do whatever it takes to invoke the failure and the machine should end up sitting at the BSOD waiting for someone to restart the box.
I thought that setting might be next on my list. I did notice that "automatic reboot" was checked when I set the minidump path but hadn't been back.
In the end, I may not need it. A Lenovo driver reinstall seems to have solved the issue so far. Still doing reboots and logins to be sure though.
In the end, I may not need it. A Lenovo driver reinstall seems to have solved the issue so far. Still doing reboots and logins to be sure though.
Compared to "do not show known file extensions" enabled by default, "automatic reboot on error" seems completely rational. 
Actually, it would be perfectly bearable if the minidump or a proper txt crash log was generated.
Bah.. long as it's fixed for now.
Actually, it would be perfectly bearable if the minidump or a proper txt crash log was generated.
Bah.. long as it's fixed for now.
I'm pretty new at this whole *nix thing, so I'm going to ask a pretty stupid user question:
What's with the 'don't log in as root' thing? If I'm working on a server and logging in on the machine's console, and that is the only place anyone ever logs into the machine. Well, it seems to me that the only reason anyone is going to be logging into that machine is for administrative tasks, right? I mean, I'm not surfing for pr0n or torrenting illegal apps on my dom0, right? ( -or at all, since you were wondering.)
If I'm going to screw something up when I'm logged in as root, I'm still going to screw it up if I su to root, right? (Like the time when I thought it would be a good idea to comment out everything in my securetty and set my default runlevel to 3. No user accts, and not connected to the LAN yet. Well, I know more about securetty now.)
No, I wouldn't log in on an admin account for everyday tasks on my XP machine since most vulnerabilities seem to inherit the logged in account's rights (if you're lucky, at least), but on a server where the only business you have being logged in at all is administrative tasks, it seems to me that you would be better off to not even have any user accounts. Anyone logging in should be trusted, right? OK, maybe you have an admin account for backups with different rights than the mail admin's account, but it's still pretty much the same thing. In my case, I'm the admin, so why would I want to offer up more holes (in the form of more accounts/pw's) for an attacker to aim at?
If you're talking about a desktop/workstation, yes, absolutely, never log in as root. On a server, why log in as anything other than an admin acct?
What's with the 'don't log in as root' thing? If I'm working on a server and logging in on the machine's console, and that is the only place anyone ever logs into the machine. Well, it seems to me that the only reason anyone is going to be logging into that machine is for administrative tasks, right? I mean, I'm not surfing for pr0n or torrenting illegal apps on my dom0, right? ( -or at all, since you were wondering.)
If I'm going to screw something up when I'm logged in as root, I'm still going to screw it up if I su to root, right? (Like the time when I thought it would be a good idea to comment out everything in my securetty and set my default runlevel to 3. No user accts, and not connected to the LAN yet. Well, I know more about securetty now.)
No, I wouldn't log in on an admin account for everyday tasks on my XP machine since most vulnerabilities seem to inherit the logged in account's rights (if you're lucky, at least), but on a server where the only business you have being logged in at all is administrative tasks, it seems to me that you would be better off to not even have any user accounts. Anyone logging in should be trusted, right? OK, maybe you have an admin account for backups with different rights than the mail admin's account, but it's still pretty much the same thing. In my case, I'm the admin, so why would I want to offer up more holes (in the form of more accounts/pw's) for an attacker to aim at?
If you're talking about a desktop/workstation, yes, absolutely, never log in as root. On a server, why log in as anything other than an admin acct?
The idea is, if you log in as root, now the entire operating system has escalated privelages. Whereas, if you log in as an unprivelaged account, and use su or sudo, you're only giving that specific application escalated privelages.
Its a much more granular way of approaching privelages.
Now you say, we'll I'm the system admin, I know what I'm doing. Okay, good luck. If ever the machine is compromised, now every app has root access and can do whatever it wants.
Its a much more granular way of approaching privelages.
Now you say, we'll I'm the system admin, I know what I'm doing. Okay, good luck. If ever the machine is compromised, now every app has root access and can do whatever it wants.
Like I said, I'm still pretty new at this. If you log in as root every app has root privileges?
Wouldn't it just be the apps you run as root? I suppose that would include anything that runs to log you in, yes? (and I'm not sure exactly what that would be, honestly. If you run startx, would everything running have root access?) And any login scripts that run when you log in, right?
Could you clarify some?
Yes, I am the sysadmin, but I most emphatically did not say I know what I'm doing. That's why I asked the question.
Wouldn't it just be the apps you run as root? I suppose that would include anything that runs to log you in, yes? (and I'm not sure exactly what that would be, honestly. If you run startx, would everything running have root access?) And any login scripts that run when you log in, right?
Could you clarify some?
Yes, I am the sysadmin, but I most emphatically did not say I know what I'm doing. That's why I asked the question.
Logging in as Root or administrator gives everything running, and anything which can potentially run, system-level privilege.
So, if something bad comes down the network pipes while you are running as root...
So, if something bad comes down the network pipes while you are running as root...
I habitually ssh or login as user and su to root if I happen to be doing a lot of Root work.
- if there is a weakness in the network protocol (ssh in this case) and someone figures a way to sniff my username/password then they only get my permission limited user account
- when I do finally use the Root password; I'm already inside an established encrypted channel. My Root credentials remain protected inside an existing SSH session. You may have gotten my user credentials when SSH initially connected but your not getting my Root credentials once the SSH tunnel is fully established after the user name/password.
This also reinforces the habit of always logging in as user then only becoming root when needed. Logging in directly as Root quickly supports the habit of just logging as Root all the time for convenience; which negates the whole purpose of privileged separation. Connect as User, su to Root is too easy a good habit; it doesn't take enough extra time to justify skipping the user login.
If you frequently use a few programs that require root; it's better to set sudo permission for them. You remain as your user account and simply sudo the applicable command. "su" to become root should really not be a normal working situation. Even on my servers I su to Root, do what is needed and exit back to user if it's not something done simply by sudo.
In terms of programs run; yes, it is any program that you run while logged in as Root. The problem is not what you intend to run as Root but what happens to run with a user login.
When one logs in the session and console programs run as the user. The X and the applicable GUI shell also run as user. Now console shell, X, Gnome/KDE and any other related programs are running with User's security access. Since I logged in as a user, they have only the normal expected user level permissions; they can hose my home directory but shouldn't be able to break anything beyond my independent user account.
For simple tasks, I setup sudo. One such task is running Metasploit; I'm a user but it likes to run with Root permissions so it can work it's magic. It needs to muck with the networking in ways that are normally only allowed by Root. "sudo ~/MSF3/msfconsole" and there I am logged in as user but running Metasploit with Root permissions for heavy lifting. In this case, the desirable specific program is a little bubble of higher permissions inside my normal user permissions session.
Maybe I'm doing something more complex than a specific app that wants Root permissions. I'm checking logs, adding/removing packages or whatever else; stuff that when added up makes more sense to do through a full Root session. I'm still logged in as User with console/X/GUI all limited to User's permissions so I open a terminal window (xterm, konsole, cmd.com, powershell.. same idea; cli inside a window). I then su to Root; only that little console session inside the terminal window is Root. The rest of my session is still User.
(
User@login(
User@cli(
User@GUI(
Root@cli
)
)
)
)
Root is a bubble contined inside the user login. Only Root inside that bubble has Root access. Only what I run inside that Root cli runs as root.
(
Root@login(
Root@cli(
Root@GUI(
Root@cli
)
)
)
) "su" and enter your administrator password when prompted. It's amazing how much you can do without login an existing user out of the machine. (msiexec is a very nice .MSI package manager)
- if there is a weakness in the network protocol (ssh in this case) and someone figures a way to sniff my username/password then they only get my permission limited user account
- when I do finally use the Root password; I'm already inside an established encrypted channel. My Root credentials remain protected inside an existing SSH session. You may have gotten my user credentials when SSH initially connected but your not getting my Root credentials once the SSH tunnel is fully established after the user name/password.
This also reinforces the habit of always logging in as user then only becoming root when needed. Logging in directly as Root quickly supports the habit of just logging as Root all the time for convenience; which negates the whole purpose of privileged separation. Connect as User, su to Root is too easy a good habit; it doesn't take enough extra time to justify skipping the user login.
If you frequently use a few programs that require root; it's better to set sudo permission for them. You remain as your user account and simply sudo the applicable command. "su" to become root should really not be a normal working situation. Even on my servers I su to Root, do what is needed and exit back to user if it's not something done simply by sudo.
In terms of programs run; yes, it is any program that you run while logged in as Root. The problem is not what you intend to run as Root but what happens to run with a user login.
When one logs in the session and console programs run as the user. The X and the applicable GUI shell also run as user. Now console shell, X, Gnome/KDE and any other related programs are running with User's security access. Since I logged in as a user, they have only the normal expected user level permissions; they can hose my home directory but shouldn't be able to break anything beyond my independent user account.
For simple tasks, I setup sudo. One such task is running Metasploit; I'm a user but it likes to run with Root permissions so it can work it's magic. It needs to muck with the networking in ways that are normally only allowed by Root. "sudo ~/MSF3/msfconsole" and there I am logged in as user but running Metasploit with Root permissions for heavy lifting. In this case, the desirable specific program is a little bubble of higher permissions inside my normal user permissions session.
Maybe I'm doing something more complex than a specific app that wants Root permissions. I'm checking logs, adding/removing packages or whatever else; stuff that when added up makes more sense to do through a full Root session. I'm still logged in as User with console/X/GUI all limited to User's permissions so I open a terminal window (xterm, konsole, cmd.com, powershell.. same idea; cli inside a window). I then su to Root; only that little console session inside the terminal window is Root. The rest of my session is still User.
(
User@login(
User@cli(
User@GUI(
Root@cli
)
)
)
)
Root is a bubble contined inside the user login. Only Root inside that bubble has Root access. Only what I run inside that Root cli runs as root.
(
Root@login(
Root@cli(
Root@GUI(
Root@cli
)
)
)
) "su" and enter your administrator password when prompted. It's amazing how much you can do without login an existing user out of the machine. (msiexec is a very nice .MSI package manager)
Thanks Neon!
Being a noob, I have another question: I am pretty sure it will be a while before I am comfortable managing logical volumes at the command line, so I have been using the Gnome graphical LVM. I'm just guessing, but my guess is that it would need root access to set up or manage logical volumes.
How do you do that from a cli? I know that in XP if I run a program that requires a GUI by entering its name at the command line it will just run in the GUI. I don't think that happens with linux, does it?
Being a noob, I have another question: I am pretty sure it will be a while before I am comfortable managing logical volumes at the command line, so I have been using the Gnome graphical LVM. I'm just guessing, but my guess is that it would need root access to set up or manage logical volumes.
How do you do that from a cli? I know that in XP if I run a program that requires a GUI by entering its name at the command line it will just run in the GUI. I don't think that happens with linux, does it?
In generic terms, you probably want to look at Gparted which is a disk partition tool similar to Partition Magic. It will be available in the add/remove if it's not installed by default. When I run it from my program menu as a regular user, it prompts me for a password to run it as Root. (This may be a Debian 6 specific setting but I would expect Ubuntu to do something similar if not the same)
Caveat; your working with file partitions here and *nix does not like to work with mounted file partitions since you never know what other users may be working with that partition. Gparted and similar tools do not like to work with mounted partitions.
I think what you actually want to do is get the Parted Magic or Gparted liveCD. Boot from that, it'll load into a GUI desktop with a gparted icon or it'll auto-start gparted for you. Since your running from the liveCD rather than what's installed on the hard drive, you can mess with partitions all you like.
Remember that with any OS, messing with partitions is asking for something to break. Be sure you have backups of anything you can't reinstall.
If you want to work from the command line specifically then look at the basic Fdisk or the more complex Parted tool. Parted is the tools that works behind the Gparted GUI front end and Fdisk is the old-school tool.
To be honest, I liked Mandriva's partition tool enough that for years I'd simply boot the Mandriva Free install DVD and walk through it until the partition manager. Once the HDD was setup, I'd cancel out of the Mandriva install and start over with whatever OS I intended to install on those freshly created partitions.
Caveat; your working with file partitions here and *nix does not like to work with mounted file partitions since you never know what other users may be working with that partition. Gparted and similar tools do not like to work with mounted partitions.
I think what you actually want to do is get the Parted Magic or Gparted liveCD. Boot from that, it'll load into a GUI desktop with a gparted icon or it'll auto-start gparted for you. Since your running from the liveCD rather than what's installed on the hard drive, you can mess with partitions all you like.
Remember that with any OS, messing with partitions is asking for something to break. Be sure you have backups of anything you can't reinstall.
If you want to work from the command line specifically then look at the basic Fdisk or the more complex Parted tool. Parted is the tools that works behind the Gparted GUI front end and Fdisk is the old-school tool.
To be honest, I liked Mandriva's partition tool enough that for years I'd simply boot the Mandriva Free install DVD and walk through it until the partition manager. Once the HDD was setup, I'd cancel out of the Mandriva install and start over with whatever OS I intended to install on those freshly created partitions.
Actually. I'm using the Logical Volume Manager to set up space for Guest OSs and to set up the volumes on the RAID array.
Wouldn't SELinux have a mitigating effect on logging in as root? (Though you have convinced me that I should just set up a user account and su/sudo as needed.)
CentOS uses Gparted during the graphical install (I think) and it was very handy. I put my OS in its own Volume Group and Logical volume. I like that I can add to it if I need more space. I don't have to try to guess how much space I'm going to need in two years. For a first time user/admin that is great.
Wouldn't SELinux have a mitigating effect on logging in as root? (Though you have convinced me that I should just set up a user account and su/sudo as needed.)
CentOS uses Gparted during the graphical install (I think) and it was very handy. I put my OS in its own Volume Group and Logical volume. I like that I can add to it if I need more space. I don't have to try to guess how much space I'm going to need in two years. For a first time user/admin that is great.
I almost never go to the Admin account for anything anymore, as it is so easy to simply right click the application I want to update or modify and run as admin. I don't even bother to go to the administrative side to install programs. It is so much easier to give the UAC the password, and much less hassle that switching users, or logging off and on all the time.
The only thing that bothers me is malware taking over the console of something I've just given admin privileges to, while I'm working with it. I always run CCleaner to get rid of at least temporary files before such duties, and I may update MBAM and AdAware too, while I'm at it.
As soon as I'm done, I close the program, and then open it again for regular use. This way it is on the standard account settings again.
The only thing that bothers me is malware taking over the console of something I've just given admin privileges to, while I'm working with it. I always run CCleaner to get rid of at least temporary files before such duties, and I may update MBAM and AdAware too, while I'm at it.
As soon as I'm done, I close the program, and then open it again for regular use. This way it is on the standard account settings again.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle

































