| My understanding is that the attacker can generate a relatively small amount of IP-spoofed traffic, which is then used to generate a much bigger amount of amplified traffic from servers the attacker doesn't control (i.e. not IP spoofed). So you need to be able to handle: a) the reflected volumetric attack (you can block IPs and even protocols/ports here), b) a much smaller volume of IP-spoofed traffic, which for TCP services basically means you have to be handle a SYN flood (because if they spoof, they can't get a connection established to do the nastier stuff) c) make sure you don't let your countermeasures against a) be triggered by b) in a way that disrupts your legitimate customers. For a TCP based service, I'd expect the following to be quite effective: 1. At the very first stage (has to be able to handle the full volume, may be external), discard all UDP traffic, any TCP traffic pointing to the wrong port, and any traffic from blacklisted IPs. 2. At the second stage (has to be able to handle the IP-spoofable volume), terminate TCP connections using SYN cookies, and forward actual connections to the real servers. 3. At the real servers, any remaining incoming connection is coming from a non-spoofed IP. Monitor cost (TCP handshake, TLS handshake, authentication attempt) and successful accounts per IP. Block IPs that cause a high cost but no legitimate users, or an extreme cost and few legitimate users, using the stage 1 blacklist. 4. Optionally you can also aggregate information about successful logins and block sources that cause a high load at stage 2 and have few successful logins using a short-lived entry on the stage 1 blacklist. UDP based services would be much harder since you don't have such a trivial stage 2, but for TCP, stages 1+2 should be something that you can buy. |