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

4 of 30 comments (clear)

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