Re: iptables leaking blocked ip addresses.

["terry l. ridder" <artisticforge@gmail.com>]

hello;

reply below.

On 6/20/05, Sven-Haegar Koch <haegar@sdinet.de> wrote:
> On Mon, 20 Jun 2005, terry l. ridder wrote:
> 
> > On 6/20/05, Sven-Haegar Koch <haegar@sdinet.de> wrote:
> >> On Mon, 20 Jun 2005, terry l. ridder wrote:
> >>
> >>>>> one example of the leak is below:
> >>>>>
> >>>>> 200.0.0.0/8 is dropped if the destination port is 25 (smtp).
> >>>>
> >>>> iptables-save(8) output, please. What you posted here doesn't tell us
> >>>> much.
> >>>>
> >>>
> >>> while i have reservations concerning posting the output of iptables-save
> >>> i have placed it on my web server:
> >>>
> >>> http://204.238.34.206/iptables-save-20jun2005.txt
> >>
> >> You are filtering in the nat table.
> >>
> >
> > yes, i am.
> >
> >> The nat table gets only the first packet from each connection (the one
> >> that would match -m state --state NEW).
> >>
> >
> > that is incorrect. the nat table is getting all packets.
> 
> no, it's not.
>

no, that is incorrect.

> 
> please have a look at "man iptables":
> 
>      nat:
>            This  table  is  consulted  when a packet that creates a new
>            connection is encountered.  It consists of three  built-ins:
>            PREROUTING  (for  altering packets as soon as they come in),
>            OUTPUT (for altering locally-generated packets before  rout-
>            ing),  and  POSTROUTING  (for  altering  packets as they are
>            about to go out).
>

there is no connection, netfilter or tcp.
any packets from 200.0.0.0/8 with destination port 25 (smtp) are
dropped, end of story. they are being dropped in nat prerouting.
they are not source nat'ed or destination nat'ed, they are dropped.
there is no connection, netfilter or tcp, ever established.

> 
> Note the "is consulted when a packet that creates a new connection is
> encountered" - once for every new connection, not for all following
> packets.
> 

again there is no connection. they are dropped before any connection,
netfilter or tcp, can be established.

> 
> >> A retransmit from the blocked IP will not be a new connection,
> >> so it will pass through your rules.
> >
> > again this is incorrect.
> 

see above, your logic is flawed.

> 
> no - once a connection entry in /proc/net/ip_conntrack is created, a
> restransmit will match this entry even if it's a tcp-syn again.
> 
> netfilter-connections are different from tcp connections.
> 

it does not matter whether they are different or the same. there
is no connection, netfilter or tcp. the packets are being dropped in
nat prerouting before any type of connection can be established.

> 
> >> And on your comment to another mail that you are not using connection
> >> tracking:
> >> This is wrong. If you have the nat table, you must have ip_conntrack
> >> loaded - and if its loaded it tracks your connections, even if you
> >> dont use -m state at all. There is no iptables nat without connection
> >> tracking.
> >
> > i may have been looking at the wrong window, i will check on that.
> 
> thr textfile referenced your other mail contains IP_NF_CONNTRACK=m for
> your firewall - connection-tracking is at least built.
> 
> And if you load the nat support (aka iptable_nat module) the ip_conntrack
> module will be loaded, too.
> 

yes it it. so what?

from the firewall box:
Module                  Size  Used by
ipt_LOG                 7008    1 
af_packet              21316  0 
ipt_limit                 2848    3 
iptable_nat            27780  1 
ip_conntrack         46928  1 iptable_nat
iptable_filter          3264    1 
ip_tables               17712  4 ipt_LOG,ipt_limit,iptable_nat,iptable_filter

<snip>

i said i looked at the wrong window and i corrected that mistake.

> 
> c'ya
> sven
> 

-- 
terry l. ridder ><>