The Experiment Signatures Preparation

The single packet attacks can be classified into two types. In the first type, only the packet headers are used (i.e., IP and TCP headers) in the attack. In the second type, the payload or the data field of the packet is also used. Intuitively, the second type needs more processing time per packet. This processing time varies depending on how far from the beginning of the payload field the NIDS needs to match a specific string, word, or pattern of characters (the payload size in each TCP/IP packet is between 46 and 1500 bytes). For instance, if a packet of payload size 1500 needs to be processed and if the signature of the attack specifies that the string “CD root” must be matched at the beginning of the payload , then it will be processed faster than if the signature specifies that it needs to be checked at the end. Of course, more processing time will be needed for matching if the signature specifies that “CD root” should be matched anywhere in the payload.

To achieve the best processing speed possible when handling text patterns match- ing, SNORT and BRO use regular expressions (regexp). SNORT uses Perl Compatible Regular Expression (PCRE1) library andBRO follows FLEX’s2 regular expression syn- tax [50]. TeStID uses Java regular expression available from theStreamBase Language standard functions library [93]. Using these variants of regular expression syntax to represent an attack results in different regular expression search strings. This needs to be coded carefully for testing the attacks with payload for each variant. A single missing/extra wild card character results in missing an attack.

For this experiment, a selected set of attacks from SNORT official signatures are used which were developed and tested by the Sourcefire Vulnerability Research Team® (VRT) [88]. This set consists of 50 attacks specified by SNORT syntax signatures (see Appendix B.1). Using BRO signature language, we can rewrite the same SNORT 1_{PCRE is an open source library written in C. The library is a set of functions that implement}

regular expression pattern matching using the same syntax and semantics as Perl 5. More information at http://www.pcre.org.

2

Fast LExical analyzer is free software for scanning and recognizing lexical patterns in text. More information at http://flex.sourceforge.net

Chapter 7. Experiments and Results 91

signatures. BRO has a Python script (snort2bro) that converts SNORT’s signatures into BRO signatures. We make use of this to convert from SNORT toBRO. It works well most of the time but manual intervention is sometimes needed [11]. Appendix B.2 presents the equivalent BRO signature file used in the experiment. For TeStID these selected SNORT signatures are written using the proposed MSFOMTL syntax and semantic in Section 5.1. Each attack is represented by a MSFOMTL formula; the file that contains all the selected attacks is presented in Appendix B.3.

To illustrate the differences between these three systems in terms of writing or spec- ifying a signature, let us take an example which is SNORT signature id 255 (sid-255). InSNORT signature syntax it is specified as follows:

alert tcp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"sid-255 DNS zone transfer TCP"; flow:to_server,established; content:"|00 00 FC|"; offset:15;

metadata:policy security-ips drop; reference:arachnids,212; reference:cve, 1999-0532; reference:nessus,10595; classtype:attempted-recon; sid:255; rev:17;)

Explanations for the keywords used in this signature are:

• “alert tcp” means that alert should be generated and it is a signature for TCP.

• “$EXTERNAL NET any” refers to the source IP address which is defined in the system globally by the variable$EXTERNAL NET and the source port (any port).

• “$HOME NET 53” refers to the destination IP address which is defined globally in the system by the variable $HOME NET and the port 53.

• “msg:“sid-255 DNS zone transfer TCP”” is the message written into the log file when an attack occurs.

• the “flow” refers to the direction of the flow.

• “content” is the content in hexadecimal that needs to be checked in the payload. In SNORT you can specify the contents using hexadecimal or strings or combination of both.

• “offset” means how many bytes to skip from the beginning of the payload.

• “sid” is the signature id as identified inSNORT.

• the rest keywords are information keywords. A full description of all the available keywords are available at [17].

The equivalent for thisSNORT signature using BRO signature language is: signature sid-255 {

ip-proto == tcp src-ip != local_nets

Chapter 7. Experiments and Results 92

dst-ip == local_nets dst-port == 53

event "DNS zone transfer TCP" tcp-state established,originator payload /.{14}.*\x00\x00\xFC/ }

Explanations for the keywords used in this signature are:

• “signature” refers to the signature id for identifying and logging.

• “ip-proto” refers to the protocol type (TCP, UDP, etc.)

• “src-ip” refers to the source IP address. This address could be specific or globally defined in a variable (local net).

• “dst-ip” refers to the destination IP address.

• the “dst-port” refers to the destination port.

• “event” is part of the logged message when this attack occur.

• “tcp-state” information about the tcp-state at the time of receiving this packet.

• “payload” search string in the payload.

Notice here that not specifying the source port means any port. Also, the content that need to be search in the payload is typed directly with regexp syntax.

In MSFOMTL, formally the representation of the attack is: (∃x4, x12)((∃y1, y2, y3, y5, y6, y7, y8, y10, y11)

P(y1, y2, y3, x4, y5, y6, y7, y8,1, y10, y11, x12)

∧(x4 = 53)∧(x12=f(".{14}.∗ \u0000\u0000\u00fc.∗")))

In the above formula, the regular expression is expressed as Java regexp syntax. x12 is

the payload andx4is the destination port. All other arguments are exactly as explained

in Section 5.1.1.

Beside the signature preparation overhead for these three systems, there is the over- head of the interpretation of the logged events. BRO reports by session and this means it would report less thanSNORT. This means the attacks for the same session is reported per session not per each packet that trigger the attack in the session. TeStID reports each packet that carries an attack. Fortunately, BRO and SNORT have the capability to run in offline mode (reading the dump file directly) and this allows us to establish how all the existing attacks in the trace are reported by each system. For TeStID this was done manually by validating the results of running against the test file with the result obtained by runningSNORT and BRO in the offline mode. In addition,WIRESHARK helped analyzing and verifying the packets inside the trace file.

Chapter 7. Experiments and Results 93