Snort Implementationin Cisco Products

• BRKSEC-2137

Eric Kostlan, Technical Marketing Engineer

Security Technologies Group, Cisco Systems

Session Abstract

Snort has become the de facto open standard for intrusion detection and intrusion protection. With the acquisition of Sourcefire in October, 2013, Snort is now one of the technologies used in Cisco products. This session will cover how Snort is implemented and deployed in Cisco product.

No prior knowledge of Snort will be assumed, but some familiarity with IDS/IPS and firewall technologies is assumed.

Session Objectives

Upon successful completion of this session, the attendee will be able to

• Describe the architecture of the Snort engine

• Describe the syntax of the Snort language

• Describe OpenAppID

• Describe how Snort is implemented in Cisco Sourcefire products

• Describe how Snort is implemented in other Cisco products

Agenda

• Introduction

• Snort Fundamentals

• OpenAppID

• Cisco Sourcefire Products

• Demonstration

• Other Cisco Products

• The Internet of Things

• Conclusion

Introduction

https://snort.org

What is Cisco Sourcefire?

• Snort created

• Created by Martin Roesch in 1998

• Snort is both a language and an engine

• Open source rapidly adopts and develops Snort

• Sourcefire founded

• Founded in 2001 by Martin Roesch

• Created a commercial version of Snort

• Sourcefire acquires Immunet cloud based anti-malware vendor

• Acquisition completed 2011

• Cisco acquires Sourcefire

• Acquisition completed 2013 for $2,700,000,000

Historical perspective

NSS Report on IPSBased on Sourcefire IPS technology

NSS Report on Breach DetectionBased on Sourcefire AMP technology

New, Adaptive, Threat-focused NGFW

Identity-Policy Control

& VPN

URL Filtering(subscription)

FireSIGHT

Analytics &

Automation

Advanced Malware

Protection(subscription)

Intrusion Prevention (subscription)

Application

Visibility & Control

Network Firewall

Routing | Switching

Clustering &

High Availability

WWW

Cisco Collective Security Intelligence Enabled

Built-in Network

Profiling

NSS Report on NGFWBased on Cisco and Sourcefire technology

Snort Fundamentals

Snort Engine

• Packet sniffer• Packets are read using the Data AcQuisition library (DAQ)

• Packet decoder• Decodes datalink, network and transport protocols

• Preprocessors• Normalize traffic

• Detection engine• Uses Snort rules to create signatures for threats

• Output module• Handles the task of writing and displaying events

High-level Snort architecture

network

Packet decoder

Alert and log files

Preprocessors

Detection engine

Output module

DAQ libraries

Network

Snort EnginePacket sniffer (DAQ)

Snort Engine

• Snort uses a Data Acquisition Module (DAQ) to collect packets The DAQ

• There is no native Snort packet capture library

• Different capture libraries may be used without the need to recompile Snort

• The DAQ promiscuously picks packets off the wire and passes it to the packet decoder

• DAQ mode – inline, passive or read from file

• DAQ type

• PCAP – The default DAQ

• AFPacket – Like PCAP DAQ but with better performance, and allows inline operation

• IPQ – The old way to process iptables packets. This replaces the compile option--enable-inline used in previous versions of Snort

• NFQ - This is the new and improved way to process iptables packets

• IPFW - Is used by BSD systems. It replaces the compile option --enable-ipfw

Packet sniffer (DAQ)

Snort EnginePacket decoder

Snort EnginePacket decoder

Snort Engine

• Decodes Layer 2 and Layer 3 protocols

• Focused on TCP/IP protocol suite

• Stores decoded packet information in data structures help in memory

• Data structures are utilized by the detection engine

• Configured at Snort start time (using CLI options of the configuration file)

• Specify DAQ mode

• Specify DAQ type

• Turn on or off alerting features of the decoder

• Exclude designated port/protocol pairs from inspection

Packet decoder

Snort EnginePreprocessors

Snort EnginePreprocessors

Snort Engine

• Preprocessors play a vital function in network traffic inspection

• Present packets to the detection engine in a contextually relevant way

• Normalize traffic

• Alert if they detect anomalous conditions as defined by their settings

• Major preprocessors include the following

• frag3 – Used to reassemble packet fragments prior to inspection

• stream5 – Used to reconstruct TCP data streams so that inspection can be done in the context of a TCP conversation

• Protocol decoders – Normalize TCP streams including: telnet, ftp, smtp, and rpc.

• http_inspect – Normalizes http traffic

• DCE/RPC2 – Used to decode and desegment DCE traffic

• sfPortscan – Used to detect portscans

Preprocessors

Snort EngineDetection engine

Snort Engine

• Consists of two components to perform inspection

• Rules builder

• Inspection component

• Rules builder

• On Snort startup, assembles rules into rule chains

• Optimizes rule matching by the inspection component

• Sources, destinations and port sources and destinations redundancies are eliminated

• Implements rules chains as linked lists

• Inspection component

• Matches traffic to a rule chain

• Further inspects traffic against the options in the matching rule chain

Detection engine

Snort EngineOutput module

Snort Engine

• Handles the task of writing and displaying events

• Supports several output formats

• Can send output to files or Syslog

• Can send logs and alerts in straight ASCII

• Can send packets in PCAP format

• Can use Unified2 format (the replacement for Unified format)• Fast and lightweight binary format

• Can be converted to other formats by utilities such as Barnyard2

• The output module can receive input from several sources

• The packet decoder sends data that can be use to produce PCAP output

• Preprocessors send alerts on detection of anomalous conditions

• The detection engine sends log and alert data when rules are matched

Output module

Snort Language

• A simple lightweight language for identifying

• Security policy violations

• Known network attacks and IDS/IPS evasion techniques

• Snort language supports event filters

• Limit – Alert on the a specified number of events during a specified time interval, then ignore events for the rest of the specified time interval.

• Threshold – Only alert if the event is seen a specified number of times within a specified time interval

• Communication between rules is accomplished using flowbits

Note: The snort engine is not restricted to the Snort language. It can use precompiled shared objects in addition to Snort rules.

Overview

Snort Language

• Rule header

• Used to match traffic and performAction (pass, drop, sdrop, alert, log)

• Protocol, Source, Destination 5-tuple

• Rule body

• Contains the message used for alerts

• Contains flow attributes

• Contains the Signature ID and revision number

• Can specify content or regular expressionsin combinations and locations in packet

• Can read packet contents to calculate offsets

• Can set and read flowbits to link to other rules

Rule structure

Snort LanguageOversimplified rules (used for testing)

• alert tcp any any -> any any (msg:"ProjectZ detected";

content:"ProjectZ"; sid: 1001001; rev:1;)

• alert tcp any any -> any any (msg:"ProjectQ replaced";

content:"ProjectQ"; replace:"ProjectR" sid:1001002; rev:1;)

Notes about rule action

• The second rule has replace in the body, so it performs an action not specified in the rule header

• In Cisco Sourcefire products,the action is typically configuredin the Management GUI

Snort Language

alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3306

(msg:"SERVER-MYSQL Database COM_FIELD_LIST

Buffer Overflow attempt";

flow:to_server,established;

content:"|04|"; depth:1; offset:4;

pcre:"/^[^\x0D\x0A\x00]{512}/iR";

metadata:policy max-detect-ips drop,

service mysql; reference:cve,2010-1850;

classtype:attempted-user;

sid:16703; rev:10; )

Sample Rule

Rule header

Rule body

Variables (set to “any” by default)

Alert text

Flow attribute

Content search

Metadata

Signature ID and revision number

Snort Language

• XML file associated with a particular IP address

• Specifies OS and service to port associations on the host

• Affect on preprocessors

• Frag3 and Stream5 – Uses OS information to determine policy, that is, the OS to emulate in packet re-assembly.

• Application layer preprocessors – Users the service information to determine protocol to port mapping.

• Affect on Snort rules through metadata attribute – see next slide

• Sourcefire builds Host Attribute Tables

• Manually

• Through network discovery

Host Attribute Table

Snort Language

• Example:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS

(msg:"MALWARE-CNC Win.Spyware.Rombertik outbound connection"; … ;

metadata:impact_flag red, policy balanced-ips drop, policy

security-ips drop, service http; … ; classtype:attempted-user;

sid:33161; rev:1;

• Open Source Snort

• Provides a way to annotate a rule

• Service attribute Host Attribute Table

• Sourcefire – makes additional use ofmetadata attribute, including:

• Impact flag

• Action to take, based on intrusion policy

Metadata

Snort 3.0

• Also known as Snort++

• User-friendly design

• Built-in Documentation

• Built-in configuration

• Command shell allows interaction with running instance of snort

• Auto-Detection of all protocols on all ports

• Support multiple packet processing threads

• Current version is multi-threaded, but only on thread processes packets

• Protocol

• Simplified rule language

Alpha now available at http://www.snort.org

OpenAppID

OpenAppID Overview

• What is OpenAppID?

• Application Visibility and Control (AVC) done the right way

• An open source application-focused detection language

• Enables users to create, share and implement custom application detection

• Available for download as an extension of Snort 2.9.7 from http://www.snort.org

• Road-mapped for Cisco Sourcefire products Calendar Year 2015

• Key advantages

• New simple language to detect apps

• Reduces dependency on vendor release cycles

• Build custom detections for new or specific (ex. Geo-based) app-based threats

• Easily engage and strengthen detector solutions

• Application-specific detail with security events

The AppID Preprocessor

• Identifies the application

• Generates appid attributes (payload, misc, client, service) that can be used in snort rules.alert tcp any any -> any any (msg:"FTP CWD to root"; appid:ftp;

pcre:"/cwd.*root/i"; gid:1000001; sid:1018758; rev:4; )

• Leverages Snort HTTP preprocessor for header extraction

• Generates application statistics

• Statistics are stored in Uniform2 format

• Statistics file can be read with the u2openappid or u2spewfoo commands

• Statistics can be forwarded to Syslog by using the u2streamer command

AppID Preprocessor Configuration

• Syntaxpreprocessor appid : [memcap <memsize> ,] [app_stats_filename

<filename>, ] ...

• memcap – upper bound for memory use in bytes [256 MB]

• app_stats_filename – name of application statistics file [NULL]

• app_stats_period – bucket size for statistics in seconds [300]

• app_stats_rollover_size – file size that will cause rollover in bytes [20 MB]

• app_stats_rollover_time – time duration that will cause rollover in seconds [1 day]

• app_detector_dir – name of application statistics file [/usr/local/etc/appid]

• debug [disabled]

• dump_ports [disabled]

• Example of entry in the Snort configuration file (snort.conf):preprocessor appid : app_stats_filename appstats-detectorA.log,

app_stats_period 60, app_detector_dir /var/OpenAppID

What is Lua?

• AppID preprocessor leverages the power of the Lua scripting language

• Application detectors are written using the Lua scripting language (not snort rules)

• Lua is a open-source scripting language. • Lua is designed, implemented, and maintained by a team at PUC-Rio, the Pontifical Catholic

University of Rio de Janeiro in Brazil.

• Lua is the Portuguese word for moon.

• Benefits of Lua• Proven – used in many industrial applications, including several Cisco products

• Powerful and fast – utilizes LuaJIT just-in-time compiler

• Portable and embeddable – well documented API

• Simple, lightweight, and small – under Linux, interpreter is 182K, libraries 244K

• See more at http://www.lua.org

Cisco Sourcefire Products

FirePOWER Integration into Cisco Products

FP 8000 Series

2 Gbps – 60 Gbps

NGIPS

• Provides IPS/IDS capabilities and advanced malware protection (AMP)

• Provides AVC and URL filtering

• Provides Network Discovery

• Provides firewall capabilities

• NAT

• Routing

FirePOWER Appliances

FP Virtual

200 Mbps per core

NGIPS

FP 7000 Series

50 Mbps – 1.25 Gbps

NGIPS

FP 8000 Series

2 Gbps – 60 Gbps

NGIPS

Scaling Provided by Stacking

• Stacking combines two or more devices

• One primary device

• One or more secondary devices

• Only the primary devicehas sensing interfaces

• Secondary devicesprovide their CPU andmemory resourcesto the stack

FP8370

FP 8390

60 Gbps

NGIPS

FP8390

FP8350

FP8360

FP 8350

15 Gbps

NGIPS

FP 8360

30 Gbps

NGIPS

FP 8270

45 Gbps

NGIPS

Snort Optimization on Sourcefire Appliances

• Uses Intel C compiler instead of GCC

• Major performance boost by virtue of optimized assembly.

• The network cards on the boxes are custom designed

• Load balances distinct TCP streams across the cores available on the box. This allows for horizontal scaling when boxes are stacked

• Each Snort instance has a single thread for packet processing

• Network monitoring works better with single treading

• Hardware processing

• Look for flow in flow state table, create if not there

• If flow disposition is Block or Trust, take immediate action mark entry in flow state table

• If flow disposition is Inspect, store access control policy rule and start inspection

Cisco Adaptive Security Appliance (ASA)Next-generation security for the Internet edge

1 Gbps Max1 Gbps Max

1 Gbps Max

100K Connections

10,000 CPS

Branch Locations Small / Medium Internet Edge

ASA 5512-X

1.2 Gbps Max

250K Connections

15,000 CPS

ASA 5515-X

2 Gbps Max

500K Connections

20,000 CPS

3 Gbps Max

750K Connections

30,000 CPS

4 Gbps Max

1M Connections

50,000 CPS

ASA 5525-X

ASA 5545-X

ASA 5555-X

Cisco Adaptive Security Appliance (ASA)Next-generation security for the Internet edge and data center

Enterprise Internet Edge and Data Center

4 Gbps Max

1 Million Connections

50,000 CPS

ASA 5585-SSP1010 Gbps Max

2 Million Connections

125,000 CPS

ASA 5585-SSP20

20 Gbps Max

4 Million Connections

200,000 CPS

ASA 5585-SSP4040 Gbps Max

10 Million Connections

360,000 CPS

ASA 5585-SSP60

Scaling Provided by Clustering• Up to 16 ASAs-X

• For ASA 5586-X• FW MAX Throughput: 640 Gbps• FirePOWER IPS 440 Byte

Throughput: 96 Gbps

• Each Sourcefire Sensor is anindependent instance• ASAs share connection state

information• Sourcefire Sensors do not share

signature state information

• State-sharing between firewalls for symmetry and high availability• Every session has a Primary Owner Ownership managed

by Director node• ASA provides traffic symmetry to FirePOWER module

Multi-Context Support

• Security contexts share a single Sourcefire instance

• Context IDs are passed from the ASA to Sourcefire when ASA interfaces are discovered.

• Events passed to FireSIGHT conclude Context IDs.

Cisco Next Generation Firewalls for SMB

Desktop

Model

5506-X

5506W-X

5506H-X 5508-X

Ruggedized 1RU Rack Mounted

750 Mbps Max

50,000 Connections

5000 CPS

750 Mbps Max

50,000 Connections

5000 CPS

1RU Rack Mounted

5516-X

1 Gbps Max

100,000 Connections

10,000 CPS

1.8 Gbps Max

250,000 Connections

20,000 CPS

ASA with FirePOWER ServicesFunctional Distribution of Features

IP Fragmentation

IP Option Inspection

TCP Intercept

TCP Normalization

ACL

NAT

VPN Termination

Routing

Botnet Traffic Filter

Advanced Malware Protection

File Type filteringApplication Visibility and Control

NGIPS

URL Category/Reputation

File captureFirePOWER Services

ASA

ASA with FirePOWER Services

ASA with FirePOWER Services

• Packet flow between the solution components

1. Ingress processing – inbound ACLs, IP defragmentation, TCP normalization, TCP intercept, protocol inspection, clustering/HA traffic control, VPN decryption, etc.

2. Sourcefire Services processing – URL filtering, AVC, NGIPS, AMP, etc.

3. Egress processing – outbound ACLs, NAT, routing, VPN encryption, etc.

• Packets are redirected using the Cisco ASA Modular Policy Framework (MPF)

• MPF supports fail-open, fail-closed and monitor only options

• MPF determines which traffic is send to the FirePOWER Services module

FireSIGHT Management Center

• Formally called Defense Center

• Centralizes configuration of FirePOWER appliances and ASAs with FirePOWER Services

• Receives events from FirePOWER appliances and ASAs with FirePOWER Services

• Correlates events to provide meaningful context for threats

• Can remediate devices in response to combinations of events

* Max number of devices is dependent upon sensor type and event rate

750 1500 2000 3500 4000 Virtual

Max. Devices

Managed10 35 70 150 300

Virtual FireSIGHT

Management Center

Up to 25 Managed

DevicesEvent Storage 100 GB 125 GB 1.8 TB 400 GB 4.8/6.3 TB

Max. Network

Map (hosts /

users)

2K/2K 50K/50K 150K/150K 300K/300K 600K/600KVirtual FireSIGHT

Management Center

offerings limited to 2

or 10 Managed

Devices

FS-VMW-2-SW-K9

FS-VMW-10-SW-K9Events per

Sec (EPS)2000 6000 12000 10000 20000

FireSIGHT Management Center Models

Snort Enhancements

• Security intelligence (also called IP Reputation)

• Provides many predefined IP backlists and whitelists

• AppID

• Provides over 3000 predefined application detectors

• Network discovery

• Provides context for evaluating IPS/IDS events

• Identifies host, applications and users by passively analyzing network traffic

• Populates Network Map and Host Profiles (Host Attribute Tables)

• Access control policy rules engine (not Snort rules)

• Can match Zones, VLAN, IPs, Ports & User/Group based on packet header

• Needs App ID for matching Applications and URLs

Preprocessor enhancements

Snort Enhancements

• Protected content

• Available in Snort 2.9.7. Available in Cisco Sourcefire 5.4alert tcp $EXTERNAL_NET any -> any any (msg:"ThreatZ detected";

protected_content:"59cb046fb3b51555f9b408b6b9cafa13"; hash:md5;

length:7; distance:8; sid: 1001371; rev:1;)

• Application ID

• Available in Snort 2.9.7. Targeted for Cisco Sourcefire 6.0alert tcp any any -> any any (msg:"FTP CWD to root attack";

appid:ftp; pcre:"/cwd.*root/i"; sid:1001372; rev:4;)

• File types and file groups

• Available in Snort 2.9.6. Available in Cisco Sourcefire 5.4alert tcp $EXTERNAL_NET any -> any any (msg:"metaspoit call";

file_type:MSEXE; content:"|4d 45 54 41 53|"; sid:10013728; rev:1;)

Language enhancements

Sourcefire Version Snort Version

5.3 on physical and

virtual sensors 2.9.6

5.3.1 on the ASA

5.4 on any device 2.9.7

Snort Feature DisparityBased on Snort 2.9.7 with OpenAppID and the Cisco Sourcefire 5.4 release

FirePOWER Physical

Appliance

FirePOWER Virtual

Appliance

ASA with FirePOWER

Services

Open Source Snort

OpenAppIDO O O P

On-box decryptionP O O O

NATP O P O

RoutingP O P O

Application bypassP P O O

URL filteringP P P O

AMP for NetworksP P P O

File ProcessingExample of file policy rule

File Processing

• Critical for Advanced Malware Protection (AMP) for Networks

• Leverage FTP, HTTP, SMTP, POP, IMAP Snort preprocessors

• File type is identified using ClamAV libraries

• Usually within first packet of the file payload

• Malware signature calculation & lookup

• Requires entire file

• Uses SHA256 hash in addition to more advanced detection techniques

• Can dynamically submit files for sandboxing

• Can block file transfer

• Can log file and malware events

Details

Life of a Flow (slide 1 of 2)

• Packet sniffing and hardware processing

• Packet decoding

• Preprocessing

• Security Intelligence (IP blacklist and white list)• Immediately mark flow as blocked or trusted

• Update hardware flow state

• Network layer preprocessors• Defragmentation and stream re-assembly

• AppID

• Access control rules engine

• Network discovery

• Remaining preprocessors

Simplified

Life of a Flow (slide 2 of 2)

• Snort detection engine

• Leverages AppID preprocessor to select rules for relevant applications

• Generates events

• If action is to block, mark the flow as blocked and update hardware flow state

• File processing

Simplified

FirePOWER Architecture

• ASA with FirePOWER Services and Virtual FirePOWER applianceare the, except:

• No NFE card

• Different DAQ libraries

• No SSL decryption

On-box Decryption

• Provides inspection of SSL traffic

• More granular AVC for HTTPS

• Provides AMP and IPS for HTTPS, FTPS, etc.

• Integrated into DAQ

• Decryption happens before the inspection engine sees the packets.

• Inspection engine still sees SSL handshake

• DAQ interacts with the SSL preprocessor through policy API

• Road-mapped for:

• FirePOWER virtual appliances

• ASA with firepower services

5.4 FirePOWER physical appliances

Demonstration

Other Cisco Products

Other Cisco Products

• Sourcefire technologies, including Snort are the centerpiece of the Cisco Security strategies

• Sourcefire technologies will be integrated into a wide range of Cisco products

• Snort will Internet of Things (IoT) and Internet of Everything (IoE)

• Cisco ISA

• Several products currently utilize Cisco Sourcefire AMP without a Snort engine

• Cisco Email Security Appliance (ESA)

• Cisco Web Security Appliance (WSA)

• Cisco Cloud Web Security (CWS)

Meraki Implementation of Snort

• Deploys traditional Sourcefire engine

• Downloads rules from Sourcefire servers

• First to the Meraki backend

• Then rules are distributed to devices

• Utilizes predefined security / connectivity / balanced policies

• Does not allow customization of IPS policies

• Implements organization level security reporting

• Administrators can see what signatures fire where across their whole domain

Cisco Meraki MX

• Lean IT focus

• Best in class UTM

• Radically simplified deployment

• Ultra low operating cost via cloud management

• Robust security

• Optimized for highly distributed environments

Cisco ASA with FirePOWER Services

• Threat-focused NGFW

• Advanced threat protection capabilities

• Low cost form factor available

• Unmatched visibility and control

• Provides correlation and advanced analytics

• Advanced remediation capabilities

• Protect against advanced threats

Meraki vs. ASA with FirePOWER Services

Cisco Integrated Services Router (ISR)

• For the ISR 4k, services aredeployed on a UCS-E blade

• Blade contains ESXi hypervisor

• Sourcefire sensor is deployed as a virtual machine

• Can consolidate network functionality into a single router

• Physical IPS sensor Cisco Sourcefire virtual sensor

• Physical WAN optimization device Cisco vWAAS

• Physical QoS appliance IOS QoS capabilities

• Snort integration is road-mapped for lower-end ISR routers

• Similar to Meraki Snort deployment – Snort without the full Sourcefire sensor

The Internet of Things

Cisco Security for Modern Industry

• Leverage industrial network infrastructureproducts are already on the market

• Industrial Ethernet (IE) switches

• Connected Grid Routers (CGR)

• Leverage ASA and Sourcefire technologies

• VPN technologies

• New Snort preprocessors for operational technology (OT) protocols

• New Snort rules for specific OT threats or commands

• Partner with (OT) vendors to build Industrial protections into the Cisco Industrial Security Appliance (ISA)

• Provide Cisco Validated Designs to fit Industrial processes

Industrial Security Appliance (ISA)

• Software

• Firewall: ASA

• IPS: Sourcefire FirePOWER Services

• Identify and block threats

• Generic

• OT protocol specific

• OT application specific

• Application Visibility and Control

• Protocols

• Applications

• Individual commands

ISA 3000 beta to start in July, 2015

Conclusion

Participate in the “My Favorite Speaker” Contest

• Promote your favorite speaker through Twitter and you could win $200 of Cisco Press products (@CiscoPress)

• Send a tweet and include

• Two hashtags: #CLUS #MyFavoriteSpeaker

• You can submit an entry for more than one of your “favorite” speakers

• Don’t forget to follow @CiscoLive and @CiscoPress

• View the official rules at http://bit.ly/CLUSwin

Promote Your Favorite Speaker and You Could Be a Winner

Complete Your Online Session Evaluation

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

• Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card.

• Complete your session surveys though the Cisco Live mobile app or your computer on Cisco Live Connect.

Continue Your Education

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Table Topics

• Meet the Engineer 1:1 meetings

• Related sessions

Thank you