Re: IPChains rules

[Tobias Diedrich <ranma@example.com>]

Stephen J. Turnbull wrote:

> >>>>> "Tobias" == Tobias Diedrich <ranma@example.com> writes:
>
>     Tobias> AFAIK No. At least not the "Allow only known existing
>     Tobias> incoming connections" part. You need to know the State of
>     Tobias> the Connection for that.
>
> Ah, OK.  You _can_ ignore connection attempts on TCP ports, I thought
> that was what you meant.

Now I'm not sure what you mean with that ^^;;

> It's not clear what the benefit of this is to me yet; I guess you can
> use it to block garbage at the router?  Or is it just more efficient
> to drop the packets on the floor early rather than drop them on the
> floor because the listener never sees a SYN?

As far as I understand it there are the following points about the
statefullness (aka connection tracking):
1. You need it for masquerading special modules (i.e. transparent ftp
masquerading)
2. It helps to keep your rules simple (You don't need an extra rule for
each port in the INPUT table)
3. A statefull packet filter can detect stealth port scans (i.e. port
scans from source port 80 without SYN flag set)

>     Tobias> Works for ping, traceroute,
>
> Wrong.  Ping is ICMP, traceroute is UDP.  No state ... sorry.

Well it's true that these are "stateless" connections, but the packet
filter treats them as statefull connections anyway, which is possible and
works quite good.
I think it's explained in some README somewhere...

For example, a ICMP-ECHO-REQUEST packet from lan to outside will be
allowed with my rules because all traffic from the lan to the outside is
allowed. The packet filter then assigns a state of "NEW" to this
"connection" from my system to the destination system. It will recognize
the corresponding ICMP-ECHO-REPLY packet from that host and set the state
to ESTABLISHED and will let this packet through (with my rules that is)
and after that the connection is finished. A second ICMP-ECHO-REPLY packet
would not be let through because I have not sent a ICMP-ECHO-REQUEST
packet first.

I'm pretty sure that traceroute is ICMP too btw.

IIRC it does not work for UDP connections (dns) because the packet filter
does not know that "protocol" (That's why I have two rules for
UDP-Replies)

> If RELATED means what I think it does, it's just a guess.  It could be
> (easily) spoofed; (conventional) ping and traceroute packets don't
> contain any information that would help you to verify this status.

RELATED would be an ftp-data connection to an ftp connection for example.
Other RELATED packets are ICMP error packets (i.e. icmp-host-unreachable)

From the iptables manpage:

Possible states are INVALID meaning that packet is associated with no
known connection, ESTABLISHED meaning that the packet is associated with a
connection which has seen packets in both directions, NEW meaning that the
packet has started a new connection, or otherwise  associated with a
connection which has not seen packets in both directions, and RELATED
meaning that the packet is starting a new connection, but is associated
with an existing connection, such as an FTP data transfer, or an ICMP
error.

> I wonder how much checking is done on ESTABLISHED, for that matter.
> Is it just a dynamic firewall that automatically opens an incoming
> window to the local source port when you make an outgoing connection?
> Or does it verify TCP serial numbers and (maybe) high-level protocol?
> Seems unlikely....

It's the latter ^__^
You have high level protocol modules (with conntrack_ftp being included
in the kernel)
And connection tracking for TCP and ICMP connections (conntrack) which
does verify TCP serial numbers, source host and port and such.

Really neat stuff ^_^

>     Tobias> http, ftp.
>
> Or is FTP's "two-circuit" protocol what is meant by "RELATED"?

Exactly

-- Tobias