Re: [gentoo-user] IPTABLES syntax change?
On Sat, Jan 05, 2013 at 11:57:10AM +, Mick wrote It will, but only partially. It seems that the list is long and it is getting longer and longer! Check this out: whois -h whois.radb.net -- '-i origin AS32934' | grep ^route (as advised by https://developers.facebook.com/docs/ApplicationSecurity/) ELVIS Thank you, Thank you, Thank you verrry verrry much /ELVIS It's not as bad as it looks, because... a) there's a lot of duplication b) many of the blocks are subsets with a bigger Facebook block 31.13.24.0/21 inetnum:31.13.24.0 - 31.13.31.255 netname:IE-FACEBOOK-20110418 descr: Facebook Ireland Ltd country:IE 31.13.64.0/18 31.13.64.0/19 31.13.64.0/24 31.13.65.0/24 31.13.66.0/24 31.13.67.0/24 31.13.68.0/24 31.13.69.0/24 31.13.70.0/24 31.13.71.0/24 31.13.72.0/24 31.13.73.0/24 31.13.74.0/24 31.13.75.0/24 31.13.76.0/24 31.13.77.0/24 31.13.78.0/24 31.13.79.0/24 31.13.80.0/24 31.13.82.0/24 31.13.83.0/24 31.13.84.0/24 31.13.85.0/24 31.13.86.0/24 31.13.87.0/24 31.13.88.0/24 31.13.89.0/24 31.13.90.0/24 31.13.91.0/24 31.13.92.0/24 31.13.93.0/24 31.13.94.0/24 31.13.95.0/24 31.13.96.0/19 inetnum:31.13.64.0 - 31.13.127.255 netname:IE-FACEBOOK-20110418 descr: Facebook Ireland Ltd country:IE 66.220.144.0/20 66.220.144.0/20 66.220.144.0/21 66.220.152.0/21 66.220.159.0/24 NetRange: 66.220.144.0 - 66.220.159.255 CIDR: 66.220.144.0/20 OrgName:Facebook, Inc. OrgId: THEFA-3 69.63.176.0/20 69.63.176.0/20 69.63.176.0/20 69.63.176.0/21 69.63.176.0/21 69.63.176.0/24 69.63.178.0/24 69.63.184.0/21 69.63.184.0/21 69.63.186.0/24 NetRange: 69.63.176.0 - 69.63.191.255 CIDR: 69.63.176.0/20 OrgName:Facebook, Inc. OrgId: THEFA-3 69.171.224.0/19 69.171.224.0/20 69.171.239.0/24 69.171.240.0/20 69.171.253.0/24 69.171.255.0/24 NetRange: 69.171.224.0 - 69.171.255.255 CIDR: 69.171.224.0/19 OrgName:Facebook, Inc. OrgId: THEFA-3 74.119.76.0/22 NetRange: 74.119.76.0 - 74.119.79.255 CIDR: 74.119.76.0/22 OrgName:Facebook, Inc. OrgId: THEFA-3 103.4.96.0/22 inetnum:103.4.96.0 - 103.4.99.255 netname:FACEBOOK-SG 173.252.64.0/18 173.252.64.0/19 173.252.70.0/24 173.252.96.0/19 NetRange: 173.252.64.0 - 173.252.127.255 CIDR: 173.252.64.0/18 OriginAS: AS32934 NetName:FACEBOOK-INC 204.15.20.0/22 204.15.20.0/22 NetRange: 204.15.20.0 - 204.15.23.255 CIDR: 204.15.20.0/22 OrgName:Facebook, Inc. OrgId: THEFA-3 A grand total of 9 IPV4 ranges, of which I already have 6. Time for a minor update. Thanks again for the whois lookup command. BTW, websites may break if you block all these ip ranges. LENNART It's their fault that they're broken, not mine /LENNART -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
On Wed, Jan 02, 2013 at 11:32:58PM -0500, Michael Orlitzky wrote On 12/30/2012 10:21 PM, Walter Dnes wrote: [0:0] -A FECESBOOK -j LOG --log-prefix FECESBOOK: --log-level 6 [0:0] -A FECESBOOK -j DROP [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 In fact, since you're blocking all outgoing packets to facebook, the only state that a packet from facebook can have here is INVALID or NEW. So traffic from facebook will be sent to the UNSOLICITED chain and DROPped. [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 ...making these pointless =) I've run into at least one newspaper website (I forget which, it's occasionally used for links on Slashdot) which ends up trying to redirect me to a Facebook site even though the URL does not mention Facebook at all. There is other integration as well. See the first post in http://www.dslreports.com/forum/r26618459-Increasing-integration-of-facebook-into-many-web-sites I believe this may have been straightened out since then, but 13 months ago that post was correct. And then there's the LIKE button which shows up all over the web. The mere fact that you haven't manually typed in... http://www.facebook.com/blah_blah_blah does not mean you're not connecting to it. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
On Fri, Jan 4, 2013 at 3:17 PM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Jan 02, 2013 at 11:32:58PM -0500, Michael Orlitzky wrote On 12/30/2012 10:21 PM, Walter Dnes wrote: [0:0] -A FECESBOOK -j LOG --log-prefix FECESBOOK: --log-level 6 [0:0] -A FECESBOOK -j DROP [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 In fact, since you're blocking all outgoing packets to facebook, the only state that a packet from facebook can have here is INVALID or NEW. So traffic from facebook will be sent to the UNSOLICITED chain and DROPped. [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 ...making these pointless =) I've run into at least one newspaper website (I forget which, it's occasionally used for links on Slashdot) which ends up trying to redirect me to a Facebook site even though the URL does not mention Facebook at all. There is other integration as well. See the first post in http://www.dslreports.com/forum/r26618459-Increasing-integration-of-facebook-into-many-web-sites I believe this may have been straightened out since then, but 13 months ago that post was correct. And then there's the LIKE button which shows up all over the web. The mere fact that you haven't manually typed in... http://www.facebook.com/blah_blah_blah does not mean you're not connecting to it. But all that's above layer 3, since it's an HTTP redirect, or a page transclusion which necessitates a new GET request. Michael's point stands. -- :wq
Re: [gentoo-user] IPTABLES syntax change?
On Fri, Jan 04, 2013 at 03:27:59PM -0500, Michael Mol wrote On Fri, Jan 4, 2013 at 3:17 PM, Walter Dnes waltd...@waltdnes.org wrote: The mere fact that you haven't manually typed in... http://www.facebook.com/blah_blah_blah does not mean you're not connecting to it. But all that's above layer 3, since it's an HTTP redirect, or a page transclusion which necessitates a new GET request. Michael's point stands. And I want to make sure that new GET request is blocked coming and going. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
On Jan 4, 2013 8:33 PM, Walter Dnes waltd...@waltdnes.org wrote: On Fri, Jan 04, 2013 at 03:27:59PM -0500, Michael Mol wrote On Fri, Jan 4, 2013 at 3:17 PM, Walter Dnes waltd...@waltdnes.org wrote: The mere fact that you haven't manually typed in... http://www.facebook.com/blah_blah_blah does not mean you're not connecting to it. But all that's above layer 3, since it's an HTTP redirect, or a page transclusion which necessitates a new GET request. Michael's point stands. And I want to make sure that new GET request is blocked coming and going. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications And it will, for the simple reason that outbound psckets are dropped, so inbound packets are nevrr valid. That was Michael's point.
Re: [gentoo-user] IPTABLES syntax change?
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.
Re: [gentoo-user] IPTABLES syntax change?
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, --
Re: [gentoo-user] IPTABLES syntax change?
On 12/30/2012 10:21 PM, Walter Dnes wrote: [0:0] -A FECESBOOK -j LOG --log-prefix FECESBOOK: --log-level 6 [0:0] -A FECESBOOK -j DROP [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 In fact, since you're blocking all outgoing packets to facebook, the only state that a packet from facebook can have here is INVALID or NEW. So traffic from facebook will be sent to the UNSOLICITED chain and DROPped. [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 ...making these pointless =) [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 I believe the same applies here, since you already accepted your legitimate LAN traffic above. For this to catch anything, you'd first have to send a packet to one of those subnets and something would have to respond to it. [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT So it makes even more sense to move this above the rest. If you still want to log facebook and other private traffic, the INVALID,NEW rule should come after those, otherwise the facebook/private stuff will just be dropped as UNSOLICITED.
Re: [gentoo-user] IPTABLES syntax change?
On 12/29/2012 01:32 PM, Walter Dnes wrote: Two questions I'm not sure about. 1) I run a desktop, and use passive ftp. Is there any need for me to accept RELATED packets? Probably not, I think the server needs it though. 2) Does a -j LOG return to the chain it was called from, or does it do an implicit DROP? It returns to spot where it was called from.
Re: [gentoo-user] IPTABLES syntax change?
2) Does a -j LOG return to the chain it was called from, or does it do an implicit DROP? It returns to spot where it was called from. Yep, so you could create a new chain to drop and log; /sbin/iptables -N logdrop /sbin/iptables -A logdrop -j LOG --log-prefix 'DROP ' /sbin/iptables -A logdrop -j DROP Then call that one /sbin/iptables -A tcp_packets -p TCP --dport 80 -j ACCEPT /sbin/iptables -A tcp_packets -p TCP -j logdrop
Re: [gentoo-user] IPTABLES syntax change?
OK, here is version 2. I had an excellent adventure along the way. * At the very last line (COMMIT), iptables-restore said it failed, but no clue whatsoever as to why. * I copied the rules file to a scratch-file, and converted it to a bash script that called iptables each time. * This method showed errors when using -m multiport * multiport is apparently not part of the core of iptables. It's an extra kernel option that has to be invoked explicity. * cd /usr/src/linux make menuconfig [*] Networking support --- Networking options --- [*] Network packet filtering framework (Netfilter) --- Here's where it gets tricky. You *MUST* first enable... [*] Advanced netfilter configuration ...and then go into... Core Netfilter Configuration --- ...and select... * multiport Multiple port match support Rebuild kernel and reboot. Now for the iptables rules, version 2 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :BAD_DPORT - [0:0] :BAD_SPORT - [0:0] :DROP_LOG - [0:0] :FECESBOOK - [0:0] :ICMP_IN - [0:0] :ICMP_OUT - [0:0] :PRIVATE_LOG - [0:0] :UNSOLICITED - [0:0] [0:0] -A BAD_DPORT -j LOG --log-prefix BAD_DPORT: --log-level 6 [0:0] -A BAD_DPORT -j DROP [0:0] -A BAD_SPORT -j LOG --log-prefix BAD_SPORT: --log-level 6 [0:0] -A BAD_SPORT -j DROP [0:0] -A DROP_LOG -j LOG --log-level 6 [0:0] -A DROP_LOG -j DROP [0:0] -A FECESBOOK -j LOG --log-prefix FECESBOOK: --log-level 6 [0:0] -A FECESBOOK -j DROP [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 0 -j ACCEPT [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 4 -j ACCEPT [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 11 -j ACCEPT [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 12 -j ACCEPT [0:0] -A ICMP_IN -j LOG --log-prefix IN_BAD_ICMP: --log-level 6 [0:0] -A ICMP_IN -j DROP [0:0] -A ICMP_OUT -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A ICMP_OUT -p icmp -m icmp --icmp-type 8 -j ACCEPT [0:0] -A ICMP_OUT -p icmp -m icmp --icmp-type 30 -j ACCEPT [0:0] -A ICMP_OUT -j LOG --log-prefix OUT_BAD_ICMP: --log-level 6 [0:0] -A ICMP_OUT -j DROP [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 [0:0] -A OUTPUT -d 192.168.123.248/29 -o eth0 -j ACCEPT [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -p tcp -m multiport --sports 0:1023,6000:6063 -j BAD_SPORT [0:0] -A OUTPUT -p udp -m multiport --sports 0:1023,6000:6063 -j BAD_SPORT [0:0] -A OUTPUT -d 69.63.176.0/20 -j FECESBOOK [0:0] -A OUTPUT -d 69.220.144.0/20 -j FECESBOOK [0:0] -A OUTPUT -d 69.63.176.0/20 -j FECESBOOK [0:0] -A OUTPUT -d 69.171.224.0/19 -j FECESBOOK [0:0] -A OUTPUT -d 200.58.112.0/20 -j FECESBOOK [0:0] -A OUTPUT -d 213.155.64.0/19 -j FECESBOOK [0:0] -A PRIVATE_LOG -j LOG --log-prefix IN_BAD_ADDR: --log-level 6 [0:0] -A PRIVATE_LOG -j DROP [0:0] -A UNSOLICITED -j LOG --log-prefix UNSOLICITED: --log-level 6 [0:0] -A UNSOLICITED -j DROP COMMIT -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
Two questions I'm not sure about. 1) I run a desktop, and use passive ftp. Is there any need for me to accept RELATED packets? 2) Does a -j LOG return to the chain it was called from, or does it do an implicit DROP? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
On 29-Dec-12 19:32, Walter Dnes wrote: 1) I run a desktop, and use passive ftp. Is there any need for me to accept RELATED packets? No, but you must take care of related connections. Even passive ftp opens command (1023 - 21) and data (1023 - 1023) channel. BTW, icmp-error (i.e. host unreachable) can also be connection related to some other one... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] IPTABLES syntax change?
On Fri, Dec 28, 2012 at 01:07:11AM -0500, Michael Orlitzky wrote On 12/27/2012 10:59 PM, Walter Dnes wrote: Here's my revised Paranoia Plus ruleset. Any comments? Because I'm behind a NAT-ing ADSL router/modem, many of my rules rarely see hits. However, I do have a backup dialup connection in case of problems, so most of my rules don't specify the network interface. A couple of notes... I did a bunch of inline comments below as I was trying to understand the rules. At the end I give the tl;dr, but maybe the inline comments are useful too. Thanks. My ruleset has accumulated years of cruft. I should really sit down and rewrite the thing from square 1. I have one comment. You show what appears to be a bash script for setting up the rules. I work with the contents of file /var/lib/iptables/rules-save instead. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
Walter Dnes wrote: On Fri, Dec 28, 2012 at 01:07:11AM -0500, Michael Orlitzky wrote On 12/27/2012 10:59 PM, Walter Dnes wrote: Here's my revised Paranoia Plus ruleset. Any comments? Because I'm behind a NAT-ing ADSL router/modem, many of my rules rarely see hits. However, I do have a backup dialup connection in case of problems, so most of my rules don't specify the network interface. A couple of notes... I did a bunch of inline comments below as I was trying to understand the rules. At the end I give the tl;dr, but maybe the inline comments are useful too. Thanks. My ruleset has accumulated years of cruft. I should really sit down and rewrite the thing from square 1. I have one comment. You show what appears to be a bash script for setting up the rules. I work with the contents of file /var/lib/iptables/rules-save instead. Calling iptables repeatedly from a shell script is not advisable. A better approach is described by Jan Engelhardt in his Towards the perfect ruleset document: http://inai.de/documents/Perfect_Ruleset.pdf The method of working with /var/lib/iptables/rules-save is very similar to that which he describes. Cheers, --Kerin
Re: [gentoo-user] IPTABLES syntax change?
Michael Orlitzky mich...@orlitzky.com writes: The 'conntrack' module is supposed to be a superset of 'state', so most things should be compatible. You really have two warnings there; the first is for the state - conntrack switch, and the second is because you're missing the --state flag in your rules. In your example, you turn on the state matching, iptables -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED but you don't specify *which* state(s) you want to match. It wants you to specify --state SOMETHING. I'd guess that it used to interpret no state as any state. The problem is not really the OP's fault. The problem is that if you have tables with the form -m state --state XXX at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as -m state --state - ie 'forgetting' which state(s) the rule applies to. The solution is to either change all your rules to use -m conntrack --ctstate XXX before upgrading or editing /var/lib/iptables/rules-save to globally replace '-m state' by '-m conntrack' and '--state' by '--ctstate' prior to the upgrade and (at least temporarily) edit /etc/conf.d/iptables to set SAVE_ON_STOP=no. The same will also need to be done with ip6tables if you use that. I think that this is a serious enough change in behaviour that an elog warning should have been issued.
Re: [gentoo-user] IPTABLES syntax change?
On 12/27/12 06:28, Graham Murray wrote: Michael Orlitzky mich...@orlitzky.com writes: The 'conntrack' module is supposed to be a superset of 'state', so most things should be compatible. You really have two warnings there; the first is for the state - conntrack switch, and the second is because you're missing the --state flag in your rules. In your example, you turn on the state matching, iptables -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED but you don't specify *which* state(s) you want to match. It wants you to specify --state SOMETHING. I'd guess that it used to interpret no state as any state. The problem is not really the OP's fault. The problem is that if you have tables with the form -m state --state XXX at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as -m state --state - ie 'forgetting' which state(s) the rule applies to. Youch, thanks, I'll keep an eye out for this when iptables wants a bump. I already keep the rules in a script, but it sounds like this will clobber the running rules after e.g. a reboot. My first -m state rule is, iptables -A INPUT -p ALL -m state \ --state ESTABLISHED,RELATED -j ACCEPT And if what you say is true, I'd be in deep shit if it reset to, iptables -A INPUT -p ALL -m state -j ACCEPT without a warning. I think that this is a serious enough change in behaviour that an elog warning should have been issued. It's not stable yet, right? File a bug (and CC me, please).
Re: [gentoo-user] IPTABLES syntax change?
Michael Orlitzky wrote: My first -m state rule is, iptables -A INPUT -p ALL -m state \ --state ESTABLISHED,RELATED -j ACCEPT That was mine, too (you can omit -p in this case, can't you?). And if what you say is true, I'd be in deep shit if it reset to, iptables -A INPUT -p ALL -m state -j ACCEPT without a warning. It *was* resetted here. I just noticed it reading this discussion. Don't exactly know what the stateless rule did (perhaps just nothing?), but since I didn't notice it for a pretty long time, it can't have been all to bad?! At least, it didn't crash the whole system :-) But I would have appreciated at least an update notice, too! -Matt
Re: [gentoo-user] IPTABLES syntax change?
On 12/27/12 12:52, Matthias Hanft wrote: Michael Orlitzky wrote: My first -m state rule is, iptables -A INPUT -p ALL -m state \ --state ESTABLISHED,RELATED -j ACCEPT That was mine, too (you can omit -p in this case, can't you?). Yeah, it just makes the indentation line up in my case. And if what you say is true, I'd be in deep shit if it reset to, iptables -A INPUT -p ALL -m state -j ACCEPT without a warning. It *was* resetted here. I just noticed it reading this discussion. Don't exactly know what the stateless rule did (perhaps just nothing?), but since I didn't notice it for a pretty long time, it can't have been all to bad?! At least, it didn't crash the whole system :-) But I would have appreciated at least an update notice, too! I confirmed and opened a bug: https://bugs.gentoo.org/show_bug.cgi?id=448906 Thanks again to Graham for pointing this out.
Re: [gentoo-user] IPTABLES syntax change?
On Thu, Dec 27, 2012 at 11:28:15AM +, Graham Murray wrote The problem is not really the OP's fault. The problem is that if you have tables with the form -m state --state XXX at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as -m state --state - ie 'forgetting' which state(s) the rule applies to. Thanks for pointing that out. I looked back at an archived version, and it had stuff like... -A ICMP_IN -p icmp -m state --state NEW -j UNSOLICITED -A TCP_IN -p tcp -m state --state NEW -m tcp -j UNSOLICITED -A UDP_IN -p udp -m state --state NEW -j UNSOLICITED I.e. new external connection attempts were rejected, except for my lan which bypasses this rule so I can scp/ssh etc between my machines. No wonder I was puzzled by what I saw. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
On 12/27/2012 06:11 PM, Walter Dnes wrote: On Thu, Dec 27, 2012 at 11:28:15AM +, Graham Murray wrote The problem is not really the OP's fault. The problem is that if you have tables with the form -m state --state XXX at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as -m state --state - ie 'forgetting' which state(s) the rule applies to. Thanks for pointing that out. I looked back at an archived version, and it had stuff like... -A ICMP_IN -p icmp -m state --state NEW -j UNSOLICITED -A TCP_IN -p tcp -m state --state NEW -m tcp -j UNSOLICITED -A UDP_IN -p udp -m state --state NEW -j UNSOLICITED I.e. new external connection attempts were rejected, except for my lan which bypasses this rule so I can scp/ssh etc between my machines. No wonder I was puzzled by what I saw. Ah, yes, the original problem. Once you've upgraded, you should be able to add all of your old --state rules normally, albeit with a warning. The new iptables will translate them to conntrack rules, and you can `/etc/init.d/iptables save` the result. The upgrade just fails in a horrible way.
Re: [gentoo-user] IPTABLES syntax change?
On Thu, Dec 27, 2012 at 06:50:07PM -0500, Michael Orlitzky wrote Once you've upgraded, you should be able to add all of your old --state rules normally, albeit with a warning. The new iptables will translate them to conntrack rules, and you can `/etc/init.d/iptables save` the result. The upgrade just fails in a horrible way. Here's my revised Paranoia Plus ruleset. Any comments? Because I'm behind a NAT-ing ADSL router/modem, many of my rules rarely see hits. However, I do have a backup dialup connection in case of problems, so most of my rules don't specify the network interface. A couple of notes... * My little lan is 192.168.123.248/29 * I have a TV tuner box that comes up in the zero-config space, so I have to allow 169.254.0.0/16 * I dislike a certain button following me. # Generated by iptables-save v1.4.16.3 on Thu Dec 27 22:43:12 2012 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :DROP_LOG - [0:0] :FECESBOOK - [0:0] :ICMP_IN - [0:0] :PRIVATE - [0:0] :PRIVATE_LOG - [0:0] :TCP_IN - [0:0] :UDP_IN - [0:0] :UNSOLICITED - [0:0] [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 -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 -p tcp -m tcp --sport 53 -j ACCEPT [0:0] -A INPUT -p udp -m udp --sport 53 -j ACCEPT [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -f -j LOG --log-prefix FRAGMENTS: --log-level 6 [0:0] -A INPUT -f -j DROP [0:0] -A INPUT -p tcp -j TCP_IN [0:0] -A INPUT -p udp -j UDP_IN [0:0] -A INPUT -p icmp -j ICMP_IN [0:0] -A INPUT -j LOG --log-prefix BAD_PROTOCOL: --log-level 6 [0:0] -A INPUT -j DROP [0:0] -A OUTPUT -d 192.168.123.248/29 -o eth0 -j ACCEPT [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 30 -j ACCEPT [0:0] -A OUTPUT -p tcp -m tcp --sport 0:1023 -j DROP_LOG [0:0] -A OUTPUT -p udp -m udp --sport 0:1023 -j DROP_LOG [0:0] -A OUTPUT -p tcp -m tcp --sport 6000:6063 -j DROP_LOG [0:0] -A OUTPUT -p udp -m udp --sport 6000:6063 -j DROP_LOG [0:0] -A OUTPUT -j ACCEPT [0:0] -A DROP_LOG -j LOG --log-level 6 [0:0] -A DROP_LOG -j DROP [0:0] -A FECESBOOK -j LOG --log-prefix FECESBOOK: --log-level 6 [0:0] -A FECESBOOK -j DROP [0:0] -A ICMP_IN -p icmp -m conntrack --ctstate NEW -j UNSOLICITED [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 0 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 3 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 4 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 11 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 12 -j PRIVATE [0:0] -A ICMP_IN -j LOG --log-prefix IN_BAD_ICMP: --log-level 6 [0:0] -A ICMP_IN -j DROP [0:0] -A PRIVATE -s 10.0.0.0/8 -j PRIVATE_LOG [0:0] -A PRIVATE -s 127.0.0.0/8 -j PRIVATE_LOG [0:0] -A PRIVATE -s 172.16.0.0/12 -j PRIVATE_LOG [0:0] -A PRIVATE -s 192.168.0.0/16 -j PRIVATE_LOG [0:0] -A PRIVATE -j ACCEPT [0:0] -A PRIVATE_LOG -j LOG --log-prefix IN_BAD_ADDR: --log-level 6 [0:0] -A PRIVATE_LOG -j DROP [0:0] -A TCP_IN -p tcp -m tcp --dport 0:1023 -j DROP_LOG [0:0] -A TCP_IN -p tcp -m tcp --dport 6000:6063 -j DROP_LOG [0:0] -A TCP_IN -p tcp -m tcp --sport 53 -j PRIVATE [0:0] -A TCP_IN -p tcp -m tcp --sport 80 -j PRIVATE [0:0] -A TCP_IN -p tcp -m conntrack --ctstate NEW -m tcp -j UNSOLICITED [0:0] -A TCP_IN -p tcp -j PRIVATE [0:0] -A UDP_IN -p udp -m udp --dport 0:1023 -j DROP_LOG [0:0] -A UDP_IN -p udp -m udp --dport 6000:6063 -j DROP_LOG [0:0] -A UDP_IN -p udp -m udp --sport 53 -j PRIVATE [0:0] -A UDP_IN -p udp -m udp --sport 80 -j PRIVATE [0:0] -A UDP_IN -p udp -m conntrack --ctstate NEW -j UNSOLICITED [0:0] -A UDP_IN -p udp -j PRIVATE [0:0] -A UNSOLICITED -j LOG --log-prefix UNSOLICITED: --log-level 6 [0:0] -A UNSOLICITED -j DROP COMMIT # Completed on Thu Dec 27 22:43:12 2012 -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
On 12/27/2012 10:59 PM, Walter Dnes wrote: Here's my revised Paranoia Plus ruleset. Any comments? Because I'm behind a NAT-ing ADSL router/modem, many of my rules rarely see hits. However, I do have a backup dialup connection in case of problems, so most of my rules don't specify the network interface. A couple of notes... I did a bunch of inline comments below as I was trying to understand the rules. At the end I give the tl;dr, but maybe the inline comments are useful too. * My little lan is 192.168.123.248/29 * I have a TV tuner box that comes up in the zero-config space, so I have to allow 169.254.0.0/16 * I dislike a certain button following me. # Generated by iptables-save v1.4.16.3 on Thu Dec 27 22:43:12 2012 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] You can save yourself some complexity by allowing outbound traffic by default. I see that your INPUT policy is set to DROP, but you override this in a few places: at the end of all the chains, you jump to the PRIVATE table, which ends with a -j ACCEPT. So you'll accept anything that isn't rejected by a previous rule. I'd suggesting flipping that: get rid of the -j ACCEPT at the end of the private table, and allow unmatched traffic to be dropped. :DROP_LOG - [0:0] :FECESBOOK - [0:0] :ICMP_IN - [0:0] :PRIVATE - [0:0] :PRIVATE_LOG - [0:0] :TCP_IN - [0:0] :UDP_IN - [0:0] :UNSOLICITED - [0:0] [0:0] -A INPUT -s 192.168.123.248/29 -i eth0 -j ACCEPT Since you've self-proclaimed as paranoid, I don't feel bad suggesting that you choose which ports to allow incoming, even to the LAN. If somebody brings (or creates!) a compromised machine onto your LAN, they're going to be able to hit any ports that you've got open and available through the firewall. Not much you can do about that. But you might as well prevent them from reaching everything. If you expect to SSH from the LAN, sure, let that in. But if you're not serving e.g. web pages, you might as well block port 80 from the LAN. This allows you the freedom to play with apache without worrying about whether or not you've secured it. [0:0] -A INPUT -s 169.254.0.0/16 -i eth0 -j ACCEPT I don't know anything about zeroconf, not qualified to comment. [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 FECESBOOK -j LOG --log-prefix FECESBOOK: --log-level 6 [0:0] -A FECESBOOK -j DROP Cute =) That final DROP is only needed since you -j PRIVATE (which defaults to ACCEPT) at the end of everything. [0:0] -A INPUT -p tcp -m tcp --sport 53 -j ACCEPT [0:0] -A INPUT -p udp -m udp --sport 53 -j ACCEPT Ok, in the INPUT chain you're accepting DNS traffic early. You do it again below, so I think the later one is redundant. [0:0] -A INPUT -i lo -j ACCEPT [0:0] -A INPUT -f -j LOG --log-prefix FRAGMENTS: --log-level 6 [0:0] -A INPUT -f -j DROP [0:0] -A INPUT -p tcp -j TCP_IN [0:0] -A INPUT -p udp -j UDP_IN [0:0] -A INPUT -p icmp -j ICMP_IN [0:0] -A INPUT -j LOG --log-prefix BAD_PROTOCOL: --log-level 6 [0:0] -A INPUT -j DROP DROP is redundant, since the INPUT policy is DROP. [0:0] -A OUTPUT -d 192.168.123.248/29 -o eth0 -j ACCEPT [0:0] -A OUTPUT -o lo -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT [0:0] -A OUTPUT -p icmp -m icmp --icmp-type 30 -j ACCEPT [0:0] -A OUTPUT -p tcp -m tcp --sport 0:1023 -j DROP_LOG [0:0] -A OUTPUT -p udp -m udp --sport 0:1023 -j DROP_LOG [0:0] -A OUTPUT -p tcp -m tcp --sport 6000:6063 -j DROP_LOG [0:0] -A OUTPUT -p udp -m udp --sport 6000:6063 -j DROP_LOG [0:0] -A OUTPUT -j ACCEPT Aha, you're overriding the OUTPUT policy of DROP here with an ACCEPT. You might as well set the policy to ACCEPT, and get rid of the trailing -j ACCEPT. Anything that is explicitly ACCEPTed above but not otherwise DROPped is also redundant, since traffic will be accepted by default if not dropped. I see that you want to log-before-drop specific traffic; that would still work with a policy of ACCEPT. You would add only those rules to the OUTPUT chain. [0:0] -A DROP_LOG -j LOG --log-level 6 [0:0] -A DROP_LOG -j DROP DROP would be redundant without the -j ACCEPT at the end of the PRIVATE TABLE. [0:0] -A ICMP_IN -p icmp -m conntrack --ctstate NEW -j UNSOLICITED [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 0 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 3 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 4 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 11 -j PRIVATE [0:0] -A ICMP_IN -p icmp -m icmp --icmp-type 12 -j PRIVATE [0:0] -A ICMP_IN -j LOG --log-prefix IN_BAD_ICMP: --log-level 6 [0:0] -A ICMP_IN -j DROP DROP would be redundant without the -j ACCEPT at the end of the
Re: [gentoo-user] IPTABLES syntax change?
I'm sure I made more than one typo, but the ALLOWED_ICMP below
definitely needs a dollar sign.
for ok_icmp in ALLOWED_ICMP; do
iptables -A ICMP_IN -p icmp --icmp-type ${ok_icmp} -j ACCEPT
done
[gentoo-user] IPTABLES syntax change?
Many years ago, I understood IPCHAINS, and the first versions of IPTABLES. However, IPTABLES has followed the example of Larry Wall's Practical Extraction and Reporting Language and turned into a pseudo-OS that I barely comprehend. Some rules that I added many years ago were designed to reject unsolicited connection attempts (after whitelisting my small LAN)... -A ICMP_IN -p icmp -m state -j UNSOLICITED -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED -A UDP_IN -p udp -m state -j UNSOLICITED Now these all give me the error message... WARNING: The state match is obsolete. Use conntrack instead. iptables-restore v1.4.16.3: state: option --state must be specified man iptables suggested man iptables-extensions. As near as I can tell, the new and improved way is... -A ICMP_IN -p icmp -m conntrack --ctstate INVALID -j UNSOLICITED -A TCP_IN -p tcp -m conntrack --ctstate INVALID -m tcp -j UNSOLICITED -A UDP_IN -p udp -m conntrack --ctstate INVALID -j UNSOLICITED This appears to work, i.e. it doesn't cause iptables to fail. Does this do what I think it does (reject unsolicited connections)? The reason that I'm asking is because I'm simply not sure. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] IPTABLES syntax change?
On 12/26/2012 07:47 PM, Walter Dnes wrote:
Many years ago, I understood IPCHAINS, and the first versions of
IPTABLES. However, IPTABLES has followed the example of Larry Wall's
Practical Extraction and Reporting Language
and turned into a pseudo-OS that I barely comprehend. Some rules
that I added many years ago were designed to reject unsolicited
connection attempts (after whitelisting my small LAN)...
-A ICMP_IN -p icmp -m state -j UNSOLICITED
-A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED
-A UDP_IN -p udp -m state -j UNSOLICITED
Now these all give me the error message...
WARNING: The state match is obsolete. Use conntrack instead.
iptables-restore v1.4.16.3: state: option --state must be specified
The 'conntrack' module is supposed to be a superset of 'state', so most
things should be compatible. You really have two warnings there; the
first is for the state - conntrack switch, and the second is because
you're missing the --state flag in your rules.
In your example, you turn on the state matching,
iptables -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED
but you don't specify *which* state(s) you want to match. It wants you
to specify --state SOMETHING. I'd guess that it used to interpret no
state as any state.
You said that you whitelisted your LAN prior to that rule, so you're
probably just rejecting every {ICMP, TCP, UDP} packet with those three
rules.
If so, the equivalent rules are just,
iptables -A ICMP_IN -p icmp -j DROP
iptables -A TCP_IN -p tcp -j DROP
iptables -A UDP_IN -p udp -j DROP
In other words, you only really need the connection tracking to /accept/
related connections. You don't want to deny related or established
connections, usually. And once you have accepted those two types, you
can just reject the rest, because they're necessarily new (or in rare
cases, invalid).
I would be wary of this:
-A ICMP_IN -p icmp -m conntrack --ctstate INVALID -j UNSOLICITED
since if the old rule works like I think it does (reject everything) the
new one might allow some things that the old one didn't.
