Snort first started as a packet sniffer. Another common example of a packet sniffer is tcpdump, or its graphical big brother Wireshark. In order to evolve into the IDS software that it is today, Snort added a few things in its architecture. It currently functions as a core with plug-ins system, where its primal component (the sniffer) is the core and the other elements act as plug-ins.
The other elements are the preprocesors, the detection engine and the output.
1. The sniffer – as the name says, it “sniffs” (collects) network traffic and identifies each packet structure (layer information). After collecting, the raw data (packets) are being sent to the preprocessors.
2. The preprocessors – perform certain actions to determine what kind of packets or what kind of behaviour is Snort dealing with. There are muliple preprocessor plugins. As we can see in the picture above, one of the is the HTTP plug-in which will identify HTTP packets. The sfPortscan preprocessor is a good example of how Snort determines packet “behaviour”. Having defined protocols, scan types and sensitivity levels it can identify multiple packets as a port scan. After doing its job, the processors will send the information to the detection engine.
3. The detection engine – compares each packet with each rule from a predefined ruleset. If packets match the rule contents (or the other way around), they are being forwarded to the output.
4. The output – will log and/or trigger alerts based on the rule action. Logs can be saved in different formats (syslog format, unified2) and to different locations (directly to db). As they are, logs and alerts are a bit difficult to read from the command line (especially when we are talking about orders of 10000 or more) – this being the main reason why user interfaces are required. Snort user interfaces (Snorby, ACID) act as extensions to the Output component of Snort.
As we can see from its architecture and behaviour, Snort is an ideal candindate for a sensor in a network security monitoring system.