Getting Started with mod_security
What is more important than Web security? No matter how advanced your firewall, how compartmentalized your network and how strong your encryption, it all comes crashing down if your Web applications are vulnerable. On the one hand, there's no substitute for stringent user-input validation and other secure programming practices. But on the other hand, the stakes are too high to operate without some sort of safety net.
Ivan Ristic has given us just such a safety net: his excellent Apache module mod_security acts as an application-layer proxy between users and your Web applications. The mod_security module can stop SQL injection, cross-site scripting and other input-based Web attacks dead in their tracks, with only minimal effort on your part, and with no impact at all on either your Web developers or your users.
In this article, I tell you what you need to know to install and begin configuring mod_security on your own Apache-based Web server.
Space doesn't permit a comprehensive explanation of the entire range of threats that mod_security was designed to help mitigate. If you're new to Web security, your first stop should be the Open Web Application Security Project (OWASP) Web site (see the on-line Resources), home of the OWASP Top Ten Most Critical Web Application Security Vulnerabilities. A reasonable second stop is Chapter 10, “Securing Web Servers”, of my book Linux Server Security, 2nd edition, or Ivan Ristic's book Apache Security.
For our purposes here, suffice it to say that of the different types of vulnerabilities in Web servers, by far the most typical is poor or incomplete user-input validation. In fact, many of the items on the OWASP Top Ten list are really just subsets of this family of problems; command injection and cross-site scripting, for example, are types of user-input abuse. User input, of course, includes not only the URLs requested in HTTP GET requests, but also the data sent in POST commands.
The mod_security module gives your Apache Web server increased ability to inspect and process input from Web clients before it's acted on by the scripts or processes waiting for the input. The mod_security module even lets you inspect Web server output before it's transmitted back to clients. I love this feature: it allows you to watch out for server responses that might indicate that other filters have failed and an attack has succeeded!
The mod_security module also lets you automatically log events and session data that Apache wouldn't ordinarily log. This is useful not only for forensics purposes, but also for fine-tuning your mod_security rules. If you create stringent mod_security filters that you're worried may be triggered by legitimate traffic, you can set those filters only to log rather than actually dropping or redirecting the requests that trigger them.
But wait, there's more: mod_security works against encrypted Web traffic too! Because mod_security has access to transaction data before SSL encryption and after SSL decryption, mod_security can filter HTTPS traffic just as effectively as it filters HTTP.
Why wouldn't you need mod_security? Arguably, if you have a “brochure-ware” Web site that involves no databases or cgi scripts, serving up instead only static Web pages, mod_security might not be worth the trouble of setting up. I would suggest, however, that even on such a server, mod_security still might do some good for you, for example, in inhibiting certain types of information-gathering attacks. Read on, and decide for yourself.
The mod_security module runs on both Apache 1.3 and Apache 2.0. Although for most Linux distributions, you'll need to install mod_security from source, Debian has its own binary packages for mod_security.
If you run Debian, install the package mod-security-common, plus either libapache2-mod-security or libapache-mod-security, depending on whether you run Apache version 2 or 1, respectively. Although Debian's mod_security packages are for mod_security version 1.8.7, rather than the more-advanced version 1.9, this article is sufficiently basic to apply equally to versions 1.8.7 and 1.9.
If you run SUSE or Red Hat Enterprise Linux, you need to download the latest source code from www.modsecurity.org and compile it using the apsx or apsx2 command (part of SUSE's apache-devel and apache2-devel packages, respectively, and RHEL's httpd-devel package). All you need to do, once you've got apsx or apsx2 installed and have obtained the source code file mod_security.c, is issue one of these two commands from within the directory containing mod_security.c:
/usr/sbin/apxs -cia mod_security.c
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
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- 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