Bart Haagdorens* , Tim Vermeiren**, Marnix Goossens* bart.haagdorens@vub.ac.be

1. Improving the Performance of Signature-based Network Intrusion Detection Sensors by Multi-threading Bart Haagdorens*, Tim Vermeiren**, Marnix Goossens* bart.haagdorens@vub.ac.be *: Vrije Universiteit Brussel **: Alcatel Bell R&I, Antwerp

2. Outline • Introduction • Model of a signature-based NIDS sensor • Designs for a multi-threaded NIDS • Evaluation of the designs • Conclusions & Future work • Questions

3. Introduction: a typical signature-based NIDS sensor Network Tap Analysis Backend NIDS Sensor Packets Alerts SignatureDatabase • Sensor implemented as software on standard server hardware • Performance is relevant: • Larger bandwidths • Larger signature sets

4. 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

5. 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

6. 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

7. Model for a NIDS sensor

8. Elements for a multi-threaded sensor • Pools • For fast (de)allocation of memory structures • Queues • To 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

9. Multi-threaded design 1 • Output is handled in a separate thread

10. Multi-threaded design 2 • Signature matching parallel in multiple threads

11. Multi-threaded design 3 • Content normalization moves into parallel threads

12. Multi-threaded design 4 • Stateful operations are in parallel now: • State needs to be protected • Order-of-Seniority processing

13. 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

14. Multi-threaded design 5 • To limit the impact of OoSP requirement

15. 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

16. Evaluation: results

17. 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 single-threaded 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

18. 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

19. Questions? Thank you for listening