TCP SYN Flood Mitigation Techniques Julian Villing Friday 25 th - - PowerPoint PPT Presentation

Chair of Network Architectures and Services Department of Informatics Technical University of Munich

TCP SYN Flood Mitigation Techniques

Julian Villing

Friday 25th January, 2019 Chair of Network Architectures and Services Department of Informatics Technical University of Munich

Introduction

TCP Handshake Client Server

• 1. SYN SEQ=x
• 2. SYN-ACK SEQ=y ACK=x+1
• 3. ACK SEQ=x+1 ACK=y+1

Figure 1: TCP Handshake

• J. Villing — SYN Flood Mitigation

2

Introduction

TCP SYN Flood

• TCP connection states stored in thread control blocks (TCB) [1]
• TCBs saved in backlog until connection is established or a timeout occurs
• J. Villing — SYN Flood Mitigation

3

Introduction

TCP SYN Flood

• TCP connection states stored in thread control blocks (TCB) [1]
• TCBs saved in backlog until connection is established or a timeout occurs
• SYN Floods initiate countless connections without completing the handshake
• Many unncessary connections exhaust the servers backlog (DoS Attack)
• Free space required for connection establishment
• J. Villing — SYN Flood Mitigation

3

Introduction

TCP SYN Flood

• TCP connection states stored in thread control blocks (TCB) [1]
• TCBs saved in backlog until connection is established or a timeout occurs
• SYN Floods initiate countless connections without completing the handshake
• Many unncessary connections exhaust the servers backlog (DoS Attack)
• Free space required for connection establishment
• Issue addressed by mitigation techniques
• Examples: SYN Cookies, SYN Authentication, SYN Agent
• J. Villing — SYN Flood Mitigation

3

Mitigation Techniques

SYN Cookies

• Initial sequence number (ISN) can be chosen at random [1][5]
• Used to encode state (adresses, ports, client ISN, ...)
• Compared with clients’ response
• Connection allocated directly as established
• J. Villing — SYN Flood Mitigation

4

Mitigation Techniques

SYN Cookies

• Initial sequence number (ISN) can be chosen at random [1][5]
• Used to encode state (adresses, ports, client ISN, ...)
• Compared with clients’ response
• Connection allocated directly as established
• Advantage: No state is ever allocated in the backlog
• Disadvantage: Not compliant with the TCP specification
• Reason to use: Ready for immediate use
• J. Villing — SYN Flood Mitigation

4

Mitigation Techniques

SYN Authentication

• Handshake done with mitigation device [3]
• Replies with invalid SYN-ACK
• Client responds with TCP Reset (RST)
• Direct communication is allowed
• J. Villing — SYN Flood Mitigation

5

Mitigation Techniques

SYN Authentication

• Handshake done with mitigation device [3]
• Replies with invalid SYN-ACK
• Client responds with TCP Reset (RST)
• Direct communication is allowed
• Advantage: No unnecessary TCBs allocated
• Disadvantage: Handshake has to be done twice
• Reason to use: Follows the TCP specification
• J. Villing — SYN Flood Mitigation

5

Mitigation Techniques

SYN Agent

• Connection established with separate agent [2]
• Handshake either redone with server → SEQ translation needed
• Server is informed otherwise → no translation needed
• J. Villing — SYN Flood Mitigation

6

Mitigation Techniques

SYN Agent

• Connection established with separate agent [2]
• Handshake either redone with server → SEQ translation needed
• Server is informed otherwise → no translation needed
• Advantage: Server protected from the flood
• Disadvantage: Additional device required
• Reason to use: Protects the server under all circumstances
• J. Villing — SYN Flood Mitigation

6

Conclusion

Detection

• Techniques only active during a flood
• Difficult to detect
• Legitimate client required
• J. Villing — SYN Flood Mitigation

7

Conclusion

Detection

• Techniques only active during a flood
• Difficult to detect
• Legitimate client required
• SYN Cookies: ISN is a hash value, cannot be detected
• SYN Authentication: First SYN-ACK always invalid
• SYN Agent: Duplicates server, cannot be detected
• J. Villing — SYN Flood Mitigation

7

Conclusion

Comparison Technique Guarantee Memory Immunity Computing Immunity Robustness Good Performance SYN Cookies

• ×

×

• SYN Authentication
• ×

SYN Agent

• (fulfilled), × (not fulfilled)

This table is based on the one from [4] and extends it.

Table 1: Comparison of Mitigation Techniques

• J. Villing — SYN Flood Mitigation

8

Conclusion

Comparison Technique G.

• M. I.
• C. I.

R.

• G. P.

Filtering

• ×
• ×

Increased Backlog × × ×

• ×

Reduced Timeout

• ×
• Recycling
• SYN Cache
• ×
• ×

SYN Cookies

• ×

×

• SYN Authentication
• ×

SYN Agent

• Three Counters
• ×

×

• ×

Random Drop ×

• (fulfilled), × (not fulfilled), ◦ (depends on the attack)

This table is based on the one from [4] and extends it.

Table 1: Comparison of Mitigation Techniques

• J. Villing — SYN Flood Mitigation

9

Bibliography

[1]

• W. Eddy.

TCP SYN Flooding Attacks and Common Mitigations, 2007. https://tools.ietf.org/html/rfc4987. [2] P .-E. Liu and Z.-H. Sheng. Defending Against TCP SYN Flooding with a new kind of SYN-Agent. In Machine Learning and Cybernetics, 2008 International Conference on, volume 2, pages 1218–1221. IEEE, 2008. [3]

• R. Nagai, W. Kurihara, S. Higuchi, and T. Hirotsu.

Design and Implementation of an OpenFlow-Based TCP SYN Flood Mitigation. In Mobile Cloud Computing, Services, and Engineering (MobileCloud), 2018 6th IEEE International Conference on, pages 37–42, 2018. [4]

• L. Ricciulli, P

. Lincoln, and P . Kakkar. TCP SYN Flooding Defense. CNDS, 1999. [5]

• H. Salunkhe, S. Jadhav, and V. Bhosale.

Analysis and review of TCP SYN flood attack on network with its detection and performance metrics. IJERT, 6(1):250–256, 2017.

• J. Villing — SYN Flood Mitigation

10