Linux optimize

Video: Five tips for improving Linux security

Bill Detwiler shares five tips for improving Linux security, such as not logging in as root and using keyring.

As its advocates will remind you again and again, Linux is a very secure operating system. But that doesn't mean you should get complacent and ignore fundamental security measures. During this week's TR Dojo episode, I share five tips for improving Linux security.

For those who prefer text to video, you can click the Transcript link that appears below the video player window or check out Jack Wallen's article, "Five tips for improving Linux security."

You can also sign up to receive the latest TR Dojo lessons through one or more of the following methods:

About

Bill Detwiler is Managing Editor of TechRepublic and Tech Pro Research and the host of Cracking Open, CNET and TechRepublic's popular online show. Prior to joining TechRepublic in 2000, Bill was an IT manager, database administrator, and desktop supp...

31 comments
kama410
kama410

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? (

Neon Samurai
Neon Samurai

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.

tbmay
tbmay

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.

Sensor Guy
Sensor Guy

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.

register
register

No video player. Where is the video? (using Firefox 3.6.12)

Bill Detwiler
Bill Detwiler

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

saghaulor
saghaulor

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.

Bruce Epper
Bruce Epper

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.

Slayer_
Slayer_

If that crap happens to my computer, I hand it to someone else :)

mousejn
mousejn

Security through obscurity. Linux has about 1% of Internet activity. The cyber criminals go after the fattest target.

Neon Samurai
Neon Samurai

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"

Bill Detwiler
Bill Detwiler

If you're using NoScript or Adblock, you may need to add exceptions for TechRepublic to see the video player.

auogoke
auogoke

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

kama410
kama410

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.

Neon Samurai
Neon Samurai

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.

Neon Samurai
Neon Samurai

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.

saghaulor
saghaulor

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.

Neon Samurai
Neon Samurai

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.

tbmay
tbmay

...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.

kama410
kama410

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.

JCitizen
JCitizen

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.

Neon Samurai
Neon Samurai

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.

kama410
kama410

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?

Neon Samurai
Neon Samurai

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 ) ) ) ) Root is the login session. Everything that runs after the login prompt is now running as Root. Buffer overflows are automatically running code as Root. Bugs enable exploits or DOS with Root permission. Malicious code has system wide access as Root. A security issue in any part of the userland, X or graphic desktop is automatically a Root level breach. In the first case, I use "deny all, permit only required". The proactive approach. The minimum amount of Root permissions needed exists within that xterm su session; the rest runs as normal user since it has no valid reason to run as Root. I assume that there is something bad trying to do bad things and limit the potential for that bad thing to work. In the second case, I use "allow all, deny some". The reactive approach. I'm assuming that everything on the system is coded perfectly with no bugs and no third party trying to break into my machine. I'm implicitly trusting all the code that runs behind a normal user login; all the parts that make up KDE, all the parts that make up X, all the console userland running on top of the kernel. This habit extends to Windows also. With Win7 it should be obvious thanks to it's better RunAs type implementation. I log in as user and only give admin/passwd credentials if a task requires. WinXP; create a text file "su.cmd" in \Windows or some other %path% location. Inside the text file: @echo off runas /user:administrator "cmd /T:0C /K cls" exit After that, [start] -> [Run] -> "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)

seanferd
seanferd

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...

Neon Samurai
Neon Samurai

Compared to "do not show known file extensions" enabled by default, "automatic reboot on error" seems completely rational. :D 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.

seanferd
seanferd

is idiotically set as the default behavior.

Neon Samurai
Neon Samurai

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.

JCitizen
JCitizen

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.