All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@lists.netfilter.org>
Subject: Re: Filtering in PREROUTING
Date: Wed, 17 Jan 2007 20:01:58 -0600	[thread overview]
Message-ID: <45AED516.30800@riverviewtech.net> (raw)
In-Reply-To: <web-4020726@bk3.webmaillogin.com>

On 01/17/07 16:17, Jorge Davila wrote:
> Why filter in the mangle table? Internet is wild land. There are many 
> circunstances: an web browser generating anormal traffic because some 
> security hole in the web browser has been sucessfully exploited. A host 
> taken or contamined by a virus. In that circunstances, the tcp/ip 
> traffice generated can have "illegal" headers or the traffice can be an 
> attack to some other device in our networks or to a device in remote 
> network.

You should really do your filtering in the filter table.  If you are 
worried about a compromised host sending malicious / malformed traffic 
out, you should filter in the filter table OUTPUT chain.  For forwarded 
traffic, use the filter table FORWARD chain.

As we know, not all packets traverse the nat table thus we can not 
reliably filter any and all packets there.

Likewise, the mangle table is used for special purposes in the Linux 
kernel, namely to mangle or alter a packet in some way, say change the 
ToS / DifServ fields.

There is also the fact that a kernel may not even have the mangle table 
loaded in to the kernel.

You may know that you have filtered traffic in the mangle table, but 
what about the guy / gal that replaces you when you are hit by a 
Greyhound Buss?  Will they know that you were / are filtering in the 
mangle table?

I think that some of the filtering match extensions will only work in 
the filter table, thus you could not use them in the mangle table.

> Inspecting the packets headers in the mangle table and dropping the 
> anormal traffic must be another mechanic for the "sanity" of the 
> protected networks.

What can you do in mangle that you can not do in filter as far as 
filtering traffic goes?

> I hope that my few paragraphs gives you some help to understand why 
> filter in the mangle table. Of course, you must decide in what chain 
> inside the mangle put your rules to protect your networks.

There are ways that work and then there are the proper ways to do 
things.  I can format an entire raw disk drive.  However, if any one 
else works on the system and sees that there is not a partition table 
they may assume that it is ok to use the disk.  Or, I could make a MD 
device out of an entire disk, but the Linux kernel would not know that 
the disk is a RAID AutoDetect drive b/c there is no partition table 
there to tell it such.

Some times there are reasons to do non standard things for very special 
reasons, usually very stringent performance reasons.  If you are wanting 
to filter in the mangle table to prevent the connection tracking system 
from seeing traffic (if even that will do so), you should consider the 
raw table, which is used specifically to tell the kernel not to track 
specific packets.  Oh, by the way, the raw table only has PREROUTING and 
OUTPUT chains.



Grant. . . .


  reply	other threads:[~2007-01-18  2:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-17 21:38 Filtering in PREROUTING george
2007-01-17 22:17 ` Jorge Davila
2007-01-18  2:01   ` Grant Taylor [this message]
2007-01-18  8:42     ` Alexandru Dragoi
2007-01-19 17:34       ` R. DuFresne
2007-01-18  8:46     ` george
2007-01-19 17:25     ` R. DuFresne
2007-01-18  4:44 ` p0f patch Tim Heagarty
2007-01-19 19:23   ` Tim Heagarty
2007-01-20  2:23     ` Michael Rash
2007-01-18 10:52 ` Filtering in PREROUTING Georgi Alexandrov
2007-01-19 10:19   ` george
2007-01-19 11:32     ` Pascal Hambourg
2007-01-18 14:25 ` Grant Taylor
2007-01-19 13:17   ` george
2007-01-18 14:57 ` Filtering in PREROUTING --- Some random thoughts / points Grant Taylor
2007-01-19 17:54   ` R. DuFresne
2007-01-18 19:19 ` Filtering in PREROUTING Pascal Hambourg
2007-01-19 13:17   ` george
2007-01-19 15:51     ` Grant Taylor

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=45AED516.30800@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --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 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.