Design and Implementation of a HighPerformance Network Intrusion Prevention System

1
Design and Implementation of a High-Performance
Network Intrusion Prevention System
Distributed Computing Systems Lab, Institute of
Computer Science (ICS) Foundation of Research and
Technology Hellas (FORTH) Crete, Greece
Computer Science Department School of Sciences
and Engineering University of Crete
Konstantinos Xinidis Kostas Anagnostakis Evangelos
Markatos
2
Summary of this Work

• Main focus
• Design and implementation of a high-performance,
  flexible, scalable and low-cost network intrusion
  prevention system (NIPS)
• Design highlights
• Scalable architecture combining a
  high-performance network processor (NP) and an
  array of sensors on commodity PCs
• Efficient coordination between NP and sensors for
  making prevention decisions
• Results
• Four sensors can monitor a fully-loaded Gigabit
  Ethernet link
• Reduction of the processing load of the sensors
  by at least 45 compared to state-of-the-art
  designs

3
Motivation

• Network intrusion prevention systems versus
  routers/firewalls
• Routers are capable of operating at high speed
  links, why network intrusion prevention systems
  arent?
• Significantly more complex than routers/firewalls
  
• Analyze not just packet headers (as routers do)
  but also packet content and higher-level
  protocols
• Gilders Law
• "Bandwidth grows at least three times faster than
  computer power
• Things will get worse
• Scalability is a crucial characteristic
• Progress in detection technology
• High-performance is important but we also need
  flexibility

4
Architecture of Digenis

• Components of Digenis
• A network processor (Splitter)
• Customized load balancer
• A number of PCs (Sensors)
• Network intrusion detection engines
• Splitter
• Entry/exit point of the traffic
• Spread the load across the sensors
• Sensor
• Inspect the traffic for attacks

Forward to the Splitter
No attack found
Analyzing
Sensor 1
Incoming Link
Splitter
Outgoing Link
Sensor 2
Block/Drop the Packet
Analyzing
Attack found
5
Plug-ins of Digenis

• Basic design supports plug-in extensibility
• Plug-ins design goals
• Improve the performance of the system
• Increase the flexibility of the system
• Plug-ins architecture
• Two cooperative parts
• Splitter part
• Sensor part
• Plug-ins implemented
• A plug-in that minimizes the cost of
  splitter-sensor communication

6
Splitter/Load Balancing

• Requirements
• Low per-packet overhead
• Very simple algorithms
• Keep no state
• High efficiency
• Spread load smoothly
• Flow preserving
• Possible approaches
• Stateful load balancing
• Requires from the system to hold state
• Hash-based load balancing
• Results in greater load imbalances

Sensor 1
Network
Splitter
Sensor 2
7
Sensor/Intrusion Detection Engines

• A commodity PC that runs a modified network
  intrusion detection system
• Maintains a database of known attack patterns
• Analyzes traffic for possible known attacks
• Malicious Activity ? Notifies the splitter to
  block the offending traffic
• No attack found ? Informs the splitter to forward
  the traffic
• Maintains state about the traffic it analyzes
• Active TCP connections
• Offending TCP connections
• Fragmented IP packets
• Connections per second to TCP/UDP ports

8
Splitter-Sensor Communication

• Naive approach
• Passive load balancing / forwarding of packets
• Our approach
• Trade-off processing and transmission work for
  forwarding latency
• Splitter
• Tags each packet with a unique identifier (UID)
• Stores temporarily (for a few milliseconds) the
  packets that it forwards to the sensors
• Sensors
• Send back to the splitter a unique identifier of
  the packet
• Communicate with the splitter using
  acknowledgments (ACKs)

An ACK is sent to the Splitter
Storing Packet Into Memory
Stored Packet is Transmitted
Sensor 1
Incoming Link
Splitter
Outgoing Link
Sensor 2
9
Communication BetweenSplitter-Sensor

• The sensors may send back to the splitter
• Positive ACK
• An ACK for every packet not related to any
  intrusion attempt
• Positive cumulative ACK (P-CACK)
• An ACK for a set of packets not related to any
  intrusion attempt
• Negative ACK
• An ACK for every packet that belongs to an
  offending session
• Negative cumulative ACK
• An ACK for a set of packets that belong to an
  attack session
• The packet received (PR)
• Naïve approach

P-CACK with factor 3
From Splitter
Sensor
1
2
3
To Splitter
ACK
1
2
3
10
Implementation of Digenis/Splitter

• Development platform
• Intel IXP1200 Ethernet evaluation board
• Two Gigabit Ethernet interfaces
• Eight Fast Ethernet interfaces
• 32 Mbytes of SDRAM memory
• We have used/modified VERA runtime environment
  described in Karlin01
• Implementation
• Micro-engine assembly language
• Hash-based load balancing
• Boosted by the hash unit

2 Gigabit Ethernet interfaces
8 Fast Ethernet interfaces
11
Implementation of Digenis/Sensor

• Hardware platform
• Dell Poweredge 1600SC server
• Operating system
• Linux Red-Hat 9.0
• Kernel version 2.4.20
• Sensor software
• We modified the popular, open-source network
  intrusion detection system Snort

Front View
Rear View
12
Configurations Implemented for Comparison Purposes

• A forwarder (FWD)
• Simply forwards packets from input to output
  interface
• A load balancer (LB)
• Flow-preserving load balancing
• A load balancer and forwarder (LB FWD)
• The splitter part of Digenis without the
  optimizations

13
Evaluation-Experimental Environment

• Splitter evaluation
• Intel IXP1200 Developer Workbench (version 2.01a)
• Sensor evaluation
• A 2.66 GHz Pentium IV Xeon processor
  (hyper-threading disabled)
• 512 Mbytes of DDR DRAM at 266 MHz
• 64-bit wide PCI bus clocked at 66 MHz
• Intel PRO/1000 MT Dual Port Server Adapter
• Linux OS (kernel version 2.4.22, Red-Hat 9.0)
• Packet traces
• FORTH.WEB
• FORTH.LAN
• IDEVAL

14
Performance of the Network Processor

• Experiments show that all configurations sustain
  line speed
• Metric of comparison
• Utilization of micro-engines
• Utilization of SDRAM
• Results show that

• The splitter does not consume all the resources
  of the IXP1200

• The extra cost of the splitter compared to the
  load balancer is affordable

15
Performance of the Sensors (1/3)

• The bigger the P-CACK factor, the less the total
  processing time for the sensor

• The P-CACK scheme with factor 256 is 45 more
  efficient than the PR scheme

• Diminishing packet transmission overhead for
  P-CACK factor greater than 16

• Processing cost for
• FORTH.WEB trace

• Improvement stems from
• Reduction of system-time
• Some reduction of user-time

16
Performance of the Sensors (2/3)

• The improvement depends very much on the packet
  trace used because
• Different detection heuristics are triggered
• Different detection heuristics have different
  processing costs

• As the P-CACK factor increases so does the MLFR

Maximum Loss Free Rate (MLFR) of a sensor

• Prevention costs slightly more than detection

17
Performance of the Sensors (3/3)

• The latency increases with the P-CACK factor

• P-CACK with factor 16 versus PR scheme
• 80 of the packets experience mostly 2 ms more
  latency than the PR scheme

• There are packets that experience very high
  latency
• Peaks in time spent for executing detection
  heuristics overlapped with peaks in latency
• Form of head of line (HOL) blocking

CDF for latency at MLFR for FORTH.WEB trace
18
Conclusions

• Claim
• It is feasible to build a high-performance,
  flexible, scalable, and low-cost NIPS using
  network processors and PCs
• Evidence
• Digenis architecture and proof-of-concept
  implementation
• High-performance
• NP does load balancing, PCs process in parallel
• Flexible
• Keep as much detection as possible in PCs,
  minimize NP programming
• Scalable
• Add PCs to handle additional load and/or add
  another level of load balancing
• Low-cost
• Off-the-shelf components, optimized software
  architecture to accelerate intrusion
  detection/prevention by at least 45

19
Questions?
20
Thanks!
21
Related Work

• Kruegel et al. Stateful intrusion detection for
  high-speed networks. In Proceedings of the IEEE
  Symposium on Security and Privacy, pages 285294,
  May 2002
• Charitakis et al. An active splitter architecture
  for intrusion detection. In Proceedings of the
  Tenth IEEE/ACM Symposium on Modeling, Analysis,
  and Simulation of Computer and Telecommunications
  Systems (MASCOTS 2003), October 2003

22
Memory Required on the Splitter

• Depends on the latency imported by the sensors
• The greater the imported latency the higher the
  memory requirements
• Assuming the highest latency Digenis tolerates is
  200 milliseconds
• Digenis analyzes traffic at 800 Mbps
• The required memory is approximately 20 Mbytes
• Reasonable considering that the maximum
  addressable SDRAM memory of the IXP1200 is 256
  Mbytes