Getting Started with mod_security
Listing 3. Some Custom Filters
SecFilterSelective REQUEST_METHOD ↪"!^(GET|HEAD)$" chain SecFilterSelective HTTP_Content-Type ↪"!(^application/x-www-form-urlencoded$|^multipart/form-data;)" SecFilterSelective REQUEST_METHOD "^POST$" chain SecFilterSelective HTTP_Content-Length "^$" SecFilterSelective HTTP_Transfer-Encoding "!^$" </IfModule>
Note the blank lines between filter groups. I inserted these to illustrate that appending the string chain to the end of a filter links it to the next one, such that the last filter in the chain will be evaluated only if the request first matches all prior filters in the chain. In this sense, chain is a little like an if-then statement.
The first pair of filters in Listing 3 checks to see whether the request is not a GET or a HEAD request; if not, it then checks to see if the request contains anything other than form data (content-type "application/x-www-form-urlencoded") or an uploaded file (encoding-type "multipart/form-data"), which are the only two types of encoding mod_security can parse. If both filters match, that is, the request isn't form data or a file, the request is denied (see SecFilterDefaultAction in Listing 1).
Note that our actual filter values ("!^(GET|HEAD)$" and "!(^application/x-www-form-urlencoded$|^multipart/form-data;)") are regular expressions. It's impossible for you to create your own custom filters unless you're comfortable with regular expressions; if you aren't, you may want to see Jeffrey Friedl's book Mastering Regular Expressions, 2nd edition (O'Reilly Media, 2002).
The second pair of filters in Listing 3 first checks to see if the request is a POST request. If so, it then checks to see whether the HTTP parameter Content-Length is set to null; if so, the request is rejected. POST requests are supposed to have proper lengths; if the length is null, this almost certainly suggests an attack of some kind.
Our last example filter, which unlike the first two is a single-line filter, protects us from non-null values for the HTTP parameter Transfer-Encoding. In other words, we want Transfer-Encoding to be set to null in HTTP requests, because the most common thing to set this to is chunked, which is practically never necessary but has been associated with attacks in the past.
Finally, we end with an </IfModule tag to indicate that we're done specifying mod_security parameters. In practice, the statements in Listings 1–3 would be in a single contiguous block; I split them into three groups only for readability.
If you prefer to maintain your mod_security settings in a special file, such as mod_security.conf, you can use an include statement within httpd.conf or apache2.conf, for example:
Once you've configured mod_security in httpd.conf or apache2.conf, you're ready to enable it. In the case of Apache 1.x, your httpd.conf needs to contain the line:
LoadModule security_module libexec/mod_security.so
and possibly also:
If you run Apache 2.x, your apache2.conf file needs the line:
LoadModule security_module modules/mod_security.so
This is true unless you run Debian and installed its mod_security deb packages, in which case you need to run only the following command (as root) from a command prompt:
Once mod_security is enabled, you need to restart Apache in order to load the module. After you do this, be sure to test your Web applications to make sure you didn't Denial-of-Service attack yourself via your mod_security configuration!
With that, you should be ready to explore some more-advanced filters that watch specifically for requests that your site shouldn't expect to see. I strongly encourage you to take this next step; although I think this article should have given you a good starting point, you can find examples of much more powerful filters in the “ModSecurity For Apache User Guide” and other documents on the modsecurity.org Web site. Good luck, and stay safe!
Resources for this article: /article/8744.
Mick Bauer (email@example.com) 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
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- 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