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 use a proxy only forward a successfully established TCP sessions Lots-of-SYNs Lots-of-SYN/ACKs Few ACKs Prolexic Proxy Forward to site Web site
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 how to filter spoofed IP addresses ISP checks whether a packet has a valid source IP address ISP Internet
Ingress Filtering Feasibility? Ingress filtering based on global trust Can you trust ISP A? Egress filtering routers should check all outgoing packets Can you implement this function with low cost? R 1 R 2 R 3 R 4 dest Source AS Transit AS Dest AS
Jump to SDN (Software-Defined Networking)
Intro. First, we need to talk about traditional network devices Consist of two main components Control path (plane) decision module (e.g., routing) Data path (plane) packet forwarding module Control Path Data Path Network Switch
Ossified Network Feature) Feature) millions of lines of code Opera&ng) System) 5400 RFC Specialized*Packet* Forwarding*Hardware* billions of gates Hardware 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
Software-Defined Networking Three layer Application layer Application part of control layer Implement logic for flow control 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 Control Data Plane interface (e.g., OpenFlow) Network Device Network Device Network Device Infrastructure layer Network Device Network Device Data plane from Open Networking Foundation Network switch or router
SDN - Operation L2 Forwarding Controller connect to B Host A deliver packet Switch A -> B: Forward Host B
SDN - Action OpenFlow case FORWARD DROP SET modify a packet header e.g., SRC IP 10.0.0.1 > SRC IP 20.0.0.1
SDN - Operation with SET 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
Network Security Function Virtualization Problem domain Inside attackers tenant 1 Attacker tenant 4 tenant 2 tenant 3
Network Security Function Virtualization Possible solution Distributed F/W Expensive, Hard to Install tenant 1 Attacker tenant 4 tenant 2 tenant 3
Network Security Function Virtualization Enable Security into a network device Cloud is quite complicated hard to install security devices in all possible network links Firewall tenant 1 Controller Attacker DROP DROP tenant 4 tenant 2 tenant 3
NIDS with SDN (9) flow forwarding Packet inspection Alert NIDS App (3) (4) (8) Sniffer Rules (attack signatures) Controller (1) (5) (2) (7) (7) Host A OpenFlow switch Host C Host B (6) Flow Table Add A -> C: Forward To (C, NIDS)
DDoS detection with SDN Port scanner / DDoS detector Anomaly Detector App (7) Alert Flow statistics collector (1) (4) (6) (5) Detection Analyzer Configurations Host A Controller (2) (3) OpenFlow Switch Scan detector: anomaly score DDoS detector: threshold Flow Table A -> C: Forwarding to (C) B -> C: Forwarding to (C) C -> A: Forwarding to (A) C -> B: Forwarding to (B) Host B Host C