1. Trang chủ
  2. » Công Nghệ Thông Tin

snort 2.1 intrusion detection second edition phần 4 potx

76 528 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 76
Dung lượng 1,62 MB

Nội dung

295_Snort2e_05.qxd 5/5/04 3:47 PM Page 198 198 Chapter 5 • Playing by the Rules snort which rule should activate this rule and a “count” rule option that specifies how many packets Snort will process before deactivating the dymanic rule. Generally, dynamic rules are used to log additional information on a session. This functionality is better expressed with aa “tag” option, described in chapter 4.The following example logs the next 5 bytes on port 143 after the first rule is fired: activate tcp any any -> any 143 (content:"|E8C0FFFFFF|/bin"; activates: 1;) dynamic tcp any any -> any 143 (activated_by:1; count:5;) OINK! Activate and Dynamic rules are being phased out in favor of tagging. In future versions of snort, activate/dynamic will be completely replaced by improved tagging functionality. For information on tagging, read Chapter 4. Rule Options First, let it be known that Snort rules do not require the body field to be com- plete rule definitions.The body of the rule is an excellent addition that extends the breadth of rule definition beyond simply logging or alerting based on packet source and destination. With this said, we don’t want to disregard the importance of the rule body, because it can be considered the “meat and potatoes” for rules identifying complex attack sequences.The body format is broken down into sec- tions separated by semicolons. Each section defines an option trailed by the desired option value.The rule options that can be included range from protocol specifics and fielding, including IP, ICMP, and TCP. Other applicable options include messages that print out as reference points for the system administrator, keywords to search on, Snort IDs to use as a filing system for Snort rules, and case-insensitivity options. The rule options are separated by semicolons within the main body of the Snort rule: alert tcp any any -> any 12345 (msg:" Test Message";) As you can see, the rule’s body (in bold) is confined by the parentheses. In this case, the body of the message contains two content values.The first value is a www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 199 Playing by the Rules • Chapter 5 199 message to display when the alert is triggered, and the second is the nocase option, which allows you to specify case-insensitive specific rules. In addition to the Snort specific rules and body syntax, Snort also allows you to write “pre- analysis” packet filters in BPF format. We discuss BPF-formatted rules in more detail later in the chapter. Rule Content When writing Snort rules, the most powerful and important set of options that you can include within the body of the rule revolves around analyzing the pay- load of the packet.You can analyze payloads via binary and ASCII values in addi- tion to specifying multiple other types of options that assist in identifying potentially malicious packet content. ASCII Content Similar to the method for including binary content strings in the body, ASCII content strings are included with quotations without the pipe characters. In this case, you should only include one string per rule. Later in this section, we discuss how to include lists of multiple strings to match on in a single rule.The format for using this option is the same as the binary content option content: “STRING”, and you can negate the string with the exclamation point. In the following rule, the rule searches for the bad string malicious string /etc/passwd and displays the following message string: alert tcp any any -> any any (content: "malicious string /etc/passwd"; msg:"Searching for ASCI Garbage!";) OINK! If you want to use the colon, pipe character, or quotation mark, you must first escape the character within encapsulating quotes. Including Binary Content To include binary content within your content string, you merely need to encapsulate the HEX equivalent data between pipe characters ( | ). Binary data can be easily captured and incorporated into rules using network sniffers such as www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 200 200 Chapter 5 • Playing by the Rules tcpdump, Ethereal, as well as Snort in packet sniffing mode raw data strings. Snort implements the Boyer-Moore pattern searching and matching algorithm to identify included content strings from captured packets.You can use the negation operator—exclamation point—to specify content that you do not want to match on.The format for using this option is content: “STRING”;.The following rule shows the proper syntax for including binary/HEX data into the rule: alert tcp any any -> any any (content: "|0000 0101 EFFF|"; msg:"Searching for Garbage";) ASCII and Binary Content Rules In addition to adding ASCII and binary content individually, you have the capa- bility to combine the two types of strings in a single rule. Combining strings is not a complicated task, but you must remember to use the same rules for including ASCII and binary strings in the rule. Including mixed content is dif- ferent from including multiple strings in a single rule. In the following rule, the content string is broken up into a binary, then ASCII, and then back to binary. The rule will interpret the content string as a single string, and then use that single instance of the string for packet matching. alert tcp any any -> any any (content: "|0101 FFFF|/etc/passwd|E234|"; msg:"Searching for Ascii and Binary stuff!";) The depth Option The depth content option modifier allows you to statically set the number of bytes that the rule should analyze when searching for the defined content string.To minimize CPU cycles and optimize speed for your sensor, you should use this option in conjunction with your content option.The format for the command is depth: <NUMBER_OF_BYTES>;. OINK! The average server header in HTTP 1.0 can be obtained in the first 200 bytes of a packet. www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 201 Playing by the Rules • Chapter 5 201 The offset Option The offset option content modifier informs the Snort engine to begin searching for the supplied content string at the offset byte. It is especially useful when you know that you are searching for a specific string that might be included as a subset of other strings. For example, if you know that you can write a rule based on a specific Web server version and you also know that the Web server version appears in the response header from a Web server, it might be best to use an offset of 0. It is important to note that this one of the most important options to use, and one of the most dangerous because, if set improperly, you could miss an attack.The format for setting the content modifier is offset: <NUMBER_OF_BYTES>;. The nocase Option You have the capability to disregard text case within rule content by using the nocase option. For this option to work, you must have previously defined a con- tent string within the rule. In this example, the rule will trigger on any TCP packet destined for the Telnet service with the word administrator in the payload of the packet.This rule example is helpful if you are attempting to sniff pertinent authentication credentials. As you might have gleaned from the example, the format to use this option is nocase;. alert tcp any any -> any 23 (content: "administrator"; nocase;) The session Option The session option is one of the most useful options if you use Snort in an attack capability. It allows you to grab clear-text data from protocol sessions and output that data to the screen. As you can imagine, the capability to log and view only usernames, passwords, and executed commands is extremely useful.This rule gen- erates an alert and then prints the entire FTP session transmission to standard output. alert tcp any any -> any 21 (content: "FTP Session Data"; session: printable;) Uniform Resource Identifier Content The Uniform Resource Identifier (URI) content option allows you to analyze traffic from the requesting system. Instead of matching the rule body and content www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 202 202 Chapter 5 • Playing by the Rules strings against the entire packet, you can specify it to only match the rule’s con- tent string(s) in the URI section of a request instead of the packet’s payload.The format of the URI content option is uricontent: “STRING”;. Here is the correct option syntax: log tcp any any -> any 80 (content: "Logging PHF"; uricontent:"/cgi- bin/phf";) The stateless Option In early versions of Snort, the capability to allow rules to analyze stateless data was provided in the stateless option.The latest versions of Snort, post versions 1.8, have included this functionality in the flow option.The format for the stateless option is stateless;. Reference the section Flow Control in this chapter for more information on stateless rules and including stateless content. Regular Expressions Full regular-expression support has been available in Snort since 2.1.0. Brian Caswell and Michael Pomraning wrote prototype plug-ins that used the Perl Compatible Regular Expression (PCRE) library for Snort. After some merging of the two prototypes, pcre support was added to Snort. There are many resources online for learning how to write regular expressions, so we won’t go into that here.There are a few important things to remember when using pcre.The pcre plug-in does not make use of the multipattern- matching engine discussed in later chapters. Be sure to use a content option as well as a pcre option if possible to allow Snort to be as efficient as possible by using the multipattern match engine. There are a few Snort-specific regular expression modifier options for pcre: ■ R Relative match (same as distance:0;) ■ U URI match (same as uricontent) ■ B Do not use the decoded buffers (same as rawbytes) The syntax of the pcre plug-in is: pcre:[!]"(/<regex>/|m<delim><regex><delim>)[ismxAEGRUB]"; alert tcp any any -> any 23 (content:"snort"; pcre:"/\s+\d+\.\d+.\d+/R";) www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 203 Playing by the Rules • Chapter 5 203 For more information on PCRE, check out the PCRE homepage at www.pcre.org. Flow Control The flow option, first introduced in Snort version 1.9, allows users to define the packet’s direction in reference to client-server communication streams. It dramat- ically increases the functionality of Snort because you do not have to define packet direction at the IP layer.The flow functionality works in coordination with Snort’s TCP reassembly module and allows rules to distinguish packet con- tent and direction in regard to client-server architecture. One of the most notable benefits for this feature is allowing rules to be written on potential client attack data streams toward the server, and then analyzing the server’s response to see if an attack was successful.The data in Table 5.1 represents the flow configuration options with a brief corresponding description. All of the current options sup- ported in Snort’s flow control are based on the TCP protocol and reassembling TCP sessions. Table 5.1 Flow Options Option Instructions Brief Description to_server Passes true on packets sent to the server. from_server Passes true on packets sent from the server. to_client Passes true on packets sent to the client. from_client Passes true on packets sent from the client. only_stream Only activates on reconstructed packets or packets within an established stream. no_stream This instruction is the opposite of the previous example and does not pass packets that are recon- structed or within an established stream. established The established instruction will activate on packets that are part of an established TCP connection or ses- sion. The flow control options are used in a manner similar to that of other common Snort configuration instructions. Within the body of the rule, define flow: <OPTION>, where OPTION is one of the Option Instructions in Table 5.1.The following example Snort rule will flag on TCP packets sent from the www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 204 204 Chapter 5 • Playing by the Rules client in a TCP stream transmitting toward the server with a confirmed attack string overflow. alert tcp any any -> $DMZ_WEBS 80 (msg:"Client Attacking Server Example"; flow:from_client; content:"/cgi- bin/handler/something;cat\t/etc/group|?data=Download";) Conversely, the following example flags on packets sent from a server with a potential string that can be found when a UNIX password file is viewed. With this rule, flagging packets only from servers will minimize false positives. alert tcp $DMZ any -> $EXTERNAL any (msg: "Server Potentially Sending Sensitive Info"; flow:from server; content:"root:: ";) IP Options The IP options are key in identifying numerous IP-based types of attacks in addition to other types of more complex attacks. Many of the IP options are used in writing rules to identify network device attacks, attempts to map a net- work, and protocol-based denial-of-service (DoS) attacks. Fragmentation Bits Generic fragmentation rules should be applied within your environment to pro- tect against the more complex types of attacks.The fragment bit option allows you to analyze the fragment and reserved bits within an IP header.You have three available flags within the fragmentation bits option that you can specify: ■ D “Don’t Fragment” ■ M “More Fragments” ■ R “Reserved Bit” The preceding flags were included by the Snort development team with the corresponding naming convention logic. In addition to the bit flags, there are five operator flags: As with the other Snort options that implement that operator flags, the asterisk stands as an all wildcard. ■ ! The exclamation point is used for negation. ■ + The addition sign for a specified bit flag plus either of the other bits that are implemented. www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 205 Playing by the Rules • Chapter 5 205 ■ – The minus sign for any bit. ■ ,,, The format for this option is fragbits: <BIT VALUE>;. Equivalent Source and Destination IP Option The feature to check equivalent IP addresses was a late addition and only serves one purpose: to identify forged, or spoofed, packets. Sending packets with the same source and destination used to be a common method for testing packet filter firewalls.The technique is outdated as commercial vendors ensure that their products do not build in this flaw.The format for this rule is sameip;. This rule checks for a equivalent source and destination IP address within an IP packet and should be included in all enterprise rulesets: alert ip any any -> any any (msg:" Same Source and Destination IP Address"; sameip;) IP Protocol Options Snort allows you to specify IP options within a packet upon which you would like to match or negate a packet. Due to the nature of the IP options and a development flaw within Snort, you can only include one option in a rule.This is not critical, because IP options are not commonly used within commercial network applications.The format to use this option in the configuration file is ipopts: <IP_OPTION>;.Table 5.2 lists the IP options available within Snort. Table 5.2 Snort IP Options IP Options Brief Overview eol Used to specify the end of an IP list lsrr IP loose source routing nop Used when there is no IP option set rr Record route satid The IP stream identifier sec The IP security option, also known as IPSec ssrr IP strict source routing ts The timestamp field www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 206 206 Chapter 5 • Playing by the Rules ID Option The ID option permits you to identify static IP ID values within an analyzed packet. Conventionally, it has little use, but is another of the options added within Snort in case it ever becomes tremendously essential in identifying a type of attack.The format to use the IP ID option is ID: “VALUE”. Type of Service Option Initially, the Type-of-Service (TOS) option was added for future use and to com- plete the IP rule API. However, multiple attacks were released in the summer of 2002 relating to malicious use of the IP TOS field. In most cases, the TOS field value is zero, and in the case of some old Cisco equipment, the incoming TOS field must be set to zero.The format to use the TOS option is tos: “VALUE”;. The following rule alerts on external traffic bound for Cisco devices with the TOS field not set to zero: alert tcp $EXTERNAL any -> $CISCO any (msg:" Cisco TOS Example"; tos:!"0";) Time-To-Live Option The Time-To-Live (TTL) option’s core value comes in identifying network- mapping queries via tools such as traceroute, tracert, and netroute. It compares the defined value to that of the analyzed packets in search for a direct match.The format to use this option is TTL: “VALUE”.TTL also supports >, <, and =. TCP Options There are three TCP-specific options that you can use within the body of your Snort rules. Each triggers upon a different static value within the TCP header of a packet.The sequence and ACK options are rarely used, but the TCP flags option is considered a value-add for numerous rules. Sequence Number Options The sequence number option is used to check for static TCP sequence numbers within analyzed packets, and therefore is rarely used. Static communication pro- grams and flooding tools are two of the rare example programs that can be iden- tified by guessable sequence numbers. According to Marty Roesch, “it was added for the sake of completeness.”The format to use this option is: seq: <sequence_number_value>;. www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 295_Snort2e_05.qxd 5/5/04 3:47 PM Page 207 Playing by the Rules • Chapter 5 207 TCP Flags Option The TCP flags option is comprehensive; it allows you to determine if each potential flag is set, unset, or used in combination with another flag.The alphanumeric flags are used to determine what specific flags are set within the packets, while the special characters such as the addition, asterisk, and exclama- tion mark are used as wild cards and as a negate option, respectively. In addition to the flags, you can use the reserved bit options to detect atypical network activity such as multiple types of fingerprinting techniques.Table 5.3 lists all of the TCP flags currently available within Snort. Table 5.3 Snort TCP Flags TCP Flags Brief Flag Description A The option to check if the ACK flag is set. F The option to check if the FIN flag is set. P The option to check if the PSH flag is set. R The option to check if the RST flag is set. S The option to check if the SYN flag is set. U The option to check if the URG flag is set. 0 A unique option to detect if no TCP flag has been set within the packet. 1 The 1 option determines if the reserved bit 1 is set within the packet. 2 The 2 option determines if the reserved bit 2 is set within the packet. + The addition sign is used to determine if a specific flag is set and followed by other TCP flags. Ex: A+ triggers on any packet with the ACK flag set in addition to other flags. * The asterisk is a wild card character that you can use to specify any flag that matches on any specified flags. Ex: *AS triggers on all packets that have the ACK or SYN flag set. ! Likewise to most negation commands, this checks to see if the packet does not have the specified flag set. Ex: !S trig- gers on all packets that do not have the SYN flag set. www.syngress.com Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... Be Merged 10.1.0.0/22 10.1.0.0/21 10.1.0.0/ 24, 10.1.1.0/ 24, 10.1.2.0/ 24, 10.1.3.0/ 24 10.1.0.0/ 24, 10.1.1.0/ 24, 10.1.2.0/ 24, 10.1.3.0/ 24, 10.1 .4. 0/ 24, 10.1.5.0/ 24, 10.1.6.0/ 24, 10.1.7.0/ 24 10.1.8.0/ 24, 10.1.9.0/ 24, 10.1.10.0/ 24, 10.1.11.0/ 24 198.30.1.1/32, 198.30.1.2/32, 198.30.1.3/32 (single IP addresses) 198.30.1.1/32, 198.30.1.2/32, 198.30.1.3/32, 198.30.1 .4/ 32, 198.30.1.5/32, 198.30.1.6/32, 198.30.1.7/32... Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Table 5 .4 Snort ID Ranges Range Values Usage Overview Less than 100 100 to 1,000,000 Reserved for future use For use by Snort within the www .snort. org dis­ tribution ruleset For use by custom Snort rules Greater than 1,000,000 Rule Revision Number The Snort rule revision number is used in the case that edits are done to an original... enhance the reporting and configuration features within Snort Snort ID Options The Snort ID option was included to serve as a method to categorize, distin­ guish, and identify single Snort ID rules.The simple schema allows manual and automated systems to use specific rules.The format is sid: ;.Table 5 .4 lists the ranges that can be used as Snort ID values www.syngress.com 209 210 Chapter 5 •... Subnet Masks (Bad Examples) Merged Subnet Mask Subnets to Be Merged 10.1.0.0/22 198.0.0.0/20 10.100.80.0/31 10.1.0.0/ 24, 10.1.2.0/ 24, 10.1 .4. 0/ 24, 10.1.6.0/ 24 198.1.0.0/21, 198.2.0.0/21 10.100.80.1/32, 10.100.80.101/32 Merging subnet masks can save CPU resources and enhance the performance of Snort s traffic parsing engine As a rule of thumb, you should always combine or merge subnet masks when possible,... signature/rule-based NIDS Snort implements features such as protocol anomaly checking via preprocessors Preprocessors handle packet data after Snort s decoder has parsed the packet into fields, but before the detection mechanism starts doing rule comparison.They can add a tremendous amount of functionality on top of Snort s rule-matching core OINK! Actually, Snort does do some anomaly detection in its packet... simplicity that makes Snort one of the fastest Network-based IDSs (NIDSs) available Snort can keep up with fast and heavily loaded networks because it generally has a well-defined amount of work to do for each packet that it must examine There was great demand for Snort to move beyond its rule-matching design For example, one requested feature was protocol anomaly detection, where Snort could detect that... trigger upon the detection of invalid ICMP type values Additionally, the itype option can also be set to trigger upon other specific options.The format to use the option is icode: value Meta-Data Options Snort has several options that can be used to further identify, provide corre­ sponding documentation, and categorize Snort s set of rules.These options should not be confused with threat detection options,... any -> $INTERNAL 79 (msg:" Finger";) Logging The logging capabilities of Snort can be viewed as a significant advantage over many of Snort s competitor IDSs.The logging option informs Snort that all corre­ sponding packets related to that specific instance of the rule are to be logged to the specified file Organized logging permits Snort to subdivide rule logs based on perceived tool usage, attack types,... response option, resp, allows Snort to automatically kill protocol connections based on rules that are triggered It is the most powerful protocolbased body option currently implemented in Snort. The format to use the active response modifier is resp: MODIFIER, MODIFIER2, MODIFIER3, etc; The following TCP-based modifiers are the current options that you can specify in the Snort response strings: ■ rst_all... could not be used in Snort rules, and showed several examples of working rules We examined the myriad options of rule composition, and considered the many different possible variables to focus on when writing a rule We also investi­ gated what makes for a good Snort rule, and how to write good rules as opposed to just writing functional rules Finally, we discussed the life cycle of a Snort rule, from the . Version - http://www.simpopdf.com 29 5 _Snort2 e_05.qxd 5/5/ 04 3 :47 PM Page 21 1 Playing by the Rules • Chapter 5 21 1 Table 5.5 Critical Classifications (Priority 1) Classtype Brief Description attempted-admin. http://www.simpopdf.com 29 5 _Snort2 e_05.qxd 5/5/ 04 3 :47 PM Page 21 4 21 4 Chapter 5 • Playing by the Rules length, and the <> sign means “in between.” For example, < ;10 0 is for packets with. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 29 5 _Snort2 e_05.qxd 5/5/ 04 3 :47 PM Page 21 2 21 2 Chapter 5 • Playing by the Rules Table 5.7 Low-Risk Classifications (Priority

Ngày đăng: 13/08/2014, 12:21

TỪ KHÓA LIÊN QUAN