From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 56E3013826B for ; Thu, 3 Jan 2013 03:58:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8FD3621C001; Thu, 3 Jan 2013 03:58:19 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6698B21C05A for ; Thu, 3 Jan 2013 03:57:11 +0000 (UTC) Received: from mail-pa0-f51.google.com ([209.85.220.51]:52661) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1Tqbvb-001j9b-9V for gentoo-user@lists.gentoo.org; Thu, 03 Jan 2013 10:57:11 +0700 Received: by mail-pa0-f51.google.com with SMTP id fb11so8317819pad.38 for ; Wed, 02 Jan 2013 19:57:10 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.66.88.129 with SMTP id bg1mr142238150pab.71.1357185430002; Wed, 02 Jan 2013 19:57:10 -0800 (PST) Received: by 10.68.248.66 with HTTP; Wed, 2 Jan 2013 19:57:09 -0800 (PST) Received: by 10.68.248.66 with HTTP; Wed, 2 Jan 2013 19:57:09 -0800 (PST) In-Reply-To: <50E4A857.1090800@orlitzky.com> References: <20121227004732.GB5854@waltdnes.org> <50DBA7D0.4060800@orlitzky.com> <87zk0zivjk.fsf@einstein.gmurray.org.uk> <20121227231150.GA9864@waltdnes.org> <50DCDEAF.9020002@orlitzky.com> <20121228035937.GA2949@waltdnes.org> <50DD370F.4070509@orlitzky.com> <20121231032150.GA2032@waltdnes.org> <50E4A857.1090800@orlitzky.com> Date: Thu, 3 Jan 2013 10:57:09 +0700 Message-ID: Subject: Re: [gentoo-user] IPTABLES syntax change? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=f46d042dff51731a4e04d25a5bc5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: svr-us4.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Archives-Salt: 2883c403-b385-418f-8195-691335b7f50b X-Archives-Hash: 6eb59167fc7a435740f03f5a83f5dbfb --f46d042dff51731a4e04d25a5bc5 Content-Type: text/plain; charset=UTF-8 On Jan 3, 2013 4:40 AM, "Michael Orlitzky" 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, -- --f46d042dff51731a4e04d25a5bc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jan 3, 2013 4:40 AM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 12/30/12 22:21, Walter Dnes wrote:
> > =C2=A0 OK, here is version 2. =C2=A0I had "an excellent adve= nture" along the way.
> >
>
> I'm doing the upgrade on our servers right now, and there's an= other
> possible gotcha: the newer iptables (requiring conntrack) requires
> NETFILTER_XT_MATCH_CONNTRACK support in the kernel. This is in contras= t
> to the state matches which used NETFILTER_XT_MATCH_STATE.
>
> To minimize downtime during the switch, I'm doing,
>
> =C2=A0 1. Rebuild the kernel, enable conntrack and disable state.
>
> =C2=A0 2. Fix my iptables-config script to use the conntrack stuff
>
> =C2=A0 3. Create a dummy set of rules that allows me to SSH in (withou= t
> =C2=A0 =C2=A0 =C2=A0state matching)
>
> =C2=A0 4. Run and save those rules
>
> =C2=A0 5. Reboot to new kernel
>
> =C2=A0 6. SSH in and run iptables-config
>
> =C2=A0 7. Save the rules
>
>
> > [0:0] -A INPUT -s 192.168.1= 23.248/29 -i eth0 -j ACCEPT
> > [0:0] -A INPUT -s 169.254.0.0/1= 6 -i eth0 -j ACCEPT
> > [0:0] -A INPUT -i lo -j ACCEPT
> > [0:0] -A INPUT -m conntrack --ctstate INVALID,NEW -j UNSOLICITED<= br> > > [0:0] -A INPUT -p tcp -m multiport --dports 0:1023,6000:6063 -j B= AD_DPORT
> > [0:0] -A INPUT -p udp -m multiport --dports 0:1023,6000:6063 -j B= AD_DPORT
> > [0:0] -A INPUT -s 69.63.176.0/2= 0 -j FECESBOOK
> > [0:0] -A INPUT -s 69.220.144.0= /20 -j FECESBOOK
> > [0:0] -A INPUT -s 69.63.176.0/2= 0 -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<= /a> -j PRIVATE_LOG
> > [0:0] -A INPUT -s 192.168.0.0/1= 6 -j PRIVATE_LOG
> > [0:0] -A INPUT -p icmp -j ICMP_IN
> > [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCE= PT
>
> These rules will be evaluated in order. I have no evidence for this, b= ut
> I suspect you're better off accepting the ESTABLISHED,RELATED stuf= f
> earlier in the chain so you don't slow down the packets that you w= ant.
>

True. But you will want to filter out 'suspicious' packets befor= ehand.

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,
--

--f46d042dff51731a4e04d25a5bc5--