(LinuxWorld) -- In our most recent SysAdmin article I promised an overview of Snort, the open source network intrusion detection system. I considered not writing the article after seeing the volume of options available to users of Snort, but decided that since I have received International Fame and Recognition from my security series, that I would go ahead with the article.

The following article does not cover Snort in great detail. Snort is a large program in terms of its available options, and would take several articles to cover comprehensively. Instead, here is a brief overview of the program, and some of its options.

If you haven't yet read my last article, please do. You'll find it and related references in the resources below. Otherwise, please turn your attention (and your Web browser) to Snort.org to download the Snort program.

After downloading it, you will need to compile Snort (don't you love the name?). I won't cover compiling Snort in this article as it is a very straight-forward process for any Linux administrator. Once Snort is compiled and ready to run, you can retrieve Snort's basic usage from the command snort -?. Which will produce output similar to the following:

-*> Snort! <*-
Version 1.8.1-RELEASE (Build 74)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
USAGE: snort [-options] <filter options>
Options:
        -A         Set alert mode: fast, full, console, or none  (alert file alerts only)
                  "unsock" enables UNIX socket logging (experimental).
        -a         Display ARP packets
        -b         Log packets in tcpdump format (much faster!)
        -c <rules> Use Rules File <rules>
        -C         Print out payloads with character data only (no hex)
        -d         Dump the Application Layer
        -D         Run Snort in background (daemon) mode
        -e         Display the second layer header info
        -F <bpf>   Read BPF filters from file <bpf>
        -g <gname> Run snort gid as <gname> group (or gid) after initialization
        -G <mode>  Add reference ids back into alert msgs (modes: basic, url)
        -h <hn>    Home network = <hn>
        -i <if>    Listen on interface <if>
        -I         Add Interface name to alert output
        -l <ld>    Log to directory <ld>
        -m <umask> Set umask = <umask>
        -n <cnt>   Exit after receiving <cnt> packets
        -N         Turn off logging (alerts still work)
        -o         Change the rule testing order to Pass|Alert|Log
[...]

Before we actually fire up Snort, we will want to first provide a bare configuration. The Snort configuration file is called snort.conf, and will be located in the source tree directly after compilation. The configuration file is surprisingly well-documented, and will actually walk you through basic configuration, step by step. The first step in configuring Snort is to set the the local network to be monitored. The following is a basic local network setting:

var HOME_NET 192.168.1.0/24

Once I configured my own local network, like all good technical people, I decided to ignore all further documentation and see if Snort could do anything (yes, this is satire). To this end, I executed the ./snort binary from the compiled source tree without any options. I then proceeded to scan the host running Snort, with a program called nmap. The following is what snort looks like when it starts up:

[root@host snort-1.8.1-RELEASE]# ./snort
Log directory =
Reading Conf File...
Initializing Network Interface eth0
using config file ./snort.conf
Initializing Preprocessors!
Initializing Plug-ins!
Initializing Output Plugins!
Parsing Rules file ./snort.conf
+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
No arguments to frag2 directive, setting defaults to:
    Fragment timeout: 60 seconds
    Fragment memory cap: 4194304 bytes
Stream4 config:
    Stateful inspection: ACTIVE
    Session statistics: INACTIVE
    Session timeout: 30 seconds
    Session memory cap: 8388608 bytes
    State alerts: INACTIVE
    Scan alerts: ACTIVE
No arguments to stream4_reassemble, setting defaults:
     Reassemble client: ACTIVE
     Reassemble server: INACTIVE
     Reassemble ports: 21 23 25 53 80 143 110 111 513
     Reassembly alerts: ACTIVE
Back Orifice detection brute force: DISABLED
Using LOCAL time
908 Snort rules read...
908 Option Chains linked into 144 Chain Headers
0 Dynamic rules
[...]

Snort keeps all of its logs in a directory tree beneath /var/log/snort, and will assign a directory to each IP address it detects as it scans the network. In my case, I was using a machine with the local IP address of 192.168.1.45 to scan my development machine, which was the box running Snort. Thus, my logs for this scan were in /var/log/snort/192.168.1.45. Snort also keeps a general log within /var/log/snort called alert. The following is an example from the alert log:

[**] [100:2:1] spp_portscan: portscan status from 192.168.1.45: 727 connections
across 1 hosts: TCP(726), UDP(1) STEALTH [**]
10/29-13:06:22.081919
[**] [100:2:1] spp_portscan: portscan status from 192.168.1.45: 1 connections across 1 hosts: TCP(1), UDP(0) [**]
10/29-13:06:27.816528
[**] [100:3:1] spp_portscan: End of portscan from 192.168.1.45: TOTAL time(4s) hosts(1) TCP(727) UDP(1) STEALTH [**]
10/29-13:06:39.768436

After a quick review of the above alert log excerpt, I was able to determine easily that Snort did indeed pick up my port scan from nmap. This is an excellent first step in noticing intrusion to the system.

After further review, I found that if you run Snort without any options, you are running in Packet Logger Mode. The packet logger mode will log all of the packet information to the log directory, and unless you enjoy reading lots of TCP/IP packet information, I don't suggest this option. Also, if you would like to see a summary of traffic on the network in real time, you can use the -v option. The -v option will print all TCP/IP headers to the screen. The output looks like this:

10/29-13:54:58.599541 192.168.1.45:32941 -> 192.168.1.65:22
TCP TTL:64 TOS:0x10 ID:23139 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x75925310  Ack: 0xCAC1A8AE  Win: 0x0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 16070740 16838657
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
10/29-13:54:59.105981 192.168.1.45:32941 -> 192.168.1.65:22
TCP TTL:64 TOS:0x10 ID:23140 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x75925310  Ack: 0xCAC1A8AE  Win: 0xB50  TcpLen: 32
TCP Options (3) => NOP NOP TS: 16070791 16838657
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The above packets states that the IP address 192.168.1.45 on port 32941 is sending IP traffic to 192.168.1.65 on port 22. For those unaware, port 22 is typically used for ssh.

I once knew a person who could read HEX. Yes, base 16. The following Snort options are dedicated to that individual. If you run Snort with the -v-d -e options, you will see all data while in transit over the wire as well. These options, in short, make Snort act like a network sniffer. The output looks like this:

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
10/29-14:04:42.311579 0:50:DA:8D:BA:40 -> 0:D0:B7:85:C:B type:0x800 len:0x16E
192.168.1.65:22 -> 192.168.1.45:32941 TCP TTL:64 TOS:0x10 ID:8404 IpLen:20 DgmLen:352 DF
***AP*** Seq: 0xCACE6A6E  Ack: 0x75925D74  Win: 0x7D78  TcpLen: 32
TCP Options (3) => NOP NOP TS: 16897028 16129104
00 00 01 26 DE 39 A9 4A 5E F4 9A 3A 10 6D 8A 13  	...&.9.J^..:.m..
C0 51 FA 9E 83 A7 F7 1D 96 3F FD F8 E6 11 5E 3F  	.Q.......?....^?
C7 CE 75 AF 56 01 DA 3B 15 96 90 56 08 56 0B 57  	..u.V..;...V.V.W
70 E8 77 72 EA 42 98 C7 8A C4 F8 37 47 2F C8 89  	p.wr.B.....7G/..
1C 3C 85 85 8B 9C C9 DA 5B 67 7D C9 D1 99 F2 64 .<......[g}....d
F0 82 12 94 0B 06 A6 ED B4 45 2C A4 FE 48 04 6D  .........E,..H.m
8D 0A 31 51 13 89 91 EA 86 2A 72 B6 C7 B2 6F F9  	..1Q.....*r...o.
C3 95 08 8D 3D C6 64 E7 3C A8 04 44 3A 88 8F CC  	....=.d.<..D:...
1A A5 28 8F B8 D1 B0 63 20 5F BD BF A2 81 B0 DF 	..(....c _......
0A 17 3F B6 F2 76 45 F1 A4 63 EB B3 46 1C DF BC  ..?..vE..c..F...
09 31 17 44 7B E7 72 25 F9 85 0E C5 BC 94 6F EA  	.1.D{.r%......o.
C2 87 83 B9 D2 CB 51 11 F9 CF D5 43 C7 12 EB AB 	......Q....C....
6C 94 6F C9 B4 35 F0 F8 CD 20 17 46 39 67 98 F2  	l.o..5... .F9g..
4E F2 73 12 37 BD 17 89 66 3F D5 22 33 C8 2F 27  	N.s.7...f?."3./'
9E 1E 49 6C 27 0B 98 FE 88 61 08 A7 79 73 9B 0F  	..Il'....a..ys..
36 9B C4 96 D8 EC 0E 14 ED 19 BA 63 17 C6 F4 06  6..........c....
3C 9D 31 1E 86 61 3E A7 27 F6 4D EE 7B DE 26 0E 	<.1..a>.'.M.{.&.
F2 81 87 0E 7F 71 7C 47 B9 29 CF BB F8 FB 54 04	.....q|G.)....T.
6E F8 B2 02 1E 4F AD AF A6 F7 B5 A8              		n....O......

I would like to take a moment and awe my readers by decoding the above, but I can't. I know what it is -- a HEX Dump with packet information -- but I haven't read HEX in years, and don't plan on starting again any time soon.

In future articles, I would like to offer more on Snort, including how to use actions and logging to databases such as PostgreSQL. Next week is "open topic" week: If you have something of interest that you would like to see a technical article written on, please contact me and I will consider covering it.