Paranoid Penguin - Security Features in Red Hat Enterprise 4
This month, I conclude a three-part series on distribution-specific security features. I began with SUSE Linux 10.0, continued on to Debian GNU/Linux 3.1 and this month I discuss Red Hat Enterprise Linux (RHEL) ES 4.
Red Hat Enterprise Linux is a general-purpose Linux distribution targeted to both desktop and server markets. As the name implies, RHEL is intended to be highly robust, stable and scalable; in other words, suitable for production use across large enterprises. And, sure enough, RHEL enjoys the reputation of delivering on all counts. Like SUSE, RHEL even runs on IBM eServer z-Series mainframes.
To much greater degree than Debian, however, and to a significantly greater degree than SUSE, Red Hat adheres to a strict philosophy of less is more where bundled software packages are concerned. Whereas Debian is composed of more than 15,000 packages and SUSE of more than 4,000, RHEL ES 4 weighs in at a mere 1,730 (if you include RHES Application Server and Extras packages, which aren't part of the base OS, strictly speaking).
I don't think it's at all euphemistic to say that this is an easily defended design choice. By limiting the number of packages it officially supports, Red Hat has a much smaller attack surface (not to mention help-desk surface). Fewer packages means less complexity; less complexity means better stability and security (at least in theory).
The downside of this design philosophy is obvious. It means fewer choices in any given tool space (network servers/dæmons, encryption tools and so on), less flexibility and greater likelihood that you'll end up installing third-party packages or even compiling them yourself from source.
As I've said many times in this column, there's no harm in rolling your own, especially when that means you're compiling out (excluding) unnecessary or potentially insecure features. But, nothing beats distribution-supported binary packages when it comes to automated security updates. And, none of the major Linux distributions besides Gentoo has any automated means of applying security patches directly from source code to locally compiled software.
Furthermore, as I'm about to show, RHEL ES 4 is particularly thin in the specific realms of security-enhancing software (with the sole exception of SELinux) and security-scanning software. This doesn't mean that I think RHEL is insecure; its smaller attack surface and its excellent SELinux support are both highly significant. It does mean, however, that you've got fewer choices in how you secure your RHEL-based server or desktop system, and even fewer choices in how you use it in security applications, than is the case with other major distributions.
Red Hat Enterprise Linux ES 4 has a very easy-to-use installation GUI that, besides installing the base operating system, allows you to select additional software packages, set the root password, set up networking, enable a simple local firewall policy and enable SELinux. After the first reboot, this installer runs additional modules for setting up a Red Hat Network subscription, creating the first nonroot user account and configuring the X Window System.
Personally, I don't care for the Red Hat installer's software package selection module at all. First, it allows you to select only from a subset of the packages available on the installation medium. (That is, as far as I could tell—it could simply be that a few packages I knew were available but couldn't find, such as gnupg, were simply buried within categories in which I didn't think to look). For the packages it does display, the installer shows neither detailed descriptions nor even approximate disk space required.
In addition, its dependency-checking functionality is decidedly primitive. If the software installer can't find something it needs, it returns an error but doesn't give you any means of solving the problem (locating the missing package, deselecting or uninstalling the package with the unmet dependency and so on). Although simplicity may be a virtue, this limited functionality doesn't compare very favorably at all with Debian's aptitude package management tool or SUSE's YaST. If you want to run this installer module again after installation is complete, it's located in GNOME's Application menu under System Settings under Add/Remove Applications, though I think you might be much happier performing additional software installations using up2date or even good old RPM.
So, what security-related packages are available in RHEL ES 4? Table 1 lists most of them. In a nutshell, if you want to secure the local system, SELinux and your local firewall policy are very nearly the only tools available to you. If you want to audit and analyze the security of other systems, RHEL ES 4 has very little to offer besides Nmap.
Table 1. Some Security-Enhancing Packages in RHEL ES 4
|bind-chroot||Configures your BIND-based DNS server to run in a chroot jail.|
|dovecot||IMAP server (mail delivery agent) designed for security.|
|freeradius||RADIUS authentication service for network devices.|
|krb5-server||Kerberos authentication/encryption server.|
|splint||Tool for auditing C code for bugs, including security vulnerabilities.|
|vsftpd||Very Secure FTP Dæmon: RHEL's only FTP server, but an excellent choice.|
|cryptsetup||Tool for creating encrypted filesystems (as virtual block devices).|
|ethereal, tcpdump||Classic protocol analyzers (aka packet sniffers).|
|gnupg||GnuPG e-mail/general-purpose encryption tool.|
|ipsec-tools||Utilities for building IPSEC VPN tunnels.|
|nc||Netcat, a versatile IP packet redirector.|
|nmap, nmap-front end.||The Nmap port scanner and its GUI front end.|
|openldap-clients, openldap-servers||OpenLDAP directory and authentication system.|
|openssh||The most popular free Secure Shell dæmon and client.|
|openssl||General-purpose SSL/TLS cryptographic library and tools.|
|policycoreutils, setools, setools-gui||Tools for configuring and managing SELinux policies.|
|selinux-doc||Not installed by default, but you'll want this collection of SELinux documents.|
|postfix-pflogsumm||Log summarizer for the Postfix Mail Transfer Agent.|
|spamassassin||Popular SPAM/UCE filter.|
|stunnel||General-purpose SSL/TLS wrapper for TCP applications.|
|sudo, usermode||Tools for allowing nonprivileged users to run processes as root.|
|tcp_wrappers||Provides simple IP-based access controls to TCP applications.|
|up2date, up2date-gnome||Red Hat's automated network-based software update tool.|
On the face of it, this is a decent list of applications; these are all important security-enhancing tools. Notably absent, however, are:
Any sort of file-integrity checker, such as Tripwire or AIDE.
Syslog-NG, a much more powerful system logger than the archaic syslogd on which RHEL still relies.
Any sort of virtualization environment (user-mode Linux, Bochs, Xen and so on).
The ubiquitous intrusion detection system and packet-logger Snort.
Web security tools such as squidguard, mod_security and so on.
You're perfectly free, of course, to download and compile the source code of any of these tools manually. But, you won't be able to leverage up2date's automatic update features on such packages.
So, both in terms of available security packages and the software installer itself, RHEL is a bit underwhelming. On the plus side, I do like the Red Hat Enterprise Linux installer's firewall/SELinux module (Figure 1). Both the firewall and SELinux functionality are enabled by default, and the help window on the left-hand portion of the screen explains both settings in plain language.
If you're completely new to SELinux, you can select a warn setting that causes the kernel to log events that violate the local SELinux policy without actually blocking those events. By default, however, SELinux is set to active, using a default policy that restricts the behavior of Apache (httpd), bind, NIS (ypbind), dhcpd, mysqld, ntpd, portmap, postgresql, snmpd, squid and syslogd.
The last thing worth noting about the Red Hat Enterprise Linux ES 4 installer is that both during initial setup, when you enter the root password, and after the first reboot, when you create the first nonroot user account, the installer performs no password complexity checks of any kind (of the sort SUSE's installer performs). It doesn't even warn against choosing an overly simple password via a simple text box like Debian does.
This is unfortunate. Password guessing and brute-force attacks are still very much with us. I was pleased to see, however, that by default, the XScreenSaver utility is configured to lock X sessions by password automatically any time the screen saver kicks in. (If only those passwords that protect XScreenSaver were required to include some combination of mixed upper-/lowercase, punctuation and numerals, I'd be happier still!)
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Where's That Pesky Hidden Word?
- Three More Lessons
- Doing Astronomy with Python
- Upcoming Webinar: Getting Started with DevOps
- Non-Linux FOSS: Flaky Connection? Mosh it!