On Jan 3, 2013 4:40 AM, "Michael Orlitzky" <mich...@orlitzky.com> wrote: > > On 12/30/12 22:21, Walter Dnes wrote: > > OK, here is version 2. I had "an excellent adventure" along the way. > > > > I'm doing the upgrade on our servers right now, and there's another > possible gotcha: the newer iptables (requiring conntrack) requires > NETFILTER_XT_MATCH_CONNTRACK support in the kernel. This is in contrast > to the state matches which used NETFILTER_XT_MATCH_STATE. > > To minimize downtime during the switch, I'm doing, > > 1. Rebuild the kernel, enable conntrack and disable state. > > 2. Fix my iptables-config script to use the conntrack stuff > > 3. Create a dummy set of rules that allows me to SSH in (without > state matching) > > 4. Run and save those rules > > 5. Reboot to new kernel > > 6. SSH in and run iptables-config > > 7. Save the rules > > > > [0:0] -A INPUT -s 192.168.123.248/29 -i eth0 -j ACCEPT > > [0:0] -A INPUT -s 169.254.0.0/16 -i eth0 -j ACCEPT > > [0:0] -A INPUT -i lo -j ACCEPT > > [0:0] -A INPUT -m conntrack --ctstate INVALID,NEW -j UNSOLICITED > > [0:0] -A INPUT -p tcp -m multiport --dports 0:1023,6000:6063 -j BAD_DPORT > > [0:0] -A INPUT -p udp -m multiport --dports 0:1023,6000:6063 -j BAD_DPORT > > [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK > > [0:0] -A INPUT -s 69.220.144.0/20 -j FECESBOOK > > [0:0] -A INPUT -s 69.63.176.0/20 -j FECESBOOK > > [0:0] -A INPUT -s 69.171.224.0/19 -j FECESBOOK > > [0:0] -A INPUT -s 200.58.112.0/20 -j FECESBOOK > > [0:0] -A INPUT -s 213.155.64.0/19 -j FECESBOOK > > [0:0] -A INPUT -s 10.0.0.0/8 -j PRIVATE_LOG > > [0:0] -A INPUT -s 127.0.0.0/8 -j PRIVATE_LOG > > [0:0] -A INPUT -s 172.16.0.0/12 -j PRIVATE_LOG > > [0:0] -A INPUT -s 192.168.0.0/16 -j PRIVATE_LOG > > [0:0] -A INPUT -p icmp -j ICMP_IN > > [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT > > These rules will be evaluated in order. I have no evidence for this, but > I suspect you're better off accepting the ESTABLISHED,RELATED stuff > earlier in the chain so you don't slow down the packets that you want. >
True. But you will want to filter out 'suspicious' packets beforehand. In my previous employment, I had a Gentoo-based firewall with more than 100 lines of rules. Plus I also employ 'ipset' to allow on-the-fly manipulation of blocking/routing. If you want to see the whole nine yards, I can try asking my replacement to send me the whole deal. Rgds, --
