In the last 2 weeks we have seen double the amount of ddos attacks, and way bigger then normal. All of them being amplification attacks. I think the media whoring done during the spamhaus debacle motivated more people to invest time building up there openresolver list, since really no one has disclosed attacks of that size and gave the blueprints of how to do it. Now we know the attack has been around for awhile but no one really knew how big they could take it until a couple weeks ago.. Now I know your openresolver DB is meant to get them closed but it would take only a small amount of someones day to write a script to crawl your database.. You go to fixedorbit.com or something of the sort, look up the as's of the biggest hosting companies, plop there list of ip allocaitons in to a text file, run the script and boom i now have the biggest open resolver list to feed my botnet.. Maybe you should require some sort of CAPTCHA or registration to view that database. While im sure people have other ways of gathering up the open resolvers , you just took away all the work and handed it to them on a silver platter. While i am and others surely are greatful for the data, i think a little more thought should be put in how you are going to deliver the data to who should have it, and that would be the network / AS they are hanging off of. just my 2 cents.. P.S. I would like to get a list for our AS off list if you can reply back directly. On Tue, Apr 9, 2013 at 3:15 PM, Jared Mauch <jared@puck.nether.net> wrote:
Tom,
The main criteria is the RCODE=0 vs RCODE=5 refused.
I exposed the Recursion Available bit this last week to cover more of the use cases, but many servers provide a very large referral to root.
You are correct in that your system doesn't provide that so should be less "visible" as a result. I haven't coded everything to pull out that level of data from the responses.
Of the responding IPs, a fair percentage 89% respond with the RA bit set. I'm working to close the gap on exposing the direct data of those last 11% in a more detailed bit of information, including if it provides a root referral or otherwise.
Hope this helps,
- Jared
On Apr 9, 2013, at 8:59 AM, Tom Laermans <tom.laermans@phyxia.net> wrote:
Jared,
If you mean there can be a referral with RCODE=0 and Recursion Available = 0, you'll need a third column actually documenting if there is a referral.
This server is listed in ORP:
$ dig www.google.be @195.160.166.139
; <<>> DiG 9.7.3 <<>> www.google.be @195.160.166.139 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 615 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available
;; QUESTION SECTION: ;www.google.be. IN A
;; Query time: 6 msec ;; SERVER: 195.160.166.139#53(195.160.166.139) ;; WHEN: Tue Apr 9 14:58:21 2013 ;; MSG SIZE rcvd: 31
RCODE=0, Recursion available=0:
http://openresolverproject.org/search.cgi?mode=search6&search_for=195.160.166.0%2F24
Hence my question, what is it doing wrong?
Tom
On Mon, 2013-04-08 at 07:05 -0400, Jared Mauch wrote:
The referral, including a referral to root can be quite large. Even
Jared Mauch
On Apr 8, 2013, at 3:08 AM, Tom Laermans <tom.laermans@phyxia.net>
wrote:
As far as I know, responding either NOERROR or REFUSED produces
larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. packets of the same size.