Tài liệu Snort rules syntax and keywords doc

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.. Snort supports both header and payload inspection metho

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

! What are rules?

! Basic rule anatomy

! 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

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

Snort Data Flow

Packet Decoder Preprocessor (Plug-ins) Detection Engine (Plug-ins) Output Stage (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

Preprocessors

• Lend total flexibility to packet analysis

• Several are available right now

– Port scan detection

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

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

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

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

11

Basic Rule Anatomy

! Each rule has two parts:

! Rule header – first portion.

! Rule options – second portion.

! Specific syntax, format and

keywords for each part.

An individual rule is broken into two general parts The first part, the rule header, defines ‘who’ must be involved in order for the traffic to be considered by the rule options The second part, the rule options, define the ‘what’ must be involved This includes packet header information (such as TCP flag settings) or the contents of the payload

Generally speaking, both sections are used for general rules It is possible to specify rules with only

a rule header so that the specified action can be taken for the provided hosts and ports This is generally the case where pass rules are used to ignore traffic between specific hosts and ports, such

as port 53 traffic coming from a site’s DNS servers Log rules sometimes use only a rule header to specify specific traffic to be logged for later examination, for example all the FTP command channel traffic for a particular server on the network

! Source and destination IPs

! Source and destination ports

! Direction of traffic

alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any (flags: SF; msg: “SYN-FIN scan”;)

The rule header is the first portion of each rule It defines the network protocol and ‘who’ must be involved For each of the individual fields there are many options (with specific syntax) that can be used to specify single values, ranges, or groups of values Each field will be discussed in upcoming slides, covering possible values and the proper syntax for each

Note: Snort’s detection engine breaks the comparison of a packet into two parts, corresponding to the parts of a rule The first comparison compares the rule header to the packet If the packet does not fit the profile of one of the rule headers in a rules set, the detection engine moves on to the next packet If the packet does fit the profile of the rule header, then the detection engine continues on to test the rule options

14

Rule Header: Action

! Action field tells Snort what to do.

! Valid values include:

! Alert – alert and log packet when triggered.

! Log – log only when triggered.

! Pass – ignore (drop) this traffic.

! Activate – alert then turn on dynamic rule(s)

! Dynamic – ignored until turned on by activate

rule, then act as log rule

! Also possible to define your own.

alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any

Action field

The first field in the rule header is the action field This field instructs Snort as to what it is supposed to do if the rule is triggered There are currently three valid values for the action field:

Alert: This value instructs Snort to create an entry in the “alerts” file and to log the packet as well The alert

file is a single file that contains all detects that were made The information written to this file in the default alert mode consists only of the packet header information For the log entry, the same information that is written to the alerts file is written to a directory structure and collection of individual files

Log: This value instructs Snort to only make a log entry No record of the traffic will be made in the alerts file Pass: When a rule is triggered that has ‘pass’ specified as the action, Snort will drop the packet and not do any

further processing of it This is useful for example if you want to monitor for anonymous ftp attempts on your network to non-anonymous ftp servers You would write a pass rule to drop anonymous ftp attempts to your valid anonymous ftp server You would then use a second, normal, ‘alert’ rule to log the anonymous ftp attempts

Activate: These rules when triggered not only alert, but are also used to turn on other rules (dynamic) that

remain idle until turned on

Dynamic: These remain idle (will not trigger) until turned on by an activate rule Once turned on their

behavior is the same as ‘log’ rules

It’s also possible to define your own action types which can be used to route rule output to various destinations This sophisticated usage will not be covered here, but can be 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 was developed for public use to avoid having an errant pass rule accidentally disable every alert and log rule in the system The –o option was developed as an “expert mode” for people once they understood how the rules system worked

15

Rule Header: Protocol

! Protocol field tells Snort what type of

network traffic the rule applies to.

! Valid values include:

protocols will be added in the future

16

Rule Header: Source IP

! Source IP field defines where hostile traffic is originating from.

! Specified in CIDR notation (Classless Inter Domain Routing)

! Possible to specify multiple

to specify multiple addresses or subnets as the source when needed using a special syntax introduced

in Snort version 1.7 Specifying multiple IP addresses in a rule is called using an IP List.

The addresses are specified in CIDR notation, an easy to write and understand format This format includes as much of the address as needed, along with the number of bits in the network mask

In situations where a rule uses the two-way traffic flow for the traffic direction field (‘<>’), this address can represent either a source or destination address and is paired with the port data on the same side of the direction field

17

Rule Header: Source IP (Cont.)

Format: Address/netmask or any or

any - match all addresses

! - negate address (!192.168.5.5/24 - all but 192.168.5.5)

$HOME_NET – variable defined elsewhere in rules file

This slide depicts the supported formats you can specify the source IP in using CIDR notation Examples are provided for the standard network classes (A, B, C) as well as for specifying a specific host For locations where subnetting is used, specify the number of bits in the the network mask thatyou are using (such as 30)

For rules that apply to any traffic, specify the keyword ‘any’ which matches all possible IP

addresses Use the negation operator (‘!’) to apply a rule to all traffic except the specified host or network

A new syntax was introduced with Snort version 1.7 which allows you to specify more than on address at a time To do this, specify the list of addresses in CIDR notation, separating them by a comma The entire list is then enclosed by brackets (‘[‘, ‘]’) Note: Do not leave any spaces when using this format At this time Snort’s rule parser cannot support spaces embedded in the address list

In order to make your rules more portable, it’s also possible to use a variable which is defined elsewhere (command line option or rules file) to specify the source IP Variables and their usage are discussed in a later section

The formats specified here also apply when to the destination IP field, which is covered on a later slide

18

Rule Header: Source Port

! Source Port field defines from what

port on the source host the traffic originates from.

! Specified as a number or range.

alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any Source Port field

The source port field is used to specify the port on the source host that the traffic is originating from The source port can be specified as a specific number, range of numbers, or the keyword ‘any’ which represents all possible source ports

The syntax used for the source port field is the same as the destination port field, which is discussed later

Another point that needs to be made is in reference to the ICMP protocol The ICMP protocol does not use ports like TCP and UDP Since the rule syntax requires ports to be listed for the source and destination, they must still be included for rules that apply to the ICMP protocol For ICMP Snort will ignore the value entered for the ports, but it is traditional to specify the keyword ‘any’

This slide depicts the many ways you can specify the source port You can specify a specific port or different types of ranges It’s even possible to use negation (but not with the ‘any’ parameter) to specify all ports except the one or range specified.

When specifying ranges, the numbers specified are included in the range Using the range

‘33000:34000’ as an example, the range specified is from 33,000 to 34,000, not from 33,001 to 33,999

The formats specified here also apply when specifying the destination ports, which is covered on a later slide

In situations where a rule uses the two-way traffic flow for the traffic direction field (‘<>’), this port can represent either a source or destination port

20

Rule Header: Traffic Direction

! Traffic Direction field defines what

direction packets must be traveling.

! -> defines source to destination

! <> direction doesn’t matter (bi-directional)

alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any Traffic Direction field

The traffic direction field allows you to specify the direction the packet must be traveling Two options are available, allowing you to specify a specific direction of flow, or that direction doesn’t matter

Using the notation that looks like an arrow (‘->’), the packet must be traveling from a source to a destination The source information is specified to the left of the arrow, and the destination is on the right The packet must be traveling in the specified direction If it is traveling in the opposite direction, the packet will not pass the rule header test and will not be inspected any further against the rule

If you use the notation that looks similar to a double headed arrow (‘<>’), the packet can be traveling

to or from either address/port pair For this notation, either address can represent the source IP and port and the other address/port then represents the destination

21

Rule Header: Destination Address

! Destination IP field defines where

hostile traffic is going to.

! Specified in CIDR notation (Classless Inter Domain Routing)

! Refer to Source Address slides for

In situations where a rule uses the two-way traffic flow for the traffic direction field (‘<>’), this address can represent either a source or destination address

22

Rule Header: Destination Port

! Destination Port field defines the

port the traffic must be destined for.

! Specified as a number or range.

alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any

Destination Port field

The destination port field defines the port on the destination machine the traffic must be destined for The destination port is defined using the same formats used to specify the source port Please refer

to the slides pertaining to the source port field for the available formats and proper syntax

In situations where a rule uses the two-way traffic flow for the traffic direction field (‘<>’), this port can represent either a source or destination port depending on the direction the traffic is traveling

24

Rule Options

! Defines ‘what’ is involved.

! Tells Snort what packet attributes

must be inspected.

! Forms a signature defining a specific attack or probe.

alert tcp !10.1.1.0/24 any->10.1.1.0/24 any (flags: SF; msg: “SYN-FIN scan”;)

The rule options portion is the second half of a rule The rule options define the ‘what’ portion of a rule – what attributes of a packet must be inspected and the values they must contain for the packet

to be considered hostile This portion of a rule is only used if the packet meets the specifications of the rule header parameters first

If a packet has met both the requirements of the rule header and the rule options, the rule is then

‘triggered’ Depending on the type of rule, certain actions can take place The most common action that takes place is an alert message being written to the alert file and the packet data being sent to the log files Other options include, but are not limited to SAMBA messages, logged to a database, or one of the many new options that are constantly being added

25

Rule Options Syntax

! Options portion enclosed in

26

Rule Options Syntax (cont.)

! Rule Options portion made up of

individual packet attributes and further

actions.

! Combine multiple packet attributes to

form complete signature.

! Specific, simple syntax must be used.

( flags: SF; msg: “SYN-FIN scan”;)

Packet attribute

The contents of the rule options section between the parentheses is made up of small, individual parts These parts primarily consist of packet attributes and values, but may also consist of actions you want Snort to take beyond those that can be defined in the rule header (Remember the first field

in the rule header allows you to specify one of three possible main actions – alert, log or pass.)

The syntax used in the rule options is the same for both packet attributes and actions It generally consists of an attribute or action keyword followed by a value This is a key concept for

understanding the rule options section: everything generally appears in pairs and uses a simple syntax structure that must be followed for every item

27

Packet Attribute Syntax

! Packet attributes are separated by

semicolon.

! Semicolon must always be included, even on last attribute.

(flags: SF ; msg: “SYN-FIN scan”;)

Attributes separated by a semicolon

Individual parts in the rule option portion are separated by a semicolon (‘;’) For readability you may include spaces between the parts Note that even the last attribute in the rule option section must be terminated with a semicolon Failure to include the semicolon will cause an error when Snort processes the rules file during startup

TIP: When making changes to rules or rule files, do NOT start Snort with the ‘-D’ option When Snort is run in daemon mode it will not display messages about any errors it encounters during startup

28

Packet Attribute Syntax (cont.)

! Must specify packet attribute/action name.

! Must specify packet attribute/action value.

! Attribute names and values discussed in

later section.

( flags : SF ; msg: “SYN-FIN scan”;)

Attribute/Action name Attribute/Action value

Everything in the rule option section must exist in pairs The first item is the attribute or action name, and the second item is the value

There is a specific list of packet attributes or action keywords that can be used (The last section of this presentation covers each of these keywords in depth.) Action keywords tell Snort what actions should take place (in addition to the rule header action) Packet attributes tell Snort to look at an individual attribute of a packet, such as the TCP flags or payload At the time of writing, not every packet attribute is accessible via these keywords For those that are not, tcpdump style filters will have to be used

The value that must accompany each attribute/action keyword depends on the specified

attribute/action Some require numeric values, others require 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

! Each rule is typically a single line.

! Long rules can span multiple lines if continuation character (‘\’) is used.

! Break large rule sets into multiple

files.

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 lines if a continuation character (‘\’) is used The continuation character is placed at the end of a line that is continued on the next line in the file This capability can also be used to make 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 by signature types, such as web exploits, buffer overflows, etc

31

Multiple Rules Files

web-lib overflow-lib misc-lib scan-lib backdoor-lib

‘Master’ Rules File

Include web-lib Include overflow-lib

…

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 ‘master’ rule file as the parameter

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 makes finding a particular rule much easier and keeps them organized

32

Include Syntax

! Primarily used in ‘master’ rule file.

! Can be used in any rule file.

The ‘include’ command is most often used in a ‘master’ file The ‘master’ file is the file specified when using Snort with the ‘-c’ option However, it is also possible to use ‘include’ commands in any rules file, even those that have been ‘included’ into another file

The syntax is very easy to use, it consists of the word ‘include’ immediately followed by the name of the file you want included If needed, you can optionally specify the path to the file as in the second example shown in the slide

33

Variables In Rules Files

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

• Define variables in rules file.

– Variable will be defined for specific rule file or any included rule files.

– Can be overridden by command line option.

• Define variables on command line.

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 You define a variable in the rule file (usually at the top of the file) and the variable value will be substituted wherever the variable is referenced in that rule file, and in any included rule files

A second option with more flexibility is to assign variable values on the command line This assumes that you have referenced this variable in any rule files that are about to be used Again, this avoids hard-coding the value so it is more flexible, but you have to remember to assign a value if this

is the option you chose If you assign both a command line value and a rule set value to the same variable, the variable define on the command line will override the same variable defined in the rules file

• Var <variable_name> <value>

• To use, place ‘$’ in front of variable name

Once the variable is defined, you can use it in rules by placing a dollar sign (‘$’) immediately followed by the name of the variable you want to use In the example depicted on this slide, the variable ‘HOME_NET’ is being defined The value being assigned to it is ‘192.168.5.0/24’ When used in any rule, such as the IRC connection rule shown here, Snort will substitute the value

‘192.168.5.0/24’

The variable ‘HOME_NET’ is a commonly used variable and has become a common term

associated with Snort It’s used to define the network Snort is protecting (essentially the destination addresses) If you then needed to use the same rules file for another network, you only need to change the single line defining the ‘HOME_NET’ variable rather than every single rule

36

Default Variable Value

• Optionally define a default value if variable is

undefined.

• Format:

• $(<variable_name>:-<default_value>)

• Example:

• var HOME_NET $(HOME_NET:-192.168.5.0/24)

It’s also possible to define a default value for a variable if it’s not been already defined This is useful if you are defining variables on 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 one of many possible sophisticated uses of this option It would be used at the top of a rules file to define the variable ‘HOME_NET’ As it defines the variable, the default value syntax will define a default value of ‘192.168.5.0/24’ if the variable has not already been created This allows you to define default variable values in the rules file, but not override them if they were defined on the command line This way the variable will always be defined and Snort will not display an error message if you forgot to define it on the command line

37

Variable Error Messages

• Define error message if variable is not defined.

Initializing rule chains

ERROR test-lib (3): HOME_NET is undefined!

It’s also possible to display meaningful error messages when a variable is undefined This replaces the default error message Snort would display

The syntax is slightly more complicated than what is used to define a variable and care must be taken

to be sure to include the question mark (‘?’) after the colon The error message can be any string that you want displayed when the listed variable is not defined This is useful when you are requiring that some variables be defined on the command line and want a meaningful error message when you forget

38

Define Variables on

Command Line

• Use the -S command line option:

snort -c snort-lib -S HOME_NET=192.168.5.0/24

snort -c snort-lib -S HOME_NET=192.168.5.0/24 -S WEB_SERVER=192.168.5.44

To define variables on the command line, specify the ‘-S’ option Note that the ‘S’ is a capital and not lowercase letter Immediately following the ‘-S’, specify the name of the variable you want to define followed by an equal sign (‘=‘) and then the value

To define multiple variables on the command line, specify each variable using it’s own separate ‘-S’ The second example on this slide depicts how to define multiple variables

39

Reference: Available Rule Options

This section covers each of the available packet attributes and alternative actions that can be specified in the rule options section