devxlogo

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

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

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.gzlooking up www.modsecurity.orgconnecting to www.modsecurity.org:80requesting http://www.modsecurity.org/download/mod_security-1.8.4.tar.gzremote size / mtime: 351172 / 1091101387mod_security-1.8.4.tar.gz                     100% of  342 kB  125 kBpsroot@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.cgcc -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.cgcc -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.sochmod 755 /usr/local/apache/libexec/mod_security.socp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf.bakcp /usr/local/apache/conf/httpd.conf.new /usr/local/apache/conf/httpd.confrm /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:


  •     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 “
        SecFilter “<.>“

    The first filter protects against only JavaScript injections with the

  • 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.

  • 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).

  • Deploy Host-based and Network-based IDS
    You never can be 100 percent sure that all the users in your system have strong, non-dictionary passwords, which raises the possibility that your system is vulnerable to brute-force password scans via SSH, telnet, or FTP. Brute-force attacks can easily find a user with a weak password and gain access to his or her account. So, you need to run NIDS or HIDS to detect such attempts and block them in any possible way.

    This example uses Snort and the ipfw firewall (FreeBSD). Installing Snort and ipfw is pretty easy. You can enable the ipfw in the FreeBSD kernel configuration file (option IPFIREWALL) and install Snort from the ports by typing the following commands from the Unix shell:

    root@artiste:/usr/local/etc/rc.d>cd /usr/ports/security/snortroot@artiste:/usr/ports/security/snort>make && make install

    Keep in mind that you must enable Snort at /etc/rc.conf by adding options like snort_enable="YES" and snort_interface="fxp0" (where fxp0 is the interface to listen on your server). The configuration file lives at /usr/local/etc/snort.conf. The RULE_PATH variable by default is configured to /usr/local/share/snort and that is a correct place to add your own rule sets.

    Don't forget to create a log directory for Snort's logs. Just run the following:

    root@artiste:~/snort>mkdir -p /var/log/snort/

    If this is your first install, start the Snort manually by executing /usr/local/etc/rc.d/snort.sh start. If everything is configured correctly and your system has /dev/bpf0 configured in kernel, it will start up successfully. Otherwise, it'll fail with the following error:

    Running in IDS mode with inferred config file: /usr/local/etc/snort.confLog directory = /var/log/snortInitializing Network Interface xl0ERROR: OpenPcap() device xl0 open:        (no devices found) /dev/bpf0: Device not configuredFatal Error, Quitting..

    If you don't have /dev/bpf0 in the kernel, add pseudo-device bpf to your kernel configuration file and rebuild the kernel. Once you've configured everything correctly, you'll be able to run the daemon. Listing 1 displays the output you should see.

    Now, you can write your own rule set file for detecting SSH brute force attempts. Why SSH? First of all, it's not as innocuous as you may assume. Secondly, Snort includes rule sets for telnet brute force attempts (which are really simple) in the default distribution.

    Put your ssh.rules file at /home/white/snort/ssh.rules, and add its include option to Snort's configuration file at /usr/local/etc/snort.conf:

    include /home/white/snort/ssh.rules

    The following is the rule set itself (/home/white/snort/ssh.rules):

    alert tcp any any -> $HOME_NET 22 (         msg:"Potential SSH Brute Force Attack";         flow:to_server;         flags:S;         threshold:type threshold, track by_src, count 3, seconds 60;         classtype:attempted-dos;         sid:2001219;         rev:4;         resp:rst-all; )

    This rule set file sends TCP_RST packets in both directions when somebody tries to perform more than three connections during a 60-second span.

    Moreover, Snort also logs the attempts. You can see them in the /var/log/snort/alert log file:

    root@artiste:/var/log/snort>tail /var/log/snort/alert[**] [1:2001219:4] Potential SSH Brute Force Attack [**][Classification: Attempted Denial of Service] [Priority: 2]10/20-09:11:35.582914 10.0.185.98:3294 -> 10.0.185.115:22TCP TTL:64 TOS:0x0 ID:8481 IpLen:20 DgmLen:60 DF******S* Seq: 0xC5A27561  Ack: 0x0  Win: 0xE000  TcpLen: 40TCP Options (6) => MSS: 1460 NOP WS: 0 NOP NOP TS: 43538876 0

    It also creates a special directory, which keeps the TCP session information of each attempt. The following is a listing of it:

    root@artiste:/var/log/snort>ls -al /var/log/snort/10.0.185.98total 22drwx------  2 root  wheel   512 Oct 20 09:11 .drwxr-xr-x  5 root  wheel   512 Oct 20 08:54 ..-rw-------  1 root  wheel  9336 Oct 20 08:54 TCP:1371-22-rw-------  1 root  wheel   353 Oct 20 08:58 TCP:2650-22-rw-------  1 root  wheel   353 Oct 20 09:00 TCP:2791-22-rw-------  1 root  wheel   353 Oct 20 09:11 TCP:3294-22-rw-------  1 root  wheel   353 Oct 20 08:56 TCP:4004-22

    Now, leveraging all this logged data, you can use ipfw to completely or particularly block access from the destination host, which has repeatedly tried to guess a password. Using ipfw policy routing (option IPFIREWALL_FORWARD), you can redirect the attacker to your honeypot or just block his or her access for a definite period of time.

    As an example, the following command adds a blocking rule and then adds a job to remove a block after 30 minutes (you can put it into the script and run it from the cron program, if it finds a new file in /var/log/snort/10.0.185.98). Specifically, it is an example of how to add and later remove a host (10.0.185.98) from the stop-list:

    root@artiste:/var/log/snort>ipfw add 10 reset tcp from 10.0.185.98 to 10.0.185.115 2200010 reset tcp from 10.0.185.98 to 10.0.185.115 22root@artiste:/var/log/snort>echo ipfw delete 10 | at now+30mJob 1 will be executed using /bin/shroot@artiste:/var/log/snort>atqDate                    Owner   Queue   Job#10:03:00 10/20/04       root    c       1

    Why Not Just Use Swatch?
    Of course using Swatch would be much easier in this situation. For example, Swatch knows how to make an external call to a program once the rule has happened and Snort currently doesn't. On the other hand, Snort is much more flexible despite its less intuitive syntax.

    Moreover, you should think twice before giving Swatch such powerful access-blocking capabilities. It could easily lock out your server just because of a single typo. Sometimes the right approach is letting your software do the job, but not when it deals with the only entrance to your servers—SSH or telnet.

    For Demonstration Purposes Only
    The examples in this article were only a presentation of the possibilities and the flexibility of IDS systems. They are not a correctly planned IPS. Do not use these examples on a production system with the expectation that they will make it safe—they won't.

    IDS Is Not a Silver Bullet
    Intrusion detection and prevention systems are very powerful helpers in securing your servers. However, always keep in mind that no system will meet your needs perfectly. To keep your server as secure as possible, be prepared to lend your personal touch with custom code and scripting.

    devxblackblue

    About Our Editorial Process

    At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

    See our full editorial policy.

    About Our Journalist