Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Antony Stone <Antony@Soft-Solutions.co.uk>
To: Netfilter <netfilter@lists.netfilter.org>
Subject: Re: Leaking ICMP and UDP packets
Date: Tue, 20 Apr 2004 19:37:20 +0100	[thread overview]
Message-ID: <200404201937.20176.Antony@Soft-Solutions.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.44.0404201059380.9758-100000@dudester.spoontail.com>

On Tuesday 20 April 2004 7:06 pm, Daniel David Benson wrote:

> Ok, so if I understand correctly, the 10.101.10.103 host is trying to
> respond to this windows box -- it only knows the default gateway to get to
> that 169 address.

Yes, and the default gateway (your firewall) only knows its external interface 
to send out packets which don't belong to the internal LAN/s.

>  It doesn't NAT because it doesn't have a corresponding
> "initiated" NAT entry?  I guess I'm confused as to why it doesn't match
> the global NAT entry -- I suspect it's my lack of understanding of how NAT
> is implemented.

Hm, actually, yes, you have a point there - you do have a generic SNAT rule 
which should apply to any packets leaving the external interface.   I don't 
have an answer for that one right now.

>  In the end, I should be blocking these 169 requests in
> the FORWARD table anyway.

Yes, that would be a good plan.

> Is it common practice to set the NAT chains default policies to DROP?

NO!!!!   *Never* set a nat table (or a mangle table) to have any default 
policy other than ACCEPT.

Think really *really* hard before using a rule with a DROP target in the nat 
or mangle tables (it can be valid sometimes, but make sure know what it will 
do before you use it).

>  I guess, I'd like to know the best way to stop these bad boys from getting
> out to be a good netizen.

Well, I wouldn't worry about it too much - an upstream ISP will drop them soon 
enough with that destination address.

If you do want to drop them yourself, however, start with the addresses listed 
in http://www.rfc-editor.org/rfc/rfc3330.txt and block anything entering or 
leaving your network with a source or destination address in these ranges.

Regards,

Antony.

-- 
"The future is already here.   It's just not evenly distributed yet."

 - William Gibson

                                                     Please reply to the list;
                                                           please don't CC me.



      reply	other threads:[~2004-04-20 18:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-19 16:17 Leaking ICMP and UDP packets Daniel David Benson
2004-04-19 16:31 ` Frank Gruellich
2004-04-19 16:54   ` Daniel David Benson
2004-04-19 17:08     ` Daniel David Benson
2004-04-19 17:45 ` Antony Stone
2004-04-20 17:13   ` Daniel David Benson
2004-04-20 17:46     ` Antony Stone
2004-04-20 18:06       ` Daniel David Benson
2004-04-20 18:37         ` Antony Stone [this message]

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=200404201937.20176.Antony@Soft-Solutions.co.uk \
    --to=antony@soft-solutions.co.uk \
    --cc=netfilter@lists.netfilter.org \
    /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