Problems with OUTPUT rules ESTABLISHED,RELATED

Problems with OUTPUT rules ESTABLISHED,RELATED

[John Lange]

I'm looking for some advice tuning iptables rules.

The problem is, quite a few packets are being dropped which I don't
think should be.

Here are the basic rules:

iptables -P INPUT DROP
iptables -P OUTPUT DROP

iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

With the above rules why does the following get blocked?

-----
Aug  2 13:04:47 HOST kernel: IN= OUT=eth0 SRC=XXX.XXX.XXX.XXX
DST=XXX.XXX.XXX.XXX LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=11945 DF
PROTO=TCP SPT=80 DPT=48473 WINDOW=1805 RES=0x00 ACK URGP=0 UID=501
-----

This appears to be the return ACK of the inital SYN. Shouldn't that be
permitted under the above rules?

Could it have something to do with the DF flag on the packet?

-- 
John Lange

Re: Problems with OUTPUT rules ESTABLISHED,RELATED

[Peter Volkov Alexandrovich]

Hi.

On Втр, 2005-08-02 at 13:59 -0500, John Lange wrote:
> The problem is, quite a few packets are being dropped which I don't
> think should be.
> 
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> 
> iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT
> 
> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> With the above rules why does the following get blocked?
> 
> -----
> Aug  2 13:04:47 HOST kernel: IN= OUT=eth0 SRC=XXX.XXX.XXX.XXX
> DST=XXX.XXX.XXX.XXX LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=11945 DF
> PROTO=TCP SPT=80 DPT=48473 WINDOW=1805 RES=0x00 ACK URGP=0 UID=501
> -----
> 
> This appears to be the return ACK of the inital SYN. Shouldn't that be
> permitted under the above rules?

No. IIUC your connection is in state NEW while it have not seen packets
in both directions (man iptables). After syn packet have reached your
host syn,ack packet should be sent to client. At this moment your
connection is in state NEW. And your rules forbid OUTPUT packets in
state NEW. Thus packet is dropped.

Peter.

Re: Problems with OUTPUT rules ESTABLISHED,RELATED

[John Lange]

Thanks Peter.

Perhaps you can help clarify this for me?

According to http://www.knowplace.org/netfilter/ip_overview.html , the
handshake procedure is as follows:

1. (B) --> [SYN] --> (A)
2. (B) <-- [SYN/ACK] <--(A)
3. (B) --> [ACK] --> (A)

I read it as meaning that up until the end of step 2 the connection
would be NEW. At the end of Step 2 and beyond the connection would be
ESTABLISHED.

A packet with just the "ACK" flag set can only be part of an established
connection. quote "The important thing to note here is that after the
three-way handshake is completed, and the connection is complete, every
packet that is part of this TCP connection will always have the ACK bit
set."

So, my understanding is the only way a packet could be generated with
the ACK flag set and the SRC as my server's IP is as part of an
established connection.

If that is the case then it should not be blocked because I have an
OUTPUT rule  which allows it.

Where am I going wrong here?

If I do:

iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Then all outbound packets are allowed so I definitely don't want that.

-- 
John Lange

On Tue, 2005-08-02 at 23:47 +0400, Peter Volkov Alexandrovich wrote:
> Hi.
> 
> On ²âà, 2005-08-02 at 13:59 -0500, John Lange wrote:
> > The problem is, quite a few packets are being dropped which I don't
> > think should be.
> > 
> > iptables -P INPUT DROP
> > iptables -P OUTPUT DROP
> > 
> > iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT
> > 
> > iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > 
> > With the above rules why does the following get blocked?
> > 
> > -----
> > Aug  2 13:04:47 HOST kernel: IN= OUT=eth0 SRC=XXX.XXX.XXX.XXX
> > DST=XXX.XXX.XXX.XXX LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=11945 DF
> > PROTO=TCP SPT=80 DPT=48473 WINDOW=1805 RES=0x00 ACK URGP=0 UID=501
> > -----
> > 
> > This appears to be the return ACK of the inital SYN. Shouldn't that be
> > permitted under the above rules?
> 
> No. IIUC your connection is in state NEW while it have not seen packets
> in both directions (man iptables). After syn packet have reached your
> host syn,ack packet should be sent to client. At this moment your
> connection is in state NEW. And your rules forbid OUTPUT packets in
> state NEW. Thus packet is dropped.
> 
> Peter.
> 

Re: Problems with OUTPUT rules ESTABLISHED,RELATED

[Peter Volkov Alexandrovich]

Hi, again.

On Втр, 2005-08-02 at 15:58 -0500, John Lange wrote:
> Perhaps you can help clarify this for me?

Perhaps. :) But be aware that I'm not a TCP guru. ;)

May be somebody from netfilter mailing list point us to the right
documentation. The general question is at which points of the packet
traversal diagram the connection tracking code changes its state? Or in
which chain/tables syn,ack packet is the part of ESTABLISHED connection?

> According to http://www.knowplace.org/netfilter/ip_overview.html , the
> handshake procedure is as follows:
> 
> 1. (B) --> [SYN] --> (A)
> 2. (B) <-- [SYN/ACK] <--(A)
> 3. (B) --> [ACK] --> (A)
> 
> I read it as meaning that up until the end of step 2 the connection
> would be NEW. At the end of Step 2 and beyond the connection would be
> ESTABLISHED.
> 
> A packet with just the "ACK" flag set can only be part of an established
> connection. quote "The important thing to note here is that after the
> three-way handshake is completed, and the connection is complete, every
> packet that is part of this TCP connection will always have the ACK bit
> set."
> 
> So, my understanding is the only way a packet could be generated with
> the ACK flag set and the SRC as my server's IP is as part of an
> established connection.
> 
> If that is the case then it should not be blocked because I have an
> OUTPUT rule  which allows it.

TCP connection states are not the same as iptables connection states.
And connection tracking code think that connection is ESTABLISHED only
after step 2. But (I hope :)) packet should pass connection tracking
code BEFORE it get INPUT or OUTPUT chain and thus connection should be
at the ESTABLISHED state in this chains. Thus setting just ESTABLISHED
should be Ok.

> Where am I going wrong here?
> 
> If I do:
> 
> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
> 
> Then all outbound packets are allowed so I definitely don't want that.

I think your problem is in the following rule:

iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT

change it on

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT

Please tell me if this works for you.

Peter.

Re: Problems with OUTPUT rules ESTABLISHED,RELATED

[Jörg Harmuth]

> May be somebody from netfilter mailing list point us to the right
> documentation. The general question is at which points of the packet
> traversal diagram the connection tracking code changes its state? Or in
> which chain/tables syn,ack packet is the part of ESTABLISHED connection?

As (almost) always, I can recommend:

http://iptables-tutorial.frozentux.net/chunkyhtml/index.html

Recalling from my (ofcourse limited :)) memory, connections which have
seen traffic in both directions are in (iptables) state ESTABLISHED. So,
this is the case right after the SYN/ACK packet. This packet is allowed
by the original ruleset.

>>According to http://www.knowplace.org/netfilter/ip_overview.html , the
>>handshake procedure is as follows:
>>
>>1. (B) --> [SYN] --> (A)
>>2. (B) <-- [SYN/ACK] <--(A)
>>3. (B) --> [ACK] --> (A)

Correct.

>>I read it as meaning that up until the end of step 2 the connection
>>would be NEW. At the end of Step 2 and beyond the connection would be
>>ESTABLISHED.

See above.

>>A packet with just the "ACK" flag set can only be part of an established
>>connection. quote "The important thing to note here is that after the
>>three-way handshake is completed, and the connection is complete, every
>>packet that is part of this TCP connection will always have the ACK bit
>>set."

Except for some RST packets.

>>So, my understanding is the only way a packet could be generated with
>>the ACK flag set and the SRC as my server's IP is as part of an
>>established connection.

I agree.

>>If that is the case then it should not be blocked because I have an
>>OUTPUT rule  which allows it.

Not in this case. According to the discussion above and your rules, we
have the following situation:

1.) SYN packet arrives at your box. Because of "--syn --dport 80"
    this is allowed.
2.) Your box answers with a SYN/ACK packet, which is also allowed.
    => "--state ESTABLISHED,RELATED". State changes to ESTABLISHED.
3.) The other box sends the 3rd packet of the handshake => ACK. This
    packet gets dropped, because there is no rule in INPUR that
    permits ESTABLISHED packets. At this point the connection is
    basically dropped.

You should be able to see this, when you tcpdump on the respective
interface, eth0 in this case. Solution: Add the following rule.

iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

BTW, these rules are recommended too:

iptables -I INPUT -i lo -j ACCEPT
iptables -I OUTPUT -o lo -j ACCEPT

> 
> TCP connection states are not the same as iptables connection states.
> And connection tracking code think that connection is ESTABLISHED only
> after step 2. But (I hope :)) packet should pass connection tracking
> code BEFORE it get INPUT or OUTPUT chain and thus connection should be
> at the ESTABLISHED state in this chains. Thus setting just ESTABLISHED
> should be Ok.

You only need RELATED for FTP and the like.

> 
>>Where am I going wrong here?
>>
>>If I do:
>>
>>iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>>
>>Then all outbound packets are allowed so I definitely don't want that.

I'm no friend of general OUTPUT filtering (OUTPUT policy == DROP), it
makes things more complicated than necessary and provides little or no
security. There are good reasons to have single DROP rules in OUTPUT,
but this is discussed on this list often. So, it's up to you, but I
can't recommend it.

> 
> I think your problem is in the following rule:
> 
> iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT
> 
> change it on
> 
> iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT

No, this is no problem, IMO "--syn" is the better way. Only having
"--state NEW" allows alway the first packet of a connection to pass,
even if this is a ACK packet or the like (nmap comes to mind). However,
"--syn" requires the SYN bit to be set and this is only the case for a
NEW connection (see RFC 793 for details).

Briefly, the following rules should get you starting:

iptables -P INPUT DROP
## I don't like - up to you.
iptables -P OUTPUT DROP
## You want this :)
iptables -P FORWARD DROP

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED \
   -j ACCEPT
iptables -A INPUT -p tcp --dport 80 --syn -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED \
   -j ACCEPT

Be aware, that this only permits HTTP. If e.g. your web server likes to
lookup the hostnames of each connection, you must permit outgoing DNS
(and the reverse path) too, and so on. If I may express a wish, please
make sure that ICMP 3 and 11 can pass in both directions. Thanks in
advance :)

Have a nice time,

Joerg

Re: Problems with OUTPUT rules ESTABLISHED,RELATED

[John Lange]

On Wed, 2005-08-03 at 11:15 +0200, Jörg Harmuth wrote:
> 3.) The other box sends the 3rd packet of the handshake => ACK. This
>     packet gets dropped, because there is no rule in INPUR that
>     permits ESTABLISHED packets. At this point the connection is
>     basically dropped.
> 
> You should be able to see this, when you tcpdump on the respective
> interface, eth0 in this case. Solution: Add the following rule.
> 
> iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

When I initially summarized my ruleset I was mostly talking about OUTPUT
rules and so I left out the above rule. Keep in mind the packets I have
seen getting dropped are coming FROM my server so the INPUT rules should
not effect them.

> Briefly, the following rules should get you starting:
> 
> iptables -P INPUT DROP
> ## I don't like - up to you.
> iptables -P OUTPUT DROP
> ## You want this :)
> iptables -P FORWARD DROP
> 
> iptables -A INPUT -i lo -j ACCEPT
> iptables -A INPUT -m state --state ESTABLISHED,RELATED \
>    -j ACCEPT
> iptables -A INPUT -p tcp --dport 80 --syn -j ACCEPT
> 
> iptables -A OUTPUT -o lo -j ACCEPT
> iptables -A OUTPUT -m state --state ESTABLISHED,RELATED \
>    -j ACCEPT

This is basically exactly what I have which is why its still a mystery
to me why some packets are being dropped coming FROM the web server to
clients.

Regarding "OUTPUT -P DROP"; I used to believe as you do that it was
excessively complicated and not worth it but recently I've changed my
mind.

We have seen a dramatic increase in the number of exploits which target
vulnerable PHP software (mostly phpBB). This exploits invariably launch
a process which makes an outbound connection of some kind where they
receive further code or instructions.

Preventing the exploit is obviously the best thing but the second best
thing is preventing the attacker from being able to utilize it. Blocking
OUTPUT is one of the tools that helps.

Frankly, I think the Linux kernel security model is seriously broken in
this regard. Why the kernel allows any random process to take over ports
with no security check what-so-ever is beyond my understanding but that
is a topic for another list...

See my posting on the linux kernel list here:

http://www.ussg.iu.edu/hypermail/linux/kernel/0310.0/0224.html


-- 
John Lange