Theron ZORBAS <[email protected]> writes: > I have an OpenBSD 5.2 i386 firewall. It was running so good till > last night. > We are under a ddos attack(DNS Amplification attack) (ANY? isc.org > requests)
First of all, unless you *want* to run an open resolver, reconfigure so only the ones you want to do recursion for (typically at most clients in a subset of directly connected networks) will get the data they ask for. The difference in size between a full answer to the query you quote and a 'denied' reply is quite significant. > Our firewall freezes. I cant ping to my firewall interfaces even > internal interface. It doesnt answer maybe replies very slowly. > Before this > freezing issue i got these messages at /var/log/messages: > > /bsd: > uvm_mapent_alloc: out of static map entries > /bsd: WARNING: mclpools limit > reached; increase kern.maxcluster > > > I increased up kern.maxcluster values > but did not work. We had to reboot firewall every 2 hours cause of this ddos > attack. > After that i realized that changing this pf rule worked: > > "block log > all" to "block all" > > Now we are still under attack but firewall handles it. It > drops udp port 53 attacks and doesnt log any packet. > But this is not what i > want. As default i wanna log which packet my firewall blocked. > > So how can i > log all blocked packets and my firewall can be still up and running? If pf logging or not is the difference between your firewall crashing or not, I'd put a significantly lower priority on collecting statistics than shutting up the noise makers. I was in a similar situation a little while back (blagged about it too, see [1]). If you do want to run a name service but want to send the recursion gropers packing, you could do what I did - read the log for requests denied by named, then blackhole route the offending IP address to make sure you don't make any noise yourself by sending replies (pfctl -k and adding to a table you block drop are optional extras). - P [1] http://bsdly.blogspot.ca/2012/12/ddos-bots-are-people-or-manned-by-some.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
