How to use snort on Backtrack 4: Basic examples with a test attack

Snort is a very well known intrusion detection system (IDS) which can be very powerful in detecting malicious attacks against a system or network.

One of the big advantages of using it is that it is free and open-source.

Snort can be a little tricky to understand and use for the beginner, so here I discuss some basic usage, as well as showing some "practice" attacks (run snort on one system, and attack it from a second system to see what it looks like)

Please remember to use these techniques for legitimate defensive and testing purposes, and not maliciously. Every action you take has consequences, and you will be heir to the results of your actions.

I am using snort on Backtrack 4 R2, as it is pre-installed and configured for convenience.


Smart packet filter and rule-set

Essentially snort is just a packet filter, like tcpdump or tshark (wireshark). The power of snort is within its rule-based engine, which is able to filter packets, look for attack-signatures, and alert on them.

First I will run snort and tcpdump side by side in their most basic format, and we will see what we can capture.


Packet filter: tcpdump and snort comparison

Look at this quick comparison of tcpdump and snort where I started both applications, and pinged them once (my target system is 192.18.1.64, and I sent a ping from 192.168.1.67)

tcpdump -i eth0 host 192.168.1.64

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:32:16.272777 IP 192.168.1.67 > bt.lan: ICMP echo request, id 10525, seq 1, length 64
14:32:16.272804 IP bt.lan > 192.168.1.67: ICMP echo reply, id 10525, seq 1, length 64

snort -q -v -i eth0

12/07-14:35:30.674241 192.168.1.67 -> 192.168.1.64
ICMP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
Type:8  Code:0  ID:12829   Seq:1  ECHO
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

12/07-14:35:30.674269 192.168.1.64 -> 192.168.1.67
ICMP TTL:64 TOS:0x0 ID:16338 IpLen:20 DgmLen:84
Type:0  Code:0  ID:12829  Seq:1  ECHO REPLY
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

If you look closely you will see that, with the preceding options, you get more or less the same output from both tcpdump and snort. We can see that we are getting an ICMP echo request from 192.168.1.67, and replying.


Detecting signatures with snort

Now we will edit the snort configuration to enable some rules (probably best to make a backup copy of "/etc/snort/snort.conf" before you try this.

I am going to configure snort on my target system. I edit /etc/snort/snort.conf and comment out the following lines by adding a "#" in front

var HOME_NET any

var EXTERNAL_NET any

...and add the following lines

var HOME_NET 192.168.1.64 # Test target system

var EXTERNAL_NET 192.168.1.67 # Test attacker system

These lines effectively tell snort what is inside (and outside) your protected zone.


Detecting port-scans

Now I will enable a rule to detect port-scans. Port-scans are usually the first active component of an attack, so a good idea to monitor for these.

Near the end of the "snort.conf" file in the rules section, uncomment the following line:

include /etc/snort/rules/scan.rules

Now we will start snort on the target, and then run a standard nmap scan from the attacking system

snort -q -A console -i eth0 -c /etc/snort/snort.conf

nmap 192.168.1.64

This produces a huge amount of alerts to the screen. Each alert in this example is saying something along the lines of:

12/07-15:05:34.012119  [**] [1:2000537:6] ET SCAN NMAP -sS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 192.168.1.67:33811 -> 192.168.1.64:9943

However, if you were to simply scan a single port with the following nmap command, this would not trigger an alert.

nmap -sV -sT -p T:80 192.168.1.64

This is because thresholds are used in the scan signature, in order to separate legitimate connections from port-scans. The real skill in using snort, is in configuring the rule-set to only trigger for real issues, and ignore legitimate traffic.


Malicious payloads

OK, so I will disable the scan rules, and try something a little more aggressive.

I will uncomment the following rule to enable it, and see if we can trigger it:

include /etc/snort/rules/ftp.rules

On the target system I will start an FTP server (I am using vsftpd, a version which has no known exploits, just for testing this attack). I then attack the FTP server on the system using the Metasploit db_autopwn method.

This is a very noisy attack, because using db_autopwn will basically scan for any open ports, and then launch all exploits which happen to match the port information found (more detail on how to run this attack here).

So, what did we see on the target system? Certainly many exploit attempts triggered alerts.

12/07-15:48:06.820726  [**] [125:7:1] (ftp_telnet) FTP traffic encrypted [**] [Priority: 3] {TCP} 192.168.1.67:56383 -> 192.168.1.64:21
12/07-15:48:21.217972  [**] [1:2417:4] FTP format string attempt [**] [Classification: A suspicious string was detected] [Priority: 3] {TCP} 192.168.1.67:50638 -> 192.168.1.64:21
12/07-15:48:21.217972  [**] [1:1377:17] FTP wu-ftp bad file completion attempt [ [**] [Classification: Misc Attack] [Priority: 2] {TCP} 192.168.1.67:50638 -> 192.168.1.64:21
12/07-15:48:21.217972  [**] [125:2:1] (ftp_telnet) Invalid FTP Command [**] [Priority: 3] {TCP} 192.168.1.67:50638 -> 192.168.1.64:21
12/07-15:48:35.448702  [**] [1:8415:2] FTP SIZE overflow attempt [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 192.168.1.67:34203 -> 192.168.1.64:21
 ...truncated...

It is definitely picking up some nasties, and alerting us to tell us which IP address is the source.


False positives

Interestingly, whilst I was running this test, and writing this blog, I also got some false positives:

12/07-15:53:53.638563  [**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**] [Priority: 3] {TCP} 192.168.1.64:54680 -> 209.85.229.191:80
12/07-16:01:59.533010  [**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**] [Priority: 3] {TCP} 192.168.1.64:54680 -> 209.85.229.191:80
12/07-16:02:57.275727  [**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**] [Priority: 3] {TCP} 192.168.1.64:54680 -> 209.85.229.191:80
 ...truncated...

This false-positive situation is quite common, as I have not done any optimization at this stage. (209.85.229.191 is actually a server at www.blogger.com). This is not a threat, this is part of me writing my blog, that has somehow triggered a rule in my configuration.


Deploying snort in a network

Running snort in this way (IDS) does not stop exploits, but it would alert you to potential attacks that you may otherwise be unaware of.

To block attacks you would need to run snort in IPS mode (Intrusion Prevention) which involves running snort inline, and dropping malicious packets. Maybe a blog for another time.

This test is with snort in a single host scenario. Typically in a network deployment you would use a span-port on a switch, and connect a system running snort to the span port, so that it could "see" all the traffic on that subnet.

Additional configurations would include; deploying logging and alerting in a more resilient and manageable way, such as syslog or mysql.


Summary

In summary, intrusion Detection/Prevention (IDS/IPS) is an important part of a defense-in-depth strategy for secure environments.

Snort is essentially free, though needs a considerable amount of configuration and monitoring, in order to ensure that it is properly optimized - detecting threats, but not wasting time/resources by generating false positives.


(Please leave a comment if you found this exercise helpful)