Blocking DNS DDOS
netmagi last edited by
My 2 DNS servers are getting hit regularly with this:
They're configured correctly, so they're denying the request:
named: client 126.96.36.199#9725: query (cache) './NS/IN' denied
but, it's annoying as all heck. Each time the target changes, or one is added, I add that IP to an alias. A rule blocks the IP's from accessing DNS on my network. This works ok, but it's a pain to keep adding IP's to the alias, (and not practical since now these IP's cannot make legit requests to my servers which are authoritative for a handful of domains). I see some people made comments in the SANS thread about blocking these requests based on the payload length, etc. Is there any way in pfSense to do this?
If you read the thread at SANS, you'll see the request is always for ".", and any response at all to the spoofed IP (the attackers spoof the traffic from the IP they want to attack) contributes to the attack. . . .
Anybody else dealing with this?
netmagi last edited by
btw on a sidenote, the IP's I've seen targetted in the attacks (the one's spoofed) so far have been:
Cry Havok last edited by
If you have the memory and processor power to spare, snort is one option.
nickFM last edited by
This may be an old thread but was recently passed my way in an email of somebody reporting the exact same problem. (Who found it on google for "188.8.131.52" I suspect) So I figured I'd chime in on it!
I can't speak for all of the IPs, but as far as 184.108.40.206, 220.127.116.11 and 18.104.22.168 go, these are F5 BigIP load balancers. Specifically Global Traffic Managers (GTMs). The GTMs do their best to find the fastest datacenter to serve you content from, their preferred method (which may not be perfect, but works pretty well) is to send a DNS_DOT query to your DNS server. Unfortunately this is often classified as the aforementioned attack. All the GTMs are using from this query is the response time, no other information is gleaned (or stored) from the probed DNS server.
The load balancers at those IPs serve some high profile sites and the marketing content for countless more, so triggering a probe from them is pretty common. Realistically blocking traffic from them will result in sites being slow and/or unavailable.
Hope this helps clear up any confusion anyone has. F5 has a knowledge base article regarding it (though it is admittedly behind their support wall), which I have quoted below.
Nick (at FederatedMedia dot Net if anyone would like to reach me)
SOL6480: LDNS probing may appear to be an attack ( https://support.f5.com/kb/en-us/solutions/public/6000/400/sol6480.html )
When a client or a local DNS server direct a DNS request to the BIG-IP GTM, the BIG-IP GTM attempts to probe the local DNS server to obtain path metrics. In addition, all other F5 Networks devices that are equipped with a big3d agent and are included in the configuration will probe the local DNS server. The metric information collected by the big3d agents is used to make wide area load balancing decisions based on network conditions between the big3d agent and the local DNS server.
By default, big3d agents first attempt to probe the local DNS with a DNS_DOT query. If the probe attempt fails, big3d attempts the following tasks, in the following order:
TCP port 53 socket connection
ping (ICMP echo)
Attackers commonly use similar probing techniques when looking for security vulnerabilities. Therefore, the BIG-IP GTM probing may appear to be an attack or a prelude to an attack and may be reported by intrusion detection systems.
Administrators that have noticed the BIG-IP GTM probing generally report the following symptoms:
Local DNS servers are being excessively pinged by the source addresses of F5 Networks devices.
Border routers are intercepting an unusual number of pings from the source addresses of F5 Networks devices.
Unusually large numbers of attempted connections to TCP or UDP port 53 appear to be an attack.
Unusual methods are used to query a DNS server (DNS_REV or DNS_DOT).
The path metrics provided by the BIG-IP GTM probing are required to make dynamic load balancing decisions.