Other Types of DDoS Attacks Advanced Network Security Peter Reiher August, 2014

1. Other Types of DDoS AttacksAdvanced Network Security Peter ReiherAugust, 2014

2. Outline • Reflector attacks • Shrew attacks • Crossfire attacks

3. Reflector Attacks A type of DDoS attack that addresses issue of asymmetry Use a third party site to change a small attack message to a big one Relies on IP spoofing Can make use of several different protocols for reflection

4. A Reflector Attack Spoofing the IP address of the target Reflector SYN/ACK SYN Target Attacker

5. The Attack Multiplied

6. Why Is This Helpful to the Attacker? • Packets arrive at target with many source IP addresses • Which are legitimate • Makes it harder to defend • The reflector’s response might be bigger than the attacker’s request • Leading to amplification

7. Common Types of Reflectors • DNS servers • Small requests can give large results • 100X amplification factor • NTP • A protocol flaw made reflector attacks worthwhile • Can amplify 200X • Some DHT implementations

8. The Core Reflector Problem • Attackers can spoof target IP address • May be difficult to detect attackers • Attackers can use botnets to hide traffic volume • Reflectors cannot easily distinguish between legitimate and illegitimate requests • Large number of possible reflectors • Victim’s provider ISP can see the attack but can do little about it

9. Defending Against Reflector Attacks • Cut down on IP spoofing • That’s often hard • Make reflecting sites less available • Most DNS servers are only intended for local use, anyway • Change reflector site behavior • Either in protocol or site • Research approaches

10. One Research Approach - RAD Basic idea: reflected messages are replies to request If the target remembers what he requested He knows what replies he should see Drop “unexpected” replies

11. RAD Deployment Choices • Local • Only sees the false replies • Validate replies correspond to requests • Reply volume may overwhelm a local defense • Only requires local cooperation • Core • Can see all traffic • Validate that packets correspond to source AS • Requires core cooperation

12. Local RAD • Validate that replies correspond to a request • Most reflectable protocols have a repeated field from the request in the reply • Initial sequence number between SYN and SYN/ACK • ID number in DNS query and DNS response • ID and sequence number in ICMP ECHO and ICMP ECHOREPLY • Place a message authentication code (MAC) in these fields • Validate the reply’s MAC, proving the reply corresponds to a legitimate request

13. What Is In the MAC? • Create MAC with 512-bit SHA-1 • Use src. IP, dest. IP, src. port, dest. port, a counter and a 384-bit secret • IP addresses and ports allow us to generate different MACs for different destinations and data flows • Counter allows us to generate different MACs for the same destination over time • Secret is unique to source

14. Using Local RAD No correct MAC! REQ + MAC BAD REQ Sender Gateway Attacker Internet Reflector BAD RPL RPL + MAC

15. Core RAD • Local RAD can be overwhelmed by sheer traffic volume • Move filtering farther from the target, into the core • Core RAD: • Have edge ASes mark all their outbound traffic • Have core nodes validate marks • If a invalid mark is detected, drop the packet

16. Marking the Packets in Core RAD • Generate a HMAC using the source address, destination address, packet contents and a secret key • Source and Destination prevent replays of one valid packet to many targets • Packet contents makes it easier to detect replays • Place the HMAC into the IP ID field

17. Core RAD in Operation BAD PKT PKT PKT + MAC Sender Edge AS Attacker Core AS Reflector

18. Core RAD and DNS Reflector Attacks

19. RAD Lessons • Local RAD • Provides a defense that only requires local cooperation • Limited by local bandwidth or ISPs bandwidth • Core RAD • Provides nearly complete protection • Requires core ASes to participate • Core ASes can sell as a service

20. Shrew Attacks Classic DDoS attacks have high volume Which makes their presence pretty obvious And requires lots of attacker resources Shrew attacks deny service more stealthily, requiring fewer resources

21. TCP and Packet Losses • TCP responds to losses by assuming they are caused by congestion • Detected by packets not ACKed • Due to timeout waiting for the ACK • TCP’s response is to send less data • The more losses, the less data sent • Length of timeouts defined in the TCP protocol

22. Causing the Shrew Attacks Send brief bursts of high volume traffic At specifically chosen intervals To match timeouts of TCP’s expectation of ACK delivery The bursts cause ACKs to be dropped The other party thinks that there’s persistent congestion and backs off

23. Effect of a Shrew Attack • The attacker’s average sending rate isn’t too high • E.g., ~900 Kbps • The target’s sending rate drops to near zero • Because he keeps missing ACKs at critical moments

24. Handling Shrew Attacks • Hard to detect this shrew behavior using existing methods • So figuring out that someone is doing it isn’t too likely • Randomizing the TCP wait time helps • But good choices don’t match nicely with behavior in face of real congestion

25. Crossfire Attacks Traditional DDoS flooding attacks involve sending packets to the target You could instead send packets “across” the target’s nearby networks Congest those networks without ever sending packets to the target at all

26. The Crossfire Concept Cut off a part of the Internet (the target area) that contains your victim (the public server) Create the congestion by sending from your attack machines to decoy servers you set up near the target links By congesting a set of target links

27. Crossfire Effectiveness • Can seriously degrade performance in the attacked area • While targeting a relatively low number of links • 10-50, in the original experiments • With sufficient attack nodes, each need only send a few Mbps

28. Crossfire Countermeasures Difficult to defend against Either design networks with higher internal connectivity Or get ISPs and core providers to work together quickly and closely Neither is ideal

29. Conclusion • There are many interesting variations of DDoS attacks • More are discovered all the time • Most real world attacks aren’t exotic • But only because they don’t need to be • If we can stop the basic ones, we’ll need to tackle the advanced ones