Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I mean if the attacker tries to ask all the open DNS resolver respond to a web server. The web server can just block its UDP ports. If the all the DNS response go to a Authoritative Nameserver(victim), it can just drop all DNS response.
Or is DNS Amplification all about bandwidth?
DNS Amplification attacks are very easy to prevent by filtering UDP packets at the edge routers. This is how Cloudflare is able to easily thwart a 300+ gb/s DDoS attack.
At the point the query makes it to your server it's already too late. Your server will waste its resources trying to do something with the packets and the requests. Even if you have something like iptables drop all connections it's still going to use up all of the bandwidth on the server inbound. Redirecting all traffic someplace else eats up your outbound bandwidth and propagates the network failure between your server and the now new target.
It's a network infrastructure issue. Not a server issue (unless it's an open recursive resolver). The traffic needs to be handled (killed) further up the pipe. Here's a CERT advisory from March 23rd.
Unfortunately, due to the overwhelming traffic volume that can be produced by one of these attacks, there is often little that the victim can do to counter a large-scale DNS amplification-based distributed denial-of-service attack. While the only effective means of eliminating this type of attack is to eliminate open recursive resolvers, this requires a large-scale effort by numerous parties.
Additionally
Source IP Verfication: Because the DNS queries being sent by the attacker-controlled clients must have a source address spoofed to appear as the victim’s system, the first step to reducing the effectiveness of DNS amplification is for Internet Service Providers to deny any DNS traffic with spoofed addresses.
The problem is that you need to drop the traffic before it reaches your network. So even when dropping packets at your server is way too late. The best way to reduce risk is to use packet scrubbing services like Akamai or Cloudfare who have DDoS mitigation techniques in place to prevent this traffic from reaching your network.
Blocking the traffic on the server will not stop the DDoS from eventually saturating its uplink and possibly other links within the network. DNS amplification attacks are all about generating large amounts of bandwidth.
The uplink will still be saturated.
The only way to mitigate this is to turn on RRL (response rate limiting) on servers and get rid of open resolvers. And for legitimate open resolvers, have them send UDP packets as small as possible with the TC bit set ("please retry using TCP") so that amplification doesn't happen yet it doesn't break legitimate traffic.
Other mitigation techniques for resolvers include enforcing a minimum TTL (which also helps against poisoning) and a reasonable maximum payload size for responses sent using UDP. Google DNS are using a 512 bytes limit for this reason.
Disabling recursion responses on public DNS servers to random internet IPs - ie closing the "open resolver" hole - does NOT mitigate this because you can still do a spoofed DNS reflector/amplification attack simply by sending queries that result in a "can't give you an answer" response, which can still be much larger than the incoming query.
Really need to use some combination of response-rate limiting or upstream measures as mentioned here previously. Technically you could use egress-filtering to block outgoing packets that originated on a different link/interface than the route to the spoofed destination, but on simple networks (ie with a single internet link) that's not feasible.
Here's an old whitepaper that discusses some other mitigation measures, like using packet hop-counts to guess about the legitimacy of an incoming packet:
http://cs.unc.edu/~jeffay/courses/nidsS05/slides/17-Egress-Filtering.pdf
But of course filtering and rate-limiting responses at the "reflector point" still doesn't mitigate the large incoming packet-stream that is being directed at your DNS server. It does spare the intended target from being DDoS'd by your DNS server and your DNS server from being bogged-down with junk traffic.
