iptables leaking blocked ip addresses.

iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

i have recently noticed that iptables is leaking blocked ip addresses into
the local network.

one example of the leak is below:

200.0.0.0/8 is dropped if the destination port is 25 (smtp).
the large majority of the packets are dropped but a random few are leaking
pass iptables.
404 19712 DROP       tcp  --  eth2   *       200.0.0.0/8         
0.0.0.0/0           tcp dpt:25
143   6992 DROP       tcp  --  eth2   *       201.0.0.0/8         
0.0.0.0/0           tcp dpt:25

at the 2nd lines of defenses the following is seen:

date and time is utc.

2005-06-18 08:20:38.310864 IP 200.221.11.147.29937 >
204.238.34.206.25: R 0:0(0) win 0
2005-06-18 08:35:33.035504 IP 200.221.11.147.9618 > 204.238.34.206.25:
R 3184482893:3184482893(0) win 64240
2005-06-18 09:12:47.772699 IP 200.221.11.147.37399 >
204.238.34.206.25: R 0:0(0) win 0
2005-06-18 10:15:29.731794 IP 200.221.11.147.37803 >
204.238.34.206.25: R 3790354139:3790354139(0) win 64240
2005-06-18 12:28:47.356603 IP 200.221.11.147.37540 >
204.238.34.206.25: R 3124247582:3124247582(0) win 64240
2005-06-18 14:42:14.852914 IP 200.221.11.147.59505 >
204.238.34.206.25: R 2944314039:2944314039(0) win 64240
2005-06-18 16:56:23.417184 IP 200.221.11.147.51204 >
204.238.34.206.25: R 3050896753:3050896753(0) win 64240
2005-06-18 19:09:00.235525 IP 200.221.11.147.14427 >
204.238.34.206.25: R 2304489220:2304489220(0) win 64240
2005-06-18 21:22:08.824748 IP 200.221.11.147.54471 >
204.238.34.206.25: R 2920726621:2920726621(0) win 64240
2005-06-18 23:35:36.046110 IP 200.221.11.147.27797 >
204.238.34.206.25: R 0:0(0) win 0
2005-06-19 01:49:10.050142 IP 200.221.11.147.29328 >
204.238.34.206.25: R 0:0(0) win 0
2005-06-19 04:01:59.082248 IP 200.221.11.147.23754 >
204.238.34.206.25: R 0:0(0) win 0
2005-06-19 06:15:32.815212 IP 200.221.11.147.46328 >
204.238.34.206.25: R 1445346336:1445346336(0) win 64240

computers are all running debian sarge with kernel 2.6.11.10 and iptables
version iptables v1.2.11.

i also have a short web page concerning the iptables leaks at:
http://204.238.34.206/iptables-leaks.txt

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[Jan Engelhardt]

>at the 2nd lines of defenses the following is seen:
>
>date and time is utc.
>
>2005-06-18 08:20:38.310864 IP 200.221.11.147.29937 >
>204.238.34.206.25: R 0:0(0) win 0

This looks to me like tcpdump output. As far as I understand, the "listener" 
(used by iptraf, tcpdump, etc.) listens before iptables does it works, so you 
always see packets. - even those which are to be DROPed.

Take a client connected to eth2 and listen on the eth2 bus. There should not 
be anything.

>2005-06-18 08:35:33.035504 IP 200.221.11.147.9618 > 204.238.34.206.25:
>R 3184482893:3184482893(0) win 64240
>2005-06-18 09:12:47.772699 IP 200.221.11.147.37399 >
>204.238.34.206.25: R 0:0(0) win 0


Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: iptables leaking blocked ip addresses.

[/dev/rob0]

On Monday 20 June 2005 10:34, terry l. ridder wrote:
> i have recently noticed that iptables is leaking blocked ip addresses
> into the local network.
>
> 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.

> the large majority of the packets are dropped but a random few are
> leaking pass iptables.
> 404 19712 DROP       tcp  --  eth2   *       200.0.0.0/8
> 0.0.0.0/0           tcp dpt:25
> 143   6992 DROP       tcp  --  eth2   *       201.0.0.0/8
> 0.0.0.0/0           tcp dpt:25

Put a logging rule here to prove it:
iptables -vA $CHAIN -s 200.0.0.0/7 -j LOG --log-prefix "LACNIC-leak: "

> at the 2nd lines of defenses the following is seen:
>
> date and time is utc.
>
> 2005-06-18 08:20:38.310864 IP 200.221.11.147.29937 >
> 204.238.34.206.25: R 0:0(0) win 0

What is this output?

> i also have a short web page concerning the iptables leaks at:
> http://204.238.34.206/iptables-leaks.txt

Still not clear to me.

I do see that you've disabled CONFIG_IP_NF_CONNTRACK, which is a very 
odd choice. Connection tracking is the strength of iptables!
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: iptables leaking blocked ip addresses.

[/dev/rob0]

On Monday 20 June 2005 10:55, I wrote:
> Put a logging rule here to prove it:
> iptables -vA $CHAIN -s 200.0.0.0/7 -j LOG --log-prefix "LACNIC-leak:

This should also specify "-p tcp --dport 25" of course.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

reply below.

On 6/20/05, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> 
> >at the 2nd lines of defenses the following is seen:
> >
> >date and time is utc.
> >
> >2005-06-18 08:20:38.310864 IP 200.221.11.147.29937 >
> >204.238.34.206.25: R 0:0(0) win 0
> 
> This looks to me like tcpdump output. As far as I understand, the "listener"
> (used by iptraf, tcpdump, etc.) listens before iptables does it works, so you
> always see packets. - even those which are to be DROPed.
>

the tcpdump capture is on the mail server, 204.238.34.206 and *_not_* on
the firewall, 204.238.34.232.

> 
> Take a client connected to eth2 and listen on the eth2 bus. There should not
> be anything.
>

the tcpdump output is on the mail server, 204.238.34.206.
those packets are being seen on the internal network.
i agree there should not be any 200.0.0.0/8 packets on the internal network
but there are. therefore, iptables is leaking.

> 
> >2005-06-18 08:35:33.035504 IP 200.221.11.147.9618 > 204.238.34.206.25:
> >R 3184482893:3184482893(0) win 64240
> >2005-06-18 09:12:47.772699 IP 200.221.11.147.37399 >
> >204.238.34.206.25: R 0:0(0) win 0
> 
> 
> Jan Engelhardt
>

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello

reply below.

On 6/20/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> On Monday 20 June 2005 10:34, terry l. ridder wrote:
> > i have recently noticed that iptables is leaking blocked ip addresses
> > into the local network.
> >
> > 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

> 
> > the large majority of the packets are dropped but a random few are
> > leaking pass iptables.
> > 404 19712 DROP       tcp  --  eth2   *       200.0.0.0/8
> > 0.0.0.0/0           tcp dpt:25
> > 143   6992 DROP       tcp  --  eth2   *       201.0.0.0/8
> > 0.0.0.0/0           tcp dpt:25
> 
> Put a logging rule here to prove it:
> iptables -vA $CHAIN -s 200.0.0.0/7 -j LOG --log-prefix "LACNIC-leak: "
> 
> > at the 2nd lines of defenses the following is seen:
> >
> > date and time is utc.
> >
> > 2005-06-18 08:20:38.310864 IP 200.221.11.147.29937 >
> > 204.238.34.206.25: R 0:0(0) win 0
> 
> What is this output?
>

tcpdump -tttt -n -r /home/mail/tcpdump-20-jun-2005-00 | grep -e 'IP
200' | less -S

> 
> > i also have a short web page concerning the iptables leaks at:
> > http://204.238.34.206/iptables-leaks.txt
> 
> Still not clear to me.
>

what part is not clear? i will attempt to clarify.

> 
> I do see that you've disabled CONFIG_IP_NF_CONNTRACK, which is a very
> odd choice. Connection tracking is the strength of iptables!
>

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[/dev/rob0]

On Monday 20 June 2005 11:17, terry l. ridder wrote:
> 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

Yikes, this is very long. First, I see that you're doing all your 
filtering in nat, PREROUTING and POSTROUTING. Why? I prefer to do 
filtering in the filter table as $DEITY intended. :)

Second, I think you would benefit from reading the HOWTOs (again?). I 
would also strongly suggest enabling and using connection tracking.

I have no idea what you will get with all this filtering in the nat 
table. It is giving me a headache to try to figure it out! In fact I 
hereby give up.

There are many premade iptables scripts which can produce good, safe 
firewalls, but they will only work on kernels with standard netfilter 
options enabled. For me the netfilter section of kernel configuration 
is very simple. I modularise every available option!

My suggestion to you, then, is to remake your kernel (or maybe just 
modules) and get a more standard firewall. Then add your rules as 
desired.

The particular task you are trying to accomplish here appears to be 
related to spam control. Blocking off huge portions of the Internet 
indeed can reduce your spam. But please consider that the USA is far 
and away the world's largest spam source.

I prefer to do spam control in the MTA. I'm fairly effective there; not 
perfect but quite good nonetheless. I do no blocking of large 
netblocks, and minimal prequeue content filtering.

> > Put a logging rule here to prove it:
> > iptables -vA $CHAIN -s 200.0.0.0/7 -j LOG --log-prefix
> > "LACNIC-leak: "

Please try this, with "-p tcp --dport 25" as amended by followup. Put 
this rule in either filter/INPUT or filter/FORWARD as appropriate. It 
won't hurt anything to put it in both if you're not sure. Watch your 
appropriate kernel logs to see what hits.

> > > i also have a short web page concerning the iptables leaks at:
> > > http://204.238.34.206/iptables-leaks.txt
> >
> > Still not clear to me.
>
> what part is not clear? i will attempt to clarify.

I do not think you really understand what your NAT rules are doing. I 
sure don't.

> > I do see that you've disabled CONFIG_IP_NF_CONNTRACK, which is a
> > very odd choice. Connection tracking is the strength of iptables!
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

reply below.

On 6/20/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> On Monday 20 June 2005 11:17, terry l. ridder wrote:
> > 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
> 
> Yikes, this is very long. First, I see that you're doing all your
> filtering in nat, PREROUTING and POSTROUTING. Why?
>

because that is the way i know that works.
it has worked fine for many years. it was not until i upgraded the
firewall machine (new computer with debian sarge) that iptables
began to leak.

>
> I prefer to do filtering in the filter table as $DEITY intended. :)
> 

<major sniip>

one of the reasons for using table nat is to dnat all ip addresses with
destination port 25 (smtp) to the mail server, 204.238.34.206.

connection tracking is turned off since at one time i was
using tarpit instead of just dropping the connections.
tarpitting all of lacnic, apnic, a large portion of ripencc, and a large portion
of arin became boring. now i just drop the connections.

i have added logging on both the firewall box, 204.238.34.232, and the mail
server, 204.238.34.206. both boxes will be logging the leaks.

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[/dev/rob0]

On Monday 20 June 2005 12:20, terry l. ridder wrote:
> > Yikes, this is very long. First, I see that you're doing all your
> > filtering in nat, PREROUTING and POSTROUTING. Why?
>
> because that is the way i know that works.

Again I doubt you know exactly what it is doing. For instance in your 
lonely filter table, FORWARD rules there are 3 rules which do nothing 
at all ... ACCEPT targets, when the policy is ACCEPT. (They do packet 
counting which is limited by the "limit" module, so even the packet 
counters are meaningless.)

> it has worked fine for many years.

Luck.

> it was not until i upgraded the 
> firewall machine (new computer with debian sarge) that iptables
> began to leak.
>
> > I prefer to do filtering in the filter table as $DEITY intended. :)

For me that is more or less a matter of faith. I hope someone who knows 
more about it will come along and explain why your NAT use is poor 
design. In the meantime I bet a few external nmap's of your IP would 
give you some unpleasant surprises.

> <major sniip>
>
> one of the reasons for using table nat is to dnat all ip addresses
> with destination port 25 (smtp) to the mail server, 204.238.34.206.

I'd do that with a single DNAT rule,  have a single SNAT rule to let the 
internal mail server out, and do my filtering in filter / FORWARD. It 
also seems odd that you are using NAT at all, since the mail server 
already has a real Internet IP. I only use NAT with RFC 1918 addresses.

> connection tracking is turned off since at one time i was
> using tarpit instead of just dropping the connections.

Whatever. Without connection tracking you might as well use ipchains.

> i have added logging on both the firewall box, 204.238.34.232, and
> the mail server, 204.238.34.206. both boxes will be logging the
> leaks.

Please do followup with the results; I will be interested to see what 
packets are getting through.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: iptables leaking blocked ip addresses.

[Jan Engelhardt]

>> http://204.238.34.206/iptables-save-20jun2005.txt
>
>Yikes, this is very long. First, I see that you're doing all your 
>filtering in nat, PREROUTING and POSTROUTING. Why? I prefer to do 
>filtering in the filter table as $DEITY intended. :)

Yeah I would wonder too; esp. because they are in OUTPUT, not in 
PRE/POSTROUTING.
I'd recommend a -P DROP anyway and build up -j ACCEPTs from there.


Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: iptables leaking blocked ip addresses.

[/dev/rob0]

On Monday 20 June 2005 13:50, Jan Engelhardt wrote:
> I'd recommend a -P DROP anyway and build up -j ACCEPTs from there.

Not easy to do that without connection tracking.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: iptables leaking blocked ip addresses.

[Sven-Haegar Koch]

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.
The nat table gets only the first packet from each connection (the one 
that would match -m state --state NEW). A retransmit from the blocked IP 
will not be a new connection, so it will pass through your rules.

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.

If you must filter in PREROUTING, do it at least in PREROUTING of the
filter table.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

reply below.

On 6/20/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> On Monday 20 June 2005 12:20, terry l. ridder wrote:
> > > Yikes, this is very long. First, I see that you're doing all your
> > > filtering in nat, PREROUTING and POSTROUTING. Why?
> >
> > because that is the way i know that works.
> 
> Again I doubt you know exactly what it is doing.
>

no one can know exactly what it is doing given all the variables that
may effect what iptables is doing.  unknown bugs in the linux kernel
and/or iptables. memory hiccups. cpu hiccups. random bit flips.

having observed the behaviour of the linux kernel and iptables i
have a reasonable expectation of what they are doing.

>
> For instance in your
> lonely filter table, FORWARD rules there are 3 rules which do nothing
> at all ... ACCEPT targets, when the policy is ACCEPT. (They do packet
> counting which is limited by the "limit" module, so even the packet
> counters are meaningless.)
>
> 
> > it has worked fine for many years.
> 
> Luck.
>

there is no such thing as luck.

> 
> > it was not until i upgraded the
> > firewall machine (new computer with debian sarge) that iptables
> > began to leak.
> >
> > > I prefer to do filtering in the filter table as $DEITY intended. :)
> 
> For me that is more or less a matter of faith. I hope someone who knows
> more about it will come along and explain why your NAT use is poor
> design. In the meantime I bet a few external nmap's of your IP would
> give you some unpleasant surprises.
>

you have my permission to nmap my network, 204.238.34.0/24.
you must post the results of nmap here.

do you have anything to contribute besides sniping at the manner in
which i run and manage my network?
 
>
> > <major sniip>
> >
> > one of the reasons for using table nat is to dnat all ip addresses
> > with destination port 25 (smtp) to the mail server, 204.238.34.206.
> 
> I'd do that with a single DNAT rule,  have a single SNAT rule to let the
> internal mail server out, and do my filtering in filter / FORWARD. It
> also seems odd that you are using NAT at all, since the mail server
> already has a real Internet IP. I only use NAT with RFC 1918 addresses.
>

because the spammers, scammers, and other scum keep hammering
my network trying every address in 204.238.34.0/24 destination port 25.

> 
> > connection tracking is turned off since at one time i was
> > using tarpit instead of just dropping the connections.
> 
> Whatever. Without connection tracking you might as well use ipchains.
>

the tarpit howto does say to turn connection tracking off.

> 
> > i have added logging on both the firewall box, 204.238.34.232, and
> > the mail server, 204.238.34.206. both boxes will be logging the
> > leaks.
> 
> Please do followup with the results; I will be interested to see what
> packets are getting through.
>

i will post the results.

>

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[/dev/rob0]

On Monday 20 June 2005 14:30, Sven-Haegar Koch wrote:
> On Mon, 20 Jun 2005, terry l. ridder wrote:
> You are filtering in the nat table.
> The nat table gets only the first packet from each connection (the
> one that would match -m state --state NEW). A retransmit from the
> blocked IP will not be a new connection, so it will pass through your
> rules.
>
> 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.

TY for that. I didn't know all that, although I did suspect that NAT 
relied on ip_conntrack. "man iptables" doesn't say that directly (if 
so, I missed it), but it does imply it.
 nat:
        This table is consulted when a packet that cre­ates a new
        connection is encountered. ...

This also applies in another thread today, "Re: using NetFilter to
share the SAME SINGLE IP between a Linux router AND a computer 
simultaneously".

Anyway, what DOES happen in the case that there is no ip_conntrack? 
Would not every packet appear to the kernel as a new connection?

> If you must filter in PREROUTING, do it at least in PREROUTING of the
> filter table.

Alas, there is no such chain (built-in.) :)
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: iptables leaking blocked ip addresses.

[/dev/rob0]

On Monday 20 June 2005 14:36, terry l. ridder wrote:
> > > > I prefer to do filtering in the filter table as $DEITY
> > > > intended. :)
> >
> > For me that is more or less a matter of faith. I hope someone who
> > knows more about it will come along and explain why your NAT use is
> > poor design.

(Sven did this, thanks again, Sven.)

> do you have anything to contribute besides sniping at the manner in
> which i run and manage my network?

I do apologise for the tone which came across. I understand and
validate your feelings: I definitely could have worded it better. But
in fact I do believe I offered some useful suggestions; do with them 
what you will.

> > > connection tracking is turned off since at one time i was
> > > using tarpit instead of just dropping the connections.
> >
> > Whatever. Without connection tracking you might as well use
> > ipchains.
>
> the tarpit howto does say to turn connection tracking off.

Ah, I did not know this. TY for the information. But that itself brings 
the whole tarpitting concept into question, in my mind. Anything which 
throws away the main benefit of iptables can't be worth the trouble.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

reply below.

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.

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

again this is incorrect.

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

> 
> If you must filter in PREROUTING, do it at least in PREROUTING of the
> filter table.
>

why?

> 
> c'ya
> sven
> 


-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

reply below.

On 6/20/05, Sven-Haegar Koch <haegar@sdinet.de> wrote:

<snip>

> 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 have checked and i was looking at the wrong window when i copied the
.config. i have corrected that mistake.

please refer to http://204.238.34.206/iptables-leaks.txt

>
> c'ya
> sven
> 

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

reply below.

On 6/20/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> On Monday 20 June 2005 12:20, terry l. ridder wrote:

<snip>

> 
> In the meantime I bet a few external nmap's of your IP would
> give you some unpleasant surprises.
>

you lose the bet.
since you did not have the courage to post the results of an nmap of my
network, i will.

please see http://uuoc.com/?id=953 for the results of an external nmap
of my network, 204.238.34.0/24.

<snip>

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[Sven-Haegar Koch]

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.

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

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

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

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.

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

Look at the module-dependencies in your /lib/modules/`uname 
-r`/modules.deb, mine says:

/lib/modules/2.6.10-ac10-aurora/kernel/net/ipv4/netfilter/iptable_nat.ko: 
/lib/modules/2.6.10-ac10-aurora/kernel/net/ipv4/netfilter/ip_conntrack.ko 
/lib/modules/2.6.10-ac10-aurora/kernel/net/ipv4/netfilter/ip_tables.ko

meaning that to load iptable_nat.ko the modules ip_conntrack.ko und 
ip_tables.ko need to be loaded.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

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

Re: iptables leaking blocked ip addresses.

[Alistair Tonner]

On June 20, 2005 11:34 am, terry l. ridder wrote:
> hello;
>
> i have recently noticed that iptables is leaking blocked ip addresses into
> the local network.
>
> one example of the leak is below:
>
> 200.0.0.0/8 is dropped if the destination port is 25 (smtp).
> the large majority of the packets are dropped but a random few are leaking
> pass iptables.
> 404 19712 DROP       tcp  --  eth2   *       200.0.0.0/8
> 0.0.0.0/0           tcp dpt:25
> 143   6992 DROP       tcp  --  eth2   *       201.0.0.0/8
> 0.0.0.0/0           tcp dpt:25
>
> at the 2nd lines of defenses the following is seen:
>
> date and time is utc.
>
> 2005-06-18 08:20:38.310864 IP 200.221.11.147.29937 >
> 204.238.34.206.25: R 0:0(0) win 0
> 2005-06-18 08:35:33.035504 IP 200.221.11.147.9618 > 204.238.34.206.25:
> R 3184482893:3184482893(0) win 64240
> 2005-06-18 09:12:47.772699 IP 200.221.11.147.37399 >
> 204.238.34.206.25: R 0:0(0) win 0
> 2005-06-18 10:15:29.731794 IP 200.221.11.147.37803 >
> 204.238.34.206.25: R 3790354139:3790354139(0) win 64240
> 2005-06-18 12:28:47.356603 IP 200.221.11.147.37540 >
> 204.238.34.206.25: R 3124247582:3124247582(0) win 64240
> 2005-06-18 14:42:14.852914 IP 200.221.11.147.59505 >
> 204.238.34.206.25: R 2944314039:2944314039(0) win 64240
> 2005-06-18 16:56:23.417184 IP 200.221.11.147.51204 >
> 204.238.34.206.25: R 3050896753:3050896753(0) win 64240
> 2005-06-18 19:09:00.235525 IP 200.221.11.147.14427 >
> 204.238.34.206.25: R 2304489220:2304489220(0) win 64240
> 2005-06-18 21:22:08.824748 IP 200.221.11.147.54471 >
> 204.238.34.206.25: R 2920726621:2920726621(0) win 64240
> 2005-06-18 23:35:36.046110 IP 200.221.11.147.27797 >
> 204.238.34.206.25: R 0:0(0) win 0
> 2005-06-19 01:49:10.050142 IP 200.221.11.147.29328 >
> 204.238.34.206.25: R 0:0(0) win 0
> 2005-06-19 04:01:59.082248 IP 200.221.11.147.23754 >
> 204.238.34.206.25: R 0:0(0) win 0
> 2005-06-19 06:15:32.815212 IP 200.221.11.147.46328 >
> 204.238.34.206.25: R 1445346336:1445346336(0) win 64240
>
> computers are all running debian sarge with kernel 2.6.11.10 and iptables
> version iptables v1.2.11.
>
> i also have a short web page concerning the iptables leaks at:
> http://204.238.34.206/iptables-leaks.txt


	I hope that what I saw was the corrected configuration:

	given that, I have to agree that your filtering method is slightly odd, 
however I can follow that it will work -- somewhat.
	In my diagrams, and understanding these packets are FORWARD packets, thus 
your iptables flow is as follows:
1) mangle PREROUTING
2) nat PREROUTING (where you have a lot of drops done)
3) mangle FORWARD
4) filter FORWARD (keep this fella in mind.....)
5) mangle POSTROUTING
6) nat POSTROUTING (where you appear to be dropping a lot of outbound stuff)

	The tcpdump didn't have a lot of detail to my eye... since you filter 
200.x.x.x 255.0.0.0. could these packets have an illegal netmask on them?
	you have a couple of ACCEPT rules in FORWARD -- I'm not 100% certain but I 
suspect that those ACCEPTS could shortcut NAT Postrouting -- but don't take 
it as bible.

	Those are just a couple of thoughts on what might be happening in there.. I'm 
not sure what changed on debian in that upgrade, but folks on their mailing 
lists would have a better clue.  I'm a gentoo/slackware/*cough*RH*cough* 
user .. and HP-UX and Solaris -- but thats work and no fun on an off night.


	Alistair.

	

Re: iptables leaking blocked ip addresses.

[Jozsef Kadlecsik]

On Mon, 20 Jun 2005, terry l. ridder wrote:

> 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

Thou salt not filter in the nat table.

It's in the documentation and was also countless times were written to the
list: only the first packet of every connection traverses the nat table.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

reply below.

On 6/21/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> On Mon, 20 Jun 2005, terry l. ridder wrote:
> 
> > 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
> 
> Thou salt not filter in the nat table.
>

there is no good reason not to filter in the nat table.
 
>
> It's in the documentation and was also countless times were written to the
> list: only the first packet of every connection traverses the nat table.
>

there is no connection if the packet is dropped in the nat table.

> 
> Best regards,
> Jozsef
>

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[Jozsef Kadlecsik]

On Tue, 21 Jun 2005, terry l. ridder wrote:

>
> On 6/21/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> > On Mon, 20 Jun 2005, terry l. ridder wrote:
> >
> > > 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
> >
> > Thou salt not filter in the nat table.
>
> there is no good reason not to filter in the nat table.

Your firewall setup is a perfect example why one should not filter in the
nat table.

Look at the packets which "leaked in": all of them TCP RST packets.
According to the TCP connection tracking, a RST packet which belongs to no
known connection will be marked as INVALID. Because it's a NEW INVALID
packet, connection tracking drops the conntrack reference immediately.
Consequently, as having no conntrack reference attached to the packet, the
nat table skips processing it. And because you intentionally not filter in
the filter table, the packets "leak in".

Thou salt not filter in the nat table.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello.

reply below.

On 6/21/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> On Tue, 21 Jun 2005, terry l. ridder wrote:
> 
> >
> > On 6/21/05, Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> > > On Mon, 20 Jun 2005, terry l. ridder wrote:
> > >
> > > > 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
> > >
> > > Thou salt not filter in the nat table.
> >
> > there is no good reason not to filter in the nat table.
> 
> Your firewall setup is a perfect example why one should not filter in the
> nat table.
>

my firewall has worked for many years just the way it is, never had any
problems with any leaks of any kind.

> 
> Look at the packets which "leaked in": all of them TCP RST packets.
>

yes, they are all tcp rst packets.

> 
> According to the TCP connection tracking, a RST packet which belongs to no
> known connection will be marked as INVALID. Because it's a NEW INVALID
> packet, connection tracking drops the conntrack reference immediately.
> Consequently, as having no conntrack reference attached to the packet, the
> nat table skips processing it. And because you intentionally not filter in
> the filter table, the packets "leak in".
>

there is not connection to track.

all packets from 200.0.0.0/8 with destination port 25 (smtp) are
dropped. the only addresses leaking in are the 200.0.0.0/8 with
destination port 25 (smtp). none of the other network address
blocks which are blocked are leaking.

if what you wrote above were true i should be seeing more tcp rst
packets from blocked network address blocks leaking in. i am not.
therefore, what you wrote above is not true.

> 
> Thou salt not filter in the nat table.
>

will you please stop with the 'party line'.

> 
> Best regards,
> Jozsef
>

-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[Feizhou]

> I do see that you've disabled CONFIG_IP_NF_CONNTRACK, which is a very 
> odd choice. Connection tracking is the strength of iptables!

You mean weakness.

netfilter's conntrack module sucks in performance and at the same time 
is not fully stateful.

If I wanted a stateful firewall, I would go for a OpenBSD solution.

For filtering to host, netfilter is ok without connection tracking.

Re: iptables leaking blocked ip addresses.

[Jozsef Kadlecsik]

On Tue, 21 Jun 2005, Feizhou wrote:

>
> > I do see that you've disabled CONFIG_IP_NF_CONNTRACK, which is a very
> > odd choice. Connection tracking is the strength of iptables!
>
> You mean weakness.
>
> netfilter's conntrack module sucks in performance and at the same time
> is not fully stateful.

Could you please back your claims with data (performance) and examples
(not fully stateful)?

About netfilter performance *data* you can read
http://people.netfilter.org/kadlec/nftest.pdf.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: iptables leaking blocked ip addresses.

[/dev/rob0]

On Monday 20 June 2005 15:47, terry l. ridder wrote:
> > In the meantime I bet a few external nmap's of your IP would
> > give you some unpleasant surprises.
>
> you lose the bet.
> since you did not have the courage to post the results of an nmap of
> my network, i will.
>
> please see http://uuoc.com/?id=953 for the results of an external
> nmap of my network, 204.238.34.0/24.

Lack of courage, lack of interest, lack of will to be your unpaid 
security analyst, whatever. It's remarkable that you found that nmap 
acceptable, neither unpleasant nor surprising.

You certainly have won your arguments! People point to specific 
documented examples of why you're wrong, and you insist otherwise. 
Indeed I am convinced: writing to you is a waste of my time. Your 
arguments have been very persuasive in that regard.

For those who are playing along at home: I hope you looked at the 
poster's nmap results. It's a good example of a bad firewall. Here's 
one of mine:

(The 1654 ports scanned but not shown below are in state: filtered)
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
53/tcp  open  domain
80/tcp  open  http
113/tcp open  auth

And the iptables-save(8) rules that did this:

# Generated by iptables-save v1.2.8 on Mon Jun 20 23:26:37 2005
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [4102225:931569781]
:AllowFwd - [0:0]
:AllowIn - [0:0]
:Reject - [0:0]
:State - [0:0]
-A INPUT -j State
-A INPUT -j AllowIn
-A INPUT -j Reject
-A FORWARD -j State
-A FORWARD -j AllowFwd
-A FORWARD -j Reject
-A FORWARD -p tcp -j REJECT --reject-with icmp-port-unreachable
-A AllowFwd -s 192.168.6.0/255.255.255.0 -j ACCEPT
-A AllowFwd -d 192.168.6.0/255.255.255.0 -j ACCEPT
-A AllowFwd -o tun+ -j ACCEPT
-A AllowIn -p tcp -m tcp --dport 22 -j ACCEPT
-A AllowIn -p tcp -m tcp --dport 25 -j ACCEPT
-A AllowIn -p tcp -m tcp --dport 53 -j ACCEPT
-A AllowIn -p tcp -m tcp --dport 80 -j ACCEPT
-A AllowIn -p tcp -m tcp --dport 113 -j ACCEPT
-A AllowIn -p udp -m udp --dport 53 -j ACCEPT
-A AllowIn -i lo -j ACCEPT
-A AllowIn -p icmp -j ACCEPT
-A Reject -p tcp -j REJECT --reject-with icmp-port-unreachable
-A Reject -j DROP
-A State -m state --state INVALID -j DROP
-A State -m state --state RELATED,ESTABLISHED -j ACCEPT
-A State -i tun+ -j ACCEPT
COMMIT
# Completed on Mon Jun 20 23:26:37 2005
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: iptables leaking blocked ip addresses.

[Jan Engelhardt]

>> > using tarpit instead of just dropping the connections.
>> Whatever. Without connection tracking you might as well use ipchains.
>the tarpit howto does say to turn connection tracking off.

No, it does not! To quote:

  You probably don't want the conntrack module loaded while you are using
  TARPIT, or you will be using resources per connection.

Which is not the same as "does not work with conntrack".



Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: iptables leaking blocked ip addresses.

[Jozsef Kadlecsik]

On Tue, 21 Jun 2005, Jan Engelhardt wrote:

> >> > using tarpit instead of just dropping the connections.
> >> Whatever. Without connection tracking you might as well use ipchains.
> >the tarpit howto does say to turn connection tracking off.
>
> No, it does not! To quote:
>
>   You probably don't want the conntrack module loaded while you are using
>   TARPIT, or you will be using resources per connection.
>
> Which is not the same as "does not work with conntrack".

The overhead of TARPIT created in conntrack can completely be avoided by
using NOTRACK and TARPIT targets together.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: iptables leaking blocked ip addresses.

[Jan Engelhardt]

>The overhead of TARPIT created in conntrack can completely be avoided by
>using NOTRACK and TARPIT targets together.

Probably, but it does not belong to the topic ("leaking blocked ip addr.s").

On the NOTRACK, I've got a question, or maybe just a weird problem:
NOTRACK is only valid in the mangle table, and TARPIT is one of the last rules 
in my filter:INPUT set.

So it looks to me like I would need to copy all filter:INPUT rules that -j 
ACCEPT into mangle:INPUT - because a plain -j NOTRACK would disable tracking 
everything, and I can't just do -p tcp --dport 25 -j NOTRACK, because it's a 
lot more than just dport 25.


Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: iptables leaking blocked ip addresses.

[Jozsef Kadlecsik]

On Tue, 21 Jun 2005, Jan Engelhardt wrote:

>
> >The overhead of TARPIT created in conntrack can completely be avoided by
> >using NOTRACK and TARPIT targets together.
>
> Probably, but it does not belong to the topic ("leaking blocked ip addr.s").

Yes, diverted from the original topic - I wrote it for the sake of
completeness.

> On the NOTRACK, I've got a question, or maybe just a weird problem:
> NOTRACK is only valid in the mangle table, and TARPIT is one of the last rules
> in my filter:INPUT set.
>
> So it looks to me like I would need to copy all filter:INPUT rules that -j
> ACCEPT into mangle:INPUT - because a plain -j NOTRACK would disable tracking
> everything, and I can't just do -p tcp --dport 25 -j NOTRACK, because it's a
> lot more than just dport 25.

NOTRACK is valid in the raw table alone. If you want a generic "NOTRACK
and TARPIT everything which is not allowed", then that I think won't go.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: iptables leaking blocked ip addresses.

[Cedric Blancher]

Le mardi 21 juin 2005 à 17:36 +0800, Feizhou a écrit :
> netfilter's conntrack module sucks in performance and at the same time 
> is not fully stateful.

The last serious paper I could read about performances comparison was
published on pf website long ago and desmonstrated a clear advantage for
Netfilter against pf or ipf.

	http://www.benzedrine.cx/pf-paper.html

However, at this time, Netfilter was indeed not fully stateful. But it's
no longer the case as Netfilter now implements TCP window tracking in
stock kernels.

If you know good comparisons published, I wuold be happy to read them.

> If I wanted a stateful firewall, I would go for a OpenBSD solution.

Question of feeling essentially now, and other functionnalities. For
instance, if I need hot failover, I will go to OpenBSD.


There may be other problems I'm not aware of, so please back your
affirmations if it's the case. Thx.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: iptables leaking blocked ip addresses.

[terry l. ridder]

hello;

reply below.

On 6/21/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> On Monday 20 June 2005 15:47, terry l. ridder wrote:
> > > In the meantime I bet a few external nmap's of your IP would
> > > give you some unpleasant surprises.

you made the above comment did you not?
you implied that my network was not secured.

> >
> > you lose the bet.
> > since you did not have the courage to post the results of an nmap of
> > my network, i will.
> >
> > please see http://uuoc.com/?id=953 for the results of an external
> > nmap of my network, 204.238.34.0/24.
> 
> Lack of courage, lack of interest, lack of will to be your unpaid
> security analyst, whatever. It's remarkable that you found that nmap
> acceptable, neither unpleasant nor surprising.
>

i see, yet you make unfounded statements which i quote below:

> > > In the meantime I bet a few external nmap's of your IP would
> > > give you some unpleasant surprises.

> 
> You certainly have won your arguments! People point to specific
> documented examples of why you're wrong, and you insist otherwise.
> Indeed I am convinced: writing to you is a waste of my time. Your
> arguments have been very persuasive in that regard.
> 

you should really read the Iptables Tutorial 1.1.19 written by
Oskar Andreasson located at
http://iptables-tutorial.frozentux.net/iptables-tutorial.html

since you may not read it, i will quote a few  parts.

<begin quote>
6.2. Tables

The nat table is used mainly for Network Address Translation. "NAT"ed
packets get
their IP addresses altered, according to our rules. Packets in a stream only 
traverse this table once. We assume that the first packet of a stream
is allowed.
The rest of the packets in the same stream are automatically "NAT"ed or 
Masqueraded etc, and will be subject to the same actions as the first packet. 
These will, in other words, not go through this table again, but will
nevertheless be
treated like the first packet in the stream.
<end quote>

did you catch that last sentence? since the the first packet in the stream is
dropped the rest of the packets in the same stream are also dropped.

<begin quote>
This is the main reason why you should not do any filtering in this
table, which we
will discuss at greater length further on. The PREROUTING chain is
used to alter
packets as soon as they get in to the firewall. The OUTPUT chain is used for 
altering locally generated packets (i.e., on the firewall) before they
get to the
routing decision. Finally we have the POSTROUTING chain which is used to alter 
packets just as they are about to leave the firewall.
<end quote>

7.2.10. PREROUTING chain of the nat table

The PREROUTING chain should not be used for any filtering since, among
other things, this chain is only traversed by the first packet in a
stream. The PREROUTING chain should be used for network address
translation only, unless you really know what you are doing.


-- 
terry l. ridder ><>

Re: iptables leaking blocked ip addresses.

[Joakim Axelsson]

2005-06-21 09:36:34-0500, "terry l. ridder" <artisticforge@gmail.com> ->
> hello;
> 
> reply below.
> 
> On 6/21/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> > On Monday 20 June 2005 15:47, terry l. ridder wrote:
> > > > In the meantime I bet a few external nmap's of your IP would
> > > > give you some unpleasant surprises.
> 
> you made the above comment did you not?
> you implied that my network was not secured.
> 
> > >
> > > you lose the bet.
> > > since you did not have the courage to post the results of an nmap of
> > > my network, i will.
> > >
> > > please see http://uuoc.com/?id=953 for the results of an external
> > > nmap of my network, 204.238.34.0/24.
> > 
> > Lack of courage, lack of interest, lack of will to be your unpaid
> > security analyst, whatever. It's remarkable that you found that nmap
> > acceptable, neither unpleasant nor surprising.
> >
> 
> i see, yet you make unfounded statements which i quote below:
> 
> > > > In the meantime I bet a few external nmap's of your IP would
> > > > give you some unpleasant surprises.
> 
> > 
> > You certainly have won your arguments! People point to specific
> > documented examples of why you're wrong, and you insist otherwise.
> > Indeed I am convinced: writing to you is a waste of my time. Your
> > arguments have been very persuasive in that regard.
> > 
> 
> you should really read the Iptables Tutorial 1.1.19 written by
> Oskar Andreasson located at
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html
> 
> since you may not read it, i will quote a few  parts.
> 
> <begin quote>
> 6.2. Tables
> 
> The nat table is used mainly for Network Address Translation. "NAT"ed
> packets get
> their IP addresses altered, according to our rules. Packets in a stream only 
> traverse this table once. We assume that the first packet of a stream
> is allowed.
> The rest of the packets in the same stream are automatically "NAT"ed or 
> Masqueraded etc, and will be subject to the same actions as the first packet. 
> These will, in other words, not go through this table again, but will
> nevertheless be
> treated like the first packet in the stream.
> <end quote>
> 
> did you catch that last sentence? since the the first packet in the stream is
> dropped the rest of the packets in the same stream are also dropped.
> 
> <begin quote>
> This is the main reason why you should not do any filtering in this
> table, which we
> will discuss at greater length further on. The PREROUTING chain is
> used to alter
> packets as soon as they get in to the firewall. The OUTPUT chain is used for 
> altering locally generated packets (i.e., on the firewall) before they
> get to the
> routing decision. Finally we have the POSTROUTING chain which is used to alter 
> packets just as they are about to leave the firewall.
> <end quote>
> 
> 7.2.10. PREROUTING chain of the nat table
> 
> The PREROUTING chain should not be used for any filtering since, among
> other things, this chain is only traversed by the first packet in a
> stream. The PREROUTING chain should be used for network address
> translation only, unless you really know what you are doing.
> 
> 
> -- 
> terry l. ridder ><>

I'll try to make this a gently as possible. Trying to do firewalling in' -t
nat' will _NOT_ work. Its not intended at all for firewalling. ONLY for
NATing. Thats why is it named '-t nat'.

Please understand that any documentation can be wrong or missinterpreted.
Its the actually code that will do its work despite what any docmentation
says. We as experts on iptables (netfilter) code are telling you that you
can't use iptables in the way you are trying to to build a good working
firewall.

Even if your solution has worked before or not, this is the case now and it
won't work the way you have setup your iptables. Even tho i think that you
had the very same problem with your firewall before but not noticed it.

1. Firewalling is done in 'iptables -t filter' (or just iptables)
2. Address changes (NATing) are done in 'iptables -t nat'. Only some packets
will travese this "domain".
3. Any changes to the packets are done in 'iptables -t mangle'
4. Any operations needed to be done before conntrack gets the packet is done
in 'iptables -t raw'.

Please understand, your firewall config using -n nat as a firewall is
faulty. Please do the firewalling part in '-t filter' and only the NATing
part i '-t nat'.

Conclusion: Iptables does not leak packets when used properly.

-- 
/Joakim Axelsson A.K.A Gozem@EFnet

Re: iptables leaking blocked ip addresses.

[Feizhou]

Cedric Blancher wrote:
> Le mardi 21 juin 2005 à 17:36 +0800, Feizhou a écrit :
> 
>>netfilter's conntrack module sucks in performance and at the same time 
>>is not fully stateful.
> 
> 
> The last serious paper I could read about performances comparison was
> published on pf website long ago and desmonstrated a clear advantage for
> Netfilter against pf or ipf.
> 
> 	http://www.benzedrine.cx/pf-paper.html

Yes...when NOT doing stateful. I have no arguments for netfilter's 
filtering performance. Filtering barely adds overhead for my boxes. 
Loading the conntrack module however had some painful effects...
> 
> However, at this time, Netfilter was indeed not fully stateful. But it's
> no longer the case as Netfilter now implements TCP window tracking in
> stock kernels.

Ah, sorry, I knew that this was brought up some time ago but I did not 
the end result. I take back my not fully stateful statement.
> 
> If you know good comparisons published, I wuold be happy to read them.
> 

I will try a Linux based bridge setup in place of our OpenBSD firewall 
now that we can get some equivalency in function. Or just go stateless. 
Any suggestions on what kernel version to use? A Fedora errata in case I 
install Fedora Core 3/4? Or a stock Linux kernel?

Re: iptables leaking blocked ip addresses.

[Jan Engelhardt]

>NOTRACK is valid in the raw table alone. If you want a generic "NOTRACK
>and TARPIT everything which is not allowed", then that I think won't go.

Would it work to have a -t filter-capable NOTRACK target?



Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: iptables leaking blocked ip addresses.

[Jozsef Kadlecsik]

On Tue, 21 Jun 2005, Jan Engelhardt wrote:

>
> >NOTRACK is valid in the raw table alone. If you want a generic "NOTRACK
> >and TARPIT everything which is not allowed", then that I think won't go.
>
> Would it work to have a -t filter-capable NOTRACK target?

No, that'd be too late, the packet were already be tracked by then.
Everything which is not marked by NOTRACK in the raw table, before
conntrack, will enter conntrack.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: iptables leaking blocked ip addresses.

[Jan Engelhardt]

>> >NOTRACK is valid in the raw table alone. If you want a generic "NOTRACK
>> >and TARPIT everything which is not allowed", then that I think won't go.
>>
>> Would it work to have a -t filter-capable NOTRACK target?
>
>No, that'd be too late, the packet were already be tracked by then.
>Everything which is not marked by NOTRACK in the raw table, before
>conntrack, will enter conntrack.

Would it at least be possible to make a target which drops the conntrack 
struct, so memory is freed?


Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: iptables leaking blocked ip addresses.

[Jozsef Kadlecsik]

On Wed, 22 Jun 2005, Jan Engelhardt wrote:

> >> Would it work to have a -t filter-capable NOTRACK target?
> >
> >No, that'd be too late, the packet were already be tracked by then.
> >Everything which is not marked by NOTRACK in the raw table, before
> >conntrack, will enter conntrack.
>
> Would it at least be possible to make a target which drops the conntrack
> struct, so memory is freed?

Conntrack memory is never really freed but reused from a slabcache.  (The
memory freed at module unload time).

Releasing the memory back to the slabcache from a target in the filter
table does not worth the effort: the resources to search trough conntrack
to find a matching connection, failing to find one, grabbing the memory
from the slabcache, initiating the elements are all already wasted. And
DROP in the filter table implements exactly the wanted feature ;-) by
releasing the memory back to the slabcache in the case of dropped NEW
packet.

Looking at it from the point of view of the TARPIT target, it'd also make
no use:

1. packet arrives, resources in conntrack wasted
2. new module drops conntrack entry
3. TARPIT responds to the attacker
4. goto 1.

Then better let alone the created conntrack entry and spare
grabbing/initiating new conntrack entry at every packet sent by the
tarpitted sender.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary