Slashdot Mirror

← Back to Stories (view on slashdot.org)

Securing Linux Production Systems

Posted by timothy on from the checklist-of-checklists dept.

robyannetta writes "Securing Linux Production Systems: A Practical Guide to Basic Security in Linux Production Environments is a practical step-by-step guide for securing Linux production systems. It shows how to meet basic security requirements for Linux systems that need to pass security audits. If you have been assigned to come up with a corporate Linux Security Standard, then you should definitely read on."

30 comments

  1. Other interesting stuff by larry2k · · Score: 1, Informative

    If you'll read de above article maybe you'll find interesting this: http://www.securityfocus.com/tools

    --

    The package said "Windows XP or better. Pentium Class Processor or better"... So I got a Mac with OS X

  2. first p0st! by Anonymous Coward · · Score: 0

    yeah!

  3. / and /boot by BollocksToThis · · Score: 1

    Why are some people so adamant that / and /boot be on different partitions? I'm not saying they're wrong, just that it's never been explained. With usr, var, tmp and home all on different partitions, there's not a hell of a lot left, so what conflicts with the miniscule amount of data in /boot? Is this just a holdover from the bad old days of kernel-under-1024-cylinders-or-bust?

    --
    This sig is part of your complete breakfast.
    1. Re:/ and /boot by Meetch · · Score: 2, Informative
      I'm not sure about before LVM, but now it's in...

      While I'm sure with enough fiddling it can be done, /boot generally doesn't like living in an LVM filesystem. The main reason for that would be the boot loader needs to load extra and interpret the metadata to figure out where the initrd you want is loaded from. I imagine most distros simply won't let you put /boot on a logical volume because it requires too much extra.

      I did manage to get /boot to live happily on a software RAID1 mirrored partition - this was based on a RH 7.3 build, but RedHat won't do that for you by default (do any?).

      Of course, it's not such a problem with proper enterprise storage (but you still can't put boot on an LV, as a rule)...

    2. Re:/ and /boot by ceswiedler · · Score: 1

      Boot can live on a RAID because you really just boot off of one of the devices, right? All the implementations I've heard about revolve around 'boot from hda1, then from hdc1' where hda1 and hdc1 make RAID device md1. Software RAID has the nice property of its component disks being readable even if RAID isn't enabled / running. Grub can't read RAID devices or LVM AFAIK.

    3. Re:/ and /boot by Meetch · · Score: 1
      Yeah, the RAID/md metadata lives at the end of the partitions, which boot loaders generally don't look at. And indeed, LILO has its uses (installing onto hda1 and hdc1 instead of md1 or whatever without disrupting the mirror)

      Of course, again, if you have the luxury of good hardware RAID, then you don't even have to think about this.

    4. Re:/ and /boot by Johnny+Doughnuts · · Score: 1

      So you have the ability to mount /boot ro, or not mount it at all at boot time for extra security from stupid mistakes.

    5. Re:/ and /boot by BollocksToThis · · Score: 1

      Interesting... the thought of not mounting /boot at all had never even occurred to me.

      Mounting it ro doesn't seem as good a reason though, as many people recommend mounting / ro as well (good advice IMO).

      --
      This sig is part of your complete breakfast.
  4. Not that impressed with the list ... by dougmc · · Score: 1
    I wasn't that impressed. Maybe the list is just too simple, but there's several problems with it. A few samples ...
    I would remove at least the CTRL-ALT-DELETE trap entry:

    # sed -i 's/ca::ctrlaltdel:/#ca::ctrlaltdel:/g'
    Um, why? He talks about physical security first, but if the machine is physically secure, why would you care about this entry? Being able to hit CAD is useful ... but I guess you could force somebody to login, su to root, then reboot the box, creating a log trail ... or they could just hit the power switch instead.

    He talks about disabling unused accounts. Which sounds fine, but in modern Linux distributions, those `unused' system accounts are often used for a daemon to switch to after giving up permissions. Removing the account will break things -- something you don't want to do if you don't understand what you're doing. Yes, he does say `if you're sure', but provides little in the way of helping to determine which accounts could be removed.

    As for all the password aging stuff, this is mostly needed to comply with poorly thought out corporate policies and the like. But password policies don't do much to increase security unless you educate your users about the reasons behind it -- otherwise, they'll just write today's password on their desk, or do whatever else they have to do to keep track of the password that you keep changing on them.

    Restricting User Access Based on Time and Day? Does _anybody_ find this to be useful? Does anybody restrict logins based on the time of day?

    Shared Accounts are bad (security-wise), no matter how you look at them. sudo and similar programs are your friends. (But the section about `Restricting su Access to System and Shared Accounts' is good.)

    All in all, it's not a bad list, but he seems to spend a lot more time on passwords than they're worth, and less time on things like keeping patches up to date or educating your users.

    1. Re:Not that impressed with the list ... by Anonymous Coward · · Score: 0

      You are missing an important point about password policies. These policies are very important to force people to change their passwords and not to use easy passwords. Too many accounts are compromised using poor passwords.

      Regarding your statement: "they'll just write today's password on their desk", people don't write the passwords of their own individual accounts on their desk. The usually do this with shared account passwords and the article addresses this problem at 'Restricting su Access to System and Shared Accounts'.

      I'm not sure if there is so much to say about patching servers. You simply have to patch systems.

      A system account that is used by a daemon is not an 'unused' account.

    2. Re:Not that impressed with the list ... by menscher · · Score: 1
      One reason to disable the Ctrl-Alt-Del entry is to prevent accidental reboots. Yes, it can happen. Especially if the admins also manage Windows machines. I now habitually hit CAD while sitting down, simply because I need to do it so often in order to log in or unlock my screensaver on a Windows box. And it would really suck to reboot your server due to such a trivial mistake.

      In any case, what use does CAD serve? You can always become root and type "reboot", right? Unless, of course, the machine is horribly hung, in which case CAD probably wouldn't do you much good anyway.

    3. Re:Not that impressed with the list ... by dougmc · · Score: 1

      A system account that is used by a daemon is not an 'unused' account.

      Well, duh. But when you install a system, it usually comes with a large (and getting larger, as time goes on) list of accounts already installed. How does a newbie (whom the original article was written for) know which are used and which aren't?

      NONE of these accounts can be removed without understanding if they're really used. (And assuming that you installed only the packages that you need, they're probably ALL being used.)

      Years ago, SGIs installed with a few completely open accounts -- 4DGifts, guest and others. (And nevermind the default `xhost +' !) And they got beat up for it, and now this isn't done anymore.

      For example, a FC3 system I recently installed got all these accounts created automatically :

      root bin daemon adm lp sync shutdown halt mail
      news uucp operator games gopher ftp nobody dbus
      vcsa nscd rpm haldaemon netdump sshd rpc rpcuser
      nfsnobody mailnull smmsp pcap apache squid
      webalizer xfs ntp gdm named dovecot

      One is obviously used: root.

      A few had better be disabled, based on their names: shutdown, halt. (sync is similar, but safe enough.)

      A few have been around forever (bin, daemon, adm, others) but it's not obvious if they can be safely removed or not.

      A few are obviously used for daemons to switch to to drop priviledges (gopher (ok, maybe I should remove that package), ftp, nfsnobody, apache, squid, webalizer, ntp, named)

      In any event, it requires quite a bit of experience and work to determine which of these accounts can be removed without breaking anything important. I have the experience, but haven't put in the time -- because I know that the benefits of doing so are pretty minimal, and long as all of these accounts cannot be logged into remotely.

      I'm not sure if there is so much to say about patching servers. You simply have to patch systems.

      Well, sure, at the highest level, yeah. And the entire article could be written as `Keep your system secure!' too. In any event, keeping patches up to date is so very important, especially on a system that provides services to the Internet, that it deserves at least a few paragraphs on how to set it up and automate it. (And yes, if possible, it should be automated.)

      Sorry, but merely saying `disable any unused system accounts' is not enough. And unfortunately, another complete paper could be written on just that subject.

      Regarding your statement: "they'll just write today's password on their desk", people don't write the passwords of their own individual accounts on their desk. The usually do this with shared account passwords

      Oh, yes they do. They also save them in files, or email them to themselves.

      And the more password restrictions you put on them -- forcing changes often, not allowing the use of old passwords (or even passwords related to old passwords), requiring funny characters and capitialization (54g$h@Fe), and the more different passwords you make them memorize, the more they'll do it.

      Ultimately, the main reason behind strong passwords came from the ease of using programs like `crack' to go through one's entire /etc/passwd file and find passwords quickly.

      But with shadow passwords becoming ubiquitous and servers dedicated to one purpose becoming the norm rather than the exception, and computers that can crack _every possible_ 8 character password (via huge banks of ASICs I believe) in mere days (have they done the same with md5sums yet?) things have changed. Now, it's much harder to get the `passwd file', and if you do, it's pretty much game over, even if everybody has totally random passwords.

      Yes, some restrictions on passwords are good things (require at least X characters, don't allow single words, things from your gcos field, etc.) but at some point,

    4. Re:Not that impressed with the list ... by Anonymous Coward · · Score: 0

      He talks about disabling unused accounts. Which sounds fine, but in modern Linux distributions, those `unused' system accounts are often used for a daemon to switch to after giving up permissions. Removing the account will break things -- something you don't want to do if you don't understand what you're doing. Yes, he does say `if you're sure', but provides little in the way of helping to determine which accounts could be removed.

      Actually, the article does provide some help by suggesting the find command:

      "All system or vendor accounts that are not being used by users, applications, by the system or by daemons should be removed from the system. You can use the following command to find out if there are any files owned by a specific account:
      # find / -path /proc -prune -o -user -ls"

      I think this is not a bad starting point.

    5. Re:Not that impressed with the list ... by dougmc · · Score: 1
      You can use the following command to find out if there are any files owned by a specific account:
      ...
      I think this is not a bad starting point.
      Yes, it is a bad starting point. Because merely not finding any files does not mean that you can safely remove the account. Most system accounts don't own any files. (root and bin (though I forgot the purpose behind bin long ago) are the big exceptions.)

      This is really only useful if you've just removed a user account and want to remove any files he had (because they may not all be in his home directory.)

  5. Firewall? by BladeMelbourne · · Score: 2, Insightful
    Funny how Werner added the following after reading our comments here:

    I will not cover iptables in this paper. The reason is because most companies use hardware based firewalls to protect the servers in their production network. And this is usually being taken care of by another team and not by Linux systems administrators. If you are interested in a Linux Stateful Firewall using iptables, you might want to check out my instructions at Linux Stateful Firewall & IP Masquerading.

    Werner made somewhat incorrect assumptions in that little paragraph.

    iptables is an extra security measure I highly recommend - even on networks with hardware firewalls.

    It is unwise to lock the security screen door but leave the front door unlocked when you are not home.

    It's also intersting to note the following at the bottom of the page:

    Copyright © Notice
    This article may not be published, sold, reproduced or copied in whole or in part without obtaining permission first. But you are welcome to put links from your site to the article.

    If Werner is going to claim copyright, he should state his sources - there is very little chance that he wrote every word. --Mike

    1. Re:Firewall? by Meetch · · Score: 1
      If Werner is going to claim copyright, he should state his sources - there is very little chance that he wrote every word.

      There is every chance, actually. I've read some of Werner's Oracle installation stuff - it's very much "what I learnt bashing my head against all these problems" digested relatively neatly into a pseudo-howto. From what I've seen he generally writes from experience (or his notes), and hiss mis-steaks are hiss onw. ;)

      Good Stuff Werner. I wish I had this when I was setting up our last RAC cluster - would have saved me many hours!

    2. Re:Firewall? by caseih · · Score: 2, Interesting

      There is almost no reason to run iptables on production servers if you've followed all the correct steps. Remember that iptables is not an application-level firewall and as such cannot do anything to protect your server. That is because you want your server to serve stuff. No iptables firewall can protect you from bad guys exploiting your services that you exposed intentionally! Instead you should disable every service that you don't want to expose to the outside world. In some cases, like sendmail, you have services you need internally to the server itself and so you bind them to localhost. My server is live on the internet and runs no firewall. Every port open on it (http, https, pop3, imap, smtp) is open because I want it open. It would be mostly pointless to turn on iptables. The only case I can see iptables being useful is to restrict the source ip address for ssh.

    3. Re:Firewall? by Spoing · · Score: 1
      1. iptables is an extra security measure I highly recommend - even on networks with hardware firewalls.

      Why?

      1. It is unwise to lock the security screen door but leave the front door unlocked when you are not home.

      What you say is phrased as if it is wisdom, though I can't think of a technical or practical reason for it.

      If the machine is a server, you've already stripped it down to the base functions, audited it, and know just how it could be exploited.

      You know that most of those methods are social not technical.

      You know the remaining ones -- if any -- are imposed by management.

      You know that a firewall that plugs any remaining hole will anger the manager(s)...so you let that traffic through.

      So...how will a firewall help? It looks like comfort food to me.

      --
      A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
    4. Re:Firewall? by Anonymous Coward · · Score: 1, Informative

      I'm the author of this article. Someone just emailed me that the article was posted here.

      Your assertion is simply incorrect. You seem to have too much time to make other people look bad. When this article was posted on osnews I got emails from people about why I didn't cover iptables. I realized that I should have explained my reasoning behind this which prompted me to add a note. My experience is that hardware based firewalls are used for production systems/networks and not iptables. And just because someone posted a similar opinion on osnews doesn't mean that I used his idea. You shouldn't make this kind of assertion about other people. There are simply other people who agree with me or probably just have read my updated note.

      Unfortunatelly, when I wrote my first Oracle article people copied the whole article, some even removed all links and my name. This prompted me to add the copyright notice.

      Werner

    5. Re:Firewall? by Phleg · · Score: 1

      You can limit outgoing connections with iptables, too. For instance, only allowing outbound traffic to IPs on an internal "safe" network, and for the ports on which you have applications being served. Assuming they're low port numbers, only root can bind those. If someone is able to break in through a non-privileged service, they won't be able to get a shell over a random high port, or over ICMP traffic.

      --
      No comment.
    6. Re:Firewall? by caseih · · Score: 1

      Very true. Most server setups I know of, though, have a hardware firewall that creates a DMZ. I think in this case a hardware firewall (a separate dedicated box) does a better job of this. Besides if someone compromises a box with iptables running on it, they simply have to turn them off. Obviously they'd have to get root, but if they've compromised a service it won't be long until they have root. Of course SELinux will make a huge difference here.

    7. Re:Firewall? by Anonymous Coward · · Score: 0
      What complete rubbish.

      Say you had one server running Apache, and another running MySQL or PostgreSQL. They are both firewalled from the internet, and only port 80 is allowed through to the Apache box, all other ports are secure.

      Now say an exploit was found in Apache... allowing a user to modify PHP files, become root, execute some perl,etc., it would be possible to compromise the DB server. This is preventable if iptables was configured on the DB server, allowing only DB traffic from the Apache webserver. The chance of an unpatched Apache exploit and an unpatch PostgreSQL exploit simultaneously is low.

      If the machine is a server, you've already stripped it down to the base functions, audited it, and know just how it could be exploited.
      This is indeed true, however just knowing how one of your servers could be explited whilst not taking every possible precaution is not enough. Stopping all but the needed services is not enough. SSH/FTP may be open to allow remote adminitration/software updates/content updates. No software/service is perfect (SSH a while ago), security issues do exist, even if they have yet to be found. Russian Roulette if your servers aren't protected from each other...

      Only one public service (http, etc) behind the internet-firewalled servers needs to be compromised, and the other servers can be compromised too.

      iptables isn't just useful in dropping packets to unused ports, or giving IP based permissions to machines that should be able to gain access. It also protects servers from compromised servers on the same network.

      You know that most of those methods are social not technical.
      You can't control the social behaviour of others. All you can do is secure you property and hope for the best. If you don't, it's only a matter of time.

      I'm glad you are not an admin of my servers or those at my company.

    8. Re:Firewall? by Spoing · · Score: 1
      Back at you. I don't see anything in your response that is aided by a firewall. Proper setup of the services and isolation of the web/db/... severs from each other would do the trick. The firewall wouldn't do jack extra.

      As for your Apache example...the web server itself is both stable and secure. The apps on it have to be chosen with care, though. One of the reasons why I try and stay away from PHP apps...they tend to have poor default security. (Not all PHP, though I've noticed it too many times to give a PHP app an early nod.)

      --
      A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
    9. Re:Firewall? by aminorex · · Score: 1

      Several historical exploits have involved sending packets which were not handled by any user-space process, but rather directly by the kernel. Netfilter can be used to drop those packets rather than processing them. Far less kernel code runs in a manner dependent upon the structure and content of the packet if it is immediately recognized as a DROP or REJECT case. This means there is less opportunity to exploit kernel defects.

      --
      -I like my women like I like my tea: green-
  6. Historical by A+nonymous+Coward · · Score: 1

    LILO used to require the boot image be within the first 1024 cylinders I think. So /boot was /dev/hda1 and small enough to guarantee the entire partition was within the safe range. Otherwise, as you installed new versions of the kernel image, it would eventually migrate away from the safe range.

    --
    Infuriate left and right
  7. Roles, anyone? by neonfreon · · Score: 2, Insightful

    Am I missing something here or does this paper totally ignore the fact that in the real world, what you can do to secure a system depends on what you want the system to do.

    A secure system is great, but it is totally pointless if the server doesn't serve a function. Securing a system should always start with defining what exactly the system needs to do, so that you can know what exactly it doesn't need to do, as securing a system equates to eliminating possible security risks that aren't essential to system functionality.

    For example, the paper's section on SUID/SGID binaries says that they can be dangerous, but doesn't inform the reader as to which SUID/SGID binaries are necessary to perform different tasks. This information is thus not very useful to kind of person that could potentially benefit from this paper, because the kind of person that doesn't know SUID/SGID bits can be dangerous will most likely not know which SUID/SGID bits can be safely removed.

    1. Re:Roles, anyone? by Anonymous Coward · · Score: 0

      A secure system is great, but it is totally pointless if the server doesn't serve a function. Securing a system should always start with defining what exactly the system needs to do...

      The article mentions this:
      "Patching Linux Systems and Limiting Software Packages (RPMs)":
      A very important step in securing Linux systems is to determine the primary purpose. It is, therefore, very critical to remove unneeded software. This can take some time but the more software you remove from the system, the less likely exploits can be found that require patches".

  8. mistake by passthecrackpipe · · Score: 1

    he writes about "Securing Sendmail". and then launches into a howto. He got that wrong, as it should have read: "Install Postfix"

    --
    People who think they know everything are a great annoyance to those of us who do.
    1. Re:mistake by Anonymous Coward · · Score: 0

      By default, sendmail is only listening for local connection. There is no problem with that. Only if you use sendmail as a relay server, then it becomes an issue.

  9. CERT checklist by data64 · · Score: 1

    In addition to the guide above, remember to also look at the CERT security checklist for unix machines. http://www.cert.org/tech_tips/AUSCERT_checklist2.0 .html