Modes of Operation

At this point, you may be asking yourself, Why do I need to know Snort? It sounds much like tcpdump, in that it sniffs packets and can read and write into the same libpcap format. Here are just a few of the reasons Snort is a versatile solution for both packet sniffing and intrusion detection. Snort:

As you begin to use Snort, you will notice the many advantages it offers over tcpdump for raw data interpretation.

Next, we'll cover how to run Snort in its three basic operational modes.

Snort as a Sniffer

While the previously discussed network sniffer tools (tcpdump, ethereal, and Tethereal) are more full-featured and provide excellent packet analysis, there may come a time when you quickly look at the network traffic on a Snort sensor. In this case, using Snort as a sniffer might be valuable. The Snort sniffer-mode output is slightly different than the other command-line sniffers. It is actually very easy to read and you may find you prefer it for quick captures. One very nice feature of sniffer-mode Snort is the network traffic summary at the end of the capture. Sometimes this can be a very useful troubleshooting tool for network administrators.

Enable sniffer mode for Snort using the -v flag:

               # snort -v
Running in packet dump mode
Log directory = /var/log/snort

Initializing Network Interface eth0

        --== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface eth0

        --== Initialization Complete ==--

-*> Snort! <*-
Version 2.1.x (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
06/24-11:19:32.257859 64.147.136.193:3131 -> 192.168.0.15:9100
TCP TTL:128 TOS:0x0 ID:21742 IpLen:20 DgmLen:48 DF
******S* Seq: 0x5DB36D37  Ack: 0x0  Win: 0xFAF0  TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:19:32.261606 64.147.136.5 -> 224.0.0.10
EIGRP TTL:2 TOS:0x0 ID:0 IpLen:20 DgmLen:60
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:19:34.470931 64.147.136.1 -> 224.0.0.10
EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20 DgmLen:60
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:19:34.482799 64.147.136.1 -> 224.0.0.10
EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20 DgmLen:60
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

===========================================================================
Snort analyzed 38 out of 38 packets, dropping 0(0.000%) packets

Breakdown by protocol:                Action Stats:
    TCP: 1          (2.632%)          ALERTS: 0
    UDP: 0          (0.000%)          LOGGED: 0
   ICMP: 0          (0.000%)          PASSED: 0
    ARP: 0          (0.000%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 37         (97.368%)
DISCARD: 0          (0.000%)
===========================================================================
Wireless Stats:
Breakdown by type:
    Management Packets: 0          (0.000%)
    Control Packets:    0          (0.000%)
    Data Packets:       0          (0.000%)
===========================================================================
Fragmentation Stats:
Fragmented IP Packets: 0          (0.000%)
    Fragment Trackers: 0
   Rebuilt IP Packets: 0
   Frag elements used: 0
Discarded(incomplete): 0
   Discarded(timeout): 0
  Frag2 memory faults: 0
===========================================================================
TCP Stream Reassembly Stats:
        TCP Packets Used: 0          (0.000%)
         Stream Trackers: 0
          Stream flushes: 0
           Segments used: 0
   Stream4 Memory Faults: 0
===========================================================================
Snort exiting

Upon startup, Snort displays the mode, the logging directory, and the interface on which it is currently listening. When initialization completes, Snort begins dumping packets to the screen. This output is fairly basic: it displays only the IP and TCP/UDP/ICMP headers and little else. To break out of sniffer mode, use Ctrl-C. Snort exits by generating a summary of packets captured, including the protocols, packet fragmentation statistics, and stream reassembly stats. To view application data, use the -d flag. This option provides even more detailed output:

               # snort -vd

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:27:35.408290 ARP who-has 64.147.136.1 tell 64.147.136.144

06/24-11:27:35.408860 64.147.136.144:50507 -> 64.147.130.2:53
UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:57 DF
Len: 29
E8 0A 01 00 00 01 00 00 00 00 00 00 03 6E 73 31  .............ns1
03 6B 73 6C 03 63 6F 6D 00 00 01 00 01           .ksl.com.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:27:35.408838 ARP reply 64.147.136.1 is-at 0:D0:BC:ED:15:E4

06/24-11:27:35.409465 64.147.130.2:53 -> 64.147.136.144:50507
UDP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:121 DF
Len: 93
E8 0A 85 80 00 01 00 01 00 02 00 01 03 6E 73 31  .............ns1
03 6B 73 6C 03 63 6F 6D 00 00 01 00 01 C0 0C 00  .ksl.com........
01 00 01 00 00 70 80 00 04 40 93 82 02 C0 10 00  .....p...@......
02 00 01 00 00 70 80 00 02 C0 0C C0 10 00 02 00  .....p..........
01 00 00 70 80 00 06 03 6E 73 32 C0 10 C0 47 00  ...p....ns2...G.
01 00 01 00 00 70 80 00 04 40 93 82 03           .....p...@...

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The application data is clearly visible and you can see the plain text within packets. In this instance, the text sent from a DNS server shows up in plain text.

To view more details and see results similar to tcpdump—including data link layer headers, as opposed to just the application layer data—use the -e flag as well. Using both the -d and -e options displays almost all the data within the packet:

               # snort -vde

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:34:00.840645 0:8:74:F3:CC:F9 -> 0:D0:BC:ED:15:E4 type:0x800 len:0x47
64.147.136.144:50507 -> 64.147.130.2:53 UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:57 DF
Len: 29
28 BF 01 00 00 01 00 00 00 00 00 00 03 6E 73 31  (............ns1
03 6B 73 6C 03 63 6F 6D 00 00 01 00 01           .ksl.com.....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

06/24-11:34:00.841157 0:D0:BC:ED:15:E4 -> 0:8:74:F3:CC:F9 type:0x800 len:0x87
64.147.130.2:53 -> 64.147.136.144:50507 UDP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:121 DF
Len: 93
28 BF 85 80 00 01 00 01 00 02 00 01 03 6E 73 31  (............ns1
03 6B 73 6C 03 63 6F 6D 00 00 01 00 01 C0 0C 00  .ksl.com........
01 00 01 00 00 70 80 00 04 40 93 82 02 C0 10 00  .....p...@......
02 00 01 00 00 70 80 00 02 C0 0C C0 10 00 02 00  .....p..........
01 00 00 70 80 00 06 03 6E 73 32 C0 10 C0 47 00  ...p....ns2...G.
01 00 01 00 00 70 80 00 04 40 93 82 03           .....p...@...

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The hexadecimal dump displays more data. MAC addresses are visible, in addition to the IP addresses. When performing tests on a network or simply capturing data using Snort, the -vde switches provide the most information.

Most networks generate traffic at such a rate that it causes the Snort sniffer output to scroll by too fast. In order to direct the sniff trace to a logfile instead of the console, use snort -dve > temp.log. You can also use Snort in packet-logger mode, discussed in the next section.

In summary, here are the available runtime switches to use with Snort in sniffer mode:

-v

Dump packet headers to standard output. "Verbose" mode—although ironically, less verbose than -vd or -ve.

-d

Dump packet payloads.

-a

Display ARP packets.

-e

Display link layer data.

These switches can be run individually or in combination with each other, whatever works best for your purposes.

Snort as a Packet Logger

The next step past sniffing packets is logging them. Logging is as simple as adding the -l option, followed by the directory in which you wish to store the logs. Snort's default logging directory is /var/log/snort. If you specify a directory that does not exist, Snort exits with an error message. You can use the -d, -a, and -e options (discussed in the previous section) to control the amount of information logged for each packet. In this example, the logging directory is set to /usr/local/log/snort, rather than the default /var/log/snort, and the logfiles include the packet payloads:

               # snort -l /usr/local/log/snort -d

When run in this mode, Snort collects every packet it sees and places it in the logging directory in hierarchical mode. In other words, a new directory is created for each address captured and the data pertaining to that address is stored in that directory. Snort places the packets into ASCII files, with filenames generated from the protocol and port number. This organization makes it easy to see who has been connecting to your network and what ports and protocols they are using: simply use ls -R (or dir /s in Windows) to list the log directory. Be sure to specify your home network variable (either in your configuration file or using the -h switch) to specify logging for just your home network. This hierarchical organization is most useful if a limited number of hosts are involved or if you wish to view the IP addresses of captured hosts at a glance. However, the logging directory can become very congested over time due to the ever-increasing number of directories and files. If you're logging all the traffic on a very active network, it is even possible to run out of inodes (a Unix datastructure that limits the total number of files in a filesystem) long before you're run out of storage. If someone were to do a full scan of your network and map all 65,536 TCP ports as well as all 65,536 UDP ports, you would suddenly have 131,000 or more files, all possibly in a single directory. This file explosion can severely tax the limits of most any machine, and could easily turn into a full-blown denial-of-service attack. If you're not careful, you can cause yourself real headaches.

Binary logging dumps everything to a single file that is readable by Snort, tcpdump, or ethereal. This greatly increases the speed and portability of the packet capture. Most systems can capture and log at network speeds of 100 Mbps without trouble.

To log packets in binary, use the -b switch. Here is one example:

               # snort -b -l /usr/local/log/snort/temp.log

Once you have your capture, you can read back the file you just created using the -r switch. The output is similar to Snort's sniffer output Note that -r can't be used with -C. It would make it easier to follow simple conversations, though.

# snort -r /usr/local/log/snort/temp.log

While in this mode, Snort is not limited to reading the stored binary data in sniffer mode. You can run Snort in NIDS mode with a set of rules or filters that search for suspicious traffic. This can be useful for forensic analysis of suspicious traffic. By storing the data and then having a script examine it later, you have the luxury of very careful analysis of the packet stream. You also have the luxury of using tools other than Snort to help with your analysis.

Snort as an NIDS: Quick and Dirty

While Snort is a passable network sniffer, it is an excellent tool to detect intruders. When used as an NIDS, Snort provides near real-time intrusion detection capability.

Warning

Although some companies claim it, there is no such thing as a "real-time alert." When a packet is received and its content deciphered and judged to be malicious, the IDS must send out a notification to the administrator. In the time it takes for the administrator to receive the notification, log in to the system, and confirm the packet's signature, several minutes to an hour may have passed. The attacker's goal may be accomplished in that time. Some of the signatures are triggered by a host's response to a successful attack—certainly too late to stop the intrusion.

Also, if network devices are brought down or if the monitoring software is attacked, it could be several hours or days before the administrator physically arrives at the location or discovers there was an attack. Most successful infiltrations take less time to accomplish than it takes for the IDS system to notify an administrator that an attack has occurred. Security administrators must define for themselves what constitutes "real time."

We will spend a lot of time looking at the various ways that Snort can be used as an NIDS and all of the configuration options available. For now, let's just get it running and logging to the console so you can see Snort in action.

To get going, we need the latest set of rules. I usually keep my rules in a single location so that I can track changes and keep track of my configuration files. I create a directory in /usr/local/share/ called snort_rules (this is not a requirement, it just allows me to keep everything in one spot, and the guy who taught me FreeBSD did it this way). Inside this directory, I create a directory with the month and year (for example, march_2004). Since the Snort rules are updated fairly often (and you want to be able to spot the latest attacks), you should update your rules regularly. As long as you are running the same version of Snort, you can likely just copy your snort.conf file from one rules directory to another (run Snort using the -T option after upgrading, just to be sure).

If you are running Snort Version 2.1.x, you can download the latest rules from:

http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz

If you are running Snort CURRENT (riding the bleeding edge), you can download the latest rules from:

http://www.snort.org/dl/rules/snortrules-snapshot-CURRENT.tar.gz

Copy the gzipped tarball to the rules directory you created and expand it and move into the uncompressed rules directory using the following commands:

$ tar zxvf snortrules-snapshot-2_1.tar.gz
$ cd rules

or:

$ tar zxvf snortrules-snapshot-CURRENT.tar.gz
$ cd rules

You now have a directory with about 60 files. The files with the .rules extension contain the actual signatures that Snort uses to match against the packet contents going by on the wire. The threshold.conf file is where you will put your threshold and suppression rules (investigated in Chapter 9). The snort.conf file stores the configuration for Snort when running in IDS mode. The other files help Snort classify the different alert generators and rules. You will not need to touch most of these files. The only thing you will likely need to be aware of (certainly initially) is the snort.conf file.

In alert mode, Snort requires a configuration file (in fact, just specifying the location of the snort.conf file puts Snort into alert mode). The default location for the configuration file is /etc/snort.conf; if your configuration file is located somewhere else, you must supply the -c switch along with the file's location. Alerts are placed in the alert file in your logging directory (/var/log/snort by default, or the directory you specified with the -l switch). Snort exits with an error if the configuration file or its logging directory does not exist. You can specify what type of alert you want (full, fast, none, or Unix sockets) by supplying the -A command-line switch. You need to use the -A switch if you do not use the -c switch, or Snort will not enter alert mode. Additionally, if you use just the -c switch, Snort will use the full alert mode by default.

Your friend through the entire process of learning about the IDS mode of Snort will be the -T flag (test mode). It initializes the configuration, preprocessors, output plug-ins, and rule sets, and outputs the results of the initialization to the console, letting you see if everything is working correctly.

A first look at the snort.conf file is a bit daunting for the uninitiated. The snort.conf file is used to store all the configuration information for a Snort process running in IDS mode. The vast bulk of the snort.conf file is commented-out instructions on how to use the file. In Chapter 5, we will go into great detail on the various settings and entries in this critical Snort file, but let's get a quick configuration built so we can start watching for attackers (and seeing how Snort watches for the bad guys).

The default settings for almost all of the entries in the file should be fine for your initial explorations. We won't make changes to most of the variables (this might lead to some false-positive alerts, but while we're playing it won't really matter). The only variable we want to set is the RULE_PATH variable—this tells Snort where to find the rule set files. Find the line below in the snort.conf file:

var RULE_PATH ../rules

Change the line to the full path to where you've extracted the rules. For example:

var RULE_PATH /usr/local/share/snort_rules/march_2004/rules

To get Snort started, enter the following command line:

snort -c /usr/local/share/snort_rules/march_2004/rules/snort.conf

It generates the following output on the console (this output includes the configuration of several preprocessors):

Running in IDS mode
Log directory = /var/log/snort

Initializing Network Interface eth0

        --== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface eth0
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file /usr/local/share/snort_rules/rules/snort.conf

+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
,-----------[Flow Config]----------------------
| Stats Interval:  0
| Hash Method:     2
| Memcap:          10485760
| Rows  :          4099
| Overhead Bytes:  16400(%0.16)
`----------------------------------------------
No arguments to frag2 directive, setting defaults to:
    Fragment timeout: 60 seconds
    Fragment memory cap: 4194304 bytes
    Fragment min_ttl:   0
    Fragment ttl_limit: 5
    Fragment Problems: 0
    Self preservation threshold: 500
    Self preservation period: 90
    Suspend threshold: 1000
    Suspend period: 30
Stream4 config:
    Stateful inspection: ACTIVE
    Session statistics: INACTIVE
    Session timeout: 30 seconds
    Session memory cap: 8388608 bytes
    State alerts: INACTIVE
    Evasion alerts: INACTIVE
    Scan alerts: INACTIVE
    Log Flushed Streams: INACTIVE
    MinTTL: 1
    TTL Limit: 5
    Async Link: 0
    State Protection: 0
    Self preservation threshold: 50
    Self preservation period: 90
    Suspend threshold: 200
    Suspend period: 30
Stream4_reassemble config:
    Server reassembly: INACTIVE
    Client reassembly: ACTIVE
    Reassembler alerts: ACTIVE
    Zero out flushed packets: INACTIVE
    flush_data_diff_size: 500
    Ports: 21 23 25 53 80 110 111 143 513 1433 
    Emergency Ports: 21 23 25 53 80 110 111 143 513 1433 
HttpInspect Config:
    GLOBAL CONFIG
      Max Pipeline Requests:    0
      Inspection Type:          STATELESS
      Detect Proxy Usage:       NO
      IIS Unicode Map Filename: /usr/local/share/snort_rules/rules/unicode.map
      IIS Unicode Map Codepage: 1252
    DEFAULT SERVER CONFIG:
      Ports: 80 8080 8180 
      Flow Depth: 300
      Max Chunk Length: 500000
      Inspect Pipeline Requests: YES
      URI Discovery Strict Mode: NO
      Allow Proxy Usage: NO
      Disable Alerting: NO
      Oversize Dir Length: 500
      Only inspect URI: NO
      Ascii: YES alert: NO
      Double Decoding: YES alert: YES
      %U Encoding: YES alert: YES
      Bare Byte: YES alert: YES
      Base36: OFF
      UTF 8: OFF
      IIS Unicode: YES alert: YES
      Multiple Slash: YES alert: NO
      IIS Backslash: YES alert: NO
      Directory: YES alert: NO
      Apache WhiteSpace: YES alert: YES
      IIS Delimiter: YES alert: YES
      IIS Unicode Map: GLOBAL IIS UNICODE MAP CONFIG
      Non-RFC Compliant Characters: NONE
rpc_decode arguments:
    Ports to decode RPC on: 111 32771 
    alert_fragments: INACTIVE
    alert_large_fragments: ACTIVE
    alert_incomplete: ACTIVE
    alert_multiple_requests: ACTIVE
telnet_decode arguments:
    Ports to decode telnet on: 21 23 25 119 
1652 Snort rules read...
1652 Option Chains linked into 152 Chain Headers
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++


+-----------------------[thresholding-config]----------------------------------
| memory-cap : 1048576 bytes
+-----------------------[thresholding-global]----------------------------------
| none
+-----------------------[thresholding-local]-----------------------------------
| gen-id=1      sig-id=2275       type=Threshold tracking=dst count=5   seconds=60 
+-----------------------[suppression]------------------------------------------
-------------------------------------------------------------------------------
Rule application order: ->activation->dynamic->alert->pass->log

        --== Initialization Complete ==--

-*> Snort! <*-
Version 2.1.x (Build 24)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)

It will sit here (watching the traffic) until you stop Snort by hitting Ctrl-C or using kill-USR1. The following summary then appears:

===============================================================================
Snort analyzed 3210 out of 3807 packets, dropping 597(15.682%) packets

Breakdown by protocol:                Action Stats:
    TCP: 2602       (68.348%)         ALERTS: 6         
    UDP: 2          (0.053%)          LOGGED: 6         
   ICMP: 8          (0.210%)          PASSED: 0         
    ARP: 0          (0.000%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 0          (0.000%)
DISCARD: 0          (0.000%)
===============================================================================
Wireless Stats:
Breakdown by type:
    Management Packets: 0          (0.000%)
    Control Packets:    0          (0.000%)
    Data Packets:       0          (0.000%)
===============================================================================
Fragmentation Stats:
Fragmented IP Packets: 0          (0.000%)
    Fragment Trackers: 0         
   Rebuilt IP Packets: 0         
   Frag elements used: 0         
Discarded(incomplete): 0         
   Discarded(timeout): 0         
  Frag2 memory faults: 0         
===============================================================================
TCP Stream Reassembly Stats:
        TCP Packets Used: 2602       (68.348%)
         Stream Trackers: 1559      
          Stream flushes: 0         
           Segments used: 0         
   Stream4 Memory Faults: 0         
===============================================================================
Final Flow Statistics
,----[ FLOWCACHE STATS ]----------
Memcap: 10485760 Overhead Bytes 16400 used(%2.287951)/blocks (239909/1564) Overhead 
blocks: 1 Could Hold: (73326)
IPV4 count: 1563 frees: 0 low_time: 1080162455, high_time: 1080162458, diff: 0h:00:
03s
    finds: 2612 reversed: 1022(%39.127106) 
    find_sucess: 1049 find_fail: 1563 percent_success: (%40.160796) new_flows: 1563
 Protocol: 1 (%0.306279) finds: 8  reversed: 3(%37.500000) 
  find_sucess: 5 find_fail: 3 percent_success: (%62.500000) new_flows: 3
 Protocol: 6 (%99.617152) finds: 2602  reversed: 1018(%39.123751) 
  find_sucess: 1043 find_fail: 1559 percent_success: (%40.084550) new_flows: 1559
 Protocol: 17 (%0.076570) finds: 2  reversed: 1(%50.000000) 
  find_sucess: 1 find_fail: 1 percent_success: (%50.000000) new_flows: 1
Snort exiting

Now, a file called alert is in the /var/log/snort directory. This file contains the alerts generated while Snort was running. The output for this run is shown below (I ran an nmap SYN scan on the Snort host to generate some alerts):

[**] [1:469:1] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/24-15:07:35.187504 192.168.1.2 -> 192.168.1.105
ICMP TTL:51 TOS:0x0 ID:23210 IpLen:20 DgmLen:28
Type:8  Code:0  ID:1290   Seq:0  ECHO
[Xref => http://www.whitehats.com/info/IDS162]

[**] [1:618:5] SCAN Squid Proxy attempt [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/24-15:07:35.583826 192.168.1.2:49641 -> 192.168.1.105:3128
TCP TTL:44 TOS:0x0 ID:56810 IpLen:20 DgmLen:40
******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20

[**] [1:1421:3] SNMP AgentX/tcp request [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/24-15:07:35.589463 192.168.1.2:49641 -> 192.168.1.105:705
TCP TTL:44 TOS:0x0 ID:54050 IpLen:20 DgmLen:40
******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://
cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]

[**] [1:615:5] SCAN SOCKS Proxy attempt [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/24-15:07:35.674332 192.168.1.2:49641 -> 192.168.1.105:1080
TCP TTL:44 TOS:0x0 ID:9794 IpLen:20 DgmLen:40
******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20
[Xref => http://help.undernet.org/proxyscan/]

[**] [1:1420:3] SNMP trap tcp [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/24-15:07:35.696925 192.168.1.2:49641 -> 192.168.1.105:162
TCP TTL:44 TOS:0x0 ID:41259 IpLen:20 DgmLen:40
******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://
cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]

[**] [1:1418:3] SNMP request tcp [**]
[Classification: Attempted Information Leak] [Priority: 2] 
03/24-15:07:35.827022 192.168.1.2:49641 -> 192.168.1.105:161
TCP TTL:44 TOS:0x0 ID:37753 IpLen:20 DgmLen:40
******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://
cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]

Let's quickly dissect an alert. Here's an identification number for the alert followed by the alert name:

[**] [1:1418:3] SNMP request tcp [**]

Snort alerts are classified according to the type of alert. The classification for this alert is "Attempted Information Leak." A Snort rule specifies a priority for an alert as well. This lets you filter out low priority alerts to concentrate on the most worrisome. The priority of this alert is 2:

[Classification: Attempted Information Leak] [Priority: 2]

This is the header and packet information for the packet that caused this alert:

03/24-15:07:35.827022 192.168.1.2:49641 -> 192.168.1.105:161
TCP TTL:44 TOS:0x0 ID:37753 IpLen:20 DgmLen:40
******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20

Each Snort alert includes a link to a description of the rule that generated the alert:.

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://
cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]

This link is very useful for determining if the alert is a false positive or an actual problem. Alerts that you build yourself or get from the mailing lists or newsgroups will likely not have this information.

In the next chapter, we will look at the threats to your network and how Snort is able to detect these attacks in the act. Following that interlude, we dive back into the technical details of getting Snort up and running in a way that suits your environment best.