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”.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
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