How to harden RHEL systems

Some time ago, the NSA released an excellent guide how to harden RHEL5 systems.

Despite of being written for RHEL5, it partially also applies to RHEL6 and newer versions of Fedora. It is also worth looking at it for users of non-RH breed distributions. To be mentioned: Its clearly focused on server systems, not desktops.

Some of the topics are really basic stuff which is already in place as industries “best practices”, other methods are not that well known.

Most of the items can be implemented very easy, others should be reviewed if the complexity is worth the gain of security.

Minimize Software to Minimize Vulnerability is a good starting point. RHEL5 is quite bad on this point, a default installation comes with a complete desktop environment. RHEL6 made a lot of progress on this issue as I wrote about it in a earlier post.

The default file system layout of most Linux distributions is suboptimal. At least /var, /tmp and /home should be on separate file systems. You can enhance the systems security by setting mount options such as noexec, nodev and nosuid where appropriate.

Always set SELinux to Enforcing mode where possible. Since tools like audit2allow and selinux-polgengui enables users to easily create basic policies, its no more rocket science. For further readings and hints about SElinux, have look on Dan Walsh’s Blog.

Check if only needed daemons are running. I. e if you are not using NFS, disable portmapper and friends.

Other things things disabling rhnsd is IMHO not a good idea. Enabling a warning banner for pre-login texts is just clueless.

NSA provides a nice guide which is really worth reading for server administrators. Some topics described in the guide are maybe overkill and complex, while others are easy to implement and maintain. Hopefully NSA will soon update its paper to RHEL6.

It also shows that Linux distributors have room for improvements to provide a better default security.

Have fun!

SUSE Manager based on Fedora Spacewalk

SUSE announced the availability of SUSE manager. Having a closer look to it, one recognizes it is based on Fedora Spacewalk. It is a clone of the Red Hat Satellite.

A few weeks ago I was puzzled to see a post on the spacewalk-devel mailing list. SUSE was contributing some code. What the heck? Now it is clear, they are using Spacewalk as there source for its own product. Spacewalk is no longer just the upstream of RHN Satellite, but also a major tool for managing SLES systems.

The open source way
It is good practice to share knowledge and code between different distributions. SUSE profits from the work Red Hat has done before, and Red Hat profits from the contributions of SUSE. IMHO this is the right way how open source software should work.

The price tag
SUSE claims “SUSE Manager allows you to save up to 50 percent for Linux support”. Really?

Lets have a look to How to buy. The price is exactly the same as for RHN Satellite: USD 13,500. Really the same price tag? Lets dig deeper on features Click on Database support. One would read

"SUSE Manager provides a built-in Oracle XE database, but can also leverage existing 
Oracle 10g or 11g databases, to locally store all data related to the 
managed Linux servers."  

Means: With the free Oracle XE database delivered with SUSE you can manage just a few systems. If you want to manage more systems, you need to buy a very expensive Oracle License which, last least, doubles the price tag of SUSE Manager.

And Debian? There are some works going on, maybe I’m going to write soon about Spacewalk and what it can do for and with Debian.

Because SUSE was not in a hurry to release its new product, I can not understand why SUSE was not helping the Spacewalk project to get PostgreSQL production ready before releasing it. This would provide its customers (and the spacewalk community) a real benefit.

I hope that SUSE will sustainably contribute code to Spacewalk, it is now in the interest of users of both distributions.

Have fun!