How to lock down Linux

How to lock down Linux

Summary: Any operating system can be cracked if you don't adequately protect it. Yes, even Linux. Here are some security basics on how to protect your Linux systems.

SHARE:

Linux is, by design, a very secure operating system, but so what? You can have the best security system in the world on your house, but if you leave your front-door open anyone can still walk in. Even people who know better, like Linux kernel developers, blow it sometimes. That's what happened to the Linux Foundation's constellation of sites. Multiple important Linux sites were down for weeks and as of October 3rd, kernel.org is still down. This doesn't have to happen to you. Here are a few simple suggestions from me, and some more advanced ones from Greg Kroah-Hartman, one of Linux's lead developers.

First, here are some rules that everyone should know. Number one with a bullet is security expert Bruce Schneier's mantra, "Security is a process, not a product." I don't care that your server was Fort Knox, two weeks ago, if you haven't updated your system with the latest security patches, checked to make sure your users haven't started running a porn Web server, and looked over your network logs to see if someone or something isn't up to mischief then you can't trust your system today.

In addition, as Kroah-Hartman wrote, "it is imperative that nobody falls victim to the belief that it cannot happen to them. We all need to check our systems for intrusions." And, I might add, we need to keep doing it all the time.

Therefore, make darn sure that your root password, which should really be a passphrase, not a password, isn't been being used by anyone than you. If your users really need fuller access than they usually get to the system, provide them with sudo access.

Thinking of users: Lock them down. Give them only as much permission and access as they absolutely must have. If it turns out they need access to say a group file directory give it to them after they've shown a need for it, not before. While you're at it, set their home directories to be encrypted.

Moving on to the network, every system connected to the Internet needs a firewall set up to, once again, give users the absolute minimum of needed access. If someone doesn't need to use a network port, that port should be blocked. Period. End of statement.

That's all security 101 stuff. Kroah-Hartman gets into more technical detail. Still, what he's suggests doesn't require you be some kind of security ninja. You just need to know and practice some Linux administration basics.

For starters if you have any suspicion that your system has been compromised Kroah-Hartman suggests that you need a clean install of your operating system. If, you have everyone's home directories in a separate home partition-which you should-you can reinstall your operating system during an idle period and no one will even be the wiser that everything has been refreshed.

After that, Kroah-Hartman suggests that you "verify that your package signatures match what your package manager thinks they are. To do this on a rpm-based system, [such as Red Hat or openSUSE] run the following command:

rpm --verify -all

"Please read the rpm man page for information on how to interpret the output of this command." On Debian-Linux based systems, such as Mint or Ubuntu, it's more complicated. From a Bash shell you need to run the following:

dpkg -l \*|while read s n rest; do if [ "$s" == "ii" ]; then echo $n; fi; done > ~/tmp.txt for f in `cat ~/tmp.txt`; do debsums -s -a $f; done

Let's say you find a program that smells funny, you'll want to get rid of it and install a fresh version. To do this, stop the program from running with, using the Secure Shell (ssh) daemon, with the following command:

$ /etc/init.d/sshd stop

and then re-install the suspect program.

You should also get into the habit of not just glancing over your startup scripts and system logs from inside your operating system--You are already doing that right? Right!?--but taking your system down, rebooting it with a live CD Linux distribution, and checking for rogue start-up scripts and odd log entries. For this kind of work, I prefer to use a Linux distribution like SystemRescueCd, which are designed for repair work, to look a system over for problems. You can use any live CD distribution though and if you're happy with your main Linux, there's no reason not to say use a live Ubuntu USB-stick or CD to over an Ubuntu system.

If you do all this, well you can still be cracked if an expert is targeting you, but you'll be a lot safer from run-of-the-mill crackers and their automated programs. Good luck and stay safe out there. Even for Linux users, it's a dangerous old Internet out there.

Related Stories:

The Air Force's secure Linux distribution

Some Linux Foundation crack attack details emerge

Hackers break into Linux Foundation

If you have a mysterious problem with a Linux box, try bashing your system with sys_basher

What is a hacker?

Topics: Security, Linux, Open Source, Operating Systems, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

93 comments
Log in or register to join the discussion
  • Overconfidence is the real issue

    The real issue is overconfidence of the Linux community. People like Steven have played the ???Linux is secure by design??? card for so long it lulled the Linux users to sleep, leaving them vulnerable to the hackers that are taking notice.

    Kernal.org down? These are the best in the business but their hubris left them open to attack. What chance does the average Linux hack have to secure the OS? Not much if the Kernal.org types can???t get it right.

    For Steven to publish an article like this indicates that hackers are taking notice, the Linux community is asleep at the switch and it???ll only get worse as time goes on.

    Welcome to the real world, you???d better wake up and upset your users with real security, just like the Windows world.
    Cynical99
    • RE: How to lock down Linux

      @Cynical99
      As prof.ebral commented in a reply earlier. Even if the o/s is secure, doesn't mean the software running under it is secure. And hackers have taken notice.
      mheartwood
      • Still does not explain

        @mheartwood
        How was kernel.org *rooted*?? A SQL injection or a weak or compromised password - that one I can understand.

        But how on E can any of these lead to a <i>total system compromise</i> as in the case of both kernel.org and Linux Foundation?

        Simple. Some other weakness have been in play. And Linux has *plenty* such weaknesses.

        One is the <i>stupid</i> SUID utilities such as sudo. One weakness in a utility run through sudo and the attacker is *root*. Why? Because Linux <i>does not allow anyone but root to execute privileges operations</i>. So, to change password you are temporarily elevated all the way to root.

        Stupid Linux security architecture.
        honeymonster
      • RE: How to lock down Linux

        @honeymonster

        What's better? Not being a smartass, just want to hear what you think is a better model.
        thebaldguy
      • Role Based Access Control (RBAC)

        @mheartwood: [i]What's better? Not being a smartass, just want to hear what you think is a better model.[/i]

        Such as that implemented in Solaris.
        ye
      • What better?

        @thebaldguy
        Actual <i>privileges</i> which can be <i>delegated</i> would go a long way. Need to allow some users to change timezone? Give them the right to do it. Need to allow some users to shutdown or reboot? Give them the right to do that.

        The stupid Linux (and Unix) model is to grant the users <i>execute</i> right on an executable which will run as godda** <b>root</b> while performing the task. Countless vulnerabilities which would otherwise have been benign have allowed Unix/Linux systems to be rooted this way.

        Better yet, grant the rights to users (not to utilities) *and* let the executable declare it's needed <i>capabilities</i> in its manifest. For certain powerfull capabilities the OS can then inquiry the user whether he really thinks this fancy desktop background utility should be allowed to take ownership of any file on the system.
        honeymonster
      • Sounds like Linux capabilities to me...

        @honeymonster<br>This man page dates capability support back to the Linux 2.2 era. That's pre 2000, by my reckoning:<br><br><a href="http://linux.die.net/man/7/capabilities" target="_blank" rel="nofollow">http://linux.die.net/man/7/capabilities</a>
        Zogg
      • RE: How to lock down Linux

        <i>How was kernel.org *rooted*?? A SQL injection or a weak or compromised password - that one I can understand.</i><br><br>And your point? That anything can be hacked using a weak password? Well no doh, genius.<br><br><i>But how on E can any of these lead to a total system compromise as in the case of both kernel.org and Linux Foundation?<br><br>Simple. Some other weakness have been in play. And Linux has *plenty* such weaknesses.</i><br><br>Well you're supposed to be the smart guy. You <b>tell us</b> what happened.<br><br><i>One is the stupid SUID utilities such as sudo. One weakness in a utility run through sudo and the attacker is *root*. Why? Because Linux does not allow anyone but root to execute privileges operations. So, to change password you are temporarily elevated all the way to root.</i><br><br>As opposed to somebody ignoring UAC and running an executable off the desktop? Given also that the executable bit is turned on by default in Windows? That many still run Windows using an admin account for their daily business?<br><br>The SUID bit is designed by a Linux administrator to temporarily run scripts that elevate users into a superuser status in order to do <b>certain things</b> that <b>only the Linux administrator will allow them to do.</b> It's just another layer of user privileges granted by the domain admin and only through the domain admin. <b>It's only used judiciously in certain situations and needs to be monitored.</b> If it's not monitored correctly then that's human failure, not OS failure. The same kind of scenario mentioned up above with weak passwords. <br><br><i>Stupid Linux security architecture.</i><br><br>Nothing stupid about it all if it's practiced correctly. Maybe you should use it sometime. Know what you're talking about.
        ScorpioBlue
      • RE: How to lock down Linux

        @Zogg
        Yeah, Linux <i>attempted</i> to put in capabilities - which would be akin to Windows privileges.

        Only - it doesn't work. So no distribution uses them. The *main* problem (there are more) is that the file systems does not support flagging files with capabilities, which would be necessary to circumvent the root requirement.

        @ScorpioBlue
        The <i>point</i> is that even if a user with access to a system has his password cracked - it should NOT allow total system compromise. Get it? That is what happened to kernel.org. Users with <i>ordinary</i> user rights to the system, not <i>root</i> access, had *their* systems compromised. And the attacker jumped from there to compromising the entire kernel.org. That is total system compromise through an ordinary user account. Bad. Really bad.

        You need to educate yourself on how UAC works. Even if a user logs in with an account with admin privs, he is not <i>running</i> as an admin. That is a big difference between Windows and Linux: Windows actually has a meaningful token representing the <i>subject</i> (i.e. the process), while Linux *can only* represent actual users on the system through the effective user-id.

        Windows will warn you before launching an executable downloaded from the Internet or received through mail. On top of that you need to accept yet another time to run with elevated privs.

        The SUID bit elevates the process to <i>root</i>. Instead of granting rights to specific intrinsic functions (Windows style), in Linux you grant the user right to run a process with <i>total system privileges</i> and hope the process doesn't go astray. This is a long standing issue, duly recognized by the kernel developers. Only the fanbois don't get it yet.
        honeymonster
      • Sorry Honey, you're wrong...

        @honeymonster<br>I'm guessing you googled for "Linux capabilities" last night and found something that said Linux filesystems didn't support them, but forgot to check that document's date... ;-).<br><br>FYI, here is what "man capabilities" says on my Fedora 15 box:<br><i>"Since kernel 2.6.24, the kernel supports associating capability sets with an executable file using setcap(8)."</i><br><br>This is just the current "state of play". The initial filesystem support was being implemented way back in 2002:<br><a href="http://lwn.net/Articles/14303/" target="_blank" rel="nofollow"><a href="http://lwn.net/Articles/14303/" target="_blank" rel="nofollow">http://lwn.net/Articles/14303/</a></a><br><br>And yes, Fedora 15 is using this:<br>$ ls -als /bin/ping<br>40 -rwxr-xr-x. 1 root root 39344 Feb 9 2011 /bin/ping<br>$ getcap /bin/ping<br>/bin/ping = cap_net_raw+ep
        Zogg
      • RE: How to lock down Linux

        [i]The point is that even if a user with access to a system has his password cracked - it should NOT allow total system compromise. Get it? That is what happened to kernel.org. Users with ordinary user rights to the system, not root access, had *their* systems compromised. And the attacker jumped from there to compromising the entire kernel.org. That is total system compromise through an ordinary user account. Bad. Really bad.[/i]

        And how do you know [b]that's[/b] what happened? You still haven't given us any proof that that is what happened.

        [i]You need to educate yourself on how UAC works. Even if a user logs in with an account with admin privs, he is not running as an admin. That is a big difference between Windows and Linux: Windows actually has a meaningful token representing the subject (i.e. the process), while Linux *can only* represent actual users on the system through the effective user-id.[/i]

        In UAC you get a pop up window asking "Do you want to allow the following program to make system changes to the computer". Or it will ask "A Program Needs Your Permission To Continue". Hit Continue or Cancel. The end user blindly hits continue or cancel without even entering a password and the damage may or may not be done as a result. That is what the end user will see as far as UAC goes or not and depending upon how annoying it is, they may just wind up disabling it. Or you can right mouse click it and run all your programs as an administrator using and administrator's password. But if you haven't set up a user account ahead of time to take advantage of this, then that's all a waste of time.

        [i]The SUID bit elevates the process to root. Instead of granting rights to specific intrinsic functions (Windows style), in Linux you grant the user right to run a process with total system privileges and hope the process doesn't go astray. This is a long standing issue, duly recognized by the kernel developers. Only the fanbois don't get it yet.[/i]

        Only to that particular process or folder. Did I not emphasize that enough up above? I even [b]bold-faced[/b] those points for you so you wouldn't miss it. Go back and read it again if you have to.
        ScorpioBlue
      • RE: How to lock down Linux

        @honeymonster

        I did not see anyone mention this on the first page of replies to you, but you obviously don't have a lot of experience with Linux. I don't have a lot of linux experience, and even I know that SUDO can be setup to ONLY allow access to specific tools, you can give one user (or group) sudo rights to to change network settings, but nothing else, while another user (or group) only has access to restart services, this is called least level of privileges. Try searching for the man pages for sudo and learn how to use it. No enterprise in their right minds would allow a new hire sys admin full root access via sudo on their servers.

        If a linux server was hacked it was because somewhere at some time a bad security decision was made. maybe the "normal user" used to be on an admin team and moved to a new job... who knows, they won't tell us. All the security you need is there, you just have to learn how to use it.

        On a side note I do agree they need a newer default file system for linux...
        aiellenon
    • RE: How to lock down Linux

      @Cynical99

      And since when did the average user start running a server instead of a desktop?
      And what are these real security concerns for me as a Linux desktop user? viruses? if so then where are they?
      guzz46
      • Funny, I never said &quot;User&quot;

        @guzz46
        I said "Hack" as most Linux system admins are pretty much hacks. They barely scratch the surface of the OS because their knowlege is so limited.

        Again, if Kernal.org can't secure their web sites and servers, what chance does the average Linux hack have? Answer, not much.
        Cynical99
      • RE: How to lock down Linux

        @Cynical99

        I see, well I'm not running a server so I guess I need not worry.

        Actually this article should really be renamed to How to lock down a Linux server.
        guzz46
      • Not really

        @guzz46 wrote:<br>"Actually this article should really be renamed to How to lock down a Linux server. <br><br>From the article:<br>"Thinking of users: Lock them down.<br><br>This article, such as it is, appears to be aimed at organizations utilizing Linux servers, Linux desktops or both. Linux sysadmins manage servers, desktops and users in an organization. (Just like Windows sysadmins do.)<br><br>The article completely missed the decentralized nature of kernel.org where the kernel devs are more like telecommuters and satellite offices. Some kernel devs work at corporations (e.g., Red Hat, SUSE, IBM, Oracle), while others work from home. Thus, the security policy for kernel.org needs to address the kernel devs, colocated machines (remember the colocated machine that was also hacked?) as well as the kernel.org site. This includes the desktop, laptop and netbook PCs that the kernel devs use to access the kernel.org site and colo machines.

        Just to drive this home, see the following link (an email from Greg KH to the kernel devs) that was not included in this article:

        https://lkml.org/lkml/2011/9/30/425

        And find the following, "some developers, at least, have had their systems penetrated", in the first paragraph.
        Rabid Howler Monkey
      • Yea really

        @Rabid Howler Monkey

        The article appears to be aimed at servers and people running the servers, not desktops and desktop users, desktop users generally don't need to worry about someone hacking their PC, Ubuntu doesn't even have any open ports.
        Desktop users main concern are viruses/malware, the kind that plaque windows, but are basically non existent on Linux .

        And the link you gave doesn't really prove anything as it didn't give any details at all, there was no mention of a home machine anywhere.
        guzz46
      • &quot;Ubuntu doesn't even have any open ports.

        @guzz46 Ubuntu may be the most popular of the Linux desktops, but it's not the only one. However, since you brought it up:

        http://www.rationallyparanoid.com/articles/ubuntu-10-lts-security.html

        Search for "Display a list of services that are currently listening" and you will find some open ports. On my HP laptop when I last ran Ubuntu, there was also an open port for hplip? (for printing). This same laptop is now running a Debian desktop and there was an open port for exim which I have since closed.

        Ubuntu has a lot fewer open ports than Windows to be sure, but your information is just plain wrong. Add to this that the ufw firewall is not enabled by default in Ubuntu.
        Rabid Howler Monkey
      • RE: How to lock down Linux

        @Rabid Howler Monkey

        https://wiki.ubuntu.com/Security/Features
        http://www.psychocats.net/ubuntu/security#firewallantivirus

        "By default, Ubuntu ships with no open ports on public interfaces. In other words, a "port scan" would show all closed ports, nothing open. As a result, putting up a firewall would provide no more security than not putting one up"

        I also run debian and I scanned for open ports and there is none.
        guzz46
    • RE: How to lock down Linux

      @ScorpioBlue

      "In UAC you get a pop up window asking "Do you want to allow the following program to make system changes to the computer". Or it will ask "A Program Needs Your Permission To Continue". Hit Continue or Cancel. The end user blindly hits continue or cancel without even entering a password and the damage may or may not be done as a result"

      Unless the malware bypasses UAC altogether.
      http://www.zdnet.com/blog/security/windows-7s-default-uac-bypassed-by-8-out-of-10-malware-samples/4825

      UAC is hopeless, when I was running windows 7 I got UAC prompts just from opening DVD Decrypter, I don't see how a user is supposed to know what is potentially dangerous when UAC pops up just from opening an application, its like the boy who cried wolf, and just as you said it just becomes an annoyance.

      And I wonder if honeymonster can explain how malware such as TDL-4 can infect the MDR in windows 7 if the user isn't running as admin.
      I know if I need to modify some system file in Linux I won't be able to do it without logging in as root or knowing the sudo password.
      guzz46