Re: Open Resolver Dataset Update
I sent you a private reply, but also posting publicly… On Apr 9, 2013, at 4:55 PM, A. Pishdadi apishd...@gmail.com wrote: 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. Both systems that return a referral to root and that do full recursion are being abused in attacks. Honestly, if you send 100kpps to 2^32 IPs it would take ~12 hours. If you have 10 hosts to scan at a lower rate and skip all the 'unused' space, e.g.: 0/8 10/8 127/8 224/4 you cut down the time as well. I won't say exactly how long my weekly process takes, but it doesn't take long if you wanted to replicate the data. About 1:122 hosts responds in some fashion. That means for any given /24, expect there to be about 2 responses. While that may not be the case for some blocks, there's a good chance something is responding nearby. At some point the lack of scoping your response will result in a real problem for the person being attacked. Your hosts will get used in an attack. It's not really an IF question anymore. - jared
Re: Open Resolver Dataset Update
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=search6search_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 larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. Jared Mauch On Apr 8, 2013, at 3:08 AM, Tom Laermans tom.laerm...@phyxia.net wrote: As far as I know, responding either NOERROR or REFUSED produces packets of the same size.
Re: Open Resolver Dataset Update
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.laerm...@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=search6search_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 larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. Jared Mauch On Apr 8, 2013, at 3:08 AM, Tom Laermans tom.laerm...@phyxia.net wrote: As far as I know, responding either NOERROR or REFUSED produces packets of the same size.
Re: Open Resolver Dataset Update
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 ja...@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.laerm...@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=search6search_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 larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. Jared Mauch On Apr 8, 2013, at 3:08 AM, Tom Laermans tom.laerm...@phyxia.net wrote: As far as I know, responding either NOERROR or REFUSED produces packets of the same size.
Re: Open Resolver Dataset Update
On 7/04/2013 19:46, Jared Mauch wrote: I've continued to update my dataset originally posted about two weeks ago. Please take a moment and review your CIDRs which may be running an open resolver. I've exposed one additional bit in the user-interface that may be helpful. Some DNS servers will respond with RCODE=0 (OK) but not provide recursion. nearly 90% of the servers in the database provide recursion. What is the rationale behind listing servers not providing recursion on a list of open resolvers? As far as I know, responding either NOERROR or REFUSED produces packets of the same size. Tom
Re: Open Resolver Dataset Update
In message 51626cf9.1040...@phyxia.net, Tom Laermans writes: On 7/04/2013 19:46, Jared Mauch wrote: I've continued to update my dataset originally posted about two weeks ago. Please take a moment and review your CIDRs which may be running an open resolver. I've exposed one additional bit in the user-interface that may be helpful. Some DNS servers wil l respond with RCODE=0 (OK) but not provide recursion. nearly 90% of the servers in the database provide recursion. What is the rationale behind listing servers not providing recursion on a list of open resolvers? As far as I know, responding either NOERROR or REFUSED produces packets of the same size. Tom NOERROR can be a referral. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Open Resolver Dataset Update
The referral, including a referral to root can be quite large. Even larger than answering a normal query. I have broken the data out for the purpose of letting people identify the IPs that provide that. Jared Mauch On Apr 8, 2013, at 3:08 AM, Tom Laermans tom.laerm...@phyxia.net wrote: As far as I know, responding either NOERROR or REFUSED produces packets of the same size.
Open Resolver Dataset Update
I've continued to update my dataset originally posted about two weeks ago. Please take a moment and review your CIDRs which may be running an open resolver. I've exposed one additional bit in the user-interface that may be helpful. Some DNS servers will respond with RCODE=0 (OK) but not provide recursion. nearly 90% of the servers in the database provide recursion. Some raw stats are also available via the 'breakdown' link on the main site. If you operate a DNS server, or have an internal group that does, please take a moment and review your networks. If you email me in private from a corporate address for your ASN, I can give you access to a per-ASN report. Due to a change in methodology, I have increased the number of servers observed from 27.2 million to 30.2 million hosts. 2013-04-07 results 30269218 servers responded to our udp/53 probe 731040 servers responded from a different IP than probed 25298074 gave the 'correct' answer to my A? for the DNS name queried. 13840790 responded from a source port other than udp/53 27145699 responses had recursion-available bit set. 2761869 returned REFUSED In addition, please do continue to deploy BCP-38 to prevent spoofing wherever possible. I know at $dayjob we have been auditing this and increased the number of customer interfaces that can not spoof. - Jared
