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.
Mick Bauer (firstname.lastname@example.org) is Network Security Architect for one of the US's largest banks. He is the author of the O'Reilly book Linux Server Security, 2nd edition (formerly called Building Secure Servers With Linux), an occasional presenter at information security conferences and composer of the “Network Engineering Polka”.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Profiles and RC Files
- Understanding Ceph and Its Place in the Market
- Astronomy for KDE
- Git 2.9 Released
- OpenSwitch Finds a New Home
- Maru OS Brings Debian to Your Phone
- What's Our Next Fight?
- SoftMaker FreeOffice
- The Giant Zero, Part 0.x
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide