1 1 Snort Rules: Syntax and Keywords Paul Ritchey, Jacob and Sundstrom, Inc. pritchey@jasi.com V1.0.0 Welcome to the class titled ‘Snort Rules: Syntax and Keywords’. The purpose of this section is to teach you the basic building blocks for writing Snort rules. These basic building blocks consist of the syntax and keywords Snort provides for writing signatures and taking various types of actions. A later section will take these building blocks and teach you how to apply them to make a complete rule along with understanding the purpose of existing rules. 2 2 Agenda ! Brief Overview ! What is Snort? ! Data Flow ! What are rules? ! Basic rule anatomy ! Rule headers ! Rule options ! Rule files ! Variables in rules ! Reference: Packet Attributes The purpose of this presentation to give you the knowledge necessary to fully understand rules and how they are used with Snort for intrusion detection. You will first have a brief overview of Snort, including the data flow within Snort and how everything is tied together. You will then learn what rules are, their anatomy, and the syntax and options that can or must be used to properly define a rule. You will then learn how to combine rules into rule files, and how to use variables to aid in making your rule sets more easily updated or portable. The final section covers all of the packet attributes Snort can examine to form complete signatures. 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 Brief Overview This first section is a brief overview of Snort. It will provide a very basic overview of what Snort is and some of the terminology used when describing rules. 4 4 What Is Snort? • Intrusion Detection System (IDS). • Payload based packet inspection. • Header based packet inspection. • Flexible alerting/logging capabilities. • Limited response capabilities. • Runs on most Unix platforms. • Free (GPL). • Customisable via plug-in architecture. Snort is an intrusion detection system (IDS) made freely available by Marty Roesch at http://www.snort.org. Snort supports both header and payload inspection methods, allowing you to fully specify in a single rule what constitutes a suspect packet. This flexibility allows you to build rules customized to your site that greatly aid in minimizing false positives, but in a format that is in a human readable. Snort is also flexible when detecting events, allowing you to choose from a variety of methods how you want to be notified. Snort can output to files, databases, SAMBA alerts and various other ways. Snort also has limited capability in responding to intrusion attempts by sending ‘resets’ or other various packets. Snort can be compiled to run on most flavors of Unix including: Linux, BSD variations, Solaris, HP- UX, AIX, IRIX, Tru64 and even MacOS X. Snort will run on most operating systems that are capable of compiling and installing libpcap (a requirement). A Windows version is also available providing the same capabilities for the those not working in a Unix environment. Note the last two items: It's free and you can customize it. Snort is available in source code form for free under the standard GNU license. If Snort doesn't do something you need, write a plug-in! This allows you to extend Snort beyond what Marty and the development team has provided you, and allows you another means to customize its capabilities to your specifics site's needs. 5 5 Snort Data Flow Packet Decoder Preprocessor (Plug-ins) Detection Engine (Plug-ins) Output Stage (Plug-ins) Packet Stream Sniffing Snort Data Flow Alerts/Logs The picture shown here depicts how a packet is moved through Snort, and illustrates how the individual parts within Snort are used to provide a complete detection system. The terminology used here can be a little confusing at first, but the key to understanding Snort it that it is simply a process broken down into several logical steps, each of which is completely built around the concept of plug- ins. The first step is through the decoder. Libpcap captures a packet coming across the wire and hands it to the decoder. The decoder takes the packet and fills in a data structure with the contents of the packet, filling out the portions that apply to the packet type. The next step is through any preprocessor plug-ins that were defined in the rule file, which is covered later. Preprocessors take the data structure created by the decoder and can manipulate the contents of the structure. (Note the keyword in the last sentence: manipulate.) Not other step in Snort’s processing has the ability to manipulate the actual packet. The data structure is then passed to the detection engine where rules are applied to determine if the packet is to be alerted on, logged, etc. This step may or may not be the last step, which is determined if a rule is triggered or not. The output stage, if reached, is where the packet can be logged or alerted on. This last step can be affected by the command line parameters used when starting Snort, or by some of the options specified when configuring the source code before compilation. 6 6 Preprocessors • Lend total flexibility to packet analysis • Several are available right now – Port scan detection – HTTP protocol normalization – Tiny fragment detection – IP defragmentation – TCP stream reassembly Preprocessor plug-ins are done after the packet decoding, but before the detection engine processing. They are called only a single time per packet and may perform highly complex functions such as TCP stream assembly. They can manipulate packet data and even call the detection engine directly. The Tiny Fragment preprocessor was the first preprocessor written and was developed as something of a prototype to demonstrate the usefulness of the preprocessor plug-in interface in Snort. It’s job is to look at the size of fragments on the wire and raise an alert if a fragment is below a preset threshold size. This is useful for detecting malicious fragmentation that is commonly used in an effort to circumvent network intrusion detection systems that do not perform fragmentation. Commonly, these attacks fragment packets to the smallest size allowed by the protocol in an effort to complicate the job of a NIDS sensor. An IDS can use this fact to detect when these evasive tools are in use on the network, because packets which are fragmented by standard commercial network equipment are seldom found to be smaller than 128 bytes. The HTTP protocol normalization preprocessor takes HTTP URL strings and converts them to ASCII strings. The tiny fragment detection preprocessor looks for fragments that are smaller than a threshold size you specify. This can be used to detect subversive behaviour most likely from a crafted packet. The portscan detection plug-in will generate alerts when an IP connects to a certain number of ports in a predetermined time interval. These values are defined in the rules file. In the rules from www.snort.org, the number of ports defaults to 3 and the time interval to 5 seconds. A preprocessor ignore rule can be used to ignore known valid hosts that generate scan-like behaviour and trigger false alarms. The IP defragmentation preprocessor takes fragmented IP packets and puts them back together for the detection engine to consider. The defragmenter takes no arguments. This preprocessor largely supersedes the tiny fragment preprocessor and it is probably not necessary to run the tiny fragment detector alongside the defragmentation preprocessor. The TCP stream reassembler analyses TCP streams and lets the Snort detection engine analyse application layer data that may be spread across many packets. It can be configured with a list of ports to perform reassembly upon, a timeout before flushing data on inactive streams, and a maximum amount of data to buffer. 7 7 Detection Engine TCP Header IP Header TCP Header data Rule #1: Match? yes Rule #2: Match? Rule #X: Match? yes yes no no The Detection Engine is shown here. Decoded traffic from the packet decoder (after going through any preprocessors) is then sent to the detection engine. It is possible to run Snort without applying a rule set, but most times Snort is run with rules. The traffic is analyzed against the rules in the rule files and if a signature and rule match is detected - some kind of logging or alerting is typically done. Keep in mind that detection plug-ins can be operating with the rules to assist in finding more activity. Typically the detection engine is used with Snort based rules. These rules are single line rules in a very human readable format. Snort also supports Berkeley Packet Filter (BPF) format for rules, so it is possible to migrate an existing ‘rule’ set being used for Shadow over to Snort although you will lose access to some of the functionality Snort provides. 8 8 Output Alert File Log Directory [**] NMAP TCP ping [**] 03/21-13:33.51:880120 1.2.3.4:1029 -> 192.168.5.5:80 TCP TTL: 46 TOS: 0X0 ID: 19678 ****** A* Seq: 0XE4F00003 ACK: 0x0 Win: 0XC00 Directory name : 1.2.3.4 File name: TCP:1029-80 Contents: This slide attempts to show the results of finding some kind of malicious activity that matches a rule. We have asked for Snort to alert and log the activity. Snort will either default to the logging file ‘/var/log/snort’, or a log directory that you select as a command line option. The log directory will contain a subdirectory with a name of the IP number that directed the hostile activity. This subdirectory contains a file name that specifies the protocol and the source and destination ports involved in the activity. What you see on the right side of the slide is that we've received some activity from hostile IP 1.2.3.4 and that becomes a directory name. In that directory, we find a file TCP:1029:80 which says that 1.2.3.4 sent a TCP packet from source port 1029 to destination port 80. If an alert rule fires, the packet will be logged and an entry including the alert message will be placed in the alert file. When a packet is logged in its default format to a log file, the messages are also included with the packet dumps. The reason that there is an alert file and a log file is that all alert rules have the packets that cause the alerts logged, but log rules only send packets to the logging facility. The alert file exists to store all the alerts in one place for easy lookup, while the various log files exist to provide an in depth examination of the packets that caused alerts to go off, as well as a place to store packets that had applicable log rules. If we look at the contents of the alerts file, we see the output that tripped the alert. It appears that the ACK (acknowledgement) number is 0 which should never happen in anything other than a normal TCP SYN portion of a three-way-handshake, and so this is perceived to be an nmap scan that is attempting to verify if the destination host 192.168.5.5 is alive. It is possible that 192.168.5.5 will respond with a RESET to an unsolicited ACK to indicate it is alive. 9 9 Output, Continued Alerts written to syslog Disable alerts Full logging Full alerting Fast alerting Disable logging Alerting via Samba Binary logging Database logging Database Alerting XML Alerting Database logging Snort has many different options that can be enlisted for outputting alerts. Default logging will write to the Snort directory ‘/var/log/snort’ with a sub-directory structure recording the activity. Snort can also log in tcpdump binary mode instead, or logging can be disabled entirely. There are also plug-ins available to log to a database or output to an XML logging mechanism to make very portable logs. Full alerting does the normal alerting that we saw a couple of slides ago with analysis of the traffic through the transport level. Fast alerting abbreviates the information that is recorded to a timestamp, the alert message as identified in the rule, and the IP's and ports involved. Also, you can disable alerting all together which might be done if Snort is being used simply as a collection agent and not as a reporting agent. Alerts can also be sent to a Windows host using Samba; this is useful if you or the Snort analyst has a Windows workstation where you are most likely to do your daily work. Alerts can be written to the UNIX syslog file, a database or even a highly portable XML output file if you so choose. This slide shows a very small subset of the possible mechanisms Snort can use to record hostile activity. It’s very likely that more will be added as time passes making Snort even more convenient and valuable to use. 10 10 What Are Rules? ! Rules define what Snort is to watch for. ! Define ‘who’ and ‘what’ is involved. ! Simple syntax, easy to read and create. ! Inspect header, payload or both. By defining rules, you tell Snort what traffic is to be considered hostile. Rules define everything from the ‘who’ is involved (source and destination machines) to the ‘what’ is considered hostile (invalid TCP flag settings, for example). The syntax and keywords are very simple and intuitive, but they are very specific and must be followed closely. For those who have tried deciphering complicated tcpdump filters (such as those used for Shadow), this is a welcome change and makes keeping up with the latest trends in hacking much easier. Rules can be written to be very specific, looking for particular payloads and packet attributes, or they can be very general, specifying only a single IP or port. This allows you great flexibility and the ability to fine tune individual rules to aid in minimizing false positives, or to look for specific types of traffic. [...]... explored at Snort s web site – www .snort. org Note: The normal order rules are processed in is alert rules first, pass rules second and log rules last To change this default behavior, you must specify the ‘-o’ option which changes the order the rules are processed Specifying the ‘-o’ option changes the rule processing order to pass rules first, alert rules second and log rules last This was done when Snort. .. rules more readable by breaking them at consistent points and making them span multiple lines in a consistent format For ease of maintenance and grouping, it is possible to use multiple rules files By inserting special commands into a ‘master’ rules file, Snort will automatically treat your collection of rules files as if they were one single file This allows you to create several files and group rules. .. example shown in the slide 32 Variables In Rules Files 33 Snort offers a valuable tool in writing rules called variables By using variables effectively in your rules, it is possible to make your rules more portable and quickly make changes without having to rewrite every rule 33 Variables Add flexibility and portability to rules by using variables • Define variables in rules file – Variable will be defined... text The syntax and format of the values varies with each of these and is covered in the last section where attribute/action keywords are discussed in depth 28 Rule Files 29 In this section we will cover what rule files are and how they can be used to aid in rule maintenance and organization 29 Rule Files Rules are combined to form Rule Files ! Each rule is typically a single line ! Long rules can... files ! 30 A collection of rules that you want to Snort to use (specified using the ‘-c’ option) are placed into a single file or collection of files These files are called rules files’ (also called config files as more and more configuration data gets put into them) and are read into memory when Snort runs Each line in a rules file typically consists of exactly one rule However, rules may span multiple... This makes finding a particular rule much easier and keeps them organized 31 Include Syntax Primarily used in ‘master’ rule file ! Can be used in any rule file ! Format as follows: ! ! ! Include Example: Include web_exploits ! Include /etc /snort/ buffer_exploits ! 32 The ‘include’ command in a rules file instructs Snort to locate the listed file and replace the ‘include’ line with the contents... The top of the master rules file should contain additional configuration options (pre-processor declarations, variables (covered later)) and the commands to ‘include’ other rules files In this example, the master rules file contains pointers to five other files Each of these files contains a particular set of rules, such as web exploits, buffer overflow exploits, scans, backdoors and miscellaneous This... overridden by command line option • Define variables on command line 34 To add flexibility and portability to rules, it is often helpful to assign a variable or variables to represent a value This is particularly useful for defining your internal network This variable can then be referenced in individual rules so that it is not hard-coded This makes your rules files more portable and easier to maintain... the command line and want to define a default value if you forget or choose not to define the variable on the command line The syntax is slightly more complicated than defining a variable, and care must be taken to make sure the required minus sign (‘-’) is included immediately following the colon The example provided on this slide is a slightly more complicated use of the default value syntax and shows... as web exploits, buffer overflows, etc 30 Multiple Rules Files ‘Master’ Rules File Include web-lib Include overflow-lib … web-lib overflow-lib misc-lib scan-lib backdoor-lib 31 This slide depicts the usage of multiple rules files The ‘master’ rules file (or ‘config’ file) is the starting point leading to all of the other rules files When you start Snort using the ‘-c’ option, specify the name of the . 1 Snort Rules: Syntax and Keywords Paul Ritchey, Jacob and Sundstrom, Inc. pritchey@jasi.com V1.0.0 Welcome to the class titled Snort Rules: Syntax and. explored at Snort s web site – www .snort. org. Note: The normal order rules are processed in is alert rules first, pass rules second and log rules last.