7.3 Creating Your Own Rules

There are two separate elements that make up a typical Snort rule. We used an example previously to demonstrate a rule's composition. These next few sections explain in greater detail the individual portions of a Snort rule and how to create a customized rule for local use.

7.3.1 Snort Rule Headers

Rule headers make up the first section of a typical Snort rule. The header defines the who within the packet in question.

The rule header can be considered a brief description of the network connection. Four parameters define a unique network connection: Source IP, Source Port, Destination IP, and Destination Port. The header also includes the direction of the packet traverse, as defined by the -> or <> symbols. Using a basic example, we will break down a typical header into its component parts and explain what each part does.

Here is a portion of a standard rule alerting the user to a SYN FIN scan attempt. As shown in the example below, this scan is characterized by TCP data entering the internal network with the SYN and FIN flags set in the TCP header field. Snort looks for those flags within the packet and notes the reference and the attack's classification. The rule then prints out an alert that a scan was performed with SYN and FIN flags set.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN SYN FIN";flags:SF; reference:

arachnids,198; classtype:attempted-recon; sid:624; rev:1;)

The section enclosed within parentheses is referred to as the Rule Options section. Here is where the rule determines default messages, flags, and attack classification. Rule options are discussed later in this section.

The first field in the header is the Action field. In this example, an alert is the defined action when a matching signature is detected. The signature in this case is the presence of predefined flags set in the TCP header. Signatures within other rules may be matching payload content, other flags, or binary data. An entry is generated in the alert file within /var/log/snort when a matching packet is detected and the packet is logged in a specific directory based on its IP address.

Different values can be placed in the action field. Here are those values:

alert

Alerts and logs the packet when triggered.

log

Only logs the packet when triggered.

pass

Ignores or drops the packet or traffic matching.

activate

Alerts then activates a dynamic rule or rules.

dynamic

Ignores, until started by the activate rule, at which time, acts as a log rule.

The last two values are slowly being phased out, so do not expect to see them in later versions of Snort. The replacement option is called "tagging."

The next field is the Protocol field. This can be IP, TCP, UDP or ICMP (more protocols are planned for future versions of Snort, including ARP, IGRP, GRE, OSPF, RIP, and so on). The Source IP field follows next. This is the originating network or range used by those devices sending hostile packets. Multiple IP addresses can also be used in this field using an IP List, a bracketed list of IP addresses and their CIDR netmask, separated by a comma (the same as specifying addresses in the snort.conf file).

For example, using the same example from above, substitute the variable $EXTERNAL_NET for an IP list. What follows is the rule header only.

alert tcp [64.147.128.0/19,198.60.72.0/23] any -> $HOME_NET any

There should be no spaces between each IP address listing when using this format. You can also negate an address by placing an exclamation point or bang (!)—also known as a negation operator—directly in front of the address

Immediately following this field is the Source Port field. Here, the example used is any, but it could just as easily be a specific number, such as 21 for the FTP port, or a range of numbers, such as 20:23, indicating FTP-data through telnet. For ports that are less-than or greater-than a given port number, place a colon in front of the number to specify ports less-than or equal-to that port number. Likewise, place the colon after the port number to indicate all subsequent ports greater-than or equal-to that port. When defining ICMP in the protocol field, no port value is needed.

Again, building on the example above, define any packets coming from the IP list using ports 21 through 23 or ftp through telnet, rather than using the any option.

alert tcp [64.147.128.0/19,198.60.72.0/23] 21:23 -> $HOME_NET any

Remember that when doing ranges, the ports indicated are inclusive. This means the example above looks for ports 21, 22, and 23.

Next is the Traffic Direction operator. This is where the rule defines what direction the packets are traveling through the network. The arrow symbol (->) indicates packets originating from a source traveling to a destination. All items to the left of the symbol are source values. Using the < > symbols indicates direction is moot or that the traffic is bi-directional.

Finally, the last two fields are the Destination Address and Destination Port. The reasoning behind the respective Source Address and Source Port fields also applies.

7.3.2 Rule Options

The second half of the rule or the rule options define what is involved in the network packet. It is basically a message to Snort to inspect the packet for matching values and determine whether to consider the packet malicious. These options are triggered only if the rule headers match certain packet content. If there is a match, Snort most commonly writes an alert message to the alert file in the Snort logging directory. Packet data is logged as well. This ensures that once an alert is issued, the administrator can go back, review the packet and confirm or deny it was an intrusion attempt.

Using the same example as in the rule headers definitions, here are some of the explanations for the rule options. The rule itself has been broken onto multiple lines for clarity. You can also do this when building rules by putting a backslash (\ ) character at the end of the line.

alert tcp $EXTERNAL_NET any -> $HOME_NET any 

(msg:"SCAN SYN FIN";flags:SF; reference:arachnids,198; 

classtype:attempted-recon; sid:624; rev:1;)

The options section must start and end with a parenthesis. Each rule option is delimited by a semicolon.

The options portion of a Snort rule can be left out. The rule alert ip any any -> any any is a completely legitimate rule.

The first part of the rule option is the message that specifies the type of attack or hostile activity. Notice that there is a keyword and a value. The message keyword or "msg" is followed by the value—a text message enclosed in quotes. This message is written to the logging directory or to the alert database. Messages are usually short and succinct. When creating your own rules, do not write something esoteric or ambiguous, or use acronyms that only you can decipher. Your rules may one day end up in the main Snort Rules database. Keep messages clear and to the point.

The next field in this example of rule option is the flags field (flags:SF). This may or may not be present within other rule option sections, depending on the type of packet examined or the rule class. Rules are highly customizable and fields can be added or subtracted depending on what you look for. In this instance, the rule is looking in the TCP header for packets with the SYN and FIN flags set.

Along with the basics, there are other arguments that can be used in conjunction with the TCP flags. For instance, the plus sign (+) matches the specified flag, along with any other flags. The asterisk (*) matches any of the flags to which it is applied; the exclamation point or negation operator (!) negates any flags.

For example, in the following rule, the ACK flag is set. But this rule also states to match the ACK flag along with any other flags.

alert tcp $HOME_NET 146 -> $EXTERNAL_NET 1024: (msg:"BACKDOOR Infector.1.x"; content: 

"WHATISIT"; flags: A+; reference:arachnids,315; sid:117; classtype:misc-activity; 

rev:3;)

In some cases, these two pairs may be the extent of a rule option. However, additional pairs often appear in the rule option section of other rules. These are used both for reference and specificity when avoiding false positives. Defining the additional fields in the aforementioned example, the reference section states where the signature originated or where more information regarding its purpose can be found. The classtype option specifies the category of attack the packet matched. The sid pair or signature ID is useful for locating more information about that particular signature. The rev section is the rule revision number. If you or someone else modifies an existing rule, this value should be incremented to reflect the fact that this is a new rule or a variation on an old theme.

SIDs ranging from 0-100 are reserved for future use. The numbers 100-1,000,000 are for Snort distribution rules, and rules numbered over 1,000,000 are for locally created rules. A mapping of sids to alerts can be found in the sid-msg.map file.

7.3.3 Common Rule Options

Many additional items can be placed within rule options. The next section provides a brief overview of some of the more common options that can be used within the Rule Options section. Refer to the latest Snort Handbook (included in the /docs directory of the Snort source code archive). A rule example is provided for each when needed.

msg: < sample message>;

The message option explains the type of activity being logged. It is a way for the rule's author to better explain the reason for the alert. In this example, the message "BACKDOOR attempt" defines this type of attack.

alert tcp $EXTERNAL_NET any -> $TELNET_SERVERS 23 ( sid: 210; rev: 3; msg: 

"BACKDOOR attempt"; flow: to_server,established; content: "backdoor"; nocase; 

classtype: attempted-admin;)

flags: < flags>;

This option matches all flags within the capture. Here is a brief summary of all the arguments that match TCP flags:

A = ACK

F = FIN

P = PSH

R = RST

S = SYN

U = URG

2 = reserved bit

1 = most significant bit

0 = no flags

This option also uses the +, *, and ! signs. For example, F+ means that the FIN flag must be set but other flags can be set along with it. SA* means that either the SYN or the ACK, or both the SYN and ACK flags and any other flags can be set. The "!" negates the use of any flags. The example flags: !RP; negates both the RST and PSH flags, matching packets where neither RST nor PSH is set. Multiple flag options result in the rule checking only the final one specified.

content: < straight text>; content: < hex data>;

The content option is a keyword for defining stings of text or hexadecimal data within the payload. This is the method for detecting buffer overflow attempts or when doing analysis on binary data. This option is case-sensitive, but can be used with the nocase modifier for case-insensitive matching. Use the pipe (|) symbol for matching hexadecimal data. You can have multiple content fields in a single rule. The more specific the content fields, the more discriminating (and accurate) the rule.

The rule in this first example is looking for packets that contain the text string, "Bad command or filename", indicative of a failed access attempt. The second example looks for a value within the hexadecimal data indicated by the pipe symbols. It attempts to find matching binary packets that first contain the hex value 2A followed by the literal text "GOBBLE", and then followed by another 2A hex value.

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any ( sid: 495; rev: 6; msg: 

"ATTACK-RESPONSES command error"; flow: from_server,established; content: "Bad 

command or filename"; nocase; classtype: bad-unknown;)



alert tcp $HOME_NET 22 -> $EXTERNAL_NET any ( sid: 1810; rev: 3; msg: "ATTACK-

RESPONSES successful gobbles ssh exploit (GOBBLE)"; flow: from_

server,established; content: "|2a|GOBBLE|2a|"; reference: bugtraq,5093; 

classtype: successful-admin;)

The following four items (offset, depth, nocase, and regex) are modifiers of the content option.

offset: < value>;

One of four content helpers, offset defines the point or offset in the payload to begin searching for a match. This modifier must always follow after the content option. The default offset is or the first byte of the packet payload. In this example, the rule looks for the text string "6ISS ECRNA Built-In Provider, Strong Encryption" 30 bytes into the payload data.

alert tcp $HOME_NET 902 -> $EXTERNAL_NET any ( sid: 1760; rev: 2; msg: "OTHER- IDS 

ISS RealSecure 6 event collector connection attempt"; flow: from_

server,established; content: "6ISS ECNRA Built-In Provider, Strong Encryption";

offset: 30; depth: 70; nocase; classtype: successful-recon-limited;)

depth: < value>;

This content modifier limits the depth from the initial offset that a content check runs, preventing it from examining the entire payload. If no depth is specified, the check runs to the packet's end. The following example limits the byte depth the rule runs from the initial offset. In this instance, the limit is set at 70 bytes. There is no need to go beyond this point, since the content string will occur before this limit.

alert tcp $HOME_NET 2998 -> $EXTERNAL_NET any ( sid: 1761; rev: 2; msg: "OTHER-

IDS ISS RealSecure 6 daemon connection attempt"; flow: from_server,established;

content: "6ISS ECNRA Built-In Provider, Strong Encryption"; offset: 30; depth: 

70; nocase; classtype: successful-recon-limited;)

nocase;

The content modifier nocase deactivates case-sensitivity and looks for matching content. This is useful for protocols where the server is insensitive to upper- and lowercase. This does not affect hexadecimal matching. In the example below, the rule looks for any suffix to a file ending in .mp3, .MP3, or .Mp3:

alert tcp $HOME_NET any <> $EXTERNAL_NET 6699 ( sid: 561; rev: 6; msg: "P2P 

Napster Client Data"; flow: established; content: ".mp3"; nocase; classtype: 

policy-violation;)

regex

This modifier allows the user to specify a content search using wildcards. For example, when used with the content option, characters such as the following may be used: content: "string*"; regex; or content: "string?"; regex; This feature has been superceded by Perl Compatible Regular Expressions (PCRE).

logto: < file_name>;

This option logs specific data to a unique filename in the /var/log/snort directory, allowing for easier categorization (or directory specified with the -l option). For example, if a rule had the pair logto: "ICMP", all packets matching this rule are placed in the /var/log/snort/ICMP directory. This option is not normally found in the basic rule set downloadable for SnortCenter. It is intended for user customization. Here is a basic rule that logs all telnet connection attempts to a specific IP address range and places those alerts in /var/log/snort/telnets.

log tcp any any -> 192.168.10.0/24 23 (logto:"telnets";)

ttl: < number>;

The time to live option examines the arriving ttl field and checks for matching values. Fields with a ttl value of "1" indicate an ICMP traceroute.

alert icmp $EXTERNAL_NET any -> $HOME_NET any ( sid: 385; rev: 3; msg: "ICMP 

traceroute"; ttl: 1; itype: 8; reference: arachnids,118; classtype: attempted-

recon;)

id: < number>;

The IP identification value found in the IP header of the datagram is a 16-bit value. These values increase by 1 or 256 for each datagram sent out. Normally, you will see standard 16-bit value IDs. When a packet is fragmented into multiple smaller packets, the identification value will designate which packets belong together (they will have the same id value).

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"DOS Land attack"; id:3868; 

seq: 3868; flags:S; reference:cve,CVE-1999-0016; classtype:attempted-dos; sid:

269; rev:3;)

dsize: [<|>] < number>;

The dsize option looks at the payload size. Certain packets should not exceed a predetermined limit. ICMP packets for example should not be very big. This alert looks for packets greater than 800 bytes.

alert icmp $EXTERNAL_NET any -> $HOME_NET any ( sid: 499; rev: 3; msg: "ICMP 

Large ICMP Packet"; dsize:  >800; reference: arachnids,246; classtype: bad-

unknown;)

ack: < number>;

This option checks for a particular acknowledgment number. It can be used to check for the fingerprint of some scanners (such as Nmap pings) in the following rule. In this rule, the ack option matches packets that have the ack flag set and an acknowledgment number of "0".

alert tcp $EXTERNAL_NET any -> $HOME_NET any ( sid: 628; rev: 2; msg: "SCAN nmap 

TCP"; flags: A,12; ack: 0; reference: arachnids,28; classtype: attempted-recon;)

seq: < hex_value>;

This option checks the value of a particular TCP sequence number. Some DoS attacks use a specific sequence number. Here is a sample backdoor Trojan scan using a TCP sequence number:

alert tcp $EXTERNAL_NET 80 -> $HOME_NET 1054 ( sid: 106; rev: 4; msg: "BACKDOOR 

ACKcmdC trojan scan"; flags:  A,12; seq:  101058054; ack:  101058054; reference: 

arachnids,445; classtype: misc-activity;)

itype: < number>;

This option looks for a particular ICMP message type. It's found in the zero byte offset of the ICMP message. Stacheldraht uses this option, making it easy to spot.

alert icmp $EXTERNAL_NET any <> $HOME_NET any ( sid: 1855; rev: 2; msg: "DDOS 

Stacheldraht agent->handler (skillz)"; content: "skillz"; itype: 0; icmp_id:

6666; reference: url,staff.washington.edu/dittrich/misc/stacheldraht.analysis; 

classtype: attempted-dos;)

icode: < number>;

The icode option is often used in conjunction with the itype option. This field is found in the first byte offset of the ICMP message. If you are interested in seeing the timestamp code within an ICMP message, use the icode option with a value of 13, as shown below:

alert icmp any any -> any any ( sid: 485; rev: 2; msg: "ICMP Destination 

Unreachable (Communication Administratively Prohibited)"; itype: 3; icode: 13; 

classtype: misc-activity;)

icmp_id: < number>;

The same principle behind the icode option applies to the ICMP ID option. Notice in a prior example the ID was 6666, a static value used by Stacheldraht. This fixed numeral makes identification a simple task. The ICMP identification value is usually found in the fourth and fifth bytes offset of the ICMP message. It is used for pairing requests and responses and reflects the ping ID process.

icmp_seq: < hex_value>;

ICMP sequence numbers usually increment by one with each succeeding ICMP echo request packet sent by the host. A zero value indicates something is amiss. This rule is also looking for unique content: a long sequence of 0 bytes in binary format.

alert icmp $EXTERNAL_NET any -> $HOME_NET any ( sid: 467; rev: 1; msg: "ICMP 

Nemesis v1.1 Echo"; content: "|0000000000000000000000000000000000000000|"; 

dsize:  20; itype:  8; icmp_id:  0; icmp_seq:  0; reference: arachnids,449; 

classtype: attempted-recon;)

session: [printable|all];

Use the session option to capture user data from TCP sessions. This is useful for watching what a specific user may be doing on a system or on the network connection. Use either of the variables printable or all. printable shows what the user would see or be able to type. It echoes hidden characters and might be used for password sniffing. The variable all substitutes nonprintable characters with their hexadecimal equivalents.

ipopts: < ip_option>;

IP options are not normally used for regular TCP/UDP and ICMP traffic. They look primarily at source routing, in which a datagram learns its route from source to destination as it hops from one point to the next. Source routing is a mechanism whereby the desired route for a packet is contained in the packet itself. This can be a mechanism to map a network (traceroute), troubleshoot a problem, or improve performance—by directing packets to a low-cost connection, for instance. It is not normally used and any traffic with source routing enabled should be considered suspicious. There are two types of source routing: loose and strict. Here is a list of possible identifying options associated with source routing, all of which can be specified in the rule.

rr	Record route
eol	End of list
nop	No op
ts	Timestamp
sec	IP security option
lsrr	Loose source routing
ssrr	Strict source routing
satid	Stream identifier

Source routing may be used for spoofing a source IP address and getting back a response. This is how a cracker may hide her real IP address. If a sniffer is installed somewhere along the way, a cracker can grab the response and begin spoofing. Only a single ipopts option may be used in a rule.

alert icmp $EXTERNAL_NET any -> $HOME_NET any ( sid: 475; rev: 1; msg: "ICMP

traceroute ipopts"; ipopts:  rr; itype:  0; reference: arachnids,238; classtype: 

attempted-recon;)

fragbits: < flag_settings>;

This option looks for the fragmentation and reserved bit in the IP header. There are only three flag settings, as shown here.

R	Reserved bit
D	Don't fragment bit
M	More fragments bit

This example uses the reserved bits setting or R fragbits option.

alert ip $EXTERNAL_NET any -> $HOME_NET any ( sid: 523; rev: 4; msg: "BAD-TRAFFIC 

ip reserved bit set"; fragbits: R; classtype: misc-activity;)

content_list: < filename>;

The content-list option can be used with the react option. It provides the ability to look for a collection of strings within a packet's payload. This is useful for creating filters or running lists of illegal activity. A sample list may contain items such as warez, sploits, hackz, pr0n, and so on. The file is built with one string per line.

react: <react_basic_modifier[, react_additional_modifier...]>;

In order to use this option, you must compile Snort with the --flexresp option during initial configuration. This may require additional libraries, such as libnet. Check your configuration for the latest requirements. This option is also used in conjunction with the content-list option, as mentioned in the previous example.

Some of the basic modifiers for this option are block, which allows Snort to actually close a connection and send a warning notice visible to the user, and warn, which only sends a simple warning notice. Additional features that should be available soon, if not already, are msg, which includes the the message option text in the blocking notice. There's also proxy: <port_nr>, in which react uses the defined proxy port to send the notice.

Here is an example of how the react option is used:

alert tcp any any <> 192.168.10.0/24 80 ( content-list: "

adult"; msg: "Warning, adult content"; react: block, msg;)

uricontent: [!] "content string";

This option performs a string match just like the content option, only it matches against URIs sent to a web server. In this example, the rule warns of Unix commands sent to a web server.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS ( sid: 1328; rev: 4; 

msg: "WEB-ATTACKS ps command attempt"; flow: to_server,established; uricontent:

"/bin/ps"; nocase; classtype: web-application-attack;)

ip_proto: [!] < name or number>;

This option specifies any of the available 256 protocol numbers or values found in the protocols file, allowing users to go beyond the regular IP, TCP, UDP, and ICMP protocols normally used. For example, in mid July 2003, a serious bug was detected in the Cisco IOS release. Protocols 53, 55, 77, and 103 were deemed vulnerable and a crafted packet could cause a router to lock up. Within hours, Snort had a working rule that detected any attempts to exploit this vulnerability. Here are the rules as they were added to the rule base:

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Cisco IPv4 DoS";

classtype:attempted-dos; ip_proto 53;) 

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Cisco IPv4 DoS";

classtype:attempted-dos; ip_proto 55;) 

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Cisco IPv4 DoS";

classtype:attempted-dos; ip_proto 77;) 

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Cisco IPv4 DoS";

classtype:attempted-dos; ip_proto 103;)

These rules use three items within the rule options: a msg field, a classtype field, and the ip_proto field. For more information about available protocols, check the file /etc/protocols on Unix systems or c:\WINNT\system32\drivers\etc\protocol under Windows.

sameip;

This is a very simple option that always stands by itself. It looks for identical source and destination IP addresses.

alert ip any any -> any any ( sid: 527; rev: 4; msg: "BAD-TRAFFIC same SRC/DST"; 

reference: cve,CVE-1999-0016; reference: url,www.cert.org/advisories/CA-1997-28.

html; classtype: bad-unknown; sameip;)

stateless;

Some alerts examine TCP traffic using stateful packet inspection. In certain cases, it waits until the three-way handshake has been completed before triggering an alert. Stateful packet inspection was added after tools like stick and snot, designed to overwhelm an IDS with false alerts, came on the scene.

In some instances, it may not be necessary to await the handshake, but the packet is strange enough in its own right to trigger an alert. In cases such as these, allowing "stateless" checking is sufficient. The following example shows all TCP flags set.

alert tcp any any -> any any ( msg: "All TCP flags set"; flags: 12UAPRSF; 

stateless;)

sid: < snort rules id>;

An SID is normally intended for tools such as SnortCenter that parse alert messages. It does not affect signature recognition. Because each alert has its own unique ID, categorization is easier. This option simply provides a rule SID used by programs such as ACID and SnortCenter. Snort normally assigns an SID to each alert. Users need not assign a specific variable or ID to a custom alert.

alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 1433 ( sid: 704; rev: 5; msg: "MS-SQL 

xp_sprintf possible buffer overflow"; flow: to_server,established; content:  

"x|00|p|00|_|00|s|00|p|00|r|00|i|00|n|00|t|00|f|00|"; nocase; reference: 

bugtraq,1204; classtype: attempted-user;)

rev: < revision integer>;

This option shows the revision number of a particular rule. When a rule is improved or a more accurate signature is added, its revision number increases by one. This way you can identify which version of the rule triggered the alert.

alert tcp $SMTP_SERVERS any -> $EXTERNAL_NET 25 ( sid: 721; rev: 4; msg: 

"VIRUS OUTBOUND .pif file attachment"; flow: to_server,established; content: 

"Content-Disposition|3a|"; content: "filename=|22|"; distance: 0; within: 30; 

content: ".pif|22|"; distance: 0; within: 30; nocase; classtype: suspicious-

filename-detect;)

classtype: < class name> :

This option provides more information about an event, but does not actually trigger the alert. The following list is extracted from Snort's classification.config file, located within the Snort source.

All classtypes ending with a "1" are High Priority. The examples listed here are only those classtypes that are a "1" or High Priority. Medium, Low, and No Priority classtypes are 2, 3, and 4, respectively, and are not shown here.

attempted-user	Attempted User Privilege Gain
unsuccessful-user	Unsuccessful User Privilege Gain
successful-user	Successful User Privilege Gain
attempted-admin	Attempted Administrator Privilege Gain
successful-admin	Successful Administrator Privilege Gain
shellcode-detect	Executable code was detected
trojan-activity	A Network Trojan was detected
web-application-attack	Web Application Attack
kickass-porn	Porn Content Requested
policy-violation	Potential Corporate Privacy Violation

The following is an example of classtype used in a Snort rule.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS ( sid: 1233; rev: 7; msg: 

"WEB-CLIENT Outlook EML access"; flow: from_client,established; uricontent: ".

eml"; classtype: attempted-admin;)

priority: < priority integer>;

The classification.config file assigns a priority of High, Medium, Low, and None to all classtypes. Use this option with other external tools such as ACID and SnortCenter to search output for specific priorities.

reference : <id system>,<id>;

This option provides a link or URL to a web site or sites with more information about any given attack.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS ( sid: 1284; rev: 9; msg: 

"WEB-CLIENT readme.eml download attempt"; flow: from_client,established; 

uricontent: "/readme.eml"; nocase; reference: url,www.cert.org/advisories/CA-

2001-26.html; classtype: attempted-user;)

Using the instructions presented here, you should have enough information to begin creating your own rules or customizing existing ones. The best method for creating custom rules is to capture network traffic using tcpdump. Look for those packets that appear unique or match what you currently see happening on your network. Look for any common features that could be applied to a Snort rule, such as payload data information, unique content, or specific flags or options set within the TCP or IP header. Adding these markers to a Snort rule helps identify incoming packets.

There are some rules of thumb for writing good rules:

• The longer the contents that you include in your rules to match the payload of a packet, the better the match.

• Try to write the rules to match the characteristics of the vulnerability instead of the exploit. This is not easy, but leads to a rule that catches most attempted attacks.

• Don't forget that content rules are case-sensitive (unless the nocase option is used).