Intrusion Prevention Systems: Panacea or Placebo?

VASCAN Conference – October 24, 2005Matt Keel – Systems EngineerClarke Morledge – Network EngineerCollege of William and Mary

W&M IPS Deployment Case Study The Process that led us to IPS The Promises of IPS The Perils of IPS

Why Network Engineering Runs IPS? Threats to End Users also consume network

resources (Denial of Service) Bandwidth Flows

Layer 2 : Source / Destination MAC address Layer 3: Source / Destination IP address Layer 4: Source / Destination IP address and Source /

Destination TCP or UDP ports

The Process that Led us to IPS Early “classic” worms

Code Red -- 2001 SQL Slammer – Jan 2003

Our early response Back in 2001, all we had was a Cisco 7206 edge

router running 300 MHz CPU More rigorous Layer 3 and 4 router ACLs That’s expecting a lot for an edge router

How about a “Firewall?”

Cisco PIX 525 Internet -> Cisco 7206 -> PIX -> Campus Split access control lists across router and PIX Flow records from the PIX

Visibility of the Internet egress at layer 4 Dynamic shun (scripted login to the PIX)

Why “Firewalls” are Not Enough What is a “firewall” anyway?

Layer 3 and 4 access control lists? Network address translation provider? Virtual private network tunnel endpoint?

For P2P applications, IRC bots, etc., TCP/UDP port numbers do not mean anything anymore

Traditional “firewalls” do not look beyond Layer 4 But Layer 7 is really the evil layer…

How about a Traffic Shaper?

Packeteer PacketShaper 8500 Very useful for classifying and regulating Peer-to-Peer

applications Cheaper than an OC-12

Layer 7 aware Packeteer Flow Data Records extended Netflow-type

records with Layer 7 classification (and direction of flow) Later replaced 8500 with 10000 to get gigabit performance

But, Packeteer says “PacketShaper is not a firewall” Classification is NOT fool-proof Need intelligence on a per-session basis

Intrusion Detection Systems!

Down the rabbit hole…. Enterasys Dragon

Formerly Network Security Wizards (Ron Gula) Signature-based detection, mostly Some protocol anomaly detection

Lots of information Helpful for forensic investigation But a fair amount of false positives

Now we call people to tell them they have a problem, they do not call us

Worthless if no one looks at it

String-based Signatures are Not EnoughMicrosoft LSASS Vulnerability (MS04-011)

Search 150 bytes into TCP stream Binary string match: /ff/53/4d/42 ,

/5c/00/6c/00/73/00/61/00/72/00/70/00/63/00 However, matches on the above string could be legitimate!

What is needed is a protocol parser, but these are more expensive in terms of resources to implement Those vendors who do implement this somehow say: “We

write our signatures based on the vulnerability, not the exploit.”

Some vendors implement Perl Compatible Regular Expressions, or some variant (examples: TippingPoint, SourceFire)

Protocol Anomalies – Inspection Needed! Because so many rely on firewalls for

protection, many programmers will use trusted ports to tunnel services Evil hackers

IRC control channels on non-standard ports Peer to Peer application programmers Even folks who probably should know better

Example: should anything other than DNS use udp/53 or tcp/53?

AOL Instant Messenger uses tcp/53 just in case a firewall blocks access to 5190/tcp

Newer Challenges in Recent Years More Recent Worms

Blaster, Nachi – August 2003 LSASS based worms – May 2004

Limitations of signature-based intrusion detection The need for AUTOMATIC network containment

Speed and frequency of worm propagation The need for ACCURATE identification (false positives)

Example: Nachi ICMP looks like MS Windows traceroute Supplement to IDS

Event correlation using multiple signatures Automatically disable end-user ports via network

management – and/or “shun” on your firewall But can you really trust your IDS?

DrumRoll please….. IPS!!!

TippingPoint UnityOne 2400 March 2004 Security Management System (SMS)

Concerns In-line? What about latency? Throughput? Single point of failure? Accuracy Ability to understand signatures Ability to write your own “signatures”

TippingPoint calls them “filters”

TippingPoint IPS Architecture Layer 2 Switch with fancy stuff on top

Falls back to becoming a IEEE 802.1d compliant switch. (But you really need a bypass switch)

Use fiber (optical bypass) Power via USB TippingPoint calls it ZPHA (Zero Power High Availability)

One box handles multiple segments FPGAs handle data buffering, packet inspection,

and stream blocking CPU handles “Notifying” to SMS

Can be managed via web interface Gui (the “Local Security Manager”, SSH or console per box

SMS is the reporting interface

Where We Put IPS

TippingPoint is $$$ -- make tough decisions Internet egress/ingress Administrative and Residential network

egress/ingress Protect server farm Wireless Network: Entry point into wired

infrastructure Special cases for particularly vulnerable

departments

Promises of IPS (TippingPoint) Prevent well-known worms, etc. from accelerated

propagation Very helpful for segments where you have little control over

the hosts; e.g. student dorms Protects systems while you patch them

The window between vulnerability announcement and public exploit is shrinking

Helps reduce spyware A reasonable job blocking P2P (on wireless)

Cross-verification with Packeteer PacketShaper Packeteer handles some things TippingPoint does not.

TippingPoint handles things Packeteer does not.

Top Ten Filter Hits for One Week (Critical Blocks)

Perils of IPS (TippingPoint)

Adds complexity to network and troubleshooting What is IPS really blocking? Example: Faulty filters blocking NetBackups Example: Faulty hardware with TCP reassembly logic

Dropped some traffic down to 25% of normal rate Still no known root cause

Need visibility on both sides of IPS to troubleshoot Lack of transparency of filtering logic

Filters are not published due to intellectual property concerns

Zero Day Initiative Some filters are not even described – trust the IPS vendor!

Some filters consume more resources than others

More Perils of IPS (TippingPoint) Some filters are RECOMMENDED to be turn

on Other are turned off With NO explanation given

SMS reporting needs serious improvement CPU resources can slow down reporting

More efficient to “Block” instead of “Block and Notify”

Future Challenges for IPS

We upgraded to UnityOne 5000 TCP Syn Cookies on dedicated chip

Quarantining & Interaction with other equipment

10 Gig? Better anomaly detection

Questions????