Real Attack Stories: A Flood of DDoS

[@Haxl]

All the videos here are easy to understand, yet in depth enough that it's good to use as a base point for further research. Have you got any papers I'm able to read, and if so where can I find them?

[@devcentral]

Glad you enjoy our videos! As for papers, you can always visit devcentral.f5.com and check out articles there or you can also find some good info at www.f5.com/labs

[@Haxl]

@@devcentral Thanks I'll be sure to do that!

[@mariobros237]

About NTP mitigation, were those ports blocked on the server, or the router?

[@ChillerDragon]

Where is he writing at? Why isn't it mirror-inverted?? im soo confused xxD

[@samm4591]

Hey cool video, thanks for sharing! I had a quick question if you have a minute, doesn't phase one of IPsec have a lifetime setting that will terminate the connection after x amount of seconds? So couldn't the client have also reduced the default phase one lifetime to prevent these connections from being stored?

[@dudedudeson2800]

So, my suspicion with the IPSEC flood is that the Phase1 negotiation itself never actually completes. My reasoning here is that without knowledge of the pre-shared key, P1 couldn't ever actually complete. However, you can hold that negotiation open by not sending packet #4 (this is the packet that would make it clear to the VPN server that the client didn't have the correct key). In a lot of cases (depending on the particular vendor, firmware releases, etc.) the server might wait for message 4 for quite a long time...(iirc, on ASA, for example, it will wait for at least 120 seconds by default). Now, at this point, the server has already done its DH calculation, so getting to this point is exhausting computational resources, as well. Because the exchange isn't completing, the lifetime counter isn't even started yet. Additionally, there are usually set limits on devices as to how many embryonic negotiations the device will permit at any one time. An IKE flood can fairly easily be used as a resource starvation attack by simply filling up whatever limit there is. Even if phase 1 WAS completing (because the attacker had the key) Phase1 lifetimes are generally set to be hours long - the reason being that in phase1, you're using a DH exchange to exchange the pre-master keys - expensive computationally, especially when you have a lot of VPNs going at once. Not only that, but in Phase 1, one side can't arbitrarily reduce the lifetime values, because they're actually included as part of the Phase1 proposal that is negotiated. If the bank changed those values on their side, it is highly likely that none of their existing tunnels would come up. They would have to reach out to all of their VPN partners to change their values, as well.

[@devcentral]

@@dudedudeson2800 phenomenal answer...thanks for the great response!

[@samm4591]

@@dudedudeson2800 Makes sense! Thank you for the thorough explanation :)

[@santiagobarclay7856]

Why would LDAP servers be accesible from the internet?

[@alimovaffagh5767]

But what about the solution?!

[@devcentral]

the exact details of how the SOC mitigates these attacks is a proprietary solution, but the general idea of what they do is explained in the video (block ports, create top offender lists, etc).

[@dudedudeson2800]

So, UDP attacks like these - especially with amplification - are quite difficult to mitigate at the local level. Because UDP has zero mechanisms for traffic control or anything else, if you've got a 10Gbps internet link, and an attacker can send 20Gbps of traffic, they'll simply consume all of your bandwidth. Nothing you do at the firewall at your border can help, at that point. Sure, closing udp123 and udp53 and udp389 might keep your servers from seeing that traffic, it doesn't do anything to keep it from coming down your pipe. Additionally, depending on the type of firewall, and the firmware, an attack like this might actually cause the firewall, itself to contribute additional traffic to the overall attack. For instance, on ASA firewalls (and perhaps others as well) if an out-of-state DNS packet comes in (for instance, a DNS reply that the ASA didn't see a corresponding request for), the firewall will send an ICMP port unreachable message back to the sender - which would also be larger than the original packet, because the ICMP message will actually contain a copy of the DNS packet. The only way to really mitigate this kind of attack is to have a mitigation that works in the cloud, itself. So, your upstream ISP might have mitigation capabilities, or you might purchase services from CloudFlare or Akamai, or, indeed F5 or someone else. This talk from Black Hat 2013 gives a really good description of the attack against Spamhaus, that was, at the time, the largest DDoS attack ever seen. kzbin.info/www/bejne/rWGXi3SOm9mElbs

[@dudedudeson2800]

And, actually, John has another video here about the GitHub attack, which is good, too: kzbin.info/www/bejne/ape1gZaYnKaWhKM

[@devcentral]

@@dudedudeson2800 thanks for the great info...really appreciate the insightful response!!

[@santiagobarclay7856]

​@@dudedudeson2800, do you know why a LDAP server would need to be accesible from the internet?

[@B__NguyenucAnh]

nice thank you very much

[@devcentral]

glad you enjoyed it!