Transcript Improving the Performance of Signature

Improving the Performance of
Signature-based Network
Intrusion Detection Sensors by
Multi-threading
Bart Haagdorens*, Tim Vermeiren**, Marnix Goossens*
[email protected]
*: Vrije Universiteit Brussel
**: Alcatel Bell R&I, Antwerp
Outline
Introduction
 Model of a signature-based NIDS sensor
 Designs for a multi-threaded NIDS
 Evaluation of the designs
 Conclusions & Future work
 Questions

Introduction: a typical signaturebased NIDS sensor
Network
Tap
Packets
NIDS
Sensor
Alerts
Analysis
Backend
Signature
Database


Sensor implemented as software on standard server
hardware
Performance is relevant:


Larger bandwidths
Larger signature sets
Introduction: multiple CPUs

Current NIDS sensors: single-threaded
 Will
exploit only a single CPU
 Only marginal improvement on multi-CPU
hardware
Small-scale multi-CPU machines are quite
mature
 Multi-threaded NIDS sensor would be able
to exploit this capacity

Introduction: a multi-threaded NIDS
sensor on a multi-CPU machine

Multiple threads execute concurrently
 Use
threads to spread workload
 Overall performance will increase
State information can be kept in shared
memory
 Easy system setup and maintenance

 As
compared to traffic splitting/load balancing
Introduction: Related Work

Traffic splitters / load balancers
 No
shared memory
 Traffic splitting for NIDS is not trivial

Multi-threading
 To
isolate the latencies related to storage of
alerts
Model for a NIDS sensor
Elements for a multi-threaded
sensor

Pools
 For

Queues
 To

fast (de)allocation of memory structures
pass structures from one thread to another
Configurability
 Number

of threads, queue and pool sizes
Overhead:
 Protection
of shared data
 Thread switching (by the OS)
 More design constraints
Multi-threaded design 1

Output is handled in a separate thread
Multi-threaded design 2

Signature matching parallel in multiple
threads
Multi-threaded design 3

Content normalization moves into parallel
threads
Multi-threaded design 4

Stateful operations are in parallel now:
 State
needs to be protected
 Order-of-Seniority processing
Order-of-Seniority Processing
Stateful algorithms require packets to be
processed in-order-of-arrival
 Parallel threads: OoSP no longer
guaranteed
 OoSP conflict resolution block:

 Based
on flow ID
 Packets with the same flow ID can not be
handled in different threads at the same time
Multi-threaded design 5

To limit the impact of OoSP requirement
Evaluation: setup
Dual Xeon machine
 HyperThreading: each Xeon can execute
2 threads concurrently
 RedHat Linux 9

 NPTL
pthreads
Modified Snort 2.0.0 implementations
 Measured variable: run time
 Input traffic: Lincoln Labs dump files

Evaluation: results
Relative
run time
single Xeon, dual Xeon,
dual Xeon,
HyperThrea- HyperThrea- HyperThreading disabled ding disabled ding enabled
Snort 2.0.0 100,0%
99,8%
99,6%
Design 1
123,8%
123,2%
122,9%
Design 2
143,7%
94,1%
86,1%
Design 3
136,4%
89,0%
84,0%
Design 4
168,4%
156,2%
151,3%
Design 5
169,5%
131,4%
120,4%
Evaluation: results (2)



A single-threaded implementation benefits very
little from multiple CPUs
On a single CPU, multi-threading always
introduces overhead
Designs 2 and 3 can outperform a singlethreaded implementation by 16%
 What

about >2 CPUs, >4 threads?
Designs 4 and 5 never drop <100%
 too
much overhead: OoSP, state protection
 Limited number of CPUs
Conclusions & Future work


Multi-threaded implementations can outperform
single-threaded ones
Design has a large impact on performance:
 Stateful
operations are best kept in a single thread
 Focus on stateless, workload-intensive blocks

Machines with >2 CPUs, >4 concurrent threads?
 How
will performance scale?
 Will other designs come into focus?

New NIDS sensor implementations could
consider multi-threading from the start
Questions?
Thank you for listening