Transcript Intrusion Prevention Systems: Panacea or Placebo?

Intrusion Prevention Systems:
Panacea or Placebo?
VASCAN Conference – October 24, 2005
Matt Keel – Systems Engineer
Clarke Morledge – Network Engineer
College 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




Lots of information




Formerly Network Security Wizards (Ron Gula)
Signature-based detection, mostly
Some protocol anomaly detection
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 Enough
Microsoft 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


The need for ACCURATE identification (false positives)


Example: Nachi ICMP looks like MS Windows traceroute
Supplement to IDS



Speed and frequency of worm propagation
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)






One box handles multiple segments
FPGAs handle data buffering, packet inspection,
and stream blocking
CPU handles “Notifying” to SMS


Use fiber (optical bypass)
Power via USB
TippingPoint calls it ZPHA (Zero Power High Availability)
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


Protects systems while you patch them



Very helpful for segments where you have little control over
the hosts; e.g. student dorms
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




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


Dropped some traffic down to 25% of normal rate
Still no known root cause
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????

