Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Software Linux

Securing Linux Production Systems 30

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Securing Linux Production Systems More

Securing Linux Production Systems

Comments Filter:

  • Other interesting stuff (Score:1, Informative)

    by larry2k ( 592744 ) *
    If you'll read de above article maybe you'll find interesting this: http://www.securityfocus.com/tools
  • 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?

    • Re:/ and /boot (Score:2, Informative)

      by Meetch ( 756616 )
      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 - th

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

    • So you have the ability to mount /boot ro, or not mount it at all at boot time for extra security from stupid mistakes.
      • 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).
    • 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.
  • 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 h

    • 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 h

  • Firewall? (Score:3, Insightful)

    by BladeMelbourne ( 518866 ) on Monday January 17, 2005 @07:26PM (#11390591)
    Funny how Werner added the following after reading our comments here [osnews.com]:

    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 [puschitz.com].

    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

    • 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 la

    • Re:Firewall? (Score:3, Interesting)

      by caseih ( 160668 )
      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, yo
      • 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.
        • 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.
      • 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.
      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

    • Re:Firewall? (Score:1, Informative)

      by Anonymous Coward
      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 some

  • Roles, anyone? (Score:2, Insightful)

    by neonfreon ( 850801 )
    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 sys
  • he writes about "Securing Sendmail". and then launches into a howto. He got that wrong, as it should have read: "Install Postfix"
  • 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 [cert.org]

Slashdot Top Deals

Single tasking: Just Say No.

Close