Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


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

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.




Application Security Testing: An Integral Part of DevOps

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/snort root@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.conf Log directory = /var/log/snort Initializing Network Interface xl0 ERROR: OpenPcap() device xl0 open: (no devices found) /dev/bpf0: Device not configured Fatal 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 -> TCP TTL:64 TOS:0x0 ID:8481 IpLen:20 DgmLen:60 DF ******S* Seq: 0xC5A27561 Ack: 0x0 Win: 0xE000 TcpLen: 40 TCP 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/ total 22 drwx------ 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/ Specifically, it is an example of how to add and later remove a host ( from the stop-list:

root@artiste:/var/log/snort>ipfw add 10 reset tcp from to 22 00010 reset tcp from to 22 root@artiste:/var/log/snort>echo ipfw delete 10 | at now+30m Job 1 will be executed using /bin/sh root@artiste:/var/log/snort>atq Date Owner Queue Job# 10:03:00 10/20/04 root c 1

Comment and Contribute






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



Thanks for your registration, follow us on our social networks to keep up-to-date