Paranoid Penguin - Security Features in Red Hat Enterprise 4

I've already mentioned the Security Level applet in RHEL ES 4's GNOME desktop. Unlike with SELinux, this applet doesn't give you much more in the way of configuration options for the local firewall policy than you get at installation time. This policy allows all outbound network transactions (originating from the local system), and blocks all inbound network transactions (destined for the local system) except the services you select here. Those services are, as in the Red Hat installer, HTTP, FTP, Telnet, mail (SMTP) and SSH.

In the Security Level applet, you also can specify a list of other ports in the form [port #]:[protocol], for example 689:tcp, 53:udp, 53:tcp. If you need anything fancier than that, you have to write your own iptables statements from scratch. Happily, you can do so simply by adding or editing lines in the file /etc/sysconfig/iptables. See the iptables man page and the Red Hat Enterprise Linux 4 Security Guide for more information.

It's worth mentioning that Red Hat recently acquired Netscape Directory Server, and has updated it and rebranded it as Red Hat Directory Server. This is being positioned as a commercially supported alternative to OpenLDAP or Sun Java System Directory Server. Although not included with RHEL (it's an add-on product that costs extra), it's worth mentioning as a key component of Red Hat's security vision. RHEL does include fully supported OpenLDAP packages, however.

In the same vein, Red Hat Certificate System provides a commercially supported PKI solution. It too is an add-on product not included with RHEL. OpenSSL is included with RHEL, of course, but without any additional setup tools such as TinyCA.

I have mixed feelings about Red Hat Enterprise ES 4's security features. On the one hand, RHEL doesn't offer anywhere near as many different security-enhancing software tools as Debian GNU/Linux or SUSE Linux. Entire categories of security tools that are well represented in other major Linux distributions (integrity checkers, intrusion detection systems, virtualization environments and so on) are absent.

On the other hand, Red Hat has clearly maintained an unparalleled level of control over the size and scope of its distribution. It has made hard choices about what it will support and maintain, and what it will not, which surely reduces the attack surface of Red Hat systems. I have no doubt that Red Hat's security team has an easier time responding to vulnerabilities in RHEL's 1,730 packages than the Debian security team does with that distribution's 15,000-plus packages.

Furthermore, by not only including SELinux in RHEL 4 but enabling it by default, Red Hat has taken a very bold step. The kernel-level mandatory access controls provided by SELinux provide the potential to mitigate many of the risks one might otherwise use add-on utilities to address. Furthermore, because this sort of technology is proactive, designed to prevent bad behavior, it's inherently stronger than intrusion detection, integrity checking and other reactive technologies (though it would be better if RHEL had both proactive and reactive measures—even with SELinux, bad things can happen).

Whether you find RHEL to be lean and mean or limited and clunky will depend on your particular Linux needs. I'll allow that some of the reasons I'm not as keen on RHEL as I am on Debian and SUSE are specific to my job as a security architect and consultant. I rely on a specialized set of tools, most of which RHEL has judged to be unnecessary for its target market—presumably IT professionals in corporate settings. Still, it seems to me that if I needed to secure a corporate Web server running RHEL, with or without SELinux, I'd still want to install mod_security, Squidguard, Syslog-NG and other tools manually that RHEL presently lacks.