Network Security: Network Flooding Seungwon Shin GSIS, KAIST
Detecting Network Flooding Attacks SYN-cookies Proxy based CAPCHA Ingress/Egress filtering Some examples
SYN-cookies Background In a TCP 3-way handshake a client sends a TCP SYN packet with its own random sequence number: SEQ-C a server sends back to a TCP SYN/ACK packet with its own random sequence number: SEQ-S when the server received a TCP ACK packet, it should check Key point whether its acknowledge number is SEQ-S + 1 a server should remember SEQ-S for each client 123435354 for a client A 209502807 for a client B state should be maintained reason why a TCP SYN flooding attack is feasible: state explosion
SYN-cookies Idea stateless management of TCP connection trials scenario when a server receives a TCP SYN packet, the server should answer with a TCP SYN/ACK packet At this time, how to choose the sequence number for a TCP SYN/ACK packet a number based on client information SEQ-S = hash(src IP, SRC PORT, DST IP, DST PORT, SEQ-C) when the server receives a TCP ACK packet with its acknowledge number (AN) NO state!!!! if (AN - 1) == hash(src IP, SRC PORT, DST IP, DST PORT, (SEQ-C)) OK, it is a valid packet, make a TCP session
SYN-cookies Server No state maintained Cookie is an unforgeable token SYN C SYN S, ACK C (Seq# = Cookie) ACK S (Cookie+1) Client
Prolexic Idea Prolexic use a proxy only forward a successfully established TCP sessions Idea: only forward established TCP connections to site Lots-of-SYNs Lots-of-SYN/ACKs Few ACKs Prolexic Proxy Forward to site Web site Prolexic capacity: 20Gb/sec link can handle 40 10 6 SYN/sec 19
CAPCHAs Idea connections trials from human or bots? mitigate application level DDoS attacks Case study Killbot paper Botz-4-Sale: Surviving Organized DDoS Attacks That Mimic Flash Crowds (MIT), NSDI 2005 During attack, generate CAPCHA to differentiate human from bots present one CAPCHA per source IP address
Ingress/Egress Filtering Idea attackers commonly use spoofed IP addresses they can generate huge amount of fake source IP addresses 1. Ingress filtering (RFC 2827, 2000) how to filter spoofed IP addresses ISP checks whether a packet has a valid source IP address Big problem: DDoS with spoofed source IPs Question: how to find packet origin? ISP Internet Ingress filtering policy: ISP only forwards packets with legitimate source IP. (see also SAVE protocol)
Ingress Filtering Feasibility? Implementation problems Ingress filtering based on global trust Can you trust ISP A? ALL ISPs must do this. Egress filtering routers should check all outgoing packets Can you implement this function with low cost? Requires global trust.! If 10% of ISPs do not implement no defense Another non-solution: enforce source IP at peer AS R 1 R 2 R 3 R 4 dest Source AS Transit AS Dest AS Can transit AS validate packet source IP? No
Research Work
dfence: Transparent Network-based Denial of Service Mitigation People Ajay Mahimkar, Jasraj Dange, Vitaly Shmatikov, Harrick Vin, Yin Zhang University of Texas at Austin Published at NSDI, 2007
dfence Principle Transparency No software modifications to end-hosts or routers In-Network defense Filter attack traffic before it gets close to server Shared on-demand infrastructure Multiplex defense resources to protect multiple customers No performance penalty during peace time Stateful mitigation Necessary for effective defenses against a broad range of DoS attacks
dfence Overview Apply stateful filtering Other Customer Networks Internet Service Provider Attack Detected Distributed Set of Middleboxes Only Good traffic Customer Network under protection
dfence Server Verify cookie & establish state SYN S, ACK C (Seq# = Value S ) ACK S (Value S +1) Middlebox No State Maintained SYN C Acknowledgement # translation SYN S, ACK C (Seq# = Cookie) Window = 0 Sequence # translation SYN S, ACK C (Seq# = Cookie) Re-open window SYN C Choke client ACK S (Cookie+1) Un-choke client ACK S (Cookie+1) Client
Anomaly Based Detection Approach find normal network profile detect abnormal network patterns e.g., CPD - change point detection Change-point monitoring for the detection of DoS attacks, TDSC, 2004 CUSUM (cumulative sum) with x(n) process S(0) = 0 S(n+1) = max (0, S(n) + x(n) - w) what if S(n) exceeds some threshold value?
Capability Based Mitigation Idea propose a new network architecture servers can specify what packets they want How to client requests capability in SYN packet server responds with capability Key points router only forward request packet, and packets with valid capability
Capability Based Mitigation Capability based defense Capabilities can be revoked if source is attacking blocks attacks Capabilities packets can close be revoked to source if source is attacking! Blocks attack packets close to source R 1 R 2 R 3 R 4 dest Source AS Transit AS Dest AS Attack packets dropped 56
Jump to SDN
Background First, we need to talk about traditional network devices Consist of two main components Control plane (path) decision module (e.g., routing) Data plane (path) packet forwarding module Network Switch Control Plane Data Plane
The Ossified Network Feature) Feature) millions of lines of code Opera&ng) System) Specialized*Packet* Forwarding*Hardware* 5400 RFC billions of gates Hardware tightly coupled Many complex functions baked into the infrastructure OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, MPLS, redundant layers, An industry with a mainframe-mentality, reluctant to change
Problem of Legacy Network Too complicated control plane is implemented with complicated S/W and ASIC Closed platform vendor specific Hard to modify (nearly impossible) hard to add new functionalities New proposal: Software Defined Networking separate the control plane from the data plane provide a standardized way to control the data plane
Figure 1 depicts a logical view of the SDN architecture. Network intelligence Software Defined Networking (SDN) Three layer Application layer infrastructure to be abstracted for applications and network services, which can treat the network as a logical or virtual entity. is (logically) centralized in software-based SDN controllers, which maintain a global view of the network. As a result, the network appears to the applications and policy engines as a single, logical switch. With SDN, enterprises and carriers gain vendor-independent control over the entire network from a single logical point, which greatly simplifies the network design and operation. SDN also greatly simplifies the network devices themselves, since they no longer need to understand and process thousands of protocol standards but merely accept instructions from the SDN controllers. Application part of control layer Implement logic for flow control FIGURE 1 Software-Defined Network Architecture APPLICATION LAYER Business Applications Control layer (Controller) Kernel part of control layer CONTROL LAYER API SDN Control Software API API Network Services Run applications to control network flows INFRASTRUCTURE LAYER OpenFlow Control Data Plane interface (e.g., OpenFlow) Network Device Network Device Network Device Infrastructure layer Network Device Network Device Data plane Network switch or router from Open Networking Foundation Perhaps most importantly, network operators and administrators can programmatically configure this simplified network abstraction rather than having to hand-code tens of thousands of lines of configuration scattered among thousands of devices. In addition, leveraging the SDN controller s centralized intelligence, IT can alter network behavior in real-time and deploy new applications and network services in a matter of hours or days,
SDN Operation L2 Forwarding Controller connect to B Host A deliver packet Switch A -> B: Forward Host B
SDN Actions Way of handling network packets OpenFlow case Forward Drop Set modify a packet header e.g., DST IP 10.0.0.1 -> DST IP 20.0.0.1
Load Balancing Load Balancing Controller connect to C Host C Host A Switch connect to C Host B A -> C: Forward B -> C: DST IP = D B -> D: Forward Host D Clone
Firewall Main operation drop packets based on security policies Administrator DROP Attacker Firewall Switch Server
Firewall example scenario tenant 1 Attacker tenant 4 tenant 2 tenant 3
Firewall Possible solution distributed firewall tenant 1 Attacker tenant 4 tenant 2 tenant 3
Firewall with SDN Drop packets based on security policies at network devices Firewall Controller Administrator DROP Attacker A Firewall Switch Server S A -> S: Drop
Distributed Firewall with SDN Firewall tenant 1 Controller Attacker DROP DROP tenant 4 tenant 2 tenant 3