using tables = ipfw: ipfw_install_state: Too many dynamic rules

[Michael Sierchio]

Sorry, revise my remarks about path mtu - pre-coffee.  But you don't
really want to drop those explicitly, at least not silently.  Let TCP
take care of it.

Also, if you want to permit ICMP, you should probably restrict it to
reasonable icmptypes (echo, echo reply, error need-frag, etc.)

On Wed, Jun 29, 2011 at 11:34 AM, Michael Sierchio <kudzu at tenebras.com> wrote:
> If table 2 contains a blacklist, why not deny traffic at the top?
>
> Why are you silently dropping fragmented TCP packets?  This will break
> Path MTU discovery.
>
> Why do you have a check-state rule after rule 500? That's backwards.
> You might consider putting check-state at the beginning.
>
> You don't want to explicitly permit tcp established - that's done by
> the dynamic rules.  This one rule may be the culprit, but the rest of
> your rules need improvement too. ;-)
>
> Are you running services on 80,443,747 on this host?  Or another
> internal host?
>
> Rule 500 is broken, because TCP works differently from ICMP and UDP,
> and you only want to use the keep-state directive on packets with the
> SYN bit set.
>
> Even if you have only one interface, 'out' is ambiguous - best to
> specify the interface.
>
> You don't need the 'me' rules, since 'any' includes me.
>
> Try something like the following (pretend your external interface is 'eth0'):
>
> allow ip from any to any via lo0
>
> deny ip from any to 127.0.0.0/8
> deny ip from 127.0.0.0/8 to any
> deny ip from table\(2\) to any
>
> check-state
>
> deny tcp from any to any established
>
> allow tcp from any to any dst-port 80,443,747 in recv eth0 setup keep-state
>
> allow tcp from table\(1\) to any in recv eth0 setup keep-state
> allow udp from table\(1\) to any in recv eth0 keep-state
> allow icmp from table\(1\) to any in recv eth0 keep-state
>
> allow tcp from any to any out xmit eth0 setup keep-state
> allow udp from any to any out xmit eth0 keep-state
> allow icmp from any to any out xmit eth0 keep-state
>
> deny log logamount 1000 ip from any to any
>
>
>
>
>
> On Wed, Jun 29, 2011 at 3:58 AM, franck <freebsd at ouarz.net> wrote:
>> Hi,
>>
>> On a new FreeBSD 8.2 server, ipfw complains of too many dynamic rules as
>> traffic increases.
>> e.g.  "ipfw: ipfw_install_state: Too many dynamic rules")
>>
>> Is the following set of rules too complex? What would be the best/generic
>> approach to setup ipfw for a standard web server? Any recommendations?
>>
>> 00100 allow ip from any to any via lo0
>> 00200 deny ip from any to 127.0.0.0/8
>> 00300 deny ip from 127.0.0.0/8 to any
>> 00400 deny tcp from any to any frag
>> 00500 allow ip from table(1) to any keep-state
>> 00600 check-state
>> 00700 allow tcp from any to any established
>> 00800 allow ip from any to any out keep-state
>> 00900 allow icmp from any to any
>> 01000 allow udp from me to any dst-port 53 keep-state
>> 01100 allow udp from me to any dst-port 123 keep-state
>> 01200 allow tcp from any to any dst-port 747 setup keep-state
>> 01300 deny ip from table(2) to any
>> 20000 allow tcp from any to any dst-port 80,443 setup keep-state
>> 20100 deny log logamount 1000 ip from any to any
>> 65535 deny ip from any to any
>>
>> Note that:
>> - table 1: holds whitelist of IPs
>> - table 2: holds blacklist of IPs
>>
>> Regards,
>> Franck
>>
>> --
>> View this message in context: http://freebsd.1045724.n5.nabble.com/using-tables-ipfw-ipfw-install-state-Too-many-dynamic-rules-tp4534755p4534755.html
>> Sent from the freebsd-ipfw mailing list archive at Nabble.com.
>> _______________________________________________
>> freebsd-ipfw at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>>
>