On Sat, Jan 10, 2004 at 09:32:59AM -0600, Chris Watson wrote: > With this unique request its at least *possible* to filter out packets > based on payload. Nuke v6 packets on udp/53 since you don't run a v6 > name service. If it was just straight v4 A record storms you would just > be totally screwed. Sure you could rate limit etc.. but you would still > be over run. I was just curious if anyone had any ideas on this > subject. Theoretical or practical.
What's the main problem the flood causes, that you want to solve primarily? If it's the downstream being saturated with the DNS queries, there's no solution, except for filtering upstream, by the ISP, obviously. Is it the upstream wasted by the DNS replies (sent to unrelated addresses spoofed by the attacker), potentially causing the receipients trouble? In this case, the simplest solution would be to configure (or patch, if needed) the DNS server, so it doesn't send error replies for such queries (as it would only answer with error replies). Is it the CPU overloaded by the DNS server handling the flood of queries? In this case, you could patch the server to drop such queries early, right after reception. It's relatively easy to do this in the DNS server, as it already has all the functions to parse the queries. And finally (I guess that's what you were looking for ;), you could extend pf to do protocol inspection for DNS queries. If you just need a simple hack that drops one specific kind of query unconditionally, that's not difficult. If you want to make it a more generic feature, you'll have to extend the rule structure and parser, so it can be used from pf.conf. I'd first try patching the DNS server, and only if that is still causing too much CPU load on flood, try the pf approach. It's much simpler to do in BIND than moving all that functionality into the kernel, and you don't risk introducing a root hole, if you make a mistake. If you can't modify the DNS server for some reason, put a BIND in front of the lesser server and patch BIND. Daniel
