[gentoo-user] IPTABLES syntax change?

[gentoo-user] IPTABLES syntax change?

[Walter Dnes]

  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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] IPTABLES syntax change?

[Michael Orlitzky]

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.

Re: [gentoo-user] IPTABLES syntax change?

[Graham Murray]

Michael Orlitzky <michael@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?

[Michael Orlitzky]

On 12/27/12 06:28, Graham Murray wrote:
> Michael Orlitzky <michael@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?

[Matthias Hanft]

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?

[Michael Orlitzky]

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?

[Walter Dnes]

On Thu, Dec 27, 2012 at 11:28:15AM +0000, 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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] IPTABLES syntax change?

[Michael Orlitzky]

On 12/27/2012 06:11 PM, Walter Dnes wrote:
> On Thu, Dec 27, 2012 at 11:28:15AM +0000, 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?

[Walter Dnes]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] IPTABLES syntax change?

[Michael Orlitzky]

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 PRIVATE
TABLE.


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

This is where you essentially set an ACCEPT policy, since all unmatched
traffic winds up here.


> [0:0] -A PRIVATE_LOG -j LOG --log-prefix "IN_BAD_ADDR:" --log-level 6
> [0:0] -A PRIVATE_LOG -j DROP

DROP would be redundant without the -j ACCEPT at the end of the PRIVATE
TABLE.


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

I think you already accepted the DNS traffic.


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

By jumping to the PRIVATE table at the end, you've basically set a
policy of ACCEPT, since the PRIVATE chain ends with a -j ACCEPT.


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

DNS, probably already accepted this.


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

Same as at the end of TCP_IN. By jumping to the PRIVATE table at the
end, you've basically set a policy of ACCEPT for anything tcp, udp, or icmp.


> [0:0] -A UNSOLICITED -j LOG --log-prefix "UNSOLICITED:" --log-level 6
> [0:0] -A UNSOLICITED -j DROP

DROP would be redundant without the -j ACCEPT at the end of the PRIVATE
TABLE.


In the TCP_IN and UDP_IN tables, you try to reject NEW connections
before passing onto the PRIVATE chain which eventually allows the
traffic. So you kind-of have an ACCEPT policy, but you want to reject
any traffic that isn't for an established connection. This can be
simplified by switching to a default-DROP policy, and allowing
RELATED,ESTABLISHED connections through instead.

Here's an example that will almost certainly need some work (I haven't
even tried to run it).

# Flush existing rules
iptables -F

# Delete user-defined chains.
iptables -X FECESBOOK
iptables -X DROP_LOG
iptables -X TCP_IN
iptables -X UDP_IN
iptables -X ICMP_IN

# Recreate (empty) user-defined chains.
iptables -N FECESBOOK
iptables -N DROP_LOG
iptables -N TCP_IN
iptables -N UDP_IN
iptables -N ICMP_IN

# Set policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

#
# Add FECESBOOK rules
#
iptables -A FECESBOOK -j LOG --log-prefix "FECESBOOK:" --log-level 6
iptables -A FECESBOOK -j DROP

#
# Add DROP_LOG rules
#
iptables -A DROP_LOG -j LOG --log-level 6
iptables -A DROP_LOG -j DROP

#
# Add ICMP_IN rules
#
ALLOWED_ICMP="0 3 4 8 11 12 30"

for ok_icmp in ALLOWED_ICMP; do
  iptables -A ICMP_IN -p icmp --icmp-type "${ok_icmp}" -j ACCEPT
done

iptables -A ICMP_IN -j LOG --log-prefix "IN_BAD_ICMP:" --log-level 6

#
# Add TCP_IN rules
#
iptables -A TCP_IN -p tcp -m tcp --dport 0:1023 -j DROP_LOG
iptables -A TCP_IN -p tcp -m tcp --dport 6000:6063 -j DROP_LOG

# Add UDP_IN rules
iptables -A UDP_IN -p udp -m udp --dport 0:1023 -j DROP_LOG
iptables -A UDP_IN -p udp -m udp --dport 6000:6063 -j DROP_LOG


#
# Main INPUT chain
#
#
# Allow your LAN/Zeroconf stuff. For more paranoia (recommended), allow
# only specific ports.
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -s 192.168.123.248/29 -i eth0 -j ACCEPT
iptables -A INPUT -s 169.254.0.0/16 -i eth0 -j ACCEPT

# Block this stuff before allowing related, established traffic.
# That is, block Facebook traffic, period.
# A list of Facebook CIDRs.
FECESBOOK="69.63.176.0/20 69.220.144.0/20 69.63.176.0/20 69.171.224.0/19
200.58.112.0/20 213.155.64.0/19"

for fb in $FECESBOOK; do
    iptables -A INPUT -s "${fb} -j FECESBOOK
done

# Drop fragmented packets without further consideration.
iptables -A INPUT -f -j LOG --log-prefix "FRAGMENTS:" --log-level 6
iptables -A INPUT -f -j DROP

# If you initiate a connection, allow the response to come back in.
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# For all other (i.e. NEW) traffic, filter by protocol.
iptables -A INPUT -p tcp -j TCP_IN
iptables -A INPUT -p udp -j UDP_IN
iptables -A INPUT -p icmp -j ICMP_IN

# If it isn't TCP, UDP, or ICMP, we probably don't want it.
iptables -A INPUT -j LOG --log-prefix "BAD_PROTOCOL:" --log-level 6

#
# At this point, anything not matched is dropped.
#

Re: [gentoo-user] IPTABLES syntax change?

[Michael Orlitzky]

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
> 

Re: [gentoo-user] IPTABLES syntax change?

[Walter Dnes]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] IPTABLES syntax change?

[Kerin Millar]

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?

[Walter Dnes]

  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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] IPTABLES syntax change?

[Jarry]

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?

[Michael Orlitzky]

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?

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 817 bytes --]

Re: [gentoo-user] IPTABLES syntax change?

[Walter Dnes]

  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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] IPTABLES syntax change?

[Michael Orlitzky]

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?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2449 bytes --]

On Jan 3, 2013 4:40 AM, "Michael Orlitzky" <michael@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,
--

[-- Attachment #2: Type: text/html, Size: 3522 bytes --]

Re: [gentoo-user] IPTABLES syntax change?

[Michael Orlitzky]

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?

[Walter Dnes]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] IPTABLES syntax change?

[Michael Mol]

On Fri, Jan 4, 2013 at 3:17 PM, Walter Dnes <waltdnes@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?

[Walter Dnes]

On Fri, Jan 04, 2013 at 03:27:59PM -0500, Michael Mol wrote
> On Fri, Jan 4, 2013 at 3:17 PM, Walter Dnes <waltdnes@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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] IPTABLES syntax change?

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Jan 4, 2013 8:33 PM, "Walter Dnes" <waltdnes@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 <waltdnes@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 <waltdnes@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.

[-- Attachment #2: Type: text/html, Size: 1320 bytes --]

Re: [gentoo-user] IPTABLES syntax change?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1338 bytes --]

On Saturday 05 Jan 2013 03:26:10 Michael Mol wrote:
> On Jan 4, 2013 8:33 PM, "Walter Dnes" <waltdnes@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 <waltdnes@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 <waltdnes@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.

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/)

BTW, websites may break if you block all these ip ranges.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] IPTABLES syntax change?

[Walter Dnes]

On Sat, Jan 05, 2013 at 11:57:10AM +0000, 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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications