ipfw: Too many dynamic rules
Marat N.Afanasyev
amarat at ksu.ru
Thu Sep 9 18:15:44 UTC 2010
Gareth de Vaux wrote:
> Hi again, I use some keep-state rules in ipfw, but get the following
> kernel message:
>
> kernel: ipfw: install_state: Too many dynamic rules
>
> when presumably my state table reaches its limit (and I effectively
> get DoS'd).
>
> netstat shows tons of connections in FIN_WAIT_2 state, mostly to
> my webserver. Consequently net.inet.ip.fw.dyn_count is large too.
>
> I can increase my net.inet.ip.fw.dyn_max but the new limit will
> simply be reached later on.
>
> I currently get around this with a cronjob that sets
> net.inet.ip.fw.dyn_keepalive to 0 for just less than 5 minutes
> every night. If I leave it at 0 for longer or indefinitely then
> idle ssh sessions and the like are dropped. This works fine for
> me but it looks like there's some bug with net.inet.ip.fw.dyn_keepalive=1?
> Or with Apache?
>
> I'm using 8.1-STABLE, GENERIC kernel. Experienced the same behaviour
> on 8.0-RELEASE, but not on 6.1-RELEASE where I had a similar setup. I
> have a KeepAliveTimeout of 4 in Apache (2.2.16).
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
I wonder, are these dynamic rules really necessary? let's see, a client
connects to your web-server and you immediately should create a new
dynamic rule, therefore you participate in this DoS attack as well as
attacker. ;)
may be using
ipfw add XXX allow tcp from me 80 to any
would be enough? I usually use keep-state rules only for outgoing
connections and try to keep number of such rules as few as possible. if
you're afraid of somebody trying to attack your servers using unopened
connections you may filter out connections that aren't established.
you can try to change, of course,
net.inet.ip.fw.dyn_*_lifetime
variables, but I think that using dynamic rules to filter out web-server
answers is not as good practice as it seems.
--
SY, Marat
More information about the freebsd-stable
mailing list