360 likes | 481 Views
Network Security. EE122 Section 12. Question 1. RST. RST. Data. B. ACK. SYN ACK. SYN. ACK. Data. A. time. A sends a RESET (RST) to B E.g., because application process on A crashed B does not ack the RST Thus, RST is not delivered reliably And: any data in flight is lost
E N D
Network Security EE122 Section 12
RST RST Data B ACK SYN ACK SYN ACK Data A time • A sends a RESET (RST) to B • E.g., because application process on A crashed • B does not ack the RST • Thus, RST is not delivered reliably • And: any data in flight is lost • But: if B sends anything more, will elicit another RST Abrupt Termination
Application layer • TLS/SSL encrypts all application layer data • … but does not encrypt the TCP header! End-to-end Security
IP Header TCP Header Encrypted Content End-to-end Security TLS/SSL (Application Layer)
Application layer • TLS/SSL encrypts all application layer data • … but does not encrypt the TCP header! • Transport layer • TCP sequence number defends against blind spoofing • … but not man-in-the-middle attacks • Network layer • IPsec encrypts the entire IP payload, including the TCP header End-to-end Security
IP Header IP Header Encrypted IP Header TCP Header Encrypted TCP Header Encrypted Content Encrypted Content End-to-end Security TLS/SSL (Application Layer) IPsec (Network Layer)
Need to know the sequence number Blind Spoofing
Need to know the sequence number • How? Guess all 65536 numbers! • Alternatively, infer • first send a legitimate TCP SYN • Let’s say the receiver responds with sequence number A • Then spoof a TCP SYN assuming the receiver responds with A+1 • Defenses? Blind Spoofing
Source IP: 228.147.0.1 • 228.147.0.0/16
Source IP: 188.0.0.1 • Egress Filtering • 228.147.0.0/16
Source IP: 123.456.8.8 • 228.147.0.0/16
Source IP: 228.147.5.5 • Ingress Filtering • 228.147.0.0/16
Source IP: 228.147.5.5 What’s missing? • Ingress Filtering • 228.147.0.0/16
Receiver Attacker Source SYN SYNACK (seqno = y) ??? ACK (ackno = k?)
Receiver Attacker Source … Confirmation Request ??? Confirmation Response • Defenses?
Receiver Attacker Source … Confirmation Request (123) ??? Confirmation Response (456?) Nonce
Web server X 1Gbps 100Mbps You Web server X can comfortably handle the load you generate
Slave 1 Victim Master src = randomdst = victim Slave 2 Slave 3 Distributed Denial-of-Service (DDoS) Slave 4 Slaves send streams of traffic (perhaps spoofed) to victim Control traffic directs slaves at victim
Cause one non-compromised host to attack another • E.g., host A sends TCP SYN with source V to server R • R sends reply to V Reflector (R) Attacker (A) SYN Internet SYNACK Reflectors Victim (V)
Reflector 11 Reflector 10 Reflector 1 Reflector 8 Reflector 9 Reflector 3 Reflector 6 Reflector 2 Reflector 7 Reflector 5 Reflector 4 Slave 1 Slave 2 Victim Master Reply: src = reflectordst= victim Request: src = victim dst = reflector Slave 3 Diffuse DDoS: Reflector Attack Slave 4 Control traffic directs slaves at victim & reflectors Reflectors send streams of non-spoofed but unsolicited traffic to victim
No good defense… • Solutions so far • Overprovision • Distribute service to multiple machines Mitigating DDOS
Andrew Steve E(M, Stevepub)
Andrew Steve E(M, Stevepub) Man-In-The-Middle
Andrew Steve E(M’, Stevepub) Man-In-The-Middle
Andrewpub??? Andrew Steve E(M, Stevepub) MAC(H(M), Andrewprivate)
Andrew Steve E(M, Stevepub) MAC(H(M), Andrewprivate) E(Andrewpub, Stevepub)
E(M, Stevepub) E(Andrewpub, Stevepub) Andrew Steve MAC(H(M), Andrewprivate) Man-In-The-Middle
E(M’, Stevepub) E(MITMpub, Stevepub) Andrew Steve MAC(H(M’), MITMprivate) Man-In-The-Middle