|
|
< Day Day Up > |
|
3.4 Modes of OperationAt 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.
3.4.1 Snort as a SnifferWhile 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 exitingUpon 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:
These switches can be run individually or in combination with each other, whatever works best for your purposes. 3.4.2 Snort as a Packet LoggerThe 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 -dWhen 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.logOnce 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. 3.4.3 Snort as an NIDS: Quick and DirtyWhile 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.
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. 3.4.3.1 Get the latest rule setsTo 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: If you are running Snort CURRENT (riding the bleeding edge), you can download the latest rules from: 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. 3.4.3.2 Initial configuration of the snort.conf fileIn 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 exitingNow, 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. |
|
|
< Day Day Up > |
|
