'isc.org/ANY/IN' denied: 1466 Time(s)
 

Hi all,

I've been getting these messages ('isc.org/ANY/IN' denied: 1466 Time(s) ) through on my logwatch. I'm a bit of an amateur but have done quite a bit of research on this and found these 2 rules for my iptables -

iptables -I INPUT 1 -p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --set --name dnsanyquery

iptables -I INPUT 2 -p udp --dport 53 -m string --from 50 --algo bm --hex-string '|0000FF0001|' -m recent --name dnsanyquery --rcheck --seconds 60 --hitcount 5 -j DROP

However having installed them I'm still getting the same messages. I'd be really grateful if somebody was able to tell me what I've done wrong.

Thanks very much,
A

Hi there,

The queries you are seeing might be related to the attack described at http://www.minihowto.eu/protectio-ag...-org-any-query if you're not expecting these requests.

It looks like your server is denying these query requests, though, which implies no harm done to you (except for a bit of traffic flow). Are these messages coming from BIND?

Regarding the iptables rules you ae using, what is that hex string meant to match?

Regards,

Clifford

Thanks Clifford, I think they are that sort of attack! So no harm meant to my server, but I wanted to stop them to be a good citizen!

Emabarrasingly I'm not sure what the hex string is .... I copied it from here - http://www.junkemailfilter.com/blog/...rg-any-attack/

Do you think it should be something different?

Thanks again,

A

...and there's some threads on LQ about 'isc.org/ANY/IN'. Order old to new:
http://www.linuxquestions.org/questi...attack-935994/
http://www.linuxquestions.org/questi...on-4175417284/
http://www.linuxquestions.org/questi...es-4175450008/
http://www.linuxquestions.org/questi...on-4175450621/

Hi again,

The "denied" message seems to indicate that you are being a good citizen & not sending the replies to the intended target IPs. This is presumably done by bind, though and not by iptables. That should be fine - as long as it is stopped, it doesn't matter who does that.

Regarding the hex string, there's a different string in the URL I posted, but I haven't tried to validate or test this.

Regards

Thanks UnSpawn,

I did take a look at some of the old threads but I'm a bit of a novice with servers and they dont mean a whole lot to me. I spent ages working out how iptables work and thought I'd found what looks like a neat solution? Is anybody able to tell me whether its just a tweak to the rules I've got thats needed?

For the no recursion solution I'm not sure if I have an authoritative server! My domain dns settings are with the people that I bought the domain from - and the domain just points at my server. Does that me my server isnt authoritative?! Sorry to be such a dunce.

Thanks,
Alessia

Sorry Clifford, didnt see your reply. I think I read that even though the attempt is denied it still sends back a 'denied' message to the IP under attack?

If I change the rules to:

iptables -I INPUT 1 -p udp --dport 53 -m recent --set --name dnsanyquery
iptables -I INPUT 2 -p udp --dport 53 -m recent --name dnsanyquery --rcheck --seconds 60 --hitcount 5 -j DROP

... will that cause me problems? I cant see why an individual would do more than 5 dns queries of any type in 60 seconds? Or have I misunderstood?

Thanks v much
Alessia

cliffordw asked the right question when he said "Are these messages coming from BIND?" (as they have to be resolver messages and it would be odd getting those from a LAN-only caching name server) so you must be running a publicly exposed resolver. He's also right in that the "denied" message indicates your resolver does not allowing recursion. The iptables rule the foxpa.ws site promotes to drop the UDP reflection attack is:
Try that and please report back.

Thanks unSpawn, would the rule you've suggested not block some legitimate isc.org/ANY/IN requests? Or are there no legitimate isc.org/ANY/IN requests?

I've also found these 2 rules which look good and came well recommneded on another site ...

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

In short (somebody correct me if I'm wrong but) any client request should, by way of the providers name servers, end up at the root servers so no, you shouldn't be receiving isc.org/ANY/IN requests nor should you allow recursion for domains you're not the authoritative name server for unless you're operating a shielded caching-only name server.

Thanks for your help unSpawn, I've used your suggestion and will let you know how i get on in the next few days!

This depends on how this name server is set up and used. If it is a name server for specific zones only, then the above statement is correct.

If it is the name server for a LAN, then it is the first stop for all queries, and needs to respond to legitimate requests for the isc.org domain (either with the root servers if recursion is off, or with the final answer if recursion is on). In such a case the iptables rules should probably be refined to block only requests from the outside, while still allowing them from inside (by physical interface or IP range).

Hi unSpawn and Clifford,

Great success with unSpawns sgguestion -

Has blocked 6000 packets so far, seems to have completely solved it.

Thanks so much!

My understanding of this attack was that the Internet was simply being flooded with these requests, which of all rights should only originate from "upstream" DNS servers, but actually coming from everywhere ... on the assumption that any server would respond to them anyway if received, and thereby contribute to the chaos.

If it is the name server for a LAN then it shouldn't be listening on any public interfaces in the first place ;-p Besides that, and this is more a basic thing, common QTYPES are A, MX or quad A. Apart from a certain stubborn MTA the "wildcard" or ANY QTYPE isn't that commonly seen percentage-wise.

No, any client may ask for it. The problem is there are too many name servers that answer requests they really shouldn't and the response is asymmetric, way larger than the request.