> There are estimates that the Dyn attack was 1.2Tbps. What provider do you work for that can absorb that? I work for F5 Silverline. It would be naive to brus

> There are estimates that the Dyn attack was 1.2Tbps. What provider do you work for that can absorb that? I work for F5 Silverline. It would be naive to brush off that size of attack as it would stress any DDoS mitigation provider. We have the capacity to take it (and are adding a lot more in the coming months precisely because of attacks like this and the previous big one that hit Brian Kerbs) but you would have to talk to Sales about what sort of guarantees we would be willing to provide. That said, at least that would be our problem, since we would have to pay for the bandwidth consumed - not the customer! ;) > Does scrubbing work with a bunch of randomized source ports and source address? How do you find the "signature" in that to scrub? It was my understanding that the traffic in the Dyn attacks was indistinguishable from legitimate traffic. Can you explain how traffic scrubbing works in such scenarios? Or do you just drop stuff on the floor? (Answer from one of my more knowledgeable colleagues since I work on supporting the infrastructure rather than DDoS mitigation itself): Most attack traffic has a signature of its behaviour beyond source IP and port. For simple flood attacks, connection rate-limiting per source IP is very effective. Typically there are some simple firewall rules that will work too, especially with attacks generated against targets that don’t support the attack vector (e.g. block all GRE traffic coming to your website which is only TCP 80/443). If the attack is operating at L7, there are additional fingerprinting methods we can use around HTTP headers, intelligent rate-limiters, JavaScript injection to prove an actual human, etc.