On Jan 10, 2004, at 11:12 AM, Daniel Hartmeier wrote:
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?
Primarily it's just the saturation of his links. Which is an upstream issue.
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.
That's kind of what I have been thinking of. However I am not sure what the performance implications of that would be.
I'm wondering if anyone has done this already or has done any experimenting with that.
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
Chris Watson M.M. Bestor G. Brown #433 Wichita, KS AIM: BSDUNIX44
smime.p7s
Description: S/MIME cryptographic signature
