Detecting SYN-Flooding Attacks

1
Detecting SYN-Flooding Attacks

• Aaron Beach
• CS 395 Network Security
• Spring 2004

2
Overview

• SYN attack/floods
• Correlation between SYN FIN ratio and RST
• How to detect deviations from these trends
• Solutions to detect and stop SYN attacks

3
Goals of authors

• To stop SYN attacks at leaf routers that connect
  users to internet
• Requires less overhead computation
• Stateless (simple)
• Make detection technique that is immune to
  flooding attacks

4
Syn Flood / Attack

• 90 of DoS attacks use TCP SYN floods
• Streaming spoofed TCP SYNs
• Takes advantage of three way handshake
• Server start half-open connections
• These build up until queue is full and all
  additional requests are blocked

5
Problems with previous solutions

• Solutions such as SYN cookies, SYNDefender, SYN
  proxying,SYNkil
• Knew nothing of source
• Relied on costly IP traceback
• These solutions are statefull so they can be
  overwhelmed by SYN attacks
• 14,000SYN/sec can overload

6
Flood Detection System (FDS)

• Stateless, simple, edge (leaf) routers
• Utilize SYN-FIN pair behavior
• Include (SYNACK - FIN) so client or server
• However, RST violates SYN-FIN behavior
• Placement First/last mile leaf routers
• First mile detect large DoS attacker
• Last mile detect DDoS attacks that first mile
  would miss

7
SYN FIN Behavior
8
SYN FIN Behavior

• Generally every SYN has a FIN

9
What to do about RST

• We cant tell if RST is active or passive
• Consider 75 active
• Active represents a SYN passive does not
• Should balance out to be background noise

RED SYN BLUE- FIN BLACK RST Make sense?
10
Statistical Attack Detection

• There are very many SYNs necessary to accomplish
  a DoS attack
• At least 500 SYN/sec
• 1400 SYN/sec can overwhelm firewall
• 300,000 SYNs necessary to shut down server for 10
  minutes
• So SYN-FIN ratio should be very skewed
• during an attack

11
False Positive Possibilities

• Many new online users with long sessions
• More SYNs coming in than FINs
• A major server is down which would result in 3
  SYNs to a FIN
• Because clients would retransmit the SYN

12
CUSUM Algorithm

• Finding average number of FINs over a time
  period, and looking for a time period and testing
  for statistical homogeneity . If there are
  significant changes to this, then find when they
  changed.

13
Detection

• The algorithm will result in zero for all normal
  activity and cumulatively track (i.e. CUSUM
  cumulative sum)

14
Detection

• The internet can be quite dynamic and too
  complicated for a parametric estimation, so we
  use sequential testing which requires much less
  computation
• Two aspects of detection
• 1) False alarm time the time without attacks
  between unique false alarms
• 2) Detection time the detection delay after the
  attack starts.
• The goal is to minimize the second and maximize
  the first. However, the conflict and require
  trade offs

15
Performance Trends SYN-FIN
16
SYN attack vs Normal operation
17
Sensitivity of Detection

• 500 SYN/sec are required to shut down a server
• It takes a last mile FDS 20 seconds to detect 500
  SYN/sec DDoS attack

• Once detected SYN defender could be used to
  protect victim

18
Detection is able to

• Distinguish between attacks and background noise
• Detect DDoS with last mile FDS
• Not effected by changes in overall traffic
• Detect attacks within seconds and implement
  protection.
• Do you think this would always work?
• Can you think of any exceptions??

19
Related WorkSYN flood defense categories

• 1. Firewall based
• 2. Server based
• 3. Agent based
• 4. Router based

20
Firewall based

• Examples SYN Defender, SYN proxying
• Filters packets and requests before router
• Maintains state for each connection
• Drawbacks can be overloaded, extra delay for
  processing each packet

21
Server Based

• Examples SYN Cache , SYN cookies
• SYN cache receives packets first and then uses a
  hash table, to partially store states, however
  much more streamlined than firewall. If the
  SYN-ACK is acked then the connection is
  established with the server.

22
SYN kill this is kind of cool

• SYN kill monitors the network and if it detects
  SYNs that are not being acked, it automatically
  generates RST packets to free resources, also it
  classifies addresses as likely to be spoofed or
  legitimate
• Performance???

23
MULTOPS

• Monitors the packets going to and from a victim
  and then blocks IPs from outside of network
  limiting IP range of attack.

24
Route-based Distributed Packet filtering

• Uses packet information to determine if packet
  arriving at router has a spoofed Source /
  Destination addresses
• Results show many packets can be filtered and
  those that cant can be traced back easily

25
Future Work

• Any ideas on how to break the SYN-FIN pair
  scheme??
• Just send FINs along with the SYNs
• Will result in more traffic but what about DDoS
  that send FINs and SYNs

26
Alternatives to improve detection

• Monitoring SYN-ACK packets also
• SYN-ACKs wont go back through the same router
  that they originally passed through

27
Can it work???

• Spoofed address must be in different AS
• Also, if packet does not take same path back and
  forth from server it could possibly result in
  false positives
• Any other ways to beat it
• Large enough AS could spoof in AS
• Requires inter-FDS communication

28
(No Transcript)