[nsp-sec] DNS amplification DDoS attack in progress via cam.ac.uk and ucam.org zones
James A. T. Rice
james_r-nsp at jump.org.uk
Sun Jun 24 22:03:25 EDT 2012
Hi Folks,
There are some ongoing (for several weeks) reflection attacks using EDNS0
ANY with reply set to 9000 bytes queries at authoritive (not open
recursive) nameservers. So far these are all flows of 25 queries / packets
each, before moving on to a new source port.
The following are the authoritative nameservers being used to amplify the
traffic, please do not blackhole them - they are not the problem here, the
problem is the source of the spoofed traffic to them. Could you please
check for UDP port 53 flows to the below IP addresses, if you see many
flows of 25 packets each, the traffic is likely to be spoofed, with the
source set to the victim of the attack. A traceback / remedial action
would be appreciated.
212.13.197.229 (chiark.greenend.org.uk) (queries are ANY srcf.ucam.org)
131.111.8.37 (authdns0.csx.cam.ac.uk) (queries are ANY cam.ac.uk)
131.111.12.37 (authdns1.csx.cam.ac.uk) (queries are ANY cam.ac.uk)
There are correlations between the list of victims that spoofed queries
are received at these nameservers for, so there is possibly a common
command and control, not just a common attack tool between them all.
If you want an easy cut and paste to check for the traffic, see below.
Note if your flow data is sampled you will need to not include the check
for exactly 25 packets per flow.
NFSEN:
(dst ip 212.13.197.229 or dst ip 131.111.8.37 or dst ip 131.111.12.37) and proto udp and packets 25
Cisco:
show ip ca flow | in 212.13.197.229 .*11 .*0035 .*25
show ip ca flow | in 131.111.8.37 .*11 .*0035 .*25
show ip ca flow | in 131.111.12.37 .*11 .*0035 .*25
If you need source IPs too in order to traceback, then the attack rate of
a list of victims chiark is being used to amplify to is at
http://www.chiark.greenend.org.uk/ucgi/~ijackson/xtraffic including the
ability to see the query pps rate for each victim.
Interestingly the attack intensities increased following rate limiting
being applied. This might be correlation rather than causation however.
Thanks
James Rice
Jump Networks Ltd (AS8943)
More information about the nsp-security
mailing list