TCP Syn Attack Scenario

1
TCP Syn Attack Scenario

• Fred Kuhns
• Washington University
• Applied Research Laboratory

http//www.arl.wustl.edu/arl/project/msr
2
Syn Demo Switch Configuration
SW-1
SW-1
Out
In
Out
In
P0
P0
M
M
P1
P1
H4
H4
CP (browser)
CP (browser)
P2
P3
P4
P4
H4
H4
Attacker
Attacker
P5
P5
H5
H5
Web Server
Web Server
P6
P6
M
M
P7
P7
M
M
3
SynDemo Physical Configuration
NSP
Ingress
Egress
SPC/FPX P0
SPC/FPX P0
jumper
jumper
SPC/FPX P1
SPC/FPX P1
M
H4
H4
CP (browser)
CP (browser)
SPC/FPX P2
SPC/FPX P2
SPC/FPX P3
SPC/FPX P3
SPC/FPX P4
SPC/FPX P4
SPC/FPX P5
SPC/FPX P5
SPC/FPX P6
SPC/FPX P6
SPC/FPX P7
SPC/FPX P7
4
Syn Demo IP Configuration
Subnets off each Port
192.168.32.0 (0xC0A02000)
CP and Web Client 192.168.(32-35).0/24
These routes go into all Route Tables
192.168.(36-39).0/24
192.168.(40-43).0/24
192.168.(44-47).0/24
192.168.(48-51).0/24
192.168.(52-55).0/24
Attacker 192.168.(56-59).0/24
Web server 192.168.(60-63).0/24
PN
SP
OVIN
5
NSP and Plugin Config
Two plugin instances share a common data
structure for managing connection states
NSP-0
FPX0ing
SPC0ing
FPX0eg
SPC0eg
H4
H4
CP (browser)
CP (browser)
FPX1ing
FPX1eg
SPC1eg
SPC1ing
all TCP traffic
VCI 71
FPX2ing
FPX2eg
SPC2eg
SPC2ing
Client ACK (to SYN/ACK) causes the Ingress EM
filter to be added.
FPX3ing
FPX3eg
SPC3eg
SPC3ing
FPX4ing
FPX4eg
SPC4eg
SPC4ing
EM filter causes traffic on established
server/client connection to bypasses plugin
FPX5ing
FPX5eg
SPC5eg
SPC5ing
VCI 64
FPX6ing
FPX6eg
SPC6eg
SPC6ing
H4
H4
Attacker
Attacker
VCI 70
EM server-gtclient
FPX7ing
FPX7eg
SPC7eg
SPC7ing
SYN
H5
H5
Web Server
Web Server
RST
send RST if no ACK (to Syn/ACK) from client for
TIMEOUT secs
SYN/ACK
6
TCP Syn Attack Demo

• Use three hosts Client (CP), Attacker and Server
• Automate as much as possible to reduce errors and
  simplify
• At NSP output connected to Web Server,
• install general filter to copy all TCP packets to
  SPC
• SPC observes packet flow to ensure connections
  complete
• sends spoof packets to tear down connections that
  do not complete
• installs higher priority exact match filter to
  pass packets, after a connection has been
  completed
• counters (active, pending) on exact match filters
  are polled - removed after becoming idle
• Display and control (browser, daemon or script,
  not GUI)
• From Server, GUI Partial and complete TCP
  connections (to port 80 only?) Daemon on server
  polled from GUI.
• From Plugin, GUI Pending and complete
  connections. Able to stop and start plugin. When
  stopped still track connections and apply
  timeouts but will not send reset. Control from
  script load, unload, bind etc. Start and stop
  done via browser interface (may need a daemon as
  proxy?)
• Traffic to browser Monitor output port connected
  to client.
• Attacker State (On, Off and rate) Browser.
  Control via browser.

7
Syn Attack Scenario

• Step 1 Initial Setup and Configuration
• browser on CP enters continuous loop requesting a
  series of web pages (or images) from the server.
  For example a slide show. May be able to
  communicate with an applet to automate the
  starting and stopping of the browser.
• GUI display shows default ???
• SYN attack daemon is running, waiting for command
  (over socket) to start an attack. The command
  specifies the IP header fields and sending rate.
• Step 2 Start attack (Problem)
• SYN attack daemon commanded to start sending syn
  packets
• browser reports increased response time, also
  observe slow image/page display. May result in
  connection timeout I have not verified this.
• GUI display shows SYN packet rates to server???
• Step 3 Plugin installation (Solution)
• CP installs GM filter on Egress side of SPC
  Port7, directs all TCP packets going to the
  server to be sent to the SPC.
• saddr sport daddr 192.168.60.2/32
  dport proto TCP
• ovin 0x1C (70) QID 8
• CP loads Syn Attack Defense Plugin on Egress side
  of SPC on Port7 and binds to filter
• browser performance improves, GUI displays plugin
  stats active and pending connections.
• Step 4 Stop, unload and reset

8
Plugin

• All TCP packets going to/from server are sent to
  plugin
• TCP 3-way handshake
• (1) Client sends SYN, (2) server sends SYNACK,
  (3) client sends ACK
• On final ACK, Plugin installs EM filter for
  completed connections from server to client (port
  7, input)
• EM filter to direct valid TCP traffic to Web
  Server
• saddr 192.168.60.2 sport PortNums daddr
  192.168.32.2 dport PortNumd proto TCP
• QID ??? OVIN ??? // for SPC only, this is
  filled in automatically for FPX we need to
  calc!?!
• Do we need to allocate separate queue per flow
  no longer an issue.
• For this simple demo, I dont see why it would.
• Same qid should be fine. (JDD, FK)
• When does Plugin remove EM filters?
• Eds plugin monitors client to server TCP traffic
  (server to client bypasses plugin due to the EM
  filter) when he sees the FIN, FIN/ACK etc he
  removes filter.
• Assume no persistent connections.
• This would cause problems for our removal scheme
• Assume in future versions we would be able to
  monitor the FIN Flag
• I need to look into this at the server side
  fredk. OK.

9
Details

• GUI Display ???
• Browser display ???
• Wrote new syn attack program, must still
• make a daemon
• open socket to listen for commands
• support rate specifications
• Browser
• proof of concept done (brad at cec)
• need to refine and look at interfacing to
  external programs for control.