All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Tonner <Alistair@nerdnet.ca>
To: "Robert P. J. Day" <rpjday@mindspring.com>,
	iptables mailing list <netfilter@lists.netfilter.org>
Subject: Re: efficient source address filtering and logging?
Date: Tue, 28 Oct 2003 10:30:18 -0500	[thread overview]
Message-ID: <200310281030.19103.Alistair@nerdnet.ca> (raw)
In-Reply-To: <Pine.LNX.4.44.0310280949080.22878-100000@localhost.localdomain>

On October 28, 2003 09:59 am, Robert P. J. Day wrote:
>   i'd like to find a short, efficient way to filter incoming packets with
> bogus source addresses, but i don't see an elegant way of doing it.
>
>   as we all know, there are a number of clearly bogus source addresses on
> incoming packets:
>
>   - broadcast
>   - your own IP address
>   - any of the private class A, B or C addresses
>   - class D addresses
>
> and on and on.  so it's natural to want to discard them and, just for fun,
> log them as well.
>
>   for elegance, i can create a user-defined chain called, say,
> "reject_bad_source_addresses" to which i jump with every incoming packet.
> this user-defined chain will test for all of the bad source addresses, one
> at a time, and DROP/REJECT each one.  however, if i want to log all of
> these rejections, i'd have to double the number of rules in this chain,
> so that each test would first LOG that packet, then be followed by a
> second rule to DROP it.  kind of a pain.

	Why don't you have the first user chain test for bad addresses, send them to 
a second chain, which the logs all traffic going through it, and then drops 
all traffic going through it?

>
>   if i could rewrite the rules all backwards, i could have the
> user-defined chain full of ACCEPT rules, and only terminate the chain with
> a rule for LOG, followed by one for DROP.  but i don't see how that's
> possible.
>
>   so, is there a solution i'm missing that's clean, elegant and short?
>
> rday

-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of magic.
	Lets get magical!


  parent reply	other threads:[~2003-10-28 15:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-28 14:59 efficient source address filtering and logging? Robert P. J. Day
2003-10-28 15:26 ` James Pattie
2003-10-28 15:32   ` Robert P. J. Day
2003-10-28 15:30 ` Alistair Tonner [this message]
2003-10-28 15:33   ` Robert P. J. Day
2003-10-28 16:26 ` Chris Brenton
2003-11-02 10:29   ` Re[2]: " Peteris Krumins
2003-11-02 11:45     ` Chris Brenton
2003-11-02 13:35       ` Alistair Tonner
2003-11-02 13:48       ` Alistair Tonner
2003-11-04  3:55         ` Tarek W.
     [not found] <20031028165927.11207.15406.Mailman@netfilter-sponsored-by.noris.net>
2003-10-28 17:25 ` Earl A.Killian

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=200310281030.19103.Alistair@nerdnet.ca \
    --to=alistair@nerdnet.ca \
    --cc=netfilter@lists.netfilter.org \
    --cc=rpjday@mindspring.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.