mailing list archives
RE: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED]
From: "David Zielezna" <David.Zielezna () acma gov au>
Date: Wed, 28 Jan 2009 14:59:29 +1100
I'm checking just with a mix of tcpdump/pcap, bind logs and p0f. A bit
overboard, but logging is fun.
I haven't checked any dark hosts to see whether the attack repeatedly
sends queries to IPs which have never given an answer or indication of
any kind of life. Your monitoring will probably determine this so let
us know what behavior you find.
From: Steve Bertrand [mailto:steve () ibctech ca]
Sent: Wednesday, 28 January 2009 2:47 PM
To: David Zielezna
Cc: John Martinez; nanog () nanog org
Subject: Re: Tightened DNS security question re: DNS amplification
How are you checking for this by hand?
Would it be safe to assume that running tcpdump on a box in the
following manner on a monitor port for a sizable portion of the network
be ok (as opposed to the DNS servers themselves, as I don't have control
over them all)?
sniffer# tcpdump -n -i em5 dst port 53 | grep "NS? . (17)"
22:38:31.150114 IP 220.127.116.11.43581 > 18.104.22.168.53: 23685+ NS? .
We have a mix of DNS servers, some BIND and some DJBDNS, a BIND ACL
won't work here. We also have single-homed clients that run accessible
DNS servers that appear to be Windows based.
ACL's outside of the BIND scope would be fantastic.
For now, I'm following the above list, and blocking everything ingress
that is not source port 53 from the IP to my network 53.
If you have received this email in error, please notify the sender immediately and erase all copies of the email and
any attachments to it. The information contained in this email and any attachments may be private, confidential and
legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose,
use, forward, or distribute this email and/or its contents.
Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not
be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual
cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.