Tài liệu Snort Rules: Application pptx

1 1 Snort Rules: Application Paul Ritchey, Jacob and Sundstrom, Inc. pritchey@jasi.com V1.0.0 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. 2 2 Agenda ! Rule Analysis ! Simple Rules ! Difficult Rules ! Advanced Rules ! Writing Rules ! Simple Rules ! Difficult Rules ! Advanced Rules ! Tying It All Together 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. 3 3 Rule Analysis: Simple Rules 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. 4 4 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 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. 5 5 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";) 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. 6 6 Simple Rule #1: Back Orifice (cont.) ! Examine the rule header: ! Will ‘alert’ when triggered. ! Applies only to UDP traffic. ! Source defined by variable • $EXTERNAL = !$HOME_NET ! Destination defined by variable • $HOME_NET = your network alert UDP $EXTERNAL any -> $INTERNAL 31337 \ (msg: "IDS188/trojan-probe-back-orifice";) For this simple rule, the contents of the signature is completely contained in the rule header. This rule, when it is triggered, will execute the action ‘alert’. 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. This rule only applies to UDP traffic. If snort the traffic Snort is examining is from another protocol, this rule will not be tested against them. The destination address is defined as a variable, HOME_NET. This variable is typically defined at the top of the rules file being used, and is set to the addresses Snort is monitoring. In this particular rule, the source address is also defined as a variable, named EXTERNAL. Typically, this is set to !$HOME_NET, meaning that the source address should be outside of the network address space Snort is monitoring. The UDP packet can, however, be originating from any of the possible ports on the source host, but must be destined specifically for the port 31337 (otherwise known as ‘eleet’) on the destination machine. 7 7 Simple Rule #1: Back Orifice (cont.) ! Examine rule options. ! No packet attributes are examined. ! Only includes message. ! Possibility of false-positives: ! Low likelihood of occurrence. ! High likelihood of false-positives. alert UDP $EXTERNAL any -> $INTERNAL 31337 \ (msg: "IDS188/trojan-probe-back-orifice";) 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, making it easier to determine what a log or alert entry represents. This rule is very simple. The only thing limiting the rule down to a specific subset of UDP traffic is the destination port. Since no packet attributes or options are specified, it is very likely that detects, although not often, may very well be false-positives. Any traffic, such as streaming audio or video, that happens to be destined for destination port 31337 will trigger this rule. 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. 8 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 - BACKDOOR SIGNATURE - DeepThroat 3.1 Server Active on Network";) 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. Once installed, the trojan opens a port that allows remote hosts to control the infected machine. 9 9 Simple Rule #2: Deep Throat (cont.) ! Examine the rule header: ! Will ‘alert’ when triggered. ! Applies only to UDP traffic. ! Source specified as ‘any’ • ‘Any’ matches all possible IP addresses, including internal addresses. ! Destination defined by variable • $HOME_NET = internal network alert udp any 2140 -> $HOME_NET 60000 \ (msg:"IDS106 - BACKDOOR SIGNATURE - \ DeepThroat 3.1 Server Active on Network";) For this simple rule, the contents of the signature is again completely contained in the rule header. This rule, when it is triggered, will execute the action ‘alert’. 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. This rule only applies to UDP traffic. If snort the traffic Snort is examining is from another protocol, this rule will not be tested against them. Now the rule deviates from the previous example. Instead of specifying a variable for the source IP address, the keyword ‘any’ is specified. This means that the packet can originate from any possible IP address, there are no restrictions. However, the packet must originate from a specific port – 2140. The packet must be destined for the network the variable HOME_NET is set to, and to the specific port 6000. If the packet meets all of the above criteria, it will trigger the rule and will be logged to the alert file and logs with the message specified in the rule options section. I would like take a second to discuss the keyword ‘any’ that was specified for the source address. Snort is typically installed on a machine that resides in a ‘DMZ’. The DMZ sites outside of your internal network, and sees all traffic in bound from the internet to your network, or outbound from your network to the internet. It does not and should not see your internal traffic. Because of this, it would have been just as effective to replace the keyword ‘any’ with !$HOME_NET. 10 10 Simple Rule #2: Deep Throat (cont.) ! Examine rule options. ! No packet attributes are examined. ! Only includes message. ! Possibility of false-positives: ! Low likelihood of occurrence. ! Likelihood of detect being a false-positives. alert udp any 2140 -> $HOME_NET 60000 \ (msg:"IDS106 - BACKDOOR SIGNATURE - \ DeepThroat 3.1 Server Active on Network";) Examining the rule options section, we again that this rule like the previous example is only specifying the message option. 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. This rule is very simple. The only real limiting factors are the source and destination ports. Both ports are ephemeral ports, meaning they are out of the reserved range. Although unlikely, it’s possible that this port combination could be used during the course of a valid connection, and because there are no other criteria for the rule false-positive detects may be made. Most virus software should be capable of detecting this trojan if properly installed and used regularly. This increases the chances that a detect is a false-positive so care must be taken to fully resolve any detects. [...]... you have written the rule 31 Writing Rules: Simple Rule #2 (cont.) ! Possible Answer: ! ! pass tcp 192.168.1.1/32 any -> 10.1.0.0/16 any Snort Command Line: ! Snort –c snortrules -o 32 This is a simple rule to write, but also has a special requirement that must not be forgotten To ignore packets, the rule’s action field must be set to the value ‘pass’ This tells Snort to drop the packet being inspected... keyword ‘any’ In order for this rule to be effective, Snort must be told to process the ‘pass’ rules first By default Snort processes alert and log rules first, then the pass rules last This effectively ignores pass rules To reverse this order, you must specify the ‘-o’ option This causes Snort to process pass rules first, then alert and log rules 32 Writing Rules: Difficult Rule ! Odd behavior has been detected... variable represents all addresses except those in your network Snort rules always require a port to be specified, but ICMP does not use ports so we used the keyword ‘any’ as a placeholder We could have used any value for this field, 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 In the... Writing Rules: Simple Rule ! Your boss wants to know about all ICMP echo requests (pings) coming into your network Write the rule using the variable HOME_NET to represent your network address space The rule should both alert and log The alert message should contain the text ‘Inbound Ping’ 29 Your boss is concerned about inbound ICMP echo requests from outside addresses He would like to have Snort record... detect being a false positive, additional data possibly beyond what Snort provides may need to be examined For example, if an outside user telnets in to a server in your network, it’s possible this rule may be triggered The source port 5031 is an ephemeral port, meaning that is not a reserved port and available for anyone and any application to use If the port 5031 is used by the person connecting... ‘itype’ attribute with a value of ‘8’ to limit the rule to only record echo requests – otherwise known as pings 30 Writing Rules: Simple Rule #2 ! Corporate headquarters routinely runs a scan of all IPs owned by the company, including satellite offices Write a rule that will cause Snort to ignore all inbound TCP packets from the scanning machine, 192.168.1.1 The address space at the satellite office... require close analysis of an attack’s signature and of the source code of the attack application if available These types of rules also have the lowest likelihood of false positives because of the completeness of the examination of the packets They are also the easiest to avoid triggering by making slight alterations in the application s source code 20 Rule Analysis: Advanced Rules ! Learn to analyze difficult... processing that must take place, it can be tuned by specifying the ‘offset’ and ‘depth’ options These options reduce the amount of a packet’s payload that must be inspected by Snort In this rule, only the ‘offset’ option is used This rule tells Snort to start examining the payload 4 bytes in, effectively ignoring the first 3 bytes This may not seem like a lot, but by ignoring 3 bytes of every packet on a very... matter further, you have decided to log all FTP activity to this server to a separate log file so you can see the full session Write a Snort rule that will accomplish this Please briefly pause this presentation now and resume it when you have written the rule 33 Writing Rules: Difficult Rule (cont.) ! Possible Answer: log 10.1.1.0/24 any -> 192.168.1.2/32 21 \ (msg: “FTP activity to anonymous FTP server”;... have written the rule 35 Writing Rules: Advanced Rule (cont.) ! Possible Answer: alert any 53 -> 192.168.1.0/24 53 \ (msg: “Inbound Scan: Pr0b3z”; \ seq: 123456789; flags: S; content: “Boo!”;) 36 For this rule we set the action field to the standard ‘alert’ action 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 . 1 1 Snort Rules: Application Paul Ritchey, Jacob and Sundstrom, Inc. pritchey@jasi.com V1.0.0 Welcome to the class titled Snort Rules: Application 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