Anyone else seeing this sort of noise lately? 10:35:00.958556 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:00.961055 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.262461 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.350979 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.351001 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.573166 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.573204 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.730128 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.970730 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.121218 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374853 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374879 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.493257 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.493270 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.726303 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.863667 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.023693 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251935 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251964 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:03.326562 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.630514 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.638327 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) Note that the server involved does not run a DNS daemon, or listen on 53, or anything else that would attract attention.
Have you tried contacting the owner of the IP? A DDOS attack from that particular IP would be ironic. # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=true&showARIN=false&ext=netref2 # Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 - 72.20.63.255 DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - 72.20.23.63 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # 2012/4/6 Nathan Eisenberg <nathan@atlasnetworks.us>
Anyone else seeing this sort of noise lately?
10:35:00.958556 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:00.961055 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.262461 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.350979 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.351001 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.573166 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.573204 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.730128 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.970730 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.121218 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374853 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374879 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.493257 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.493270 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.726303 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.863667 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.023693 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251935 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251964 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:03.326562 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.630514 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.638327 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38)
Note that the server involved does not run a DNS daemon, or listen on 53, or anything else that would attract attention.
On 04/06/12 10:47, Keegan Holley wrote:
Have you tried contacting the owner of the IP? A DDOS attack from that particular IP would be ironic.
# # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=true&showARIN=false&ext=netref2 #
Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 - 72.20.63.255 DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - 72.20.23.63
If it's an attempt at a reflective DNS-based DDoS attack, then the source IP address making the query is likely spoofed. The IP address in question is really the target, not the source of the attack. That is, of course, if this is a standard reflective DDoS attack. michael
It could be a DNS amplification attack, with the source IP forged. They may be hoping you "reply" to the forged source with a response greater than the cost of them sending the query. Of course you'd have to actually be running a poorly configured DNS server on that IP for this to work... On Fri, Apr 6, 2012 at 11:47 AM, Keegan Holley <keegan.holley@sungard.com>wrote:
Have you tried contacting the owner of the IP? A DDOS attack from that particular IP would be ironic.
# # The following results may also be obtained via: #
http://whois.arin.net/rest/nets;q=72.20.23.24?showDetails=true&showARIN=false&ext=netref2 #
Staminus Communications STAMINUS-COMMUNICATIONS (NET-72-20-0-0-1) 72.20.0.0 - 72.20.63.255 DDOSWIZ.COM STAMINUS-COMMUNICATIONS (NET-72-20-23-0-1) 72.20.23.0 - 72.20.23.63
# # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html #
2012/4/6 Nathan Eisenberg <nathan@atlasnetworks.us>
Anyone else seeing this sort of noise lately?
10:35:00.958556 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:00.961055 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.262461 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.350979 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.351001 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.573166 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.573204 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:01.730128 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:01.970730 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.121218 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374853 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.374879 IP 66.171.180.48 > 72.20.23.19: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.493257 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.493270 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:02.726303 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:02.863667 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.023693 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251935 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.251964 IP 66.171.180.48 > 72.20.23.24: ICMP 66.171.180.48 udp port 53 unreachable, length 74 10:35:03.326562 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.630514 IP 72.20.23.24.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38) 10:35:03.638327 IP 72.20.23.19.53 > 66.171.180.48.53: 952+ [1au] ANY? ripe.net. (38)
Note that the server involved does not run a DNS daemon, or listen on 53, or anything else that would attract attention.
On Fri, Apr 6, 2012 at 12:52 PM, PC <paul4004@gmail.com> wrote:
Of course you'd have to actually be running a poorly configured DNS server on that IP for this to work...
Right.... was that IP ever running a DNS service? Picking random IPs to spoof and hope some of the random IPs happen to be DNS servers doesn't sound like a very "efficient" attack. It seems like the attacker would want to 'probe first' before selecting innocent servers to reflect at Perhaps 2 or 3% of the possible random IPs on the internet actually run DNS servers that could possibly respond to spoofed queries? -- -JH
On 06/04/2012 18:41, Nathan Eisenberg wrote:
Anyone else seeing this sort of noise lately?
There has been a bit of that recently for ripe.net and several other well known DNSSEC enabled domains (e.g. isc.org). It turns out that DNSSEC makes a respectable traffic amplification vector:
twinkie# dig +ignore +notcp any ripe.net | grep rcvd ;; MSG SIZE rcvd: 490 twinkie#
The dns request packet size was 26 bytes. Add packet overhead to both the request and the reply, and you end up with: request: 26 (data) + 8 (udp) + 20 (ip) + 18 (ethernet frame) + ipg (12) + 8 (preamble) = 92 reply: 490 (data) + 8 (udp) + 20 (ip) + 18 (ethernet frame) + ipg (12) + 8 (preamble) = 556 => amplification on ethernet medium == 556/92, or slightly more than 6x. Welcome back to the 1990s. Nick
On Fri, Apr 6, 2012 at 1:04 PM, Nick Hilliard <nick@foobar.org> wrote:
On 06/04/2012 18:41, Nathan Eisenberg wrote:
Anyone else seeing this sort of noise lately?
There has been a bit of that recently for ripe.net and several other well known DNSSEC enabled domains (e.g. isc.org).
It turns out that DNSSEC makes a respectable traffic amplification vector:
This is definitely a problem. Unfortunately, what really should happen is DNSSEC should be revised, to, either make sure that the client initiating the query has to either do more work than the server, or make a round trip before the DNSSEC data can be requested. One way of accomplishing that would be to indicate that DNSSEC data can be transmitted only over DNS when using TCP; since a reflection spoofer cannot complete a 3-way TCP handshake, the attacker cannot send spoofed requests for DNSSEC data over TCP. -- -JH
On Apr 6, 2012, at 11:13 AM, Jimmy Hess wrote:
It turns out that DNSSEC makes a respectable traffic amplification vector: This is definitely a problem.
Yep. So are SNMP reflection attacks (biggest attack I've seen was one of these) and any other datagram-oriented query/response protocol.
Unfortunately, what really should happen is DNSSEC should be revised, to, either make sure that the client initiating the query has to either do more work than the server, or make a round trip before the DNSSEC data can be requested.
Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38
One way of accomplishing that would be to indicate that DNSSEC data can be transmitted only over DNS when using TCP;
I suspect the root server operators might not like this idea very much. Regards, -drc
On Fri, Apr 6, 2012 at 1:24 PM, David Conrad <drc@virtualized.org> wrote: [snip]
I suspect the root server operators might not like this idea very much.
If it solves other problems adequately, they might eventually just have to learn to like it. [snip]
Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38
No. Implementation of BCP38 does have value, but the existence of BCP38 does not solve DNS application problems; Just looking towards BCP38 as a solution is like attempting to treat a disease with a theoretically effective treatment that you can't possibly get enough of to cure the disease due to limited supplies -- but ignoring mitigation of the symptoms, despite there being more readily available options for symptom mitigation. It's similar to the idea of promoting SPF as a means of stopping e-mail forgery, and saying RBLs just treat the symptoms -- stop using RBLs, and get everyone to implement SPF. The underlying problem is that "BCP38" is not really a "best common practice", despite the name of the series. It's really a "Best Uncommon Practice that really ought to be more common", but we can't control operators and force them to make it more common. Lots of networks don't and will not ever implement BCP38; BCP38 is not being more widely implemented, and there's no obvious action that will force it to change. -- -JH
Jimmy, On Apr 6, 2012, at 1:24 PM, Jimmy Hess wrote:
On Fri, Apr 6, 2012 at 1:24 PM, David Conrad <drc@virtualized.org> wrote:
I suspect the root server operators might not like this idea very much. If it solves other problems adequately, they might eventually just have to learn to like it.
I was, of course, using the root servers as a proxy for pretty much any DNS server operator. The root server operators aren't unique in the requirement to respond to an unbounded number of queries.
Treating a symptom and ignoring the disease. See http://tools.ietf.org/html/bcp38 No. Implementation of BCP38 does have value, but the existence of BCP38 does not solve DNS application problems;
You seemed to have missed the part where it isn't just a DNS problem. Your solution would appear to be to replace every datagram-based query/response protocol such as ICMP and SNMP. I personally think it is more feasible for ISPs to implement BCP38 than it is for the entire Internet to move away from using datagram-based query/response protocols, but that's probably just me.
but ignoring mitigation of the symptoms, despite there being more readily available options for symptom mitigation.
Sorry, which more readily available options are those? I don't think forcing a 3-way exchange for stuff like PMTUD is 'readily available'.
The underlying problem is that "BCP38" is not really a "best common practice", despite the name of the series.
The name of the series is "Best Current Practice".
Lots of networks don't and will not ever implement BCP38;
It is true that lots of networks don't implement BCP38. Whether or not they will ever is more debatable. I suspect that we're about one major spoofing-based infrastructure attack away from proposed legislation that would force folks to implement something like BCP38, but I may be a bit more pessimistic than most. However, I would be interested in hearing what the excuses are for folks not implementing BCP38 these days. Regards, -drc
On Apr 6, 2012, at 4:44 PM, David Conrad wrote:
However, I would be interested in hearing what the excuses are for folks not implementing BCP38 these days.
Easy: 1) hardare support varies 2) implementing bcp-38 drives customer support costs up in cases where the customer is doing something weird "e.g.: using toms isdn-dial backup to source return packets". 3) customers can't be trusted to give a complete list of valid source addresses 4) asymmetric or highly kinky routing exists more than one would like to admit There are cases where it's fairly inexcusable: Fixed broadband providers (static IP address or dynamic to a customer port/pool) CGN exit points Static routed customers (They shouldn't be doing asymmetric routing) The real reason imho.. is #2 above. desire to keep unnecessary support calls from your call center. - Jared
participants (8)
-
David Conrad -
Jared Mauch -
Jimmy Hess -
Keegan Holley -
Michael Sinatra -
Nathan Eisenberg -
Nick Hilliard -
PC