Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED]

Wed Jan 28 03:59:29 UTC 2009

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.

DZ

-----Original Message-----
From: Steve Bertrand [mailto:steve at ibctech.ca]
Sent: Wednesday, 28 January 2009 2:47 PM
To: David Zielezna
Cc: John Martinez; nanog at nanog.org
Subject: Re: Tightened DNS security question re: DNS amplification
attacks. [SEC=UNCLASSIFIED]

Good work!

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 64.57.246.146.43581 > 208.70.106.58.53: 23685+ NS? .
(17)

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.

Steve

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.