[ale] iptables issue

[Jason Lunz]

jimpop at yahoo.com said:
> Jason Lunz wrote:
>> jimpop at yahoo.com said:
>>> I have an issue wrt iptables.  I use iptables to allow/deny access to a 
>>> website.  The tables are intended to allow all in to port 80 at address 
>>> WW.XX.YY.ZZ, and all replies back out from port 80 on same address.
>>>
>>> The command line used to create the rules is this:
>>>
>>> iptables -A INPUT -p tcp -d WW.XX.YY.ZZ --dport http
>>>       -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
>>> iptables -A OUTPUT -p tcp -s WW.XX.YY.ZZ --sport http
>>>       -m state --state RELATED,ESTABLISHED -j ACCEPT
>> 
>> the second rule is superfluous. It's implied by the ESTABLISHED in the
>> first rule.
>
> Are you sure of that?  Every firewall example I've ever seen shows rules 
> for both directions.

yes, I'm sure. This is what connection tracking does. The INPUT --dport
http rule allows the connection to be established; after that, it's the
kernel's job to keep track of which packets belong to the connection.

The way you ask the conntrack module whether a packet is part of an
established session is with "--state ESTABLISHED". It's intended to be
used like this:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -d WW.XX.YY.ZZ --dport http \
	-m state --state NEW -j ACCEPT

In the above configuration, ONLY packets that are part of inbound port
80 tcp connections are allowed in or out.

The alternative is not to use connection tracking; this is called
stateless firewalling. The corresponding stateless configuration is like
this:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p tcp -d WW.XX.YY.ZZ --dport http -j ACCEPT
iptables -A OUTPUT -p tcp -s WW.XX.YY.ZZ --sport http -j ACCEPT

Your example is mixing stateful and stateless firewalling, so it doesn't
really make any sense. The advantage of stateful firewalling is that
it's more precise; the disadvantage is that it's slower. But there's no
reason I can think of to do both.

> OUTPUT BLOCKED: IN= OUT=eth1 SRC=WW.XX.YY.ZZ DST=AA.BB.CC.DD LEN=255 
> TOS=0x00 PREC=0x00 TTL=64 ID=52863 DF PROTO=TCP SPT=80 DPT=4091 
> WINDOW=6432 RES=0x00 ACK PSH FIN URGP=0

This is a packet from the webserver to a client sent as part of a
connection shutdown. I'd guess it was logged because the conntrack
module already considered the connection ended, and your OUTPUT chain
abvoe only accepts packets from established connections. It's harmless;
these kinds of things can result, for example, from the conntrack code
having different connection timeouts than the actual tcp stacks
involved.

Jason