> There are many ways in which your ruleset might break. Two of the > most > important comments I wanted to make when I first saw the posts of this > thread are: > > a) Why do you use static rule numbers? > > You'd only have to use static rule numbers if your ruleset > had more than 65536/100 = 655 rules. This limit is > relatively hard to hit in a SOHO installation (Small Office, > Home Office). If you do reach such limits, there's > definitely something weird going on with the way your ruleset > is written ;-) >
Giorgos, I am interested in where I can get more information about this. Are you suggesting that IPFW reads the ruleset and formulates a rule number according to position in the script? (I always use custom scripts). If this is true, how does this ``dynamic'' feature get affected when one houses multiple rule _sets_? Can you please provide any links to information that I can gain valuable information on this? This would certainly make ruleset creation much easier ;o) Also, links to any information on how/what/why on the 16b/100 limit on the dynamic rules, so I (we) can learn more about this? I must admit, I've never even come within 1/15 of this number, but it is interesting. All my rules have always been simply, allow, allow, allow, DENY. Tks much, Steve > b) Why do you use so many rules that 'filter' outgoing traffic? > > I saw smtp, pop3, time, http, https and many others. You > don't need to explicitly allow outgoing connections unless > the users in the internal LAN are not to be trusted at all > and even then IPFW is most of the time not the right way to > do it. > > I'd probably just use something of this form in the /etc/ipfw.rules > file > and let rc.firewall find it by setting firewall_type="/etc/ipfw.rules" > in my rc.conf file: > > # First clean up all the rules of ipfw. > flush > > # Packets should be passed to natd *before* any other rule as > # mentioned in the natd(8) manpage, unlike your current script. > add divert natd all from any to any via dc1 > > # Allow only lo0 interface to use the 127.0.0.1 address. > add allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > add deny ip from 127.0.0.1 to any > add deny ip from any to 127.0.0.1 > > # Add only the dc0 interface to receive or send packets in the > # 192.168.0.0/16 address range. > add allow ip from 192.168.0.0/16 to 192.168.0.0/16 via dc0 > add deny ip from 192.168.0.0/16 to any > add deny ip from any to 192.168.0.0/16 > > # Block packets with addresses that are used in private networks > # and should not appear in any of our interfaces below this point. > add deny ip from 10.0.0.0/8 to any > add deny ip from any to 10.0.0.0/8 > add deny ip from 172.16.0.0/12 to any > add deny ip from any to 172.16.0.0/12 > > # Allow DNS and NTP through. > add allow udp from any to any 53,123 keep-state out > > # Pass all ICMP messages through. They're rate limited by the > # kernel if sysctl net.inet.icmp.icmplim is enabled, so this is > # not very unsafe to do. > add allow icmp from any to any > > # > # Stateful tcp filtering. > # > > add check-state > add deny tcp from any to any established > > # All outgoing and incoming connections are allowed in dc0 (private > iface). > # Only outgoing connections are allowed on dc1 (external iface). > add allow tcp from any to any keep-state out xmit dc0 setup > add allow tcp from any to any keep-state in recv dc0 setup > add allow tcp from any to any keep-state out xmit dc1 setup > > # Only selected services are allowed to pass through external iface. > add allow tcp from any to any 22 keep-state in recv dc1 setup > add allow tcp from any to any 113 keep-state in recv dc1 setup > > # The default firewall policy. > add deny log logamount 0 ip from any to any > > No inline numbers, a simpler layout and a logic that you can hopefully > extend at the second from last paragraph to allow more services > through > your external interface (the `in recv dc1 setup' rules). > > Note that I haven't tested this, so it might contain syntax errors > because it's based on the ruleset I'm using at home but it also > includes > some modifications. Instead of untangling the ruleset you're now > trying > to use which seemed unnecessarily complex to me, I'm posting this just > in case it's useful but it's up to you to bring it to shape for your > setup if it doesn't "Just Work(TM)" when you load it. > > - Giorgos > > _______________________________________________ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
