Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

No-cost System Lockdown, Part 2: Open Source IDS in Use

Part 1 gave you a rundown of the most popular open source IDS solutions. Now learn how to protect your servers by employing common, practical uses for these solutions.


advertisement
art 1 of this article explained IDS and examined the most popular open source IDS solutions. Part 2 demonstrates some common, practical uses for these solutions.

The first example is application-based IDS, which addresses the problems involved with securing Web sites. Web sites commonly run on the Apache Web server and are written in PHP. Suppose you run such a site (or a number of them) and you want to secure it with IDS. Merely installing the IDS without properly configuring it will not adequately boost your site's security. To complete the basics for protecting your Web site, you need to ensure the following:

  1. The Apache server should block all queries (GET and POST) that have special HTML tags, apostrophes, and/or double inverted commas. Getting rid of the HTML tags protects against cross-site scripting (XSS) attacks and eliminating the specials characters nullifies potential SQL-injection attacks. XSS attacks occur when an attacker injects HTML and/or JavaScript into the Web pages and then lets other users unwittingly execute the code.
  2. The site should be able to log all incoming GET and POST queries in a separate text file, which would allow you to use an external HIDS, such a Swatch (Simple Watch Daemon).

Employ mod_security
You can employ mod_security (the Apache module that works as an internal IDS) to block unwanted actions or call external procedures. Once you've downloaded mod_security, you can unzip and untar it for a later build from the Unix shell with the following command:



root@artiste:/usr/local/src>fetch -v \ http://www.modsecurity.org/download/mod_security-1.8.4.tar.gz looking up www.modsecurity.org connecting to www.modsecurity.org:80 requesting http://www.modsecurity.org/download/mod_security-1.8.4.tar.gz remote size / mtime: 351172 / 1091101387 mod_security-1.8.4.tar.gz 100% of 342 kB 125 kBps root@artiste:/usr/local/src>tar zxf mod_security-1.8.4.tar.gz

The distribution includes a simple INSTALL text file that explains the two ways of installing this module: as either a dynamic shared object (DSO) module or a static one. For this exercise, use DSO, which you should build with Apache's APache eXtenSion (apxs) tool. The following output illustrates how to build the DSO module:

root@artiste:/usr/local/src/mod_security-1.8.4/apache1>/usr/local/apache/bin/apxs -\ -cia mod_security.c gcc -DHARD_SERVER_LIMIT=512 -DBUFFERED_LOGS -DDYNAMIC_MODULE_LIMIT=256 -funsigned-
char -DMOD_SSL=208119 -DMOD_ACCEL -DMOD_ACCEL_CACHEMGR -DEAPI -DEAPI_MM -
DUSE_EXPAT -I../lib/expat-lite -O6 -fomit-frame-pointer -fpic -DSHARED_MODULE -
I/usr/local/apache/include -c mod_security.c gcc -shared -o mod_security.so mod_security.o [activating module 'security' in /usr/local/apache/conf/httpd.conf] cp mod_security.so /usr/local/apache/libexec/mod_security.so chmod 755 /usr/local/apache/libexec/mod_security.so cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf.bak cp /usr/local/apache/conf/httpd.conf.new /usr/local/apache/conf/httpd.conf rm /usr/local/apache/conf/httpd.conf.new

Remember to restart Apache server.

Once the installation is complete, you must properly set up Apache configuration files to enable mod_security and to reach your security goals. The distribution includes samples of the httpd.conf configuration file for different configurations: httpd.conf.example-minimal, httpd.conf.regression-v1, and httpd.conf.regression-v2. The following is a simple configuration to include into your /usr/local/apache/conf/httpd.conf:

  • <IfModule mod_security.c>
        SecFilterEngine DynamicOnly

    The DynamicOnly option specifies analysis only of requests generated dynamically at runtime. Using this option prevents your Web server from using precious CPU cycles on checking access to static files.
  • SecFilterScanPOST On

    This option scans the POSTs.
  • SecFilterCheckURLEncoding On

    This option checks the URL encoding validation according to the RFC 1738 (www.ietf.org/rfc/rfc1738.txt).
  • SecFilterForceByteRange 1 255

    This option enforces a certain byte range on requests. (Null byte attacks try to trick C/C++-based software into thinking that a string ends sooner than it actually does.)
  • SecServerSignature "Microsoft-IIS/5.0"

    Normally, you don't need this option, but sometimes the more paranoid system administrators use it to hide their real Web server names with others.
  • SecAuditEngine RelevantOnly
        SecAuditLog logs/audit_log

    These two options enable very verbose audit logging to logs/audit_log.
  • SecFilter "<[[:space:]]*script"
        SecFilter "<.+>"

    The first filter protects against only JavaScript injections with the <script> tag. The second filter is more general. It disallows any HTML code in its parameters. Basically, this is typical XSS attack protection.
  • SecFilter "delete[[:space:]]+from"
        SecFilter "insert[[:space:]]+into"
        SecFilter "select.+from"

    These options offer protection from SQL-injection attacks. Nobody can perform DELETE FROM, INSERT INTO, or SELECT FROM operations in their queries.
  • </IfModule>

    The configuration looks like pretty simple, but it increases your protection a lot. mod_security has many more options and features, which you can find in the mod_security Reference Manual (modsecurity-manual.pdf).


  • Comment and Contribute

     

     

     

     

     


    (Maximum characters: 1200). You have 1200 characters left.

     

     

    Sitemap