BRKSEC-2137 – Snort Implementation in Cisco Products

Presenter: Eric Kostlan, Technical Marketing Engineer, Cisco Security Technologies Group


Above all, Snort is a community –Eric

Snort stats

  • over 4 million downloads
  • nearly 500,000 registered users

Snort was created in 1998 (!!). Sourcefire founded in 2001.

The Snort engine

  • Packet sniffer (DAQ)
  • Packet decoder
  • Preprocessors
  • Detection engine
  • Output module

DAQ – packet acquisition library(ies?). Snort leverages this to pull packets off the wire (Snort doesn’t have its own built-in packet capture abilities). DAQ provides a form of abstraction between the Snort engine and the hardware where the bits are flowing. DAQ – Data AcQusition. DAQ modes: inline, passive or read from file.

Packet decoder – look for header anomalies, look for weird TCP flags, much more. Generator id (GID) is 116 for the packet decoder. Decodes Layer 2 and Layer 3 protocols with a focus on TCP/IP suite.

Preprocessors – apply to Layer 3, 4, and 7 protocols. “Protocol decoders”. Normalizes traffic. Major preprocessors: frag3 (reassembly), stream5 (reconstruct TCP streams), http_inspect (normalizes http traffic), protocol decoders (telnet, ftp, smtp, so on).

Detection engine – various performance settings (eg, how long to spend on regex). Two components: rule builder and inspection component. Rule builder: assembles the rules into rule chains (doubly linked lists) and optimizes rule matching for the inspection component.

Output module – handles the task of writing and displaying events; Several output formats: files, syslog, PCAP, Unified2 format (fast and lightweight binary format). Output module receives data from several sources: packet decoder can send data that is used to produce PCAP output, preprocessors send alerts, detection engine sends log and alert data.

Snort language:

  • A lightweight language for identifying policy violations and known network attacks and IDS/IPS evasion techniques
  • Supports event filters: alert on a specified number of events during a specified time interval; threshold alert if the event is seen a specified number of times within a specified time interval
  • Supports communication between rules using “flowbits”; allows complex matching of traffic using multiple rules
  • Rule structure: header (action + 5-tuple) and body
  • Variables used in the 5-tuple default to “any”. So a rule like “alert tcp $EXTERNAL_NET any -> $SERVERS 80” will default to any -> any 80.
  • Host Attribute Table – XML file associated with a particular IP address; specifies OS and service-to-port associations of a host. This information can be used in a rule to only apply the rule to hosts running a web server, for example (“service http”). In open source Snort, the HAT has to be built manually. In Sourcefire/Cisco products, the HAT Is built automatically by passively looking at network traffic.

Snort 3.0

  • user-friendly design
  • auto detection of all protocols on all ports
  • support multiple packet processing threads
  • in alpha phase now (


  • “Application visibility and control, done right.”
  • An open source application-focused detection language
  • Allows customers/users to build their own application signatures and use them in Snort/Snort-based products
  • Roadmapped for Cisco products near end of 2015
  • In Snort 2.9.7 now
  • Runs as a preprocessor in Snort
  • Lua language – application detectors are written using Lua; small, lightweight, open source (

Snort optimizations on Sourefire appliance:

  • Intel C compiler instead of GCC
  • Network cards are custom designed
  • Hardware processing (NFE card; Netronome (?) Flow Engine) for working with flows in hardware

ASA + FirePOWER: better together

  • ASA clustering allows FirePOWER to scale really nicely in the data center by resolving the asymmetric taffic concerns
  • ASA nicely normalizes the traffic before shunting it to FirePOWER

Snort and FirePOWER versions

  • FP 5.3, 5.3.1: Snort 2.9.6
  • FP 5.4: Snort 2.9.7
  • FP 6.0: Wil be Snort 2.9.8

Amazingly detailed block diagram of FirePOWER architecture in the slides.

Snort on Meraki

  • Not full FirePOWER but not “just” the open source Snort either
  • Uses the Sourcefire ruleset
  • It’s not the full FirePOWER sensor

Snort on ISR 4k

  • Runs as a virtual sensor on ESXi on UCS-E blade


  • Snort is being brought along into the IoT space
  • New preprocessors being built to understand opertional technology (OT) protocols. Think: identifying a specific operations command being sent from an operations console to a field device.

I believe it will be well worth your time to invest in and learn Snort as I believe it will be around for many years to come as a core security technology. –Eric

One thought on “BRKSEC-2137 – Snort Implementation in Cisco Products”

Leave a Reply

Your email address will not be published. Required fields are marked *

Would you like to subscribe to email notification of new comments? You can also subscribe without commenting.