Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

Re: DNS query spam

from [Piotr Kamisiski] Network Security [Permanent Link]
Subject: Re: DNS query spam
Date: Tue, 29 Nov 2005 17:57:41 +0100 (CET) 

Hello

Thanks for your response.

The requests don't contain OPT records, but the data I've analysed doesn't cover the most intense attacks. Today has been particularly quiet. I'll wait to accumulate more data.

On Tue, 29 Nov 2005, Florian Weimer wrote:

* Piotr Kamisiski:

23:05:40.241026 IP 204.92.73.10.40760 > xx.xx.xx.xx.53: 38545+ [1au] ANY ANY? e.mpisi.com. (40) 


204.92.73.10 is one of the IP addresses for irc.efnet.ca.  Someone is
spoofing the source addresses, in the hope that DNS servers will
return a large record set.

Could you check if the packets contain OPT records (e.g. using
"tcpdump -s 0 -v")?  This protocol extension is described in the RFC
for ENDS0 (RFC 2671).  EDNS0-capable DNS resolvers can send fragmented
UDP packets, exceeding the traditional 512 byte limit of DNS UDP
replies.  The BIND 9 default maximum response size is 4096, for
example.

If the spoofed requests contain OPT records , you typically get an
amplification factor of about 60 in terms of bandwidth, and 5 in terms
of packet rate, but actual numbers may vary.

Yet another reason to restrict access to your recursive resolvers to
customers only.



Best regards,
Piotr Kamisiński
[More with this subject...]




<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  possible privilege escalation on QNX Neutrino 6.3.0, pasquale minervini
Next by Date:  RE: - Cisco IOS HTTP Server code injection/execution vulnerability-, Evans, Arian
Previous by Thread:  Re: DNS query spam, Florian Weimer
Next by Thread:  Re: DNS query spam, Jim Pingle
Indexes:  [Date] [Thread] [Top] [All Lists]