Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 ?

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
then , how do we prevent zero day attacks ? –  sashank Jul 15 '12 at 6:37
    
Zero day is when a vulnerability and exploit is publicly known but there is no security fix by the vendor. Unknown threats are detected by anomaly based analysis and rules based on the past behavior. –  Kapish M Jul 15 '12 at 23:54
add comment

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.

share|improve this answer
    
+1 for the Joel Esler reference, and also for the great explanation and references! –  pnp Jul 13 '12 at 15:45
    
thanks....... :) –  Mark Hillick Jul 13 '12 at 16:17
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.