Snort rules

•Snort uses a simple, lightweight rules description language that is flexible and quite powerful. • The first is that Snort rules must be completely contained on a single line, the Snort rule parser doesn't know how to handle rules on multiple lines. •

Snort header and rule
• Snort rules are divided into two logical sections, the rule header and the rule options. • The rule header contains the rule's action, protocol, source and destination IP addresses and netmasks, and the source and destination ports information. • The rule option section contains alert messages and information on which parts of the packet should be inspected to determine if the rule action should be taken.

Snort header and rule
• Example rule : alert tcp any any -> 111 (content:"|00 01 86 a5|"; msg: "mountd access";). • The text up to the first parenthesis is the rule header and the section enclosed in parenthesis is the rule options.

Snort rules
• The words before the colons in the rule options section are called option keywords. • the rule options section is not specifically required by any rule, they are just used for the sake of making tighter definitions of packets to collect or alert on (or drop, for that matter). • All of the elements in that make up a rule must be true for the indicated rule action to be taken.

the various rules in a Snort rules library file can be considered to form a large logical OR statement. the elements can be considered to form a logical AND statement. • At the same time.Snort rules • When taken together. .

Rule Headers • Rule Actions: • The rule header contains the information that defines the "who.drop (ignore) the packet . • The first item in a rule is the rule action. alert. and then log the packet • log . log. where.generate an alert using the selected alert method. and what" of a packet.log the packet • pass . • There are three available actions in Snort. The rule action tells Snort what to do when it finds a packet that matches the rule criteria. and pass • alert . as well as what to do in the event that a packet with all the attributes indicated in the rule should show up.

udp. There are three IP protocols that Snort currently analyzes for suspicious behavior. • Tcp • Udp • icmp . tcp.Rule headers • Protocols:The next field in a rule is the protocol. and icmp.

the destination address would match on any address in that range. The CIDR designations give us a nice short-hand way to designate large address spaces with just a few characters.1. • The addresses are formed by a straight numeric IP address and a CIDR block.168. For example.1.168. • A CIDR block mask of /24 indicates a Class C network.Rule Headers • IP Addresses:The next portion of the rule header deals with the IP address and port information for a given rule.168. /16 a Class B network.1.255. Snort does not have a mechanism to provide host name lookup for the IP address fields in the rules file.0/24 would signify the block of addresses from 192. the address/CIDR combination 192. The CIDR block indicates the netmask that should be applied to the rule's address and any incoming packets that are tested against the rule. say. . • The keyword "any" may be used to define any address. and /32 indicates a specific machine address. Any rule that used this designation for.1 to 192.

1. msg: "mountd access". and the destination address was set to match on the 192.Address in a rule • alert tcp any any -> 192.1.). .168.0/24 111 (content:"|00 01 86 a5|". • The source IP address was set to match for any computer talking.168.0 Class C network.

168. This operator tells Snort to match any IP address except the one indicated by the listed IP address.0/24 any -> 192. msg: "external mountd access".1.1.0/24 111 (content: "|00 01 86 a5|".) • This rule's IP addresses indicate "any tcp packet with a source IP address not originating from the internal network and a destination address on the internal network". • alert tcp !192.Snort rules • There is an operator that can be applied to IP addresses. .168. • For example. The negation operator is indicated with a "!". an easy modification to the initial example is to make it alert on any traffic that originates outside of the local net with the negation operator. the negation operator.

23 for telnet.Port numbers • Port Numbers • Port numbers may be specified in a number of ways. • Port ranges are indicated with the range operator ":". ranges. static port definitions. or 80 for http. meaning literally any port. "Any" ports are a wildcard value. and by negation. etc. . Static ports are indicated by a single port number. The range operator may be applied in a number of ways to take on different meanings. such as 111 for portmapper. including "any" ports.

Example • log udp any any -> 192.1.0/24 1:1024 log udp traffic coming from any port and destination ports ranging from 1 to 1024 • log tcp any any -> 500: log tcp traffic from priveleged ports less than or equal to 1024 going to ports greater than or equal to 500 .1.0/24 :6000 log tcp traffic from any port going to ports less than or equal to 6000 • log tcp any :1024 -> 192.1.168.

1.Negation in port • Port negation is indicated by using the negation operator "!".168. • log tcp any any -> 192. The negation operator may be applied against any of the other rule types (except any. which would translate to none).0/24 !6000:6010 .

1.Directional operator in header • The Direction Operator • The direction operator "->" indicates the orientation. An example of the bidirectional operator being used to record both sides of a telnet session is • log !192.1. • There is also a bidirectional operator.0/24 23 . such as telnet or POP3 sessions. of the traffic that the rule applies to. This is handy for recording/analyzing both sides of a conversation. • The IP address and port numbers on the left side of the direction operator is considered to be the traffic coming from the source host.168. or "direction". and the address and port information on the right side of the operator is the destination host. This tells Snort to consider the address/port pairs in either the source or destination orientation.168.0/24 any <> 192. which is indicated with a "<>" symbol.

• All Snort rule options are separated from each other using the semicolon "." character. Rule option keywords are separated from their arguments with a colon ":" character.Rule Options • Rule options form the heart of Snort's intrusion detection engine. There are fifteen rule option keywords available for Snort: . combining ease of use with power and flexibility.

test the TCP sequence number field for a specific value • ack .test the ICMP code field against a specific value • session .test the IP header's TTL field value • id .search for a pattern in the packet's payload•offset .test the packet's payload size against a value • content .log the packet to a user specified filename instead of the standard output file • minfrag .modifier for the content option.test the ICMP type field against a specific value • icode .dumps the application layer information for a given session . sets the offset to begin attempting a pattern match • depth .test the TCP flags for certain values • seq . sets the maximum search depth for a pattern match attempt • flags .test the IP header's fragment ID field for a specific value • dsize .modifier for the content option.Rule option • msg .prints a message in alerts and packet logs • logto .test the TCP acknowledgement field for a specific value • itype .set a threshold value for the smallest acceptable IP fragment size • ttl .

• It is a simple text string that utilizes the "\" as an escape character to indicate a discrete character that might otherwise confuse Snort's rules parser (such as the semi-colon ". ." character). • Format: msg: "<message text>".Msg • The msg rule option tells the logging and alerting engine the message to print along with a packet dump or to an alert.

• Format:logto: "<filename>".Logto • The logto option tells Snort to log all packets that trigger this rule to a special output log file. .

there is virtually no commercial network equipment available that generates fragments smaller than 256-bytes. . • It is generally used in conjunction with a single alert rule to set a boundry for the minimum fragment size that is acceptable on a network segment. • Generally speaking.Minfrag • Minfrag sets a minimum size threshold for a fragmented packet. It makes a handy detector for attackers that like to break their fragments into tiny pieces before transmitting them to try to avoid detection mechaisms. so people can take advantage of this fact by setting their minfrag value somewhere below that threshold.

possible hostile activity".) . msg: "Tiny fragments detected. • alert tcp any any -> any any (minfrag: 256.Minfrag example • Format:minfrag: "<number>".

This option keyword was intended for use in the detection of traceroute attempts. • Format: ttl: "<number>". The test it performs is only sucessful on an exact match. .TTL • This rule option is used to set a specific time-to-live value to test against.

Some hacking tools (and other programs) set this field specifically for various purposes. • for example the value 31337 is very popular with some hackers. . This can be turned against them by putting a simple rule in place to test for this and some other "hacker numbers". • Format: id: "<number>” .ID • This option keyword is used to test for an exact match in the IP header fragment ID field.

if you know that a certain service has a buffer of a certain size. plus use the greater than/less than signs to indicate ranges and limits.Dsize • The dsize option is used to test the packet payload size. Note: The > and < operators are optional! . • For example. • It has the added advantage of being a much faster way to test for a buffer overflow than a payload content check. • Format: • dsize: [>|<] <number>. you can set this option to watch for attempted buffer overflows. It may be set to any value.

. the Boyer-Moore pattern match function is called and the (rather computationally expensive) test is performed against the packet contents. Bytecode represents binary data as hexidecimal numbers and is a good shorthand method for describing complex binary data.Content • The content keyword is one of the more important features of Snort. the test is successful and the remainder of the rule option tests are performed. it can contain mixed text and binary data.The option data for the content keyword is somewhat complex. . The binary data is generally enclosed within the pipe ("|") character and represented as bytecode. • Be aware that this test is case sensitive. If data exactly matching the argument data string is contained anywhere within the packet's payload. • It allows the user to set rules that search for specific content in the packet payload and trigger response based on that data. Whenever a content option pattern match is performed.

. • alert tcp any any -> 192.168.) • Format: content: "<content string>".1.Example of content • An example of mixed text and binary data in a Snort rule.0/24 143 (content: "|90C8 C0FF FFFF|/bin/sh". msg: "IMAP buffer overflow!".

. • Format: offset: <number>. • This keyword modifies the starting search position for the pattern match function from the beginning of the packet payload. Care should be taken against setting the offset value too "tightly" and potentially missing an attack! This rule option keyword cannot be used without also specifying a content rule option.offset • The offset rule option is used as a modifier to rules using the content option keyword. • It is very useful for things like CGI scan detection rules where the content search string is never found in the first four bytes of the payload.

(Which is to say.depth • Depth is another content rule option modifier. This sets the maximum search depth for the content pattern match function to search from the beginning of its search region. . • Format: depth: <number>. • It is useful for limiting the pattern match function from performing inefficient searches once the possible search region for a given set of content has been exceeded. you probably don't need to waste time searching the payload beyond the first 20 bytes!) search rule. if you're searching for "cgi-bin/phf" in a web-bound packet.

0/24 80 (content: "cgi-bin/phf". and depth • alert tcp any any -> 192.168.) .1. offset: 3. msg: "CGI-PHF attack". depth: 22. offset.Example • An example of a combined content.

There are actually 8 flags variables available in Snort: • F . such as IP stack fingerprinting attempts or other suspicious activity. Format: flags: <flag values>.PSH • A .Reserved bit 1 (MSB in TCP Flags byte) The reserved bits can be used to detect unusual behavior.URG • 2 .FIN (LSB in TCP Flags byte) • S .Reserved bit 2 • 1 .ACK • U . All of the flags are considered as a whole for this test. they must all be "up" for this rule option to be successful.RST • P .Flags • This rule tests the TCP flags for an exact match. .SYN • R .

168. msg: "Possible SYN FIN scan".0/24 any (flags: SF.Example • alert any any -> 192.1.) .

• Essentially. .seq • This rule option refers to the TCP sequence number. and is therefore pretty much unused. it detects if the packet has a static sequence number set. It was included for the sake of completeness. • Format: seq: <number>.

. This rule has one practical purpose so far: detecting NMAP TCP pings.ack • The ack rule option keyword refers to the TCP header's acknowledge field. • Format: ack: <number>. • A NMAP TCP ping sets this field to zero and sends a packet with the TCP ACK flag set to determine if a network host is active.

0/24 any (flags: A. ack: 0.Example • alert any any -> 192.1. msg: "NMAP TCP ping".168.) .

• For a list of the available values. • It should be noted that the values can be set out of range to detect invalid ICMP type values that are sometimes used in denial of service and flooding attacks. It is set using the numeric value of this field.itype • This rule tests the value of the ICMP type field. • Format: itype: <number>.h file included with Snort or in any ICMP reference. look in the decode. .

.icode • The icode rule option keyword is pretty much identical to the itype rule. • Format: icode: <number>. just set a numeric value in here and Snort will detect any traffic using that ICMP code value. • Out of range values can also be set to detect suspicious traffic.

. printable or all. so it shouldn't be used in heavy load situations. • Format: session: [printable|all].1 and is used to extract the user data from TCP sessions.3. • The printable keyword only prints out data that the user would normally see or be able to type. The all keyword substitutes non-printable characters with their hexadecimal equivalents. and is probably best suited for post-processing binary (tcpdump format) log files. There are two available argument keywords for the session rule option. ftp. • It is extremely useful for seeing what users are typing in telnet. or even web sessions. This function can slow Snort down considerably.session • The session keyword is brand new as of version 1.1. rlogin.

Advanced rule option • Versions of Snort after 1. .3.1. • Format: include: <include file path/name> Note that there is no semicolon at the end of this line. • The first of these keywords is include.2 include new rules file parsing functionality developed by Christian Lademann. including two new rules file keywords. Included files will substitute any predefined variable values into their own variable references. The include keyword allows other rule files to be included with the rules file that indicated on the Snort command line.

• Format: var: <name> <value> .3. variables may be defined in Snort.var • As of version 1.2.1.

1.0/24 • alert tcp any any -> $MY_NET any .168.Example • var MY_NET 192.

• $(var:?message) .replace with the contents of variable "var" or print out the error message "message" and exit . "?" and "-".replace with the contents of the variable "var" or with "default" if "var" is undefined.• The rule variable names can be modified in several ways. You can define meta-variables using the "$" operator.replace with the contents of variable "var” • $(var:-default) .define meta variable • $(var) . • These can be used with the variable modifier operators. • $var .

Example • var MY_NET $(MY_NET:192.0/24) • log tcp any any -> $(MY_NET:?MY_NET is undefined!) 23 .1.168.

168.) .session • log tcp any any <> 192.1.0/24 23 (session: printable.

Example • An example shows a SYN-FIN scan detection rule. .

 .439039  .


9 .439039.4390398973 .8 28!-:11074.0714 W 472.

 %87:045943047/.13./ W 98.7..07 14:3/390178914:7-90841905./ .24/10794 7:08:8390.79380.9.3349-0:80/ 94:9.:0 94499.3/549039.84850..03..07:801:14793808.8973830..3 ..1:3..411809 W %04118097:0459438:80/.4390397:045943 W 472. 548943147905.3/090.43903945943047/ W %8047/24/1089089.70 84:/-09.7.990732.4..43903980.4.3898099390411809.943 7:0807090.9 4118093:2-07 .99.2883.943174290 -033341905.8.095.

/059 W 0598.0380941.4390395.9.8948.990732.1:3.7.7043 W 98:801:147293905.03980.7.7043147.9439480.00/0/ .990732.0843.7.7.3147..8-0030.9. 14: 70 80.2:280.943 1742507147233011.1:3.090 5488-080.7.439039 .34907./059 14790.7. 174290-0333419880.4390397:045943 24/107 %88098902. -3.

9 /0593:2-07 .-/43 9300/94..3 905.4./-043/901789 -908  4:574-.513.0- -4:3/5.89092080. 7:0 W 472.

3//059 W .5..3.42-30/..3    .250 W 30.0799.25041.439039 411809  .

439039. -3.  .

99. ..51411809/059 28 !.

9:.8-90 %070807.92.4:8 .9:3:8:..70 .8.8!89.47 8:.130757393.8.3-0:80/94/090.8-90 W $ $ W # #$% W ! !$ W   W & &# W  #0807...30..:08 .-03$3479 W   $3%!..9 41901.8 W %87:09089890%!1.9..0/-98.7.8147.0881: 472. ..99025984749078:85....81.0/-9 W #0807.-0:5147987:04594394-08:.40147989089  902:89.0/-9 $3%!.9.. %070.-0.-08.438/070/..1...9 1.8.70.

3    .250 W .3.079..

..3 1.8$28!488-0$ 8.3 .

09.806 W %87:0459437010789490%! 806:03.4250903088 W 472.. 9/090.981905.03:2-07 W 88039.03:2-07809 .806:03.8 3.9.:/0/147908.9 8063:2-07 .8. 89.3/8 90701470570992:.041.:3:80/ 9.

5.7 /090....9.. W %0....843057.7:045943047/7010789490 %!0.5:75480841.0 W 472.93 !%!538 W !%!5380989810/94074 .309474898.9.3/803/8.9 .. 80994/09072301.09990%!1.340/010/ %87:0 ./07 8.3:2-07 ..

250 W .079.3    ..3.

8 . 28!%!53 ..3 1..

0 W 984:/-03490/9.41807..93..0...9 9503:2-07 .:08.7084209208:80/3/03.:0419810/ W 47.4/0 103..3-08094:9 417.:04190!95010/ 9 8809:83903:207....990.:08 44390 /0..3/ 144/3. .3! 7010703..:089.8 W 472.894190.-0.3094/090.9 .950 W %87:09089890.99..:/0/9$3479473./!950..

:0 W :9417.:08.98:85.3/$3479/090.397.4:897......4/07:045943047/857099 2:.9 .9 .4/0.4/0 W %0.4/03:2-07 .11.94909507:0 :89809.84-080994 /090.:839.3.30. 3:207..11. W 472../039.9!.:03070.

2.3/30.030-8088438 %070.841.-0.7:2039047/8147908088437:045943  5739.907899070.9438 ...3/8:80/94097.943.9.7..1742%!8088438 W 98097020:801:1478003.-0.4..9 4108 W 472.7094 .9.5/:251472.( .9.. W %05739.0398 %81:3.-0.7 9.. 06:.990:807 4:/3472./0..3/8574-.-0 047/43573984:9/.709533 90309 743 195 470.808843 W %0808843047/8-7..9 8088435739.0883 -3..80047-0.07843    .-0 47.438/07.- 84984:/3 9-0:80/30.990:807/. 047/ 8:-899:908343 5739.-094950 %0.9:8078./ 89:.384$3479/43 .--0898:90/1475489 574.

/.:/0 047/.9..3 .0/7:045943 W '07843841$3479.9 3.:/0105.33 3.:/0 %0 3.93/.7831:3.:/0/9907:08109.:/0307:08 105.4849077:010894-0 3.422.3/30 W 472.90/4390 $3479.0450/-789.943.3.:/03.:/394307:0810047/8 W %01789419080047/883.1907   3./02.9/0..

08 .443.99070834802.3570/0130/ ..:0839490743..3.-0.7.99003/4198 30 3.:/0/1088:-899:90.7..20 4909.-07010703.

-0 /0130/3$3479 W 472..73..7 W 841..07843    ..20.-082..:0 .7.9 .

..7*%   .250 W .

3.3 .3 *%.5.0799. W .

7.208...43903984190...-0.7 W  .3/  W . .7  705.02088.0990.7479/01.....7.3/0130209.439039841.:91. .-0 W  .7...07.8 4:.7.72088...3-024/10/380.7 /0130209.-0.-024/1074507.7 4757394:990077472088..0990.-0 .-03.9478  ..7..7.0  705...0..3-0:80/990.W %07:0.0990.78:3/0130/ W  .7 /01..3/09 ...:9  705.947 W %080..439039841.7.-08:8390 4507.

7*% *%    .250 W ...

5. W 49.3.3   *%*%8:3/0130/  .

3.5.808843 W 49.3   .

 8088435739.-0 .

3 /090.$ 8.250848...250 W 30.9437:0 .

Sign up to vote on this title
UsefulNot useful