On Tue, 2009-01-20 at 14:55 -0600, Todd T. Fries forwarded: > From: ISPrime Support <supp...@isprime.com> > These are the result of a spoofed dns recursion attack against our servers. > The actual packets in question (the ones reaching your servers) do NOT > originate from our network as such there is no way for us to filter things > from our end. > If you are receiving queries from 76.9.31.42/76.9.16.171 neither of these > machines make legitimate outbound dns requests so an inbound filter of > packets to udp/53 from either of these two sources is perfect. > If you are receiving queries from 66.230.128.15/66.230.160.1 these servers > are authoritative nameservers. Please do not blackhole either of these IPs as > they host many domains. However, these IPs do not make outbound DNS requests > so filtering requests to your IPs from these ips with a destination port of > 53 should block any illegitimate requests.
I've been seeing a lot of noise from the latter two addresses after switching on query logging (and finishing an application of Team Cymru's excellent template) so I decided to DROP traffic from the addresses (with source port != 53) at the hosts in question. Well, blow me down if they didn't completely stop talking to me. Four dropped packets each, and they've gone away. Something smells "not quite right" here - if the traffic is spoofed, and my "Refused" responses have been flying right back to the *real* IP addresses, how are the spoofing hosts to know that I'm dropping the traffic? Even if I used a REJECT policy, I'd expect the ICMP messages to go back to the appropriate - as in real - hosts, rather than the spoofing sources. Something here is very odd, very odd indeed... or I'm being dumb. It's happened before. Graeme
