I just started seeing thousands of DNS queries that look like some sort of DOS attack. One log entry is below with the IP obscured. client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E When you look at z.tn.co.za you see a huge TXT record. Is anyone else seeing this attack or am I the lucky one? Is this a known attack? Roy
In article <43C9EF72.50803@garlic.com> you write:
I just started seeing thousands of DNS queries that look like some sort of DOS attack. One log entry is below with the IP obscured.
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
When you look at z.tn.co.za you see a huge TXT record.
Is anyone else seeing this attack or am I the lucky one? Is this a known attack?
Roy
You are being used as a DoS amplifier. The queries will be spoofed. Someone needs to learn about BCP 38. Mark
Mark Andrews wrote:
In article <43C9EF72.50803@garlic.com> you write:
I just started seeing thousands of DNS queries that look like some sort of DOS attack. One log entry is below with the IP obscured.
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
When you look at z.tn.co.za you see a huge TXT record.
Is anyone else seeing this attack or am I the lucky one? Is this a known attack?
Roy
You are being used as a DoS amplifier. The queries will be spoofed. Someone needs to learn about BCP 38.
Next to not running a $world recursive/caching service ;) Which is where the OP can actually do something about this problem. Folks who don't do ingress filtering will not be bothered to get it going unfortunately... Greets, Jeroen
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8BD22DF9AD3BC6F2B19E8B12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mark Andrews wrote:
In article <43C9EF72.50803@garlic.com> you write:
I just started seeing thousands of DNS queries that look like some sor= t=20 of DOS attack. One log entry is below with the IP obscured.
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
When you look at z.tn.co.za you see a huge TXT record.
Is anyone else seeing this attack or am I the lucky one? Is this a=20 known attack?
Roy =20 You are being used as a DoS amplifier. The queries will be spoofed. Someone needs to learn about BCP 38.
Next to not running a $world recursive/caching service ;) Which is where the OP can actually do something about this problem. Folks who don't do ingress filtering will not be bothered to get it going unfortunately...
Greets, Jeroen
Configure the server to serve z.tn.co.za and set "allow-query { none; };". This will stop the server amplifying the attack. Black-hole the spoofed address. This works fine for purely recursive servers as they shouldn't be getting queries from the given address anyway. On could hack the servers to identify particular tuples and black-hole them. This however is a not a long term solution to the problem and requires a lot of maintenance. Trace the spoofed traffic streams and get the offending sites turned off recommending that BCP 38 be depoloyed. For repeat offenders create a list of networks that won't implement BCP 38 and collectively de-peer with them telling them why you are de-peering and what is required to re-establish connectivity. It is in everyones interests to do the right thing here. Shunning works if you have the collective gumption to do it. Alternatively create a list of networks that agree to implement BCP 38 and don't carry traffic from anyone else. Advertise that you are BCP 38 compliant. Either way, lack of BCP 38 compliance is a collective problem and needs to dealt with in a collective manner. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
Mark_Andrews@isc.org (Mark Andrews) writes:
For repeat offenders create a list of networks that won't implement BCP 38 and collectively de-peer with them telling them why you are de-peering and what is required to re-establish connectivity. It is in everyones interests to do the right thing here.
people inside one of the largest networks have told me that they have customers who require the ability to bypass BCP38 restrictions, and that they will therefore never be fully BCP38 compliant. i've asked for BCP38 to become the default on all their other present and future customers but then there was whining about bankruptcy, old outdated equipment, and so on. sadly, there's no way to de-peer this network, or any other multinational, and so there will be no "peer pressure" on them to implement BCP38. so, it's either not in everyone's interests to do the right thing, or there is still a huge variance in what's considered "the right thing". either way, we're (the internet is) SCREWED until we (that's "we all") fix this. (if you're not seeing spoofed-source attacks, bully for you! i didn't see one today, either, but leaving this tool in the bad-guy toolbox makes us all unsafe, no matter how much or how little they may be using it this day/year.) -- Paul Vixie
On Mon, 16 Jan 2006, Paul Vixie wrote:
Mark_Andrews@isc.org (Mark Andrews) writes:
For repeat offenders create a list of networks that won't implement BCP 38 and collectively de-peer with them telling them why you are de-peering and what is required to re-establish connectivity. It is in everyones interests to do the right thing here.
people inside one of the largest networks have told me that they have customers who require the ability to bypass BCP38 restrictions, and that they will therefore never be fully BCP38 compliant. i've asked for BCP38 to become the default on all their other present and future customers but then there was whining about bankruptcy, old outdated equipment, and so on. sadly, there's no way to de-peer this network, or any other multinational, and so there will be no "peer pressure" on them to implement BCP38.
Consider people in the rest of the world who may purchase simplex satellite links. By definition they inject traffic in places they aren't announcing their route from.
so, it's either not in everyone's interests to do the right thing, or there is still a huge variance in what's considered "the right thing". either way, we're (the internet is) SCREWED until we (that's "we all") fix this.
(if you're not seeing spoofed-source attacks, bully for you! i didn't see one today, either, but leaving this tool in the bad-guy toolbox makes us all unsafe, no matter how much or how little they may be using it this day/year.)
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
joelja@darkwing.uoregon.edu (Joel Jaeggli) writes:
people inside one of the largest networks have told me that they have customers who require the ability to bypass BCP38 restrictions, and that they will therefore never be fully BCP38 compliant. ...
Consider people in the rest of the world who may purchase simplex satellite links. By definition they inject traffic in places they aren't announcing their route from.
yup, those are exactly the customers i was told about. (see above.) however, there's still a way to filter-list the various interfaces -- it's just harder than letting the routing table imply your filter-list for you. also however, if these were the only customers who weren't made to follow BCP38, there would not be a global BCP38-related problem right now. or, as i said before:
i've asked for BCP38 to become the default on all their other present and future customers ... -- Paul Vixie
At 12:52 PM 1/16/2006, Joel Jaeggli wrote:
On Mon, 16 Jan 2006, Paul Vixie wrote:
Mark_Andrews@isc.org (Mark Andrews) writes:
For repeat offenders create a list of networks that won't implement BCP 38 and collectively de-peer with them telling them why you are de-peering and what is required to re-establish connectivity. It is in everyones interests to do the right thing here.
people inside one of the largest networks have told me that they have customers who require the ability to bypass BCP38 restrictions, and that they will therefore never be fully BCP38 compliant. i've asked for BCP38 to become the default on all their other present and future customers but then there was whining about bankruptcy, old outdated equipment, and so on. sadly, there's no way to de-peer this network, or any other multinational, and so there will be no "peer pressure" on them to implement BCP38.
Consider people in the rest of the world who may purchase simplex satellite links. By definition they inject traffic in places they aren't announcing their route from.
Sounds like the landing sites would not be able to use Unicast RPF. However, they could still use BCP38. Nothing says the filters have to be magically generated from routing data (not that uRPF really does that either, since it works off the FIB on most routers). Mobile IP had the same set of issues when we were first working on the ingress filtering drafts. In their case, a bit of tunneling solved the issue. While tunneling could easily solve the satellite case too, there may be resistance to that.
In article <Pine.LNX.4.64.0601160943150.30093@twin.uoregon.edu> you write:
On Mon, 16 Jan 2006, Paul Vixie wrote:
Mark_Andrews@isc.org (Mark Andrews) writes:
For repeat offenders create a list of networks that won't implement BCP 38 and collectively de-peer with them telling them why you are de-peering and what is required to re-establish connectivity. It is in everyones interests to do the right thing here.
people inside one of the largest networks have told me that they have customers who require the ability to bypass BCP38 restrictions, and that they will therefore never be fully BCP38 compliant. i've asked for BCP38 to become the default on all their other present and future customers but then there was whining about bankruptcy, old outdated equipment, and so on. sadly, there's no way to de-peer this network, or any other multinational, and so there will be no "peer pressure" on them to implement BCP38.
Consider people in the rest of the world who may purchase simplex satellite links. By definition they inject traffic in places they aren't announcing their route from.
But they don't need to be able to source all of 0/0. They need to be able to source particular addresses which they have. If the end point of the satellite link is dynamic then they need to souce netblocks. The satellite company should be able to supply a complete list so filters can be setup appropriately. BCP 38 isn't all or nothing. You do the best you can. You limit the exposure. In this case if you get spoofed traffic from the satellite company's addresses you still talk to the satellite company to address the problem. If they have static address assignment it should be a easy job to trace the offending traffic back. If they have dynamic assignment then things get harder. It should be possible to prevent any "owned" box (other than a router) spewing out spoofed traffic to the net as a whole. "owned" routers are a different kettle of fish. This is not a new problem. Sooner or later goverments will mandate this sort of filtering if the networking community as a whole don't do it and they may not leave room to support satellite down links. Think manditory strict unicast reverse path filtering everywhere.
so, it's either not in everyone's interests to do the right thing, or there is still a huge variance in what's considered "the right thing". either way, we're (the internet is) SCREWED until we (that's "we all") fix this.
(if you're not seeing spoofed-source attacks, bully for you! i didn't see one today, either, but leaving this tool in the bad-guy toolbox makes us all unsafe, no matter how much or how little they may be using it this day/year.)
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
class "ANY" has no purpose in the real world, not even for debugging. if you see it in a query, you can assume malicious intent. if you hear it in a query, you can safely ignore that query, or at best, map it to class "IN". -- Paul Vixie
On Sun, Jan 15, 2006 at 05:27:40PM +0000, Paul Vixie wrote:
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
class "ANY" has no purpose in the real world, not even for debugging. if you see it in a query, you can assume malicious intent. if you hear it in a query, you can safely ignore that query, or at best, map it to class "IN". -- Paul Vixie
er... i guess that is true, although the DNS does work for things other than IP based networks... dispite our respective best efforts to cripple it. --bill
# > class "ANY" has no purpose in the real world, not even for debugging. if # > you see it in a query, you can assume malicious intent. if you hear it in # > a query, you can safely ignore that query, or at best, map it to class # > "IN". # # er... i guess that is true, although the DNS does work for # things other than IP based networks... dispite our respective # best efforts to cripple it. i'm not trying to cripple it. i'm saying RFC 1034/1035 was wrong about class "ANY". all answer/authority/additional data where OP=QUERY and QR=1 will have the same class as the QCLASS (of which, in spite of the QDCOUNT field, there can be only one). nodes do not have classes. not even zones have classes. each class has a hierarchy of NS RRs making a "namespace". each class needs its own root name servers. there are less-coherent / more-useful ways to interpret "the spec", and one such way could give meaning to class "ANY", but no dns implementation i'm aware of follows those alternate interpretations. since nanog isn't a protocol-fine-points mailing list, at least for the DNS protocol, one could ask "why are we discussing this?" and my answer is, there is an operational tie-in. if you see QCLASS=ANY in a firewall, that is prima facie evidence of malfeasance, not merely misconfiguration or misinterpretation.
In article <20060115231056.75AAD11425@sa.vix.com> you write:
# > class "ANY" has no purpose in the real world, not even for debugging. if # > you see it in a query, you can assume malicious intent. if you hear it in # > a query, you can safely ignore that query, or at best, map it to class # > "IN". # # er... i guess that is true, although the DNS does work for # things other than IP based networks... dispite our respective # best efforts to cripple it.
i'm not trying to cripple it. i'm saying RFC 1034/1035 was wrong about class "ANY". all answer/authority/additional data where OP=QUERY and QR=1 will have the same class as the QCLASS (of which, in spite of the QDCOUNT field, there can be only one). nodes do not have classes. not even zones have classes. each class has a hierarchy of NS RRs making a "namespace". each class needs its own root name servers. there are less-coherent / more-useful ways to interpret "the spec", and one such way could give meaning to class "ANY", but no dns implementation i'm aware of follows those alternate interpretations.
since nanog isn't a protocol-fine-points mailing list, at least for the DNS protocol, one could ask "why are we discussing this?" and my answer is, there is an operational tie-in. if you see QCLASS=ANY in a firewall, that is prima facie evidence of malfeasance, not merely misconfiguration or misinterpretation.
And if you want to refuse class ANY queries in BIND 9 create a view like the following. view "blackhole" any { allow-query { none; }; }; Note: all zones have to be in a view once you start using views. Again this really is only a stop gap measure as the attack can quite easily morph into something this won't catch. Mark
Not true,. the ANY query has mutliple uses for consolidating multiple diagnostic queries into a single display, and also for diversion monitoring systems on small domains or groups of same. Not all of us have the resources (or time) of large ISPs behind us. On 15 Jan 2006 17:27:40 +0000, Paul Vixie <vixie@vix.com> wrote:
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
class "ANY" has no purpose in the real world, not even for debugging. if you see it in a query, you can assume malicious intent. if you hear it in a query, you can safely ignore that query, or at best, map it to class "IN". -- Paul Vixie
Did you notice that it was class "ANY" and not type "ANY" that Paul noted? I've never ever heard of it being used anywhere.... As for ANY query type, what do you think will happen when you query with "ANY" to a host in a domain that is not in your local dns server cache? And btw if it is in your dns cache, how predictable do you think such results are going to be??? On Tue, 17 Jan 2006, Alon Tirosh wrote:
Not true,. the ANY query has mutliple uses for consolidating multiple diagnostic queries into a single display, and also for diversion monitoring systems on small domains or groups of same. Not all of us have the resources (or time) of large ISPs behind us.
On 15 Jan 2006 17:27:40 +0000, Paul Vixie <vixie@vix.com> wrote:
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
class "ANY" has no purpose in the real world, not even for debugging. if you see it in a query, you can assume malicious intent. if you hear it in a query, you can safely ignore that query, or at best, map it to class "IN". -- Paul Vixie
Admitted, i did not notice the type/class difference. I responded as a knee jerk reaction, and that is my mistake. For the second part, the any query type is useful (when targeted at either your NS and/or public NS servers) to quickly alert to issues such as the one being discussed with GoDaddy and Nectartech right now on this list. Pick and/or set up an NS server that is TTL agnostic (flameArmor: this system is to be used for disparate up-to-date checks only, and I know by spec this is far from foolproof but its saved my ass a couple times in the past) and checks disparate roots and its useful for finding or alerting to major name system, registrar ,and provider issues quickly. Im diverging off-topic, im sure. gnight. On 1/17/06, william(at)elan.net <william@elan.net> wrote:
Did you notice that it was class "ANY" and not type "ANY" that Paul noted? I've never ever heard of it being used anywhere....
As for ANY query type, what do you think will happen when you query with "ANY" to a host in a domain that is not in your local dns server cache? And btw if it is in your dns cache, how predictable do you think such results are going to be???
On Tue, 17 Jan 2006, Alon Tirosh wrote:
Not true,. the ANY query has mutliple uses for consolidating multiple diagnostic queries into a single display, and also for diversion monitoring systems on small domains or groups of same. Not all of us have the resources (or time) of large ISPs behind us.
On 15 Jan 2006 17:27:40 +0000, Paul Vixie <vixie@vix.com> wrote:
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY ANY +E
class "ANY" has no purpose in the real world, not even for
debugging. if
you see it in a query, you can assume malicious intent. if you hear it in a query, you can safely ignore that query, or at best, map it to class "IN". -- Paul Vixie
Last saturday one of our Web server experienced a TCP SYN attck which make the system down for four hours. It seems there is not a good solution which could detect & defend DoS traffic at any time. So, to the class ANY queries, should we only filtering out class any queries on public cache servers ? To my understandings, the amplifying result could also be reached by query type any. Joe --- Alon Tirosh <j0keralpha@gmail.com> wrote:
Admitted, i did not notice the type/class difference. I responded as a knee jerk reaction, and that is my mistake.
For the second part, the any query type is useful (when targeted at either your NS and/or public NS servers) to quickly alert to issues such as the one being discussed with GoDaddy and Nectartech right now on this list.
Pick and/or set up an NS server that is TTL agnostic (flameArmor: this system is to be used for disparate up-to-date checks only, and I know by spec this is far from foolproof but its saved my ass a couple times in the past) and checks disparate roots and its useful for finding or alerting to major name system, registrar ,and provider issues quickly.
Im diverging off-topic, im sure. gnight.
On 1/17/06, william(at)elan.net <william@elan.net> wrote:
Did you notice that it was class "ANY" and not
I've never ever heard of it being used anywhere....
As for ANY query type, what do you think will happen when you query with "ANY" to a host in a domain that is not in your local dns server cache? And btw if it is in your dns cache, how
type "ANY" that Paul noted? predictable do you think such
results are going to be???
On Tue, 17 Jan 2006, Alon Tirosh wrote:
Not true,. the ANY query has mutliple uses for consolidating multiple diagnostic queries into a single display, and also for diversion monitoring systems on small domains or groups of same. Not all of us have the resources (or time) of large ISPs behind us.
On 15 Jan 2006 17:27:40 +0000, Paul Vixie <vixie@vix.com> wrote:
client xx.xx.xx.xx#6704: query: z.tn.co.za ANY
ANY +E
class "ANY" has no purpose in the real world,
not even for debugging. if
you see it in a query, you can assume malicious intent. if you hear it in a query, you can safely ignore that query, or at best, map it to class "IN". -- Paul Vixie
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 1GB free storage! http://sg.whatsnew.mail.yahoo.com
# Last saturday one of our Web server experienced a TCP SYN attck which make # the system down for four hours. It seems there is not a good solution which # could detect & defend DoS traffic at any time. by definition, there will never be a single defense against all attacks. # So, to the class ANY queries, should we only filtering out class any queries # on public cache servers ? if you're seeing them and they're hurting you, yes. or if you're willing to undure the configuration pain of always dropping them (see marka's recent mail on "view" statements for this purpose), then yes. # To my understandings, the amplifying result could also be reached by query # type any. that's not my understanding. you're more likely to be hurt by a peer's lack of BCP38 conformance than by all the type=ANY queries you'll ever hear in DNS.
# Admitted, i did not notice the type/class difference. I responded as a knee # jerk reaction, and that is my mistake. on nanog@, the tradition is to send knee-jerk flames without having read the article you're replying to. it's our own little slice of usenet-like culture, still alive a decade or several too late. so you're fitting right in. :-). # For the second part, the any query type is useful (when targeted at either # your NS and/or public NS servers) to quickly alert to issues such as the one # being discussed with GoDaddy and Nectartech right now on this list. i don't like type ANY very much, since it's a cpu amplification attack vector against recursive nameservers. however, sendmail uses it in hopes of learning type MX and type A at the same time, and according to eric, this saves more network traffic than it generates. in any case i've not said anything against type ANY. it's common, and seeing it is not an indication of malicious intent, and it should never be blocked. my earlier comments on this thread were about "class" ANY, not "type" ANY.
participants (11)
-
Alon Tirosh -
bmanning＠vacation.karoshi.com -
Daniel Senie -
Jeroen Massar -
Joe Shen -
Joel Jaeggli -
Mark Andrews -
Paul Vixie -
Paul Vixie -
Roy -
william(at)elan.net