Chair of Network Architectures and Services Department of Informatics Technical University of Munich Evaluation of Amplification attacks in large-scale networks to improve detection performance Michael Köpferl Interdisciplinary Project Final Talk Advisors: Oliver Gasser, Stefan Metzger January 10, 2018 Chair of Network Architectures and Services Department of Informatics Technical University of Munich
Outline • Motivation • Requirements and Constraints • Architecture and Implementation • Evaluation • Conclusion M. Köpferl — Amplification Attacks 2
Motivation What is an Amplification attack? Figure 1: Devices and data flows during an Amplification attack M. Köpferl — Amplification Attacks 3
Motivation What are the benefits of detecting Amplification attacks? • Ingress Filtering (BCP38) not implemented everywhere • Detect (and suppress) Amplification at amplifier • Detection also possible at the victim, but connection could be saturated • Suppress early in the path at Amplifier M. Köpferl — Amplification Attacks 4
Motivation Goals of this project • Extensible analysis and measurement framework for Amplification attack detection in large-scale networks • Improve insight into Amplification attacks by • conducting active measurements to victims to verify detected attacks, • discovering data to correlate events: Internet addressing information • Organizational information • • Geographical location M. Köpferl — Amplification Attacks 5
Introduction Research Questions • Analyze support for Amplification attack detection in currently deployed LRZ systems: • Do the currently deployed systems allow for reliable attack detection? • Can we retrieve detailed results for evaluation and detection improvement? • How can we analyze amplification attacks in a privacy-preserving way? • Analysis detection metrics: • Which detection features improve detection performance? • Do we find clusters of similar attacks in our measurement results? M. Köpferl — Amplification Attacks 6
Introduction Amplification attack detection algorithm State of research before this project • Amplification attack detection algorithm (Böttger et al.[1, 2]) • Pairflow definition • Limited set of queries resulting into limited set of answers • Checking packet content similarities • Other classification ideas dropped, as not suitable for detection But: could be usable for additional insight and evaluation of true-positive attacks • Implementation of real-time detection in Suricata (IDP Khakimullin[3]) • Correlation and visualization of measurement data (BA Köpferl[4]) M. Köpferl — Amplification Attacks 7
Requirements and Constraints MWN ("Munich Scientific Network") • Heterogeneous network • Different types of systems Network services • Hardware and operating systems • Embedded / specialized systems • Installation of agent software not feasible ⇒ • Individual system administration responsibilities Central enforcement difficult ⇒ • Central Internet connection for the whole network • Managed by LRZ for the MWN in our case • Monitored for security events • Monitoring tools used include QRadar and Suricata M. Köpferl — Amplification Attacks 8
Requirements and Constraints Analysis of Amplification attack detection support in QRadar • Overview • Closed source, developed by IBM • Log and packet collector modules • SIEM system (including IDS/IPS modules) • Evaluation for our use case × No support for pairflow structure (Superflows do not allow our type of aggregation) × No integrated packet similarity calculation ◦ Bad performance of data export disallows post-processing approaches � Alarm generation and correlation would be possible × Conduction of active scans not possible ◦ Connected to LRZ databases, brings own mapping databases M. Köpferl — Amplification Attacks 9
Requirements and Constraints Analysis of Amplification attack detection support in QRadar • Overview • Closed source, developed by IBM • Log and packet collector modules • SIEM system (including IDS/IPS modules) • Evaluation for our use case × No support for pairflow structure (Superflows do not allow our type of aggregation) × No integrated packet similarity calculation ◦ Bad performance of data export disallows post-processing approaches � Alarm generation and correlation would be possible × Conduction of active scans not possible ◦ Connected to LRZ databases, brings own mapping databases ⇒ Cannot implement Amplification attack detection M. Köpferl — Amplification Attacks 9
Requirements and Constraints Analysis of correlation and alarm generation support in Suricata • Overview • Open source, extensible by modules • Existing Amplification attack detection module and pairflow definition • IDS/IPS functionality, reporting to SIEM system possible • Evaluation for our use case � Pairflow structure and detection algorithm implemented already � System performance was sufficient in past evaluations × No automatic alarm generation or correlation supported × No active scans or correlation lookups through connected databases M. Köpferl — Amplification Attacks 10
Requirements and Constraints Analysis of correlation and alarm generation support in Suricata • Overview • Open source, extensible by modules • Existing Amplification attack detection module and pairflow definition • IDS/IPS functionality, reporting to SIEM system possible • Evaluation for our use case � Pairflow structure and detection algorithm implemented already � System performance was sufficient in past evaluations × No automatic alarm generation or correlation supported × No active scans or correlation lookups through connected databases ⇒ Implementation of missing features possible M. Köpferl — Amplification Attacks 10
Architecture and Implementation Position of the Suricata host in the MWN Figure 2: Position of the Suricata host in the MWN M. Köpferl — Amplification Attacks 11
Architecture and Implementation Additional requirements for our project Figure 3: Additional requirements for our project M. Köpferl — Amplification Attacks 12
Architecture and Implementation LRZ constraints Figure 4: LRZ constraints M. Köpferl — Amplification Attacks 13
Architecture and Implementation System components and possible data exchange paths Figure 5: System components and possible data exchange paths M. Köpferl — Amplification Attacks 14
Architecture and Implementation Proposed system design and scan process (1) Figure 6: Proposed system design and scan process (1) M. Köpferl — Amplification Attacks 15
Architecture and Implementation Proposed system design and scan process (2) Figure 7: Proposed system design and scan process (2) M. Köpferl — Amplification Attacks 16
Architecture and Implementation Proposed system design and scan process (3) Figure 8: Proposed system design and scan process (3) M. Köpferl — Amplification Attacks 17
Architecture and Implementation Proposed system design and scan process (4) Figure 9: Proposed system design and scan process (4) M. Köpferl — Amplification Attacks 18
Architecture and Implementation Proposed system design and scan process (5) Figure 10: Proposed system design and scan process (5) M. Köpferl — Amplification Attacks 19
Architecture and Implementation Manual Evaluation Figure 11: Manual Evaluation M. Köpferl — Amplification Attacks 20
Architecture and Implementation Implemented components and functionality based on Suricata • Active measurements implemented • Measure RTT to evaluate impact (network congestion) of Amplification attack • Determine hop count to victim to validate TTL of incoming packets • Database lookups implemented allowing for correlation evaluation • Autonomous System number (Organization) • Domain Name: reverse DNS entry • Geographical location: country, region, city and GPS coordinates • Migrated Amplification detection code to version Suricata 3.2.3 for single threaded operation to overcome log rotation issues • Data privacy / anonymization issues solved • Map host part of IP address to anonymous identifiers • Keep anonymous identifiers in a mapping table for future reference M. Köpferl — Amplification Attacks 21
Architecture and Implementation Comparison of QRadar and Suricata-based implementation -based implementation × � Detection of Amplification attacks � Automatic alarm generation ◦ × � Active measurements to verify results � � Possibility of extended event correlation × Summary ◦ M. Köpferl — Amplification Attacks 22
Evaluation of detection performance Evaluation dataset • Two consecutive measurement runs, 8 hours in total • Suricata crashed after some time, but we couldn’t analyze • Very high packet drop rate in Suricata (96%) • Only a single worker thread instead of 26 M. Köpferl — Amplification Attacks 23
Evaluation of detection performance Evaluation dataset • Two consecutive measurement runs, 8 hours in total • Suricata crashed after some time, but we couldn’t analyze • Very high packet drop rate in Suricata (96%) • Only a single worker thread instead of 26 • Affected Services/Hosts • 1 protocol (NTP , port 123 UDP) • 1 internal server • 15 alerts (malicious events) • 12 external client IP addresses M. Köpferl — Amplification Attacks 23
Recommend
More recommend
