From: "terry l. ridder" <artisticforge@gmail.com>
To: /dev/rob0 <rob0@gmx.co.uk>
Cc: netfilter@lists.netfilter.org
Subject: Re: iptables leaking blocked ip addresses.
Date: Mon, 20 Jun 2005 14:36:42 -0500 [thread overview]
Message-ID: <49bf7d7050620123646910d40@mail.gmail.com> (raw)
In-Reply-To: <200506201329.19701.rob0@gmx.co.uk>
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 ><>
next prev parent reply other threads:[~2005-06-20 19:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-20 15:34 iptables leaking blocked ip addresses terry l. ridder
2005-06-20 15:48 ` Jan Engelhardt
2005-06-20 16:01 ` terry l. ridder
2005-06-20 15:55 ` /dev/rob0
2005-06-20 16:00 ` /dev/rob0
2005-06-20 16:17 ` terry l. ridder
2005-06-20 16:59 ` /dev/rob0
2005-06-20 17:20 ` terry l. ridder
2005-06-20 18:29 ` /dev/rob0
2005-06-20 19:36 ` terry l. ridder [this message]
2005-06-20 20:19 ` /dev/rob0
2005-06-21 12:57 ` Jan Engelhardt
2005-06-21 13:10 ` Jozsef Kadlecsik
2005-06-21 13:13 ` Jan Engelhardt
2005-06-21 13:39 ` Jozsef Kadlecsik
2005-06-21 18:05 ` Jan Engelhardt
2005-06-22 7:10 ` Jozsef Kadlecsik
2005-06-22 12:55 ` Jan Engelhardt
2005-06-22 13:16 ` Jozsef Kadlecsik
2005-06-20 20:47 ` terry l. ridder
2005-06-21 12:17 ` /dev/rob0
2005-06-21 14:36 ` terry l. ridder
2005-06-21 14:57 ` Joakim Axelsson
2005-06-20 18:50 ` Jan Engelhardt
2005-06-20 19:12 ` /dev/rob0
2005-06-20 19:30 ` Sven-Haegar Koch
2005-06-20 20:07 ` /dev/rob0
2005-06-20 20:23 ` terry l. ridder
2005-06-20 22:29 ` Sven-Haegar Koch
2005-06-20 23:04 ` terry l. ridder
2005-06-20 20:39 ` terry l. ridder
2005-06-21 7:11 ` Jozsef Kadlecsik
2005-06-21 7:21 ` terry l. ridder
2005-06-21 7:56 ` Jozsef Kadlecsik
2005-06-21 8:24 ` terry l. ridder
2005-06-21 9:36 ` Feizhou
2005-06-21 9:40 ` Jozsef Kadlecsik
2005-06-21 14:31 ` Cedric Blancher
2005-06-21 16:52 ` Feizhou
2005-06-21 3:24 ` Alistair Tonner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49bf7d7050620123646910d40@mail.gmail.com \
--to=artisticforge@gmail.com \
--cc=netfilter@lists.netfilter.org \
--cc=rob0@gmx.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox