Bro

Bro has a different design than Snort. Snort is a classical misuse detection system looking for predefined patterns. Bro has this functionality also (and is also not multi-threaded), but has another mode focusing on building knowledge of context (stateful protocol analyzer) and is closer to anomaly detection. It generates non-biased events (not good or bad) used at a later stage called the policy script interpreter. The events are created using heuristics that describe the intention of the communication. One example could be external log-in attempt at an SSH server. There used to be a tool ("snort2bro") to convert Snort rules to Bro, but it's no longer supported and there is no organization maintaining static signatures for Bro. Bro also always logs all activity which can be a useful resource in a forensics context.

• Preprocessing is very similar to Snort: Libpcap and DAQ. A snapshot length (only a fraction of the maximum 1500 bytes of the IP-package) is used for determining what session it belongs to and reduces the amount of traffic to look through. Default 68 byte.
  
• Event engine does the event generation. It checks integrity of packet, determines TCP/UDP. Actual or virtual session will be build from buffers. Instead of just relying on port numbers, it will determine the protocol by use of heuristics. Events can be "dns_rejected", "http_request", "x509_error". See file event.bif.bro.

  Every connection (TCP/UDP session) is associated with an analyzer tree that is capable of adding and removing analyzers. The Protocol Identification Analyzer (PIA) system is a state machine that keeps track of actions to be performed, like reassembly, turning to static matching on buffer overflow (4KB buffer per stream), and trying these different analyzers as needed to decode the "intention" of the stream. There are transport layer and application layer analyzers and these are written in a language called BINPAC. Bro assumes that if the protocol used in the beginning of a session is the one being used for the whole session in order not to have to wait for the whole session to end (be real time).
  

  
  
  
  
• Policy script interpreter decides based on combinations of events good and bad behavior. These scripts are assigned to one of the categories Base, Polity and Site. Base are loaded by default. Lots of details for each script...
  
  1. Base: Frameworks: Cluster, Communication, Control, DPD, Intel, Logging, Metrics, Notice, Packet filter, Reporter, Signatures and Software. Misc: fingerprinting of operating systems. Protocol: detection of protocols (http, ftp, irc, smtp, ssh, ssl, syslog) and a special group called CONN for data extraction from TCP/UDP/ICMP sessions.
     
  2. Policy: Frameworks: Communication, Control, DPD, Metrics, Signatures, and Software (similar as for main group Base). Integration: Snort alert support. Misc: Profiling of Bro resource consumption. Protocols: http, ftp, irc, smtp... once more. Tuning: For adjusting performance by filtering
     
  3. Site: Add custom site specific rules for turning events to notices and escalating notices to alarms
     
  
  

There are many log files created in Bro: conn.log, dns.log, weird.log, notice.log, notice_alarm.log, notice_policy.log, reporter.log, loaded_scripts.log

Distributed architecture is supported by having a load balancer (front end - often hardware), multiple workers all running Bro and they send logs to the manager instead of storing them locally. A proxy can be used for sharing information between workers at a central location (look up database?) The manager (also running Bro) receives logs and notices from the workers and stores it in a single location.

Signatures in bro turn events into alerts and alarms. They have a signature ID, a condition and an action. The condition is typically a regex expression for simple matching, typically header and content, but it can also be "context" and "dependency" (require another signature) using the "understanding" of that's going on built from the detection algorithms. The action could be to log or invoke another script for further analysis. It's important to escalate signatures to alarms, otherwise they will just be logged.

Examples:

signature sig1 {
   payload /.*index\.html/
   event “Suspicious traffic containing index.html”
}
signature sig2 {
   http-request /.*pub\.html/
   event “Suspicious http request containing pub.html”
}

Bro is also single threaded, and the best way known for increasing speed is to make use of Bro clusters. As with Snort we have a front-end doing load balancing, a manager collecting logs and workers doing the actual classification of incoming data. Proxies can be used for making worker-to-worker communication more efficient when it comes to sharing state and connection information. It must be configured in the node.cfg file.

Suricata

This IDS is new and experimental, meaning it is fairly new. It is very similar to Snort in functionality as it focuses on misuse rules. The main advantages are better structured code (but still new code), multi-threading (configurable by run-modes) meaning it can handle a lot more data on today's computers. Packet capture is still a major bottleneck and is by default single-threaded. A packet can only be processed by one thread at a single instance in time, but different packages can be inspected simultaneously. A queue keeps track of all the packages.

The rules are compatible with Snort. Suricata has some special extra options. Suricata also borrows some ideas from Bro like trying to determine protocol from content rather from port number alone. Suricata gets free updated from Emerging Threats (Snort VRT cost money for the latest definitions)

Suricata also does some HTTP reassembly, supports Gzip unpacking, and default log output format is unified2 (Barnyard is also supported). It uses Aho Corasick, and an open research question is whether it or alternative algorithms like B2G / B3G (DAWGs), Wu-Manber or any other might actually be faster. Can be changed in the "suricata.yaml" configuration file.