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!)
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
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