Hi, will try to comment to many posts at once :) > Kostas Zorbadelos <kzo...@otenet.gr> writes: > >> there is a need to restrict a specific type of DNS queries (ANY queries) >> in our nameservers. We faced a DDoS attack in our resolvers and the >> thing is that we could not simply cut access to DNS resolution to >> specific client IPs, the queries came from our own unsuspecting >> customers.
pe...@bsdly.net (Peter N. M. Hansteen) writes: > > My first impulse when reading the sans diary item was to rate-limit, > possibly via the overload table mechanism, and if not blocking them > outright perhaps put the DNS requests from the overloads in a > minimal-bandwidth queue. That may or may not be appropriate to your > context, and I suspect detection may be the main priority. > I also thought about this one, but unfortunately it would affect service for the customers and it would be unacceptable in this case. We would also need to automate detection as you mentioned. > While string matching in PF is not an option, I vaguely remember snort > users coming up with patterns to match earlier DNS tomfoolery, so > there's a chance you may be able to get useful info and possibly even a > working snort setup to deal with this one. >From the little I know about snort, I am not sure what would the action be in case of detection. The desired outcome is to filter the problem traffic not allowing it to reach the nameservers. Perhaps a working setup could be achieved, rearranging however the network setup. jca+o...@wxcvbn.org (Jérémie Courrèges-Anglas) writes: > > So you run resolvers for your clients. I will assume you're an ISP. Yes. > In that case, you should be checking that the DNS queries that seem to > come from your clients *actually* come from your clients, not out of > nowhere, from spoofed IPs. This could be done very easily with PF, *if* > your current architecture allows it (if you have a way to distinguish > network flow coming from your clients from spoofed requests coming from > the Internet). > Ohh, they do and that is the problem. We can't just cut the "offending" clients because they will have no Internet service :) Also we do not accept packets with sources in our network ranges "from the outside" in our border ACLs (I guess this is common antispoof practice). > Of course, if you're not an ISP, then forget what I said. > >> The situation is similar but not the same as the one discribed here: >> >> https://isc.sans.edu/diary.html?storyid=13261 > > Indeed, that involves authoritative nameservers flooded with requests > that can come from anywhere. > Exactly. Henning Brauer <lists-open...@bsws.de> writes: > > string matching to more or less random packets' payload in the kernel? > that is beyond insane. > I am interested to know if this has caused problems in IPtables' setups. It sounds dangerous, however Linux systems provide the capability. I guess they have thought about consequences and hopefully somehow addressed them. > the proper solution is a small userland helper process, using divert-to > and maybe socket splicing. I am not sure we are talking about the same thing (you must have an implementation clearly in your mind ;-) ), but my feeling for a proper way to address this problem is via a userland application in a proxy or intercepting mode. This could filter the offending traffic and give to the nameserver the rest to service. I think you also talk about this (correct me if I am wrong). The main problem with it is that it needs to be developed :) Perhaps relayd is a good match for this one. IPtables' string module however is here now and it provided a crude but working solution. Thanks for all the comments. Kostas
