How are signatures for IPS determined

Question

For example , how do Snort's VRT team or some one who gives us the signatures, determine them at all ?

I would be more interested to know , how are the traffic patterns analyzed against some known theoretical models( any statistical / probablistic models ?) to determine the signatures ?

Answer 1

Sashank, That is a good question.

Writing rules is a fun research work. Often it takes lot of research and analysis, and sometimes for some threats its very easy to write a signature.

This is quick very high level overview of writing signatures. The things you should know before hand to perform analysis and to start writing rules -

• Very good understanding of Protocols according to their RFCs - This includes all protocols (IP, ICMP, DHCP, TCP, UDP, SMTP, FTP, POP3, ssh, telnet etc.) in OSI layers (datalink, network, transport, session etc). The RFC is the guideline of how a protocol is designed, how it should behave. This is a very important reference in writing rules. RFC define the structure of the protocols, their headers, state, flags/attributes. On the network, any observed deviation from these RFCs standards is the key in writing rules.

• Detailed understanding of the vulnerability - What do you want to write a signature for? Do you understand how the vulnerability works? Do you know what are you looking for in the network traffic? Where shall you concentrate on in the application/service? Trying to answer these questions will give you a path to understand the vulnerability. Example - if you are writing a rule for remote buffer overflow on port 80/http on IIS, then you must understand the web server architecture, how data get handled internally in the web server, how does the web server handle the requests and generates responses. This will clarify the vulnerability. If you understand this then it lead you to what exactly you should be looking for. This is applicable for any remote or local service/process/software you want to a vulnerability rule for.

• Lot of lab work - Run the exploits over and over in different scenarios, get lot of packet captures or memory dumps. Analyse the timeline, analyse the packet headers and compare that with RFC standards, analyse the payloads. If you run an exploit 10 times, then the packet captures will give you the timeline, size of the payload/data, bit sequence (data) in the payload and most importantly it will clarify the conditions under which the exploitation is most likely to be successful. Putting all this together will bring good accuracy for the signature, then you know the exact bit patter to look for and when to look for, and where to look for.

Answer 2

Replacing 'signature' with 'rule'.

Sometimes it's a simple task, other times not so.

Rules are generally created (afaik) by examining packet captures of attacks/exploits and then creating rules that match that traffic pattern. The skill is creating a rule that is as precise as possible in order to limit false-positives but generic enough to ensure you catch everything. The built-in rules are created in the same way as many folk create their own rules - analysing packet captures, looking at the bits and bytes to create an appropriate pattern. The easy bit is obviously matching the ports and protocol (i.e. the RULE HEADER).

he traffic flow (i.e. from/to server) but then it becomes more complex with the operators (content, offset, depth, within, distance etc) or invoking pcre. The other tricky element is ensuring that a rule not only catches the traffic but doesn't affect performance detrimentally.

Snort is now a complicated beast (in a good way) and there's a lot more to it than simple rules looking for traffic patterns. The real work happens with the pre-processors and the more recent DAQ module.

Here's an old post that talks about how IDS signatures/rules are created.

A good person to chat to would be Joel Esler (@joelesler), a Sourcefire veteran and member of the VRT team. I'm not sure what he can tell you though he's a sample from him. The folks in the VRT team are real packet monkeys, great developers and perform extensive testing on their rules prior to release. Quite often this testing is done with the vendor or company who has either discovered or been affected by the attack.

There's literally loads of docs on the net about how snort rules are written, many of which are written by Sourcefire employees and the manual.