3 1 3 7 Snort Rules Application 7406 | Transmission Control Protocol | Port (Computer Networking)

Snort Rules: Application

Paul Ritchey, Jacob and Sundstrom, Inc. pritchey@jasi.com

V1.0.0

1

Welcome to the class titled ‘Snort Rules: Application’. The purpose of this class is to take the material you learned in the previous section, ‘Snort Rules: Syntax and Keywords’. This section will take those individual keywords, values and syntax to form complete rules. You will also learn how to analyze existing rules piece by piece to determine what the rule is looking for.

1

Agenda
!

Rule Analysis
Simple Rules ! Difficult Rules ! Advanced Rules
!

!

Writing Rules
Simple Rules ! Difficult Rules ! Advanced Rules
!

!

Tying It All Together
2

The first half of this presentation will examine rules of increasing complexity. You will be taught how to analyze an existing rule to determine what it is looking for. This ability is key to understanding how to piece together a complete rule from scratch that matches the signature of an attack. The second half of the presentation will ask you to write rules from scratch of increasing difficulty. The process of creating these rules will be covered in a step by step process. This will show you a possible methodology you can use when creating rules on your own. The very last section will tie together everything you have learned so far, showing you a few of the options available for Snort output. This presentation covers Snort version 1.7. If you are using a newer version of Snort, please remember that new features may have been added or existing features may have been modified after this presentation was assembled.

2

Rule Analysis: Simple Rules

3

This section will show you how to analyze simple rules, step by step. The analysis skills learned here will be built upon in later sections to analyze rules of increasing difficulty. This will help you later when you will be required to write rules from scratch.

3

Rule Analysis: Simple Rules
! !

Learn to analyze simple rules.
!

Signature based on rule header.

Examples taken from snort.org rule set and www.whitehats.com. ! Use logical approach
!

Analyze rule header first
• Determine source and destination addresses and ports • Snort uses this section first.

!

Analyze rule options next
4

In this section you will learn how to analyze simple rules. The rules were chosen because they do not incorporate packet attributes which can make some rules difficult to analyze. These are real life rules, taken directly from the rule set available from the snort.org web site and www.whitehats.com. This means that it’s possible to do further research on the exploits that the rules are designed to detect to fully round out your understanding of rules. This section will start with teaching you how to analyze rules based on a logical approach. The first step is to analyze the rule header. This determines what hosts, ports, protocols and traffic flow must be involved before Snort even starts to examine the rest of the rule – this allows Snort to quickly determine if it should completely analyze the rule against the options section, saving valuable time. Later sections will combine the analysis of the rule header with the options section for more complicated rules.

4

Simple Rule #1: Back Orifice
!

Background:
Trojan ! Allows remote control of infected machine
!

!

Rule:
!

alert UDP $EXTERNAL any -> $INTERNAL 31337 \ (msg: "IDS188/trojan-probe-back-orifice";)

5

The first rule we are going to examine is one that looks for attempts at connecting Back Orifice trojans. This particular exploit works by means of a trojan that is somehow installed on the target machine. The trojan can be installed accidentally by end users running executables attached to email messages, downloading the trojan masquerading as a useful utility, etc. Once installed, the trojan opens a port and makes itself available for control from a remote host. Further information on this particular trojan can be obtained any of the major online security web sites. In depth analysis of this trojan is beyond the scope of this course.

5

HOME_NET. but must be destined specifically for the port 31337 (otherwise known as ‘eleet’) on the destination machine. This rule only applies to UDP traffic. the contents of the signature is completely contained in the rule header. Typically. This rule. and is set to the addresses Snort is monitoring. will execute the action ‘alert’. be originating from any of the possible ports on the source host. this is set to !$HOME_NET. ! Source defined by variable ! • $EXTERNAL = !$HOME_NET ! Destination defined by variable • $HOME_NET = your network 6 For this simple rule. This variable is typically defined at the top of the rules file being used. this rule will not be tested against them. The destination address is defined as a variable. The UDP packet can. when it is triggered. meaning that the source address should be outside of the network address space Snort is monitoring. however. If snort the traffic Snort is examining is from another protocol.) ! Examine the rule header: Will ‘alert’ when triggered. ! Applies only to UDP traffic. named EXTERNAL. In this particular rule. 6 . the source address is also defined as a variable.) alert UDP $EXTERNAL any -> $INTERNAL 31337 \ (msg: "IDS188/trojan-probe-back-orifice". Alert means Snort will write an entry to the alert file and an entry to the logs unless they are overridden by command line options or other means.Simple Rule #1: Back Orifice (cont.

Since no packet attributes or options are specified. This rule is very simple. ! High likelihood of false-positives. No packet attributes are examined. although not often. ! 7 Examining the rule options section. it is seen that the only option being used is the message option. This option provides a string that is used to tag alert and log entries. 7 . that happens to be destined for destination port 31337 will trigger this rule. ! ! Possibility of false-positives: Low likelihood of occurrence. making it easier to determine what a log or alert entry represents.) ! Examine rule options.) alert UDP $EXTERNAL any -> $INTERNAL 31337 \ (msg: "IDS188/trojan-probe-back-orifice".Simple Rule #1: Back Orifice (cont. it is very likely that detects. Any traffic. The only thing limiting the rule down to a specific subset of UDP traffic is the destination port. may very well be false-positives. Care must be taken when analyzing any available data to validate that the packet was truly a probe for Back Orifice or the master program contacting a Back Orifice client. such as streaming audio or video. ! Only includes message.

) 8 The next simple rule we will examine is one that detects Deep Throat trojans. Deep Throat is another trojan that can be accidentally installed by users who unknowingly execute attachments or download the software by accident. 8 .Simple Rule #2: Deep Throat Trojan ! Background Trojan ! Allows remote control of infected host. ! ! Rule: ! alert udp any 2140 -> $HOME_NET 60000 \ (msg:"IDS106 .1 Server Active on Network". Once installed. the trojan opens a port that allows remote hosts to control the infected machine.BACKDOOR SIGNATURE .DeepThroat 3.

Alert means Snort will write an entry to the alert file and an entry to the logs unless they are overridden by command line options or other means. the keyword ‘any’ is specified. If snort the traffic Snort is examining is from another protocol. I would like take a second to discuss the keyword ‘any’ that was specified for the source address. there are no restrictions. This rule. Instead of specifying a variable for the source IP address. it will trigger the rule and will be logged to the alert file and logs with the message specified in the rule options section. and to the specific port 6000. If the packet meets all of the above criteria. ! Destination defined by variable • $HOME_NET = internal network 9 For this simple rule. including internal addresses. Applies only to UDP traffic. will execute the action ‘alert’. when it is triggered.BACKDOOR SIGNATURE \ DeepThroat 3. However. this rule will not be tested against them. Source specified as ‘any’ • ‘Any’ matches all possible IP addresses. and sees all traffic in bound from the internet to your network. or outbound from your network to the internet. Snort is typically installed on a machine that resides in a ‘DMZ’. This means that the packet can originate from any possible IP address. The DMZ sites outside of your internal network. 9 . the packet must originate from a specific port – 2140.Simple Rule #2: Deep Throat (cont.) alert udp any 2140 -> $HOME_NET 60000 \ (msg:"IDS106 . Because of this. The packet must be destined for the network the variable HOME_NET is set to. Now the rule deviates from the previous example. the contents of the signature is again completely contained in the rule header. This rule only applies to UDP traffic. it would have been just as effective to replace the keyword ‘any’ with !$HOME_NET.) ! Examine the rule header: ! ! ! Will ‘alert’ when triggered.1 Server Active on Network". It does not and should not see your internal traffic.

we again that this rule like the previous example is only specifying the message option. This increases the chances that a detect is a false-positive so care must be taken to fully resolve any detects. 10 ! Possibility of false-positives: ! ! Examining the rule options section. 10 . Although unlikely. ! ! No packet attributes are examined. Most virus software should be capable of detecting this trojan if properly installed and used regularly. This rule is very simple. and because there are no other criteria for the rule false-positive detects may be made. The only real limiting factors are the source and destination ports. Both ports are ephemeral ports.\ DeepThroat 3.) alert udp any 2140 -> $HOME_NET 60000 \ (msg:"IDS106 .BACKDOOR SIGNATURE . it’s possible that this port combination could be used during the course of a valid connection. Low likelihood of occurrence.) ! Examine rule options.Simple Rule #2: Deep Throat (cont. meaning they are out of the reserved range. Only includes message.1 Server Active on Network". This option provides a string that is used to tag alert and log entries. making it easier to determine what a log or alert entry represents. Likelihood of detect being a false-positives.

11 . Essentially they provide additional information about packets that are considered hostile beyond source and destination IPs and ports.Rule Analysis: Complex Rules 11 In this section the rules presented for analysis are a little more complicated than the previous examples.

This section will continue to build on the rule analysis technique that was used in the first section.snort. which can potentially reduce the number of false positives. Signature based on rule header. By adding packet attributes (such as TCP flags) to the rule options section. the signature doesn’t just consist of the contents of the rule header.org web site and from the www. ! Examples taken from www. The example rules used in this section are real world rules. 12 .whitehats.org rule set and www.Rule Analysis: Complex Rules ! Learn to analyze complex rules.com. ! Use logical approach ! Analyze rule header first ! Analyze rule options next ! • Specifies specific packet attributes • Can increase accuracy – decrease false positives 12 This section concentrates on analyzing more complicated rules – those containing packet attributes in the rule options section. It consists of the rule header and additional information specified in the rule options. ! Signature also based on rule options.snort. They have been taken from the rule sets available at the www.whitehats.com web site. In these rules. it’s possible to make rules more accurate. Interpretation of the rule option section with different kinds of packet attributes will be introduced here.

this trojan like any other can be accidentally installed by executing attachments to email messages.BACKDOOR SIGNATURE – NetMetro Incoming Traffic". flags:PA. Most virus detection software should detect this trojan as long as the signatures are properly maintained.) 13 The rule we are going to examine next is one that detects the NetMetro trojan. Again. NetMetro is another trojan that when installed allows remote control of the infected machine. 13 .Complex Rule #1: NetMetro ! Background: Trojan ! Allows remote control of infected machine ! ! Rule: ! alert tcp $EXTERNAL_NET 5031 -> $HOME_NET !53:80 \ (msg:"IDS79 . or downloading the trojan as it masquerades as a useful utility or game.

The destination address is specified by the variable HOME_NET. In most cases EXTERNAL_NET is set to !$HOME_NET. It specifies that the destination port can be any port except ports 53 through 80. The source address is specified by the variable EXTERNAL_NET. The source port the traffic must originate from is port 5031.) ! Examine the rule header: Will ‘alert’ when triggered. If the source port is anything but 5031.Complex Rule #1: NetMetro (cont. Both of these variables are typically defined at the top of a rules file. ! Applies only to TCP traffic. It also only applies to TCP traffic that meets the criteria of the rest of the signature. ! Source defined by variable ! • $EXTERNAL_NET = !$HOME_NET ! Destination defined by variable • $HOME_NET = your network 14 This rule when triggered will alert – meaning it will create an entry in the alerts file and create a log file. The destination port setting is more interesting.BACKDOOR SIGNATURE .NetMetro Incoming Traffic". but may also be set by command line options. it will not match the rule header information and this rule will not be triggered. flags:PA. which means that the source address can be any IP address except the IPs belonging to your network. unless these options are overridden by command line options. inclusive. 14 .) alert tcp $EXTERNAL_NET 5031 -> $HOME_NET !53:80 \ (msg:"IDS79 . This variable is set to the IP addresses your sensor is to monitor.

the rule will be triggered as soon as the TCP three way handshake is completed and the first packed with a payload is sent inbound to your network. ! High likelihood of being false positive. To rule out the possibility of a detect being a false positive. ! ! Likelihood of false positives: Low likelihood of occurrence.BACKDOOR SIGNATURE . The attribute being tested is the TCP flags setting. the TCP flags PUSH and ACK must be set. For example. The false positives are limited because the source port must exactly match 5031.) alert tcp $EXTERNAL_NET 5031 -> $HOME_NET !53:80 \ (msg:"IDS79 .) ! Examine the rule options: TCP flags PUSH and ACK must be set. if an outside user telnets in to a server in your network. additional data possibly beyond what Snort provides may need to be examined. The addition of packet attributes (in this case TCP flags) to the rule options section aids in reducing the possibility of false positives because it helps to narrow the possibility of matches somewhat. The source port 5031 is an ephemeral port. meaning that is not a reserved port and available for anyone and any application to use. although they will happen. there is a low likelihood of false positives. FIN. Other flags. ! 15 This rule is the first example of packet attributes being used in the rule options section. such as SYN. flags:PA.NetMetro Incoming\ Traffic".Complex Rule #1: NetMetro (cont. and the destination port must be outside the specified range. Telnet runs on port 23. outside the range specified by the destination port setting that specifies what ports it cannot be. No other packet attributes are examined beyond the TCP flag setting. 15 . If the port 5031 is used by the person connecting to your telnet server. For this particular rule. URG and the two reserved bits must NOT be set. it’s possible this rule may be triggered. In this case. ! No other packet attributes examined.

myscan". ttl: >220.) 16 The second difficult rule to be examined detects a particular tool used for scanning. It can also allow the rule to be tuned to help eliminate false positives.Scan . and the hacker now has enough information to launch an effective attack. ! ! Rule: ! alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \ (msg: "IDS439 .Complex Rule #2: Myscan ! Background: Port scanner. ! Allows remote detection of available services and OS fingerprinting. Combined with the ability to determine the OS. This particular scanner can allow an attacker to easily determine what services are available on a host. increasing the accuracy. For this scanner certain packet attributes are hard coded in the original source code. 16 . This allowing an accurate rule to be written that can easily detect scans from this software. ack: 0. \ flags: S.

! Source defined by variable ! • $EXTERNAL_NET = !$HOME_NET ! Destination defined by variable • $HOME_NET = your network 17 This rule when triggered will alert – meaning it will create an entry in the alerts file and create a log file. If the source port is anything but 10101. which means that the source address can be any IP address except the IPs belonging to your network. \ ack: 0. unless these options are overridden by command line options.) ! Examine the rule header: Will ‘alert’ when triggered. This means the rule does not care what port is used on the destination host. Both of these variables are typically defined at the top of a rules file. it will not match the rule header information and this rule will not be triggered. The source port the traffic must originate from is port 10101. specified by the keyword ‘any’. ttl: >220. The destination address is specified by the variable HOME_NET. The destination port can be anything. In most cases EXTERNAL_NET is set to !$HOME_NET.Scan -myscan". It also only applies to TCP traffic that meets the criteria of the rest of the signature. The source address is specified by the variable EXTERNAL_NET. 17 . ! Applies only to TCP traffic. flags: S.Complex Rule #2: Myscan (cont. This variable is set to the IP address range your sensor is to monitor.) alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \ (msg: "IDS439 . but may also be set by command line options.

acknowledgement number (ack) and the TCP flag settings are examined. Low likelihood of being false positive.) ! Examine the rule options: ! ! ! Time to live value must be greater than 220. time to live. TCP flags. but a very high likelihood that if it is triggered that it is NOT a false positive.Scan -myscan". 18 ! Likelihood of false positives: ! ! In this rule’s option section. 18 . TCP flag SYN must be set.) alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \ (msg: "IDS439 . Low likelihood of occurrence. The last attribute. flags: S. Acknowledgement number must be zero (0). the acknowledgement number. must have the SYN flag set. \ ack: 0. there is a low likelihood that the rule will be triggered. the packet attributes time to live (ttl). The second attribute.Complex Rule #2: Myscan (cont. There are many key items that lead to this conclusion and show that this rule is a very well written one. The first attribute that is examined. The next slide will show you the individual parts that combined together make this happen. ttl: >220. must have a value greater than or equal to 220. For this rule. must be zero (0).

The second item that helps tune this rule is the time to live value. it is very unlikely – but possible. Cannot normally be set to zero (0).) ! ! ! ! Source Port ! High into ephemeral ports (non-reserved). The last item that contributes to the rule’s tuning is the acknowledgement attribute value. but it will not identify the utility being used). and by making a single simple alteration and recompiling it the rule will no longer detect it (although Snort’s scan detection preprocessor should detect it. However it does depend on the above settings in the crafted packet not to be changed. Only in a crafted packet will this value ever be used. start at 1024 and go up.Scan -myscan". ! Rule vulnerable to mutations.x operating system sets the time to live attribute to a value greater than 220. Under normal conditions. the acknowledgement number can never be zero. Most operating systems specify a value much less than 220 when the packet is created. By specifying a specific value.101. Ephemeral ports. 19 Time To Live ! Acknowledgement Number. Only the Solaris 2. 19 . so for a source address to reach 10.) alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \ \ (msg: "IDS439 . ack: 0. The source code for this utility is freely available. only source addresses using that specific port might cause a trigger. The rule specifies that this attribute must be set to the value zero (0).Complex Rule #2: Myscan (cont. They are typically used in sequence. The first item that helps tune this rule is the specification of a specific port for the source port. it must have made many connections to other machines. meaning the non-reserved ports. Only one OS uses setting greater than 220. that source port will be used. ttl: >220. All of the above combine to make this a finely tuned rule that will not false positive very often. All other operating systems use values much less than 220. Because the source port is such a high number. This makes it vulnerable to mutations of the scanning utility. flags: S.

They are also the easiest to avoid triggering by making slight alterations in the application’s source code. 20 .Rule Analysis: Advanced Rules 20 This section provides analysis of advanced rules – those using more sophisticated packet attributes to examine the packet’s payload. These types of rules also have the lowest likelihood of false positives because of the completeness of the examination of the packets. These rules are the most difficult to write because they require close analysis of an attack’s signature and of the source code of the attack application if available.

Signature based on rule header.org web site and from the www.com. the signature doesn’t just consist of the contents of the rule header. This section will continue to build on the rule analysis technique that was used in the first section. ! Use logical approach ! Analyze rule header first ! Analyze rule options next ! • Specifies specific packet attributes • Can increase accuracy – decrease false positives 21 This section concentrates on analyzing more complicated rules – those containing packet attributes in the rule options section.snort.com web site.org rule set and www. Interpretation of the rule option section with different kinds of packet attributes will be introduced here. ! Examples taken from www.Rule Analysis: Advanced Rules ! Learn to analyze difficult rules. The example rules used in this section are real world rules. By adding packet attributes (such as TCP flags) to the rule options section. it’s possible to make rules more accurate.whitehats. They have been taken from the rule sets available at the www.snort.whitehats. which can potentially reduce the number of false positives. 21 . It consists of the rule header and additional information specified in the rule options. ! Signature also based on rule options. In these rules.

flags: PA.) \ \ \ 22 The first advanced rule we will examine is one that exploits a bug in an ftp daemon provided by www. ! ! Rule: ! alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg: "IDS458 .c exploit which was originally distributed in a broken form.wu-ftpd. 22 . ! Allows instant root access. as well as coming native in many Linux distributions.org that is used as a replacement for many native ftp daemons on some flavors of Unix.Advanced Rule #1: Wu-FTP Exploit ! Background: Exploits a bug in wu-ftp daemon. the attacker is instantly granted root access on a high numbered port that is opened up.FTP wuftp260-tf8". If the exploit is successful. content: "|31C0 31DB 31C9 B046 CD80 31C0 31DB 4389 D941 B03F CD80|". In this case the exploit is known as the wuftp2600.

23 .FTP wuftp260-tf8". The source address is specified by the variable EXTERNAL_NET. In most cases EXTERNAL_NET is set to !$HOME_NET. which means that the source address can be any IP address except the IPs belonging to your network. \ content: "|31C0 31DB 31C9 B046 CD80 31C0 31DB \ 43 89D941 B03F CD80|". flags: PA.) alert tcp $EXTERNAL_NET any -> $HOME_NET 21 \ (msg: "IDS458 . the packet must be destined for port 21. However. It also only applies to TCP traffic that meets the criteria of the rest of the signature. The source port is set to the keyword ‘any’. meaning that the TCP packet can originate from any possible port on the source host. This variable is set to the IP addresses your sensor is to monitor.) ! Examine the rule header: Will ‘alert’ when triggered. ! Source defined by variable ! • $EXTERNAL_NET = !$HOME_NET ! Destination defined by variable • $HOME_NET = your network 23 This rule when triggered will alert – meaning it will create an entry in the alerts file and create a log file. Both of these variables are typically defined at the top of a rules file. Port 21 is a well known reserved port that is used to provide FTP services. The destination address is specified by the variable HOME_NET. unless these options are overridden by command line options. ! Applies only to TCP traffic. but may also be set by command line options.Advanced Rule #1: Wu-FTP Exploit (cont.

hence this rule’s high level of accuracy. detects will very rarely occur primarily because of the very specific content that is being searched for. ! ! Likelihood of false positives: Low likelihood of occurrence. The first attribute is the TCP flag settings. two packet attributes are examined in order to detect the exploit. which is denoted by the enclosing pipe (‘|’) symbols. The content value. The second attribute specified examines the packet’s payload. flags: PA. is very unlikely to occur during a normal FTP session. although possible.Advanced Rule #1: Wu-FTP Exploit (cont. This rule is tuned ever so slightly by the TCP flags attribute. ! Examines payload for specific values. \ content: "|31C0 31DB 31C9 B046 CD80 31C0 31DB \ 4389 D941 B03F CD80|". For this rule. The exploit detected here works by initiating a proper TCP connection. the PUSH and ACK TCP flags must be set. 24 .) alert tcp $EXTERNAL_NET any -> $HOME_NET 21 \ (msg: "IDS458 . These packets will have the PUSH flag set indicating that data is being sent. ! Low likelihood of being false positive. more specifically an anonymous FTP session and initiating a buffer overflow. ! 24 For this rule. however these are typically other exploits which this rule doesn’t apply to and should have a different rule written to detect them. When detects do occur. Only packets with a payload should be applied against this rule.FTP wuftp260-tf8". it’s very likely that it is a positive detect. In this example the content that is being searched for is given in hex values. For this rule. It’s possible to have other flag settings without the PUSH flag set and still have a payload.) ! Examine the rule options: TCP flags PUSH and ACK must be set. The examination of a packets payload is triggered by specifying the keyword ‘content’.

which limits the possible ramifications of a successful attack that might exist on a Unix or Windows NT machine.exe|0d0a|user". offset:4.Advanced Rule #2: cgitest. which is one of the more lethal types of attacks an attacker can use. The web daemon affected by this vulnerability runs on Windows 95. The exploit works because of a buffer overflow vulnerability.) \ \ \ 25 The second advanced rule we will examine is a web based exploit. ! ! Rule: ! alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"IDS265 . flags: AP.Web cgi cgitest".exe’ is a CGI that if it is left installed on a particular web server can allow a remote attacker to execute arbitrary code on the web server. content:"cgitest. 25 .exe Exploit ! Background: Web exploit. ! Allows arbitrary execution of code on server. The ‘cgitest. nocase.

It also only applies to TCP traffic that meets the criteria of the rest of the signature. which means that the source address can be any IP address except the IPs belonging to your network. the packet must be destined for port 80.) alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"IDS265 .Advanced Rule #2: cgitest. content: "cgitest. but may also be set by command line options. the rule should be duplicated for each of the ports being used. meaning that the TCP packet can originate from any possible port on the source host. The source address is specified by the variable EXTERNAL_NET. This variable is set to the IP addresses your sensor is to monitor. The destination address is specified by the variable HOME_NET. 26 . flags: AP. In most cases EXTERNAL_NET is set to !$HOME_NET. If there are web daemons used on your network using alternative ports.Web cgi cgitest". Both of these variables are typically defined at the top of a rules file. However. offset:4. The source port is set to the keyword ‘any’. unless these options are overridden by command line options. nocase. Port 80 is one of the most common ports used for web daemons.exe Exploit (cont.) \ \ \ ! Examine the rule header: Will ‘alert’ when triggered.exe|0d0a|user". ! Source defined by variable ! • $EXTERNAL_NET = !$HOME_NET ! Destination defined by variable • $HOME_NET = your network 26 This rule when triggered will alert – meaning it will create an entry in the alerts file and create a log file. ! Applies only to TCP traffic.

although possible. it can appear in any possible combination of upper and lower case letters possible.Advanced Rule #2: cgitest. effectively ignoring the first 3 bytes. and then executing the ‘cgitest. it can be tuned by specifying the ‘offset’ and ‘depth’ options.) alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"IDS265 .exe Exploit (cont. it’s very likely that it is a positive detect. The examination of a packets payload is triggered by specifying the keyword ‘content’. The first attribute is the TCP flag settings. ! ! Likelihood of false positives: Low likelihood of occurrence. flags: AP. however these are typically other exploits which this rule doesn’t apply to and should have a different rule written to detect them. These options reduce the amount of a packet’s payload that must be inspected by Snort.Web cgi cgitest". Note the use of the ‘nocase’ option. ! Examines payload for specific values. ! 27 For this rule. When detects do occur. only the ‘offset’ option is used. The exploit detected here works by initiating a proper TCP connection to a web server. For this rule. This example shows how ASCII and hex values can be combined to form a payload signature. ! Low likelihood of being false positive. This rule tells Snort to start examining the payload 4 bytes in. This informs Snort that for the ASCII content being searched for. two packet attributes are examined in order to detect the exploit. content: "cgitest. The content value. This may not seem like a lot. detects will very rarely occur primarily because of the very specific content that is being searched for. and can be interspersed between each other. the PUSH and ACK TCP flags must be set. For this rule.exe|0d0a|user". 27 . The second attribute specified examines the packet’s payload.) \ \ \ ! Examine the rule options: TCP flags PUSH and ACK must be set. It’s possible to have other flag settings without the PUSH flag set and still have a payload. is very unlikely to occur during a normal web sessions by chance. Only packets with a payload should be applied against this rule. This rule is tuned ever so slightly by the TCP flags attribute. offset:4.ext’ CGI on that server and causing a buffer overflow. The content attribute can be a very resource intensive attribute to use. but by ignoring 3 bytes of every packet on a very busy network can quickly add up. In this example the content that is being searched for is a combination of two sections of ASCII data and one section of hex values. To help reduce the overhead of processing that must take place. These packets will have the PUSH flag set indicating that data is being sent. In this rule. nocase.

Writing Rules 28 In this section will demonstrate how to write a few rules from scratch of increasing difficulty. followed by a possible solution. Keep in mind that for some types of rules there may be several possible answers. A specification for a needed rule will be provided. all of which may be correct. 28 .

Please briefly pause this presentation now and resume it when you have written the rule. using the variable HOME_NET to represent your network address space. He would like to have Snort record this packets for future analysis and to see if there are any trends. The rule should both alert and log. Write the rule using the variable HOME_NET to represent your network address space.Writing Rules: Simple Rule ! Your boss wants to know about all ICMP echo requests (pings) coming into your network. 29 . 29 Your boss is concerned about inbound ICMP echo requests from outside addresses. Write the rule. The alert message should contain the text ‘Inbound Ping’.

Therefore the protocol field is set to ICMP. so specifying the not sign (‘!’) with the HOME_NET variable represents all addresses except those in your network. To do this. We were told that the variable HOME_NET would represent our internal network. the rule is to both alert and log. and the source address field is set to ‘!$HOME_NET’.Writing Rules: Simple Rule (cont. We also used the ‘itype’ attribute with a value of ‘8’ to limit the rule to only record echo requests – otherwise known as pings. In the rules option section we set the message option to the appropriate value as requested. itype: 8. We could have used any value for this field. 30 . it will be ignored by Snort when evaluating a packet against this rule. It is needed only to satisfy the rule parser when Snort reads and process the rules file on startup.) ! Possible Answer: alert icmp !$HOME_NET any -> $HOME_NET any \ (msg:“Inbound Ping". the rule’s action field must be set to the value ‘alert’. but ICMP does not use ports so we used the keyword ‘any’ as a placeholder.) 30 According to the specification given on the previous slide. Snort rules always require a port to be specified. We were also told to only record inbound ICMP echo requests.

31 . Please briefly pause this presentation now and resume it when you have written the rule.1. The address space at the satellite office you work at is the Class B 10. you decided to write a rule to ignore inbound packets from this scanning box.Writing Rules: Simple Rule #2 ! Corporate headquarters routinely runs a scan of all IPs owned by the company. corporate headquarters decided to run a periodic scan against all IP addresses the company owns.x.1. Write a rule that will cause Snort to ignore all inbound TCP packets from the scanning machine.x.168. Tired of filtering through the false positives caused by this routine scanning. 192. including the satellite office you work at. including satellite offices. What command line option must also be included? 31 In order to try to keep a step ahead of the hackers.1. Also list the command line option that must be included for this rule to be effective.

1/32 any -> 10. To reverse this order. This tells Snort to drop the packet being inspected when the rule is triggered.0. then alert and log rules. indicating that we don’t care what the source port is.168. Snort must be told to process the ‘pass’ rules first. but also has a special requirement that must not be forgotten.1. the keyword ‘any’. By default Snort processes alert and log rules first. This can be a useful capability in order to reduce false positives or to ignore traffic from a particular host. The destination address field is set to the proper CIDR notation for the satellite office. 192.0. The destination port is set to the same value as the source port.1.0/16. To ignore packets. In order for this rule to be effective. The source address was set to the specific host from corporate headquarters. Since the source port can vary. so the protocol field in the rule was set to the value ‘TCP’. the rule’s action field must be set to the value ‘pass’. This effectively ignores pass rules.0/16 any ! Snort Command Line: ! Snort –c snortrules -o 32 This is a simple rule to write.) ! Possible Answer: ! pass tcp 192.1.1. the keyword ‘any’ was specified. it can be any in the entire range possible. you must specify the ‘-o’ option.168. You were told this rule should ignore TCP traffic. 32 . 10. This causes Snort to process pass rules first. then the pass rules last.Writing Rules: Simple Rule #2 (cont.1.

33 . Write a rule to log all activity to this server (192. In order to investigate this matter further.1.Writing Rules: Difficult Rule ! Odd behavior has been detected on your anonymous FTP server. 33 During routine monitoring of your logs on your anonymous FTP server.0 class C address space.168.2) to a single file.1.1. you have decided to log all FTP activity to this server to a separate log file so you can see the full session. Please briefly pause this presentation now and resume it when you have written the rule. Write a Snort rule that will accomplish this. The source of the possible anomalous behavior is the 10. you have detected some behavior that just doesn’t seem normal.

we specified the ‘log’ action. 34 . For the destination address we specified its full IP address in CIDR notation. session: printable. we have specified the ‘session’ option which will record all printable (ASCII) information.1. but just in case the traffic is hostile and the attacker tries to use a reserved port we decided to use ‘any’ instead. We have also redirected the output to the file ‘anonftp’ by using the ‘logto’ option. For the source IP we specified the class C where the potentially hostile traffic is originating from using CIDR notation.Writing Rules: Difficult Rule (cont. To record the activity.) \ \ 34 For this rule.168. We could have specified the range of ports from 1.) ! Possible Answer: log 10.2/32 21 (msg: “FTP activity to anonymous FTP server”. This will conveniently log all of the activity to a single file making it easy to review any activity that is recorded. logto: “anonftp”. Since the source port can be any of the ephemeral ports.1.024 and up.1. we decided to specify the keyword ‘any’.0/24 any -> 192. We don’t really want to have every packet’s header written to the alerts file. we really don’t care about having them. along with the destination port of 21. Port 21 is the ‘control’ port for FTP sessions where we can record the commands and responses of the user and server.

The scan originates from port 53 to port 53 and has a TCP sequence number of 123456789 for every packet. Oddly enough there is a payload of varying length that always contains the string ‘Boo!’ imbedded somewhere. Although there is a payload.1. The network being monitored is the class C address space of 192. 35 . 35 The next rule to write is one for a new fictitious scan that has been seen recently.168. the PUSH flag is not set. Please briefly pause this presentation now and resume it when you have written the rule. The only TCP flag set is the SYN flag. The packets also include the payload ‘Boo!’ and have only the SYN TCP flag set. Write a rule that will both alert and log.Writing Rules: Advanced Rule ! A new (fictitious) probe has been detected from a new scanner called ‘pr0b3z’. and each packet has the same sequence number. This particular scan use port 53 for both the source and destination ports.x.

we have set both in the rule to that number. In the rules option section we specified on output message that’s descriptive and will mean something to us when we review the alerts file and log data later.) 36 For this rule we set the action field to the standard ‘alert’ action. These scans can originate anywhere so we have specified the keyword ‘any’ as the source IP. Since both the source and destination ports use 53. But. content: “Boo!”.1. We want this activity to be written to both the alert file and the log file – especially if we later run SnortSnarf on these files which we use during our analysis work.168. For the destination addresses we specified our network using standard CIDR notation. The content option was used to search packets for a payload that contains the ASCII string ‘Boo!’. We’ll specify this in the rule using the ‘flags’ attribute and this will indirectly limit the amount of payload processing Snort will have to do because although it is possible to have a payload in a SYN packet it is a rare occurrence.Writing Rules: Advanced Rule (cont. 36 . According to the description this string can appear anywhere in the payload. \ seq: 123456789. We used the ‘seq’ packet attribute to specify the sequence number. flags: S.0/24 53 \ (msg: “Inbound Scan: Pr0b3z”. From the description we have been given the sequence number is the same for all packets. so we can’t specify the ‘offset’ or ‘depth’ options to limit the amount of processing Snort will have to do.) ! Possible Answer: alert any 53 -> 192. the description given to use said that the packets only have the SYN flag set. and no other flags.

showing how the detects being monitored for are provided to you when they are detected. This last section will what you have learned and tie it all together showing how those rules would be used in real world situations. 37 .Tying It All Together 37 You have learned how to write rules and all of the syntax and keywords that go along with it. Sample Snort output is supplied as well.

5.2 root root 4096 Mar 22 06:58 1. Examining the alert file. if it detects any packets that match any of the rules it will write the activity out to the alert file and to a logging subdirectory in a log file. but the log files can contain additional information the alert files does not if certain options are turned on.5. The content of these files is similar. While Snort is running. After Snort has run for a while and detected anomalous behaviour.Specifying Rules File snort -c snort-lib ls -l /var/log/snort drwx-----.2. it will write the activity to the alerts file and the log directory and files. we see that the information it contains is simply the message from the triggered rule and the header information from the packet. and turn on additional options that cannot be specified by command line options.880120 1. Snort will process the file to build a list of anomalies to detect for alerting and logging. 38 . Special Note: This directory must already exist.3.5:80 TCP TTL:46 TOS:0x0 ID:19678 ******A* Seq: 0xE4F00003 Ack: 0x0 Win: 0xC00 38 When using Snort. Snort will not create this directory automatically if it does not exist.2. The default directory Snort writes all of its output to is ‘/var/log/snort’.1 root root 2512 Mar 22 06:58 alert cat alert [**] NMAP TCP ping! [**] 03/21-13:33:51.4 -rw------.5 drwx-----. The ‘-c’ command line option is the one you will use to do this. you will most often use it along with a rules file which tells Snort what to consider as hostile. With this option you specify the rules file that you want to use.4:60216 -> 192. Instead.168.3. Snort will issue an error message and exit.2 root root 4096 Mar 22 06:58 192.168.

ls -l total 12 -rw------.5. 39 .168. The reason this traffic was logged there is because a rule fired that checks for traffic to or from port 12345.4 traffic to destination port 2985.3.168.192.5.5:12345 -> 1.) snort -c snort-lib cd 192.1 root -rw------.5. Changing directories to one of the ones listed .5 . For instance.168.2.168.3.5.5 that used the TCP protocol and has a source port of 12345 and a destination port of 2985. Examining the contents of that file you see that source IP 192. the file TCP:12345-2985 represents activity from the host 192.2.5 sent IP 1.Specifying Rules File (cont.5.we see additional files that house all logged activity originating from that IP. we will examine one of the log subdirectories found in ‘/var/log/snort’.275350 192.5.168.1 root -rw------.4:2985 TCP TTL:64 TOS:0x0 ID:9173 DF **S***** Seq: 0x9C9B544A Ack: 0x0 Win: 0x7D78 TCP Options => MSS: 1460 SackOK TS: 9306314 0 NOP WS: 0 root root root 232 Mar 22 06:58 TCP:12345-2985 232 Mar 22 06:58 TCP:12346-1611 243 Mar 22 06:58 TCP:6969-2701 39 Continuing from the previous slide.1 root cat TCP:12345-2985 [**] Netbus/GabanBus [**] 03/21-13:33:54. A well known trojan named Netbus uses this port.

as well as creating the logging directories and log files here.1 root root root root 4096 Mar 22 08:16 1./log " " " Output placed in directory .2. Remember – the directory you tell Snort to write the alert and logs to must already exist. Snort will then record all alerts to an alert file in this directory. You can specify a default directory by using the ‘-l’ option and the name of the directory where you want the information placed. Snort places the logs and alerts in /var/log/snort.2 root drwx-----.2 root 192.Log Alerts to Directory .5.3./log snort -c snort-lib -l . This is the same as if everything was written to the default directory ‘/var/log/snort’. we have created a log file in the current directory and want the activity recorded there.168.4 4096 Mar 22 08:16 2512 Mar 22 08:16 alerts 40 By default./log alerts file contains alerts generated by Snort IP subdirectories with logged payloads ls -l . Snort will not create this directory on its own. 40 ./log drwx-----. In this case.5 -rw-------.

The log files (or file if you are logging in binary format) are the only place the FULL packet will be written out to including the payload. There are also output plugins available to log packets to a XML formatted file as well as a variety of SQL databases (e. MySQL. Depending on other command line options or rules options you use.Logging Options • Default: Full logging to default Snort directory Binary: tcpdump binary output to a single log file None: Disable logging Database: Log packets to SQL database XML: Log packets in portable XML format 41 • • • • The default method of logging is to capture the output generated from Snort detects and store it in the default Snort directory /var/log/snort. PostgreSQL. Alternatively. this will log the traffic that triggered the scan in some kind of human readable format. This is often done with high traffic volume so as not to bog down Snort with the logging process. logging can be totally disabled if not desired. you can take any detect that is discovered and log in tcpdump raw output binary format. This is only recommended if you are not interested in the payload of packets that trigger rules. Oracle) Finally. 41 .g.

The default method is to capture the detect in the file /var/log/snort/alert. but write them to the syslog facilities. as well as to an XML formatted file. followed only by a data/timestamp and source and destination ports and addresses. the message (if any) in the rule is written to the alert file first. Syslog alerts send messages in a format similar to the fast alerts. When using this level of alerting.Alerting Options • • • • • • • Full: writes alert message and header information to alert file (default) Fast: writes alert message and condensed header to alert file None: disable alerts Syslog: send alert messages to syslog SMB: send WinPopup messages to Windows hosts via ‘smbclient’ Database: Send alerts to SQL database XML: Write alerts in a portable XML format 42 Alerts are an abbreviated format of capturing the detect. Windows host via SMB alerts. The fast method writes partial information to the alert file. Fast alerting does not include the full packet header information. 42 . None will disable alerting all together. followed by a date/timestamp and full packet header information. Fast alerting on the other hand writes the message (if any) in the rule is again written first. There are also options available to send alerts to a database. Full alerting is Snort’s default behaviour.

the alert files exist merely to give the user a single place to monitor for Snort events. such as specific exploits or specific hosts. and the contents are files named according to the protocol and ports involved. This is a better overview of what is happening on the network versus the more detailed captures for logging. Alerts are more abbreviated captures of the detect that can all be found in a single file. It also provides a convenient one stop place to do quick searches for items that may be of interest. Logs exist to allow the user to analyse the exact packets that caused an alert in addition to any other packets that are possibly related to the alert event. Logging will create multiple files under multiple directories based on the IP number of the source host. 43 . Logging and alerting are conceptually different in a few ways.possibly decoded through application layer 43 You may be wondering what the difference between logging and alerting is.Alert and Logging Differences • • • • • Alerts are all contained in one file Alerts are decoded through transport layer only Logging produces multiple files Logging creates a directory structure by IP numbers Subdirectories contain activity . The directory name (IP number) indicates the source IP that triggered the logging activity. The log files are there to allow follow forensic analysis of events. Alerts exist to let the user know that something has happened and to give that user enough information to decide whether the alert warrants further investigation immediately. The actual contents of the files record the payload of the packet(s) involved.

Alert and log records are identical.200. Optionally following the date and timestamp is the ethernet information. log file only) 44 This slide shows you the general format of the alert and log files. This essentially labels each detect as it is written to disk. 44 .. Relayi ng denied.775359 FF:FF:FF:FF:FF:FF -> FF:FF:FF:FF:FF:FF type:0x800 len:0x71 Date. making it easy to determine why the packet was logged.Alert and Logging Format [**] IDS249 .7. The next item written is a date and timestamp.168. Timestamp Ethernet (optional) DF 192.1.2:25432 TCP TTL:255 TOS:0x0 ID:24915 *****PA* Seq: 0x30AC5391 Ack: 0x1E3E4A55 Win: 0x2238 Packet Header (varies) 35 35 30 20 35 2E 37 2E 31 20 3C FF FF FF FF 2D FF FF FF FF FF FF 40 FF FF FF FF FF FF FF FF FF FF 2E 63 6F 6D 3E 2E 2E 2E 20 52 65 6C 61 79 69 6E 67 20 64 65 6E 69 65 64 0D 0A 550 5. Both log and alert messages start with the message text included in the rule. Next. The date and timestamp represent the time on the sensor when the detect was made.168.1 <blahblahrs@blahblahb l. both the hex representation of the payload and the ASCII printable characters will be displayed.. with the exception of the packet payload which can be optionally included in the log files.. Packet Payload. the source and destination addresses and ports involved in the detect appear. If the packet payload is included in the logs. followed immediately by the packet’s decoded header information which can vary depending on the protocol of the packet.2:25 -> 192.SMTP Relaying Denied [**] Alert/Log Message Text 10/09-02:34:59. Hex and ASCII (optional.com>.

168.168. The above rule will be used for most of the detects.Logging/alert Examples • The following rule will be used to test various options to log and alert: \ \ alert tcp any any > 192.143 network that has the PUSH and ACK flags set and has a content of 'anonymous' in the payload. We will put this single rule in the rules file name ‘snortrules’ to simplify the logging and alert messages generated.143. Content: "anonymous". nocase) • Place the above rule in rules file ‘snortrules’. 45 In the next several slides.0/24 21 (msg: "anonymous FTP attempt". This rule says that we want to alert if any ftp connection is generated to the 192. 45 . different options will be shown to explain various logging and alerting choices. flags: PA.

It contains the packet information decoded through the TCP transport layer as can be seen by examining the file.168.143 network using a username of anonymous.168.143. It contains the output that was generated for the detect. we specify that we want to use a default logging directory of logdir. We run Snort using our one rule found in ‘snortrules’. what you don't see above is we attempt to ftp to a host on the 192.16:21 TCP TTL:64 TOS:0x10 ID:18558 DF *****PA* Seq: 0x7C451B73 Ack: 0x7DC44632 Win: 0x7D78 TCP Options => NOP NOP TS: 27713449 92831 46 In this first example. If we examine the contents of logdir directory. Next.143. we notice that there is a file named ‘alert’. This has to be an existing directory.350754 192. in this case since we did not specify the alert level Snort will default to ‘full’.15:1536-> 192.Alert and Log snort -l logdir -c snortrules In directory logdir you will find a file named alert. 46 . That triggers a detect and causes Snort to create an entry in the alerts file. [**] Anonymous FTP attempt [**] 04/28-11:58:06.168.

15 contains a file: TCP:1536-21 [**] Anonymous FTP attempt [**] 04/28-11:58:06. The subdirectory 192.143. we discover a subdirectory 192.143. We find the same message generated in the alert file.168.168.168.Alert and Log (Cont) The directory logdir contains a subdirectory named: 192.143. we discover a file name TCP:1526-21.15 that represents the hostile IP that attempted the anonymous ftp access.15. 47 .168.168.143.15:1536 -> 192. The filename identifies the protocol (TCP) as well as the source (1526) and destination ports (21) involved in the detect.350754 192. This is a log directory.143.16:21 TCP TTL:64 TOS:0x10 ID:18558 DF *****PA* Seq: 0x7c451b73 Ack: 0x7dc44632 win: 0x7d78 TCP options => NOP NOP TS: 27713449 92831 47 In the same logdir directory. If we ‘cd’ into that directory.

48 . It also still contains the full packet header information.888357 192.Alert and Log With Decode snort -l logdir -c snortrules -d In directory logdir the file alert has the following contents: [**] Anonymous FTP attempt [**] 04/28-12:03:59.143.168.143.15:1537 -> 192. which says to decode the application layer. still written in a human readable format.168.16:21 TCP TTL:64 TOS:0x10 ID:20566 DF *****PA* Seq: 0x7C451B73 Ack: 0x7DC44632 Win: 0x7D78 TCP Options => NOP NOP TS: 27713449 92831 48 Now we add the ‘-d’ option to the same command used previously. We follow the same process as before and discover that we have an alert file in logdir which is the same as before. the date/timestamp and the hosts involved. The alert file still contains the message from the triggered rule. Note that the contents of the alert file have not changed from what would normally be recorded.

888357 192.15:1537 ->192..143.168.168. while the right portion contains the ASCII representation.143. The directory 192.168. you will not only see the information contained in the alerts file.143. 49 If you now look at the log file.168. The left portion contains the hex values of the payload.Alert and Log With Decode (Cont) The directory logdir contains the subdirectory 192.143. The output of the packet’s payload is broken into two parts. but now the actual payload of the packet at the bottom of the alert. 49 .15.15 contains file named: TCP:1537-21 [**] Anonymous FTP attempt [**] 04/28-12:03:59.16:21 TCP TTL:64 TOS:0x10 ID:20566 DF *****PA* Seq: 0x94102D52 Ack: 0x94529A7B Win: 0x7D78 TCP Options => NOP NOP TS: 27748803 128108 55 53 45 52 20 61 6E 6F 6E 79 6D 6F 75 73 0D 0A USER anonymous.

16:21 TCP TTL:64 TOS:0x10 ID:18558 DF *****PA* Seq: 0x7C451B73 Ack: 0x7DC44632 Win: 0x7D78 TCP Options => NOP NOP TS: 27713449 92831 50 The ‘-b’ option allows you to log the packets to a tcpdump file instead of the normal decoded ASCII files.168. [**] Anonymous FTP attempt [**] 04/28-11:58:06. log in binary format.15:1536 -> 192. Instead Snort can open one file and continuously write to that file for the entire duration Snort is running.143.143.Alert and Log in Binary snort -l logdir -c snortrules -d -b The directory logdir contains the file alert. This creates a single binary file instead of creating many subdirectories with files in them that may contain only one packet. If you are deploying Snort on high capacity networks or Snort starts to drop packets. 50 . Logging using the binary format is much more efficient than having Snort write out a completely decoded packet in an ASCII format.168. It also relieves Snort from having to create directories and constantly opening and closing files to write out the information in ASCII format.350754 192.

The name has the date of the capture (0428 . This can be read either using Snort with the ‘-r’ option or with tcpdump with the ‘-r’ option.log This is a tcpdump binary output of entire packet. 51 In the logdir directory.log which is a tcpdump raw binary output file of the detect that was captured. 51 . This requires less work of Snort to capture and is used when there is a lot of traffic on the network and there is a concern for packets being dropped.April 28th) and the time of the capture (11:58 AM).Alert and Log in Binary (Cont) In directory logdir we find the following file: snort-0428@1158. we find a file snort-0428@1158.

. This option instructs Snort to read from tcpdump binary files instead of the network interface.. Also. or instructed Snort to log in binary.5.2. Readback mode can be especially useful for busy networks where full and constant processing on the sensor itself may not be feasible.data’ earlier and it contains tcpdump binary data. Note the ‘Entering readback mode’.3. 03/21-13:33:51.data’ instead of from the network interface. In that case you can pull the data back periodically and run Snort on the retrieved data without using extra CPU cycles on the sensor itself.raw. note the ‘snaplen = 144’.960219 1.168.Reading Tcpdump Files snort -vd -r tcpdump.168.5:693 TCP TTL:64 TOS:0x0 ID:7570 DF **S***** Seq: 0x9C55968F Ack: 0x0 Win: 0x7D78 TCP Options => MSS: 1460 SackOK TS: 9306083 0 NOP WS: 0 52 Another useful ability of Snort is the ‘-r’ command line option.. This is Snort’s way of informing you that it is reading from a file and not from the network interface.2.5:2307 TCP TTL:64 TOS:0x0 ID:7569 DF **S***** Seq: 0x9C857C3C Ack: 0x0 Win: 0x7D78 TCP Options => MSS: 1460 SackOK TS: 9306083 0 NOP WS: 0 03/21-13:33:51. In the example shown here.raw. This can be done if you've collected data using tcpdump from another sensor or other tcpdump compatible software.. sending the data to the screen. indicating that the software used to create the dump file collected 144 bytes for each packet collected. 52 .4:1399 -> 192. This assumes that we have collected ‘tcpdump.4:1398 -> 192. That is the tcpdump snapshot length.raw. we are using Snort in verbose mode.3. snaplen = 144 Entering readback mode.960269 1..data Initializing Network Interface.5. but this time we use the ‘-r’ switch to tell Snort to read its input from ‘tcpdump.

pl /var/log/snort/alert 53 There are tools available that will help you with the analysis of the alert and log files.com/snortsnarf/ snortsnarf. and you provide the directory the logs are located in. The SnortSnarf program is intended to help you view your Snort alerts in an orderly fashion using a web browser. 53 . SnortSnarf will allow you to drill down to the packet that triggered a specific alert. At the next level down.silicondefense.html) • Alert wrap-up html files • Specific source/destination alert html files • Optionally linked to log files for packet inspection • • Located in snort directory contrib subdirectory http://www. One tool that has proven to be popular as well as being very useful is SnortSnarf. This is easier than trying to assess what is happening by looking at the alerts file. SnortSnarf creates an index. and allows you to drill down from the general list of alerts to the specific packet that triggered the alert (providing logging was turned on and the decode option was specified). If logging was turned on in Snort. At the top level.html file containing a summarized list of alerts.Snortsnarf. an html file is created containing each of the same alerts in a single file.Pl • perl script to take alerts: – Formats Snort alert and log files into html output – Places output in following files for ‘drill down’: • Overall summary of detected alerts (index.

you can click on the signature name and a page displaying information about the signature will be displayed. For some signatures.alert •snort_portscan.SMTP Relaying Denied 1 1 1 Summary UDP scan 6 1 1 Summary Generated by Snortsnarf v100400. This page contains a summarized list of alerts that were triggered during the time period listed. such as the ‘SMTP Relaying Denied’ example shown here. The information displayed can include a sample rule that would detect the traffic. click on the summary link which will display a page containing information about the selected alerts.alert et al 7 alerts processed.775359 on 10/09 Latest alert at 03:00:36 on 10/9 Signature (click for definition) # Alerts # Sources # Destinations Detail link IDS249 . sample packets.1 (Jim Hoagland and Stuart Staniford) 54 This is a sample index page created by SnortSnarf.log Earliest alert at 02:34:59. number of times it was triggered. To see additional details. It lists the signatures that were detected.SnortSnarf Output Snortsnarf: Snort signatures in snort. Files included: •snort. and further explanation of the exploit. and the total number of source and destination hosts involved. 54 .

775359 on 10/09 IDS249 . Clicking on the source IP address will take you to the alerts triggered by that source host for this signature. Looking in files: •snort. the grant total of alerts triggered by the host for all alerts.1 (Jim Hoagland and Stuart Staniford) 55 When clicking on the link from the summarized index page.alert et al for signature: IDS249 .Summary of alerts in snort. This page lists all of the source and destination hosts involved with the selected alert. and the number of destination hosts involved for both of those totals. In this case only one alert of the type ‘SMTP Relaying Denied’ is listed and it involved only one source and destination IP. including all of the hosts that were involved.SMTP Relaying Denied 1 alerts on this signature. you arrive at this page.168.2 # Alerts (sig) 1 # Alerts (total) 1 # Srcs (sig) 1 # Srcs (total)) 1 Generated by Snortsnarf v100400.775359 on 10/09 Latest such alert at 02:34:59.alert •snort_portscan. The chart to the right of the address shows you how many alerts were triggered by that host for this specific alert. 55 .2 # Alerts (sig) 1 # Alerts (total) 1 # Dsts (sig) 1 # Dsts (total)) 1 Destinations receiving this attack signature Destinations 192. If there were multiple instances of this alert. they would all be listed here.200.SMTP Relaying Denied 1 sources 1 destinations Sources triggering this attack signature Source 192.log Earliest such alert at 02:34:59.1.168.

168. 192.alert •snort_portscan.216 as a source •1 instances of IDS249 .SMTP Relaying Denied Whois lookup at: ARIN RIPE APNIC Geektools There are 1 distinct destination IPs in the alerts of the type on this page.1.181.2 DNS lookup at: Amenesi Riherds Princeton [**] IDS249 .168.1.775359 on 10/09 Latest: 02:34:59.2 in snort.All 1 alerts from 192.SMTP Relaying Denied [**] 56 56 .775359 on 10/09 1 different signatures are present for 206.alert et al Looking in files: •snort.log Earliest: 02:34:59.216.

Sign up to vote on this title
UsefulNot useful