Evaluation of Amplification attacks in large-scale networks to - - PowerPoint PPT Presentation

▶
evaluation of amplification attacks in large scale
SMART_READER_LITE
LIVE PREVIEW

Evaluation of Amplification attacks in large-scale networks to - - PowerPoint PPT Presentation

Aug 01, 2023 27 likes •520 views

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 Kpferl Interdisciplinary Project Final

slide-1
SLIDE 1

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

slide-2
SLIDE 2

Outline

  • Motivation
  • Requirements and Constraints
  • Architecture and Implementation
  • Evaluation
  • Conclusion
  • M. Köpferl — Amplification Attacks

2

slide-3
SLIDE 3

Motivation

What is an Amplification attack?

Figure 1: Devices and data flows during an Amplification attack

  • M. Köpferl — Amplification Attacks

3

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

slide-8
SLIDE 8

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

slide-9
SLIDE 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
  • M. Köpferl — Amplification Attacks

9

slide-10
SLIDE 10

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

slide-11
SLIDE 11

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

slide-12
SLIDE 12

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

slide-13
SLIDE 13

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

slide-14
SLIDE 14

Architecture and Implementation

Additional requirements for our project

Figure 3: Additional requirements for our project

  • M. Köpferl — Amplification Attacks

12

slide-15
SLIDE 15

Architecture and Implementation

LRZ constraints

Figure 4: LRZ constraints

  • M. Köpferl — Amplification Attacks

13

slide-16
SLIDE 16

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

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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

slide-19
SLIDE 19

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

slide-20
SLIDE 20

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

slide-21
SLIDE 21

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

slide-22
SLIDE 22

Architecture and Implementation

Manual Evaluation

Figure 11: Manual Evaluation

  • M. Köpferl — Amplification Attacks

20

slide-23
SLIDE 23

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

slide-24
SLIDE 24

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

slide-25
SLIDE 25

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

slide-26
SLIDE 26

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

slide-27
SLIDE 27

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
  • Analysis results of attacks on the next slides
  • Report also includes correlation of benign events
  • M. Köpferl — Amplification Attacks

23

slide-28
SLIDE 28

Evaluation of detection performance

Can we find any previously undetected Amplification attacks?

  • Similarity calculation: compressibility of packets in pairflow for both directions separately
  • M. Köpferl — Amplification Attacks

24

slide-29
SLIDE 29

Evaluation of detection performance

Can we find any previously undetected Amplification attacks?

  • Similarity calculation: compressibility of packets in pairflow for both directions separately
  • Yes, we found one more NTP event that was below the fixed threshold:

Figure 12: Box-whisker graph showing similarity distribution of all NTP pairflows

  • M. Köpferl — Amplification Attacks

24

slide-30
SLIDE 30

Evaluation of detection performance

Can we find any previously undetected Amplification attacks?

  • Outliers can be missed by current threshold algorithm
  • M. Köpferl — Amplification Attacks

25

slide-31
SLIDE 31

Evaluation of detection performance

Can we find any previously undetected Amplification attacks?

  • Outliers can be missed by current threshold algorithm

⇒ Improvement suggestion

Figure 13: Suggestion for improvement of similarity thresholds

  • M. Köpferl — Amplification Attacks

25

slide-32
SLIDE 32

Evaluation of detection performance

Do we find clusters of similar attacks in the measurement results?

  • Yes, data can now be aggregated by
  • Network part of IP address
  • Second level Domain Name from reverse DNS entry
  • Organization represented by AS number
  • Location: country, region, city and GPS coordinates
  • M. Köpferl — Amplification Attacks

26

slide-33
SLIDE 33

Evaluation of detection performance

Do we find clusters of similar attacks in the measurement results?

  • Yes, data can now be aggregated by
  • Network part of IP address
  • Second level Domain Name from reverse DNS entry
  • Organization represented by AS number
  • Location: country, region, city and GPS coordinates
  • Correlated detected attacks to
  • 2 IP addresses share the same prefix
  • 3 IP addresses in OVH AS, 2 without mapping, others unique
  • Each 3 and 2 systems share second level domain, 9 without mapping
  • Each 3 and 2 systems in the same country

⇒ Country not completely overlapping with domain

  • M. Köpferl — Amplification Attacks

26

slide-34
SLIDE 34

Evaluation of detection performance

Evaluation of active measurements

  • RTT measurements of suspicious and benign event cannot be compared

⇒ have to be conducted at different stages; not possible in the current environment

  • M. Köpferl — Amplification Attacks

27

slide-35
SLIDE 35

Evaluation of detection performance

Evaluation of active measurements

  • RTT measurements of suspicious and benign event cannot be compared

⇒ have to be conducted at different stages; not possible in the current environment

  • Findings in RTT of malicious events compared to benign events
  • Findings in TTL values
  • We measured hop count to victim
  • Suricata stores TTL value of incoming packets
  • (UDP) traffic packets from attacker
  • ICMP error messages from victim separately

⇒ Comparison results

  • M. Köpferl — Amplification Attacks

27

slide-36
SLIDE 36

Evaluation of detection performance

Evaluation of active measurements

  • RTT measurements of suspicious and benign event cannot be compared

⇒ have to be conducted at different stages; not possible in the current environment

  • Findings in RTT of malicious events compared to benign events
  • Findings in TTL values
  • We measured hop count to victim
  • Suricata stores TTL value of incoming packets
  • (UDP) traffic packets from attacker
  • ICMP error messages from victim separately

⇒ Comparison results

  • 30 hosts per minute can be scanned
  • Scan is started too late due to interface delays
  • M. Köpferl — Amplification Attacks

27

slide-37
SLIDE 37

Evaluation of detection performance

Evaluation of RTT measurements (1)

Figure 14: Box-whisker plot showing RTT value distributions

  • M. Köpferl — Amplification Attacks

28

slide-38
SLIDE 38

Evaluation of detection performance

Evaluation of RTT measurements (1)

Figure 14: Box-whisker plot showing RTT value distributions

  • RTT to client is significantly higher for malicious pairflows
  • But: RTT to client is higher than to server as well
  • M. Köpferl — Amplification Attacks

28

slide-39
SLIDE 39

Evaluation of detection performance

Evaluation of RTT measurements (2)

Figure 15: Box-whisker plot showing how many RTT measurements were successful

  • M. Köpferl — Amplification Attacks

29

slide-40
SLIDE 40

Evaluation of detection performance

Evaluation of RTT measurements (2)

Figure 15: Box-whisker plot showing how many RTT measurements were successful

  • 75% of client ICMP measurements were not answered at all
  • Difficult to come to a valid conclusion for those
  • M. Köpferl — Amplification Attacks

29

slide-41
SLIDE 41

Evaluation of detection performance

Evaluation of TTL measurements

Figure 16: Box-whisher plot showing deviation of TTL values

  • M. Köpferl — Amplification Attacks

30

slide-42
SLIDE 42

Evaluation of detection performance

Evaluation of TTL measurements

Figure 16: Box-whisher plot showing deviation of TTL values

  • Active approach gets much higher number of values (45x)
  • Delta in hop count due to network structure
  • M. Köpferl — Amplification Attacks

30

slide-43
SLIDE 43

Evaluation of detection performance

Performance evaluation of active measurements

Figure 17: Time-series plot showing scan duration and number of entries per file

  • M. Köpferl — Amplification Attacks

31

slide-44
SLIDE 44

Evaluation of detection performance

Performance evaluation of active measurements

Figure 18: Scatterplot showing scan duration per entry in seconds

  • M. Köpferl — Amplification Attacks

32

slide-45
SLIDE 45

Evaluation of detection performance

Performance evaluation of active measurements

Figure 19: Time-series plot showing scan diration per entry and entries per scan job

  • M. Köpferl — Amplification Attacks

33

slide-46
SLIDE 46

Conclusion and Future Work

Results

  • Scanner implemented
  • Separated Suricata machine and Scanner host connected with an interface
  • Automated anonymization of results
  • M. Köpferl — Amplification Attacks

34

slide-47
SLIDE 47

Conclusion and Future Work

Results

  • Scanner implemented
  • Separated Suricata machine and Scanner host connected with an interface
  • Automated anonymization of results

Future Work

  • Multi-threaded implementation for pairflow structure in Suricata
  • Ready-to-run solution, including (automated) warning and visualization
  • Improve packet similarity threshold algorithm
  • Research additional measurement or correlation criteria
  • Improve scanner performance and simplify system architecture if possible
  • M. Köpferl — Amplification Attacks

34

slide-48
SLIDE 48

Bibliography

[1]

  • T. Böttger.

Detection of Amplification Attacks in Amplifier Networks. Master’s thesis, Technische Universität München, 2014. [2]

  • T. Böttger, L. Braun, O. Gasser, F. von Eye, H. Reiser, and G. Carle.

DoS Amplification Attacks – Protocol-Agnostic Detection of Service Abuse in Amplifier Networks. In M. Steiner, P . Barlet-Ros, and O. Bonaventure, editors, Traffic Monitoring and Analysis, volume 9053 of Lecture Notes in Computer Science, pages 205–218. Springer International Publishing, 2015. [3]

  • A. Khakimullin.

Real-time Amplification Attack Detection. Interdisciplinary project, Technische Universität München, 2016. [4]

  • M. Köpferl.

Effective Visualization of Amplification Attacks in Amplifier Networks. Bachelor’s thesis, Technische Universität München, München, Sept. 2015.

  • M. Köpferl — Amplification Attacks

35

slide-49
SLIDE 49

The End

Thank you for your attention

  • What are your questions?
  • M. Köpferl — Amplification Attacks

36