Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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 -
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?
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.
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.
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?
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?!
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:
Code:
iptables -A INPUT -p udp -m string --hex-string "|03697363036f726700|" --algo bm --to 65535 -j DROP
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?
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.
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.
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).
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.