Slashdot Mirror
Securing Linux Production Systems
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."
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
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.