Avg of 2 dropped connections per minute - correct order of firewall rules?

[caribguy]

I have started adding certain ranges of "known bad neighborhoods" to ipfilter. I temporarily enabled logging of the first incoming packet that is dropped by each rule and am surprised by the vast number of dropped connection attempts.

We run our own nameservers, and most of the drops are on port 53 UDP. These connection attempts come in waves of up to 50 from the same address over a short period of time.

I'm wondering if I should change the order of rules... e.g. by moving up this one:

pass in quick proto udp from any to <thishost> port = 53 keep state

Current sequence of rules on the public facing interface is as follows:

1. Allow in specific connections from known hosts
2. Deny in everything that is known to be invalid or bad
3. Allow in what has not been blocked so far and tries to access a valid, existing service
4. Deny in anything else
5. Outbound rules

Blocked example (section #2):
xyz0 @0:76 b 203.162.4.nnn,61492 -> aaa.bbb.ccc.ddd,53 PR udp len 20 63 IN

I'm wondering if allowing access to the nameserver (only for domains we are authoritative for) will merely shift the problem down to the next rule section or if it would bring down the number of failed attempts.

Or, I can just stop logging - since I already know these are bad ranges :)

Any experiences out there?

[encyclo]

As for the excessive traffic on port 53 UDP, is your vserion of BIND (or whatever DNS server) up to date? Last year's DNS exploit could possibly still be doing the rounds.

It's not an answer as such, but I would simply not log at all if you, as you say, already "know these are bad ranges".

[caribguy]

Version 9.4.3 - ISC seems to have 9.5.2 as its production release.

I might just follow your advice, it would cut the log files down to 5% of their current size...

Maybe I'll log a few packets first just to find out what their purpose is supposed to be, but looking at the source countries I doubt it's anything I'd want to let in.

Thanks Encyclo!

[encyclo]

You need to ensure that you have at least the 9.4.3-P3 version of BIND which includes the vital patch for the dynamic-update DoS attack. This is not to say that your BIND install is being actively attacked, but you still need to firmly close that security hole if it is not done already. :)

[caribguy]

Aw great :(

# named -v
BIND 9.4.3-P2

[encyclo]

Happy compiling ;) You could watch your logs for a while after the update just to see if it makes any difference (very possibly it won't, but you've got to do the update anyway). Do you run BIND in a chroot jail, or has it been hardened at all?

[caribguy]

Wanna guess?

# ps -auxww ¦ fgrep named
#*$!#*$!#*$! 89226 0.0 0.9 17396 8936 ? Is 30Jul09 1:25.37 /usr/sbin/named -c /etc/namedb/named.conf

Seems like I've got to get crankin'