A Practical Guide to Basic Security in Linux Production Environments – This article 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. This guide also discusses some Linux security steps that cannot be found in any book at the time of this writing. If you have been assigned to come up with a corporate Linux Security Standard, then you should definitely read on.
Securing Linux Production System
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This is a well written paper, covering lots of “duhs” and lots of “oh yeah, I forgot about that!” – both being very valid. Good job.
The word firewall was mentioned a couple of times – however configuring iptables would be pretty high up on my list.
I browsed rapidly through the article, and saw no mention of SELinux, grsecurity, PaX or even PIE and SSP. If an administrator is really serious about security, I strongly recommends he looks into the above-mentioned projects and implement as many of them if not all.
Gentoo has the best hardened linux project I know off, their official website could be a good start for researching these technologies.
http://www.gentoo.org/proj/en/hardened/primer.xml
Most companies have hardware firewalls and they don’t want you to use a firewall on Linux as well unless you are in DMZ. And usually you can’t patch the kernel for security features like PaX due to support issues. And Gentoo isn’t supported by most ISVs. In my experiences as a consultant you usually have no choice but to use Red Hat or SUSE.
Marc
I think that it would be more important,if the system only have open TCP/UDP ports, where its meant to offer any services.
netstat -a|grep LISTEN could have saved him some space..
nice pam howto..
Lots of the same old BS we’ve heard over and over again from so called “security professionals”.
#include <clue.h>
Although I agree that parts of the writeup was “rehashed” as you put it, bear in mind that it is the destination, and not the journey that’s important in this aspect.
If the original “BS” served its purpose fully, we won’t be getting any rooted Linux boxes around at all.
So I don’t see why this carefully thought out article should receive such a snide remark from you. For all I know, you might be an IT security person yourself… but at least the article writer shared his findings, and contributed to others.
Although the article writer is an RHCE, I appreciate the fact that he did not use any RH-centric commands or scripts… in fact he only mentioned “Red Hat” 25 times in the article (and almost all are for examples), which for someone who doesn’t use Red Hat (like me), values much higher than something that’s distro-centric (emerge bla bla immediately comes to mind).
Pretty basic stuff.
Although the article writer is an RHCE, I appreciate the fact that he did not use any RH-centric commands or scripts…
chkconfig!
this is a big issue but too much of IT security is bottom up, product/mechanism led. IT security needs to be top-down, establishing first the assets, their priorities (after risk is assessed), policies agreed, THEN these policies can be used to guide bottom-level security configuration. it is not a case of “secure everything and anything” – that is wrong.
chkconfig exists on SUSE as well.
I think you need to shift the “paradigm”, and “get onboard” with the “team.”
“Instead of trying to find an answer, why don’t we just change the problem”
My former boss actually spoke those words to my disbelief—he enunciated slowly as though to show that he was thinking outloud and dropping a deep though on those listening.
I didn’t get it, I’m into solving problems.
sorry for ranting off topic
netstat -a|grep LISTEN does not show you UDP ports and it’s displaying too much other stuff like streams not needed for finding open network ports.
netstat -a|grep LISTEN does not show you UDP ports
netstat -natp does.although i prefer to use nmap.
netstat -natp does.although i prefer to use nmap.
Forgot the u
netstat -natup
I’ll co-sign the poster mentioning PaX/SElinux
Just make sure there aren’t any problems with what you’re using the OS for. Like if you’re using Oracle and they break Oracle packages then don’t do it obviously. But certainly check into it if you want to sleep well at night.
GRsec and SElinux both boast as never being broken into. Russell Coker even has root accounts anyone can login to yet still no compromises have occured. Thats the kind of thing I’m currently trying to get good at.
Any idea if “Exec Shield” is already included in vanilla 2.6?
perfect!
Putting firewalls on end nodes is pointless. The point of a packet filtering firewall is to protect a network. If you already have control of the machine, you can turn off listeners as needed. If you’re using ipchains simply as an IP access control list, that’s what TCP wrappers are for.
Obviously if you grep for LISTEN then it’s not going to show anything other than ports that are bound to by a listening socket.
Nothing new here.No firewall setups,xattr,msec,R(S)BAC,grsecurity,hardened kernels etc.
I believe many posters forgot to read the paragraph “Focus of this article”. It clearly says the following :
a) it deals with commercial linux distributions
b) it doesn’t cover security features that require patching the kernel
c) it covers basic security requirements
d) it has been tested on RedHat Linux
Now, with this in mind, go read the guide for a second time.
The name of the article is “Securing Linux Production Systems”.
Many so called “professionals” here can’t read and have never worked on production systems in larger corporations. Otherwise they would know that patching the kernel yourself in production environments is not an option, that you can’t use iptables for firewalls because you are supposed to use hardware firewalls, you can’t use systems like Gentoo because ISVs don’t support it, you can’t use SELinux because it’s not supported yet etc.
If many so called “Linux profesionalls” are going to their bosses and tell them that the kernel needs to be patched in their production environment for security reasons, it will make no manager comfortable using Linux.
Many claim that there is nothing new here. Read again. This guy wrote a patch for restricting passwords which will be included in the upcoming RHAS 4, and he explains how to restrict su access for accounts, something I’ve never seen anywhere.
Many claim that there is nothing new here. Read again. This guy wrote a patch for restricting passwords which will be included in the upcoming RHAS 4, and he explains how to restrict su access for accounts, something I’ve never seen anywhere
Never heard of the wheel group?
Many so called “professionals” here can’t read and have never worked on production systems in larger corporations. Otherwise they would know that patching the kernel yourself in production environments is not an option
I gues you never read serious papers that deal with security.One of the steps of the many deals with patching the kernel-source with grsecurity,RSBAC (commercial supported,astronomical more advanced than SeLinux btw),or solar designers open wall,Medusa DS9 etc,(hardware) firewall is nice but the latest that should be implemented.
> Never heard of the wheel group?
You don’t understand wheel groups. In newer versions it restricts ANYONE from su-ing to ANY account. It used to be for restricting people accessing the root account only. You can’t use wheel to restrict certain people from su-ing to certain accounts only.
And I’ve read serious papers about security. But that doesn’t change the fact that you usually can’t patch kernels yourself in production environments due to support issues.
It used to be for restricting people accessing the root account only. You can’t use wheel to restrict certain people from su-ing to certain accounts only.
If people would loose their password or would carelessly post it on their monitor how does that newer version prevent another user from using that other account?Being carefull with a production server would mean in my opinion the prime would be protecting the root account and the database.Support can be a expensive option.Perhaps compiling the kernel yourself isn’t allways feasonable.Will not mean per se you couldn’t use a professional patched RSBAC kernel, which is by the way commercial supported and configured according to your needs.Your buisiness mileage may very of course.
> If people would loose their password or would carelessly post it on their monitor how does that newer version prevent another user from using that other account?
People are usually not willing to share the passwords of their own individual accounts but they do share passwords for system accounts and very often post it. You can address this problem by restricting people from su-ing to system accounts.
Parts of it are in upstream. the rest are available as patches within the redhat kernels and elsewhere in cvs.fedora.redhat.com