Filtering in PREROUTING

Filtering in PREROUTING

[george]

I've seen a few places telling me that you shouldn't filter in the
mangle table.  However, it seems sensible to me to drop junk packets in
PREROUTING rather than have to duplicate those rules in both INPUT and
FORWARD.

Having done this, I'm seeing packets dropped as invalid when I would
expect them to be OK (but most traffic is behaving as expected).  Before
I start digging into this I want to check if filtering in the mangle
table really is stupid.

Can anyone explain this to me, or point me somewhere that will tell me
please.  I haven't found anything other than a simple statement
anywhere.

Thanks,
George.

Re: Filtering in PREROUTING

[Jorge Davila]

George:

I am not an iptables expert but I will try to explain my understanding about 
filtering packets in the mangle table.

We knows that all tables have the chains PREROUTING, INPUT, OUTPUT, 
POSTROUTING, FORWARD.

We knows too that not all packets traverse all chains because that depends 
on "the path" that packet follows, in other words, we must have in mind if 
the packet if a packet locally generated (you surfing Internet in the device 
that acts as firewall) or if the packet have as final destination the 
firewall (supose that the firewall ("the gateway") is acting as a www server 
too and is receiving visits from Internet. The other thing is that packet 
must be forwarded by the device.

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.

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

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.

Best regards,

Jorge Dávila.


On Wed, 17 Jan 2007 21:38:24 +0000
  george <gk@t-t-l.co.uk> wrote:
> I've seen a few places telling me that you shouldn't filter in the
> mangle table.  However, it seems sensible to me to drop junk packets in
> PREROUTING rather than have to duplicate those rules in both INPUT and
>FORWARD.
> 
> Having done this, I'm seeing packets dropped as invalid when I would
> expect them to be OK (but most traffic is behaving as expected).  Before
> I start digging into this I want to check if filtering in the mangle
> table really is stupid.
> 
> Can anyone explain this to me, or point me somewhere that will tell me
> please.  I haven't found anything other than a simple statement
> anywhere.
> 
> Thanks,
> George.
> 
> 

Jorge Isaac Davila Lopez
Nicaragua Open Source
davila@nicaraguaopensource.com

Re: Filtering in PREROUTING

[Grant Taylor]

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

Re: Filtering in PREROUTING

[Alexandru Dragoi]

Grant Taylor wrote:
> 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. . . .
>
This works in an ideal world. But we are in internet, linux routers has 
to deal with many compromised clients that send all sort of traffic, 
including DDOS and so on. Filtering in mangle PREROUTING is the best. 
Otherwise, the bulk traffic will traverse several other chains and the 
routing table, wich consumes a lot of CPU, and many times your linux 
router will just get a bigger load instead of crashing (yea, compromised 
hosts behind you can make your machine crash, every time). If you use 
conntrack, it is even best to do the filtering in raw table in 
PREROUTING, this way your conntrack table is saved from being filled.

Re: Filtering in PREROUTING

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 18 Jan 2007, Alexandru Dragoi wrote:

>> 
>> Grant. . . .
>> 
> This works in an ideal world. But we are in internet, linux routers has to 
> deal with many compromised clients that send all sort of traffic, including 
> DDOS and so on. Filtering in mangle PREROUTING is the best. Otherwise, the 
> bulk traffic will traverse several other chains and the routing table, wich 
> consumes a lot of CPU, and many times your linux router will just get a 
> bigger load instead of crashing (yea, compromised hosts behind you can make 
> your machine crash, every time). If you use conntrack, it is even best to do 
> the filtering in raw table in PREROUTING, this way your conntrack table is 
> saved from being filled.
>

Actually, in earlier days, there was a fine way to deal with these 
matters, by *not* using a single choke point in the data stream off the 
internet connection, or for those blessed in earlier layouts and lables, a 
screening router, which was pretty much just that a small router that 
pre-filtered everything prior to it hitting the more "savvy"  and often 
complicated device labled back then "the firewall".  Course, these days, 
the lazy and cheap prefer to have the 
router-firewall-ids/ips-proxy-fax-printer-voip-kitchensink device that is 
tuned and prepped with a PHP interface with some ugly code off the 
internet shelves that will hit the security lists bi-weekly with issues in 
it's "well rounded" design forever....

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFsQEYst+vzJSwZikRAh5xAKDTU/qhcSq+H/yldZaszOtspNqhdwCfU9Z8
O9YXs0IqpCxryU8Tj5wnbGU=
=5LRB
-----END PGP SIGNATURE-----

Re: Filtering in PREROUTING

[george]

Thanks for the replies guys.

On Wed, 2007-01-17 at 20:01 -0600, Grant Taylor wrote:
> 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.

This and other comments about convention read, understood and accepted
but... I still don't know if there are technical reasons why rather than
just convention.

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

OK

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

My thinking was to have the rules in one place, PREROUTING, rather than
the same ones in both INPUT and FORWARD.  Also drop junk packets as soon
as possible as PREROUTING is the first chain traversed.

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

Thanks again,
George.

Re: Filtering in PREROUTING

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 17 Jan 2007, Grant Taylor wrote:

 	[SNIP]


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

Or, how about a shorter reply with a tiny bit of common sense;  filter 
implies seperation, thus the common sense place to "filter traffic" would 
be in the filter tables, yes?

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFsP8jst+vzJSwZikRAgATAKDLabkeh7wtKs8mYSNMzG8VrOQThgCeO9j0
76Nn0QW2R+X0mNYAHxPgTEw=
=QqWZ
-----END PGP SIGNATURE-----

p0f patch

[Tim Heagarty]

Is anybody aware of a POM for p0f? They say there is one but I can't find
it.

Thank you,

Tim Heagarty, CISSP, CISA, MCSE
http://www.TheaSecure.com/
(928) 533-9690
"There are 10 kinds of people in the world; those that understand binary,
and those that don't."

RE: p0f patch

[Tim Heagarty]

So does anybody know of a Netfilter/Iptables patch that supports the p0f log
scanning utility? The link from the p0f site to netfilter.org is broken. I'm
suspecting that the patch was never fully released or supported.



Thank you,

Tim Heagarty, CISSP, CISA, MCSE
http://www.TheaSecure.com/
(928) 533-9690
"There are 10 kinds of people in the world; those that understand binary,
and those that don't."


-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org]On Behalf Of Tim Heagarty
Sent: Wednesday, January 17, 2007 11:44 PM
To: netfilter@lists.netfilter.org
Subject: p0f patch


Is anybody aware of a POM for p0f? They say there is one but I can't find
it.

Thank you,

Tim Heagarty, CISSP, CISA, MCSE
http://www.TheaSecure.com/
(928) 533-9690
"There are 10 kinds of people in the world; those that understand binary,
and those that don't."

Re: p0f patch

[Michael Rash]

Here is a link, but I have not tried the patch:

http://svn.netfilter.org/cgi-bin/viewcvs.cgi/trunk/patch-o-matic-ng/patchlets/osf/linux-2.6/net/ipv4/netfilter/?rev=4018

If you are looking for something that is Netfilter-specific, psad
implements the p0f algorithm over Netfilter log messages (requires the
--log-tcp-options argument to iptables when creating the LOG rule):

http://www.cipherdyne.org/psad/

--
Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F



On Jan 19, 2007, Tim Heagarty wrote:

> So does anybody know of a Netfilter/Iptables patch that supports the p0f log
> scanning utility? The link from the p0f site to netfilter.org is broken. I'm
> suspecting that the patch was never fully released or supported.
> 
> 
> 
> Thank you,
> 
> Tim Heagarty, CISSP, CISA, MCSE
> http://www.TheaSecure.com/
> (928) 533-9690
> "There are 10 kinds of people in the world; those that understand binary,
> and those that don't."
> 
> 
> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org]On Behalf Of Tim Heagarty
> Sent: Wednesday, January 17, 2007 11:44 PM
> To: netfilter@lists.netfilter.org
> Subject: p0f patch
> 
> 
> Is anybody aware of a POM for p0f? They say there is one but I can't find
> it.
> 
> Thank you,
> 
> Tim Heagarty, CISSP, CISA, MCSE
> http://www.TheaSecure.com/
> (928) 533-9690
> "There are 10 kinds of people in the world; those that understand binary,
> and those that don't."
> 
> 
> 

Re: Filtering in PREROUTING

[Georgi Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

george wrote:
<snip>
> Can anyone explain this to me, or point me somewhere that will tell me
> please.  I haven't found anything other than a simple statement
> anywhere.

http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTABLES

-- 
regards,
Georgi Alexandrov

key server - pgp.mit.edu :: key id - 0x37B4B3EE
Key fingerprint = E429 BF93 FA67 44E9 B7D4  F89E F990 01C1 37B4 B3EE


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Filtering in PREROUTING

[george]

Thanks Georgi,

I don't think I'd found this before although I do recognise parts of it.

One question arises - in Ch 6 it says connection tracking (coming in)
happens between raw and mangle tables, but in Ch 7 it says it's handled
in PREROUTING.

I'm still left with the "filter in filter table is how it was designed"
but nothing deeper (to answer the "use the source" response in advance,
I certainly don't have the time and I doubt I'd manage to make enough
sense of it either).  Also, the description of the filter table also
says that you may do prior filtering ...

Cheers,
George.

> george wrote:
> <snip>
> > Can anyone explain this to me, or point me somewhere that will tell me
> > please.  I haven't found anything other than a simple statement
> > anywhere.
> 
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html#TRAVERSINGOFTABLES
> 

Re: Filtering in PREROUTING

[Pascal Hambourg]

george a écrit :
> 
> One question arises - in Ch 6 it says connection tracking (coming in)
> happens between raw and mangle tables,

Yes. Same with outgoing locally generated packets.

> but in Ch 7 it says it's handled in PREROUTING.

This is a misuse of the name PREROUTING, to make things easier to 
understand. PREROUTING is only an iptables built-in chain for some 
tables, and of course connection tracking does not occur in any iptables 
chain, as it is independent from iptables. Connection tracking of 
incoming packets is called from the NF_IP_PRE_ROUTING hook (see 
http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html), 
which is the same hook the PREROUTING chains of the various tables are 
called from.

Re: Filtering in PREROUTING

[Grant Taylor]

george wrote:
> I've seen a few places telling me that you shouldn't filter in the
> mangle table.  However, it seems sensible to me to drop junk packets in
> PREROUTING rather than have to duplicate those rules in both INPUT and
> FORWARD.

Rather than taking an absolutely closed minded approach and trying to 
convince you that I disagree and why, I'll ask this:

Are your (any one posting to this thread) statements based on things you 
your self have experienced, or been told, or seen others experience, or 
are they based on theory by the fact that you could improve efficiency 
by filtering in the very first possible place?

What sort of system(s) are you using for your firewalls / routers?
What sort of bandwidth are they filtering?
How many rules are in your rule set(s)?

I ask, because I'd like to hear constructive discussion on both sides of 
the fence.

I personally have always done my filtering in the filter table.  I can 
also say that I have never had a system even come close to weakening 
under load.  Granted most of my firewalls / routers are 233 MHz - 1 GHz 
systems (what ever is laying around) with at least a quarter gig of 
memory.  I'm also only filtering / firewalling for SOHO (DSL / Cable) or 
possibly a 10 / 100 network between subnets.  I have had one system that 
was filtering a full bleat 100 BaseT network and it never showed any 
signs of failure or even slow down.

That being said, I could see why you might want to filter in 
mangle:PREROUTING on a 486 with 16 MB RAM.

Thoughts / opinions / comments / critiques  are welcomed and encouraged.



Grant. . . .

Re: Filtering in PREROUTING

[george]

On Thu, 2007-01-18 at 08:25 -0600, Grant Taylor wrote:
> george wrote:
> > I've seen a few places telling me that you shouldn't filter in the
> > mangle table.  However, it seems sensible to me to drop junk packets in
> > PREROUTING rather than have to duplicate those rules in both INPUT and
> > FORWARD.
> 
> Rather than taking an absolutely closed minded approach and trying to 
> convince you that I disagree and why, I'll ask this:
> 
> Are your (any one posting to this thread) statements based on things you 
> your self have experienced, or been told, or seen others experience, or 
> are they based on theory by the fact that you could improve efficiency 
> by filtering in the very first possible place?

The efficiency theory.
> 
> What sort of system(s) are you using for your firewalls / routers?

It's a VIA miniITX 600M with 521M RAM but it's also my SOHO/home almost
everything except shared storage server. (Yes I know but the risk to
SOHO doesn't merit running multiple boxes).

> What sort of bandwidth are they filtering?

100M LAN with single figures boxes to 2M ADSL.#

> How many rules are in your rule set(s)?

3 in nat (really doing nat)
20 in mangle (including the arguable ones)
80 in filter

> 
> I ask, because I'd like to hear constructive discussion on both sides of 
> the fence.
> 
> I personally have always done my filtering in the filter table.  I can 
> also say that I have never had a system even come close to weakening 
> under load.  Granted most of my firewalls / routers are 233 MHz - 1 GHz 
> systems (what ever is laying around) with at least a quarter gig of 
> memory.  I'm also only filtering / firewalling for SOHO (DSL / Cable) or 
> possibly a 10 / 100 network between subnets.  I have had one system that 
> was filtering a full bleat 100 BaseT network and it never showed any 
> signs of failure or even slow down.
> 
> That being said, I could see why you might want to filter in 
> mangle:PREROUTING on a 486 with 16 MB RAM.
> 
> Thoughts / opinions / comments / critiques  are welcomed and encouraged.
> 
> 
> 
> Grant. . . .
> 
> 

Re: Filtering in PREROUTING --- Some random thoughts / points...

[Grant Taylor]

george wrote:
> I've seen a few places telling me that you shouldn't filter in the
> mangle table.  However, it seems sensible to me to drop junk packets in
> PREROUTING rather than have to duplicate those rules in both INPUT and
> FORWARD.

(Just some random thoughts / points for this discussion thread.)

  - If you put most (all) of your rules (that you can) in the 
mangle:PREROUTING chain, you will need to optimize the order of the 
rules to make sure your traffic passes through as few rules as possible.

  - In the mangle:PREROUTING chain, you can not use the -o flag to 
specify the output interface for forwarded traffic.  This means that any 
traffic that is not forwarded will still have to pass through the rules 
just for forwarded traffic.  Sure, you can add other options to the rule 
that will help decide what traffic needs to be parsed by the rule(s). 
If you use the other (what I'll call) more appropriate tables / chains 
to filter in you will have some inherent separation of which traffic 
will enter a given table / chain.

  - Locally generated packets do not traverse the mangle:PREROUTING 
chain, thus can not be filtered there.

  - You can generate a sub chain (with in a table) that can be called 
from multiple other chains.  I.e. create a small chain that filters for 
NetBEUI traffic and jump to it from filter:INPUT / filter:FORWARD / 
filter:OUTPUT.  I.e.

iptables -N Drop_NetBEUI
iptables -A Drop_NetBEUI -p tcp --sport 137 -j DROP
iptables -A Drop_NetBEUI -p udp --sport 137 -j DROP
iptables -A Drop_NetBEUI -p tcp --sport 138 -j DROP
iptables -A Drop_NetBEUI -p udp --sport 138 -j DROP
iptables -A Drop_NetBEUI -p tcp --sport 139 -j DROP
iptables -A Drop_NetBEUI -p udp --sport 139 -j DROP
iptables -A Drop_NetBEUI -p tcp --sport 445 -j DROP
iptables -A Drop_NetBEUI -p udp --sport 445 -j DROP
iptables -A Drop_NetBEUI -p tcp --dport 137 -j DROP
iptables -A Drop_NetBEUI -p udp --dport 137 -j DROP
iptables -A Drop_NetBEUI -p tcp --dport 138 -j DROP
iptables -A Drop_NetBEUI -p udp --dport 138 -j DROP
iptables -A Drop_NetBEUI -p tcp --dport 139 -j DROP
iptables -A Drop_NetBEUI -p udp --dport 139 -j DROP
iptables -A Drop_NetBEUI -p tcp --dport 445 -j DROP
iptables -A Drop_NetBEUI -p udp --dport 445 -j DROP
iptables -A Drop_NetBEUI -j RETURN

Then just jump to the chain from any where with in the filter table that 
you want to.  I.e.

iptables -A INPUT -j Drop_NetBEUI
iptables -A FORWARD -j Drop_NetBEUI
iptables -A OUTPUT -j Drop_NetBEUI



Grant. . . .

Re: Filtering in PREROUTING --- Some random thoughts / points...

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 18 Jan 2007, Grant Taylor wrote:

> george wrote:
>> I've seen a few places telling me that you shouldn't filter in the
>> mangle table.  However, it seems sensible to me to drop junk packets in
>> PREROUTING rather than have to duplicate those rules in both INPUT and
>> FORWARD.
>
> (Just some random thoughts / points for this discussion thread.)
>
> - If you put most (all) of your rules (that you can) in the 
> mangle:PREROUTING chain, you will need to optimize the order of the rules to 
> make sure your traffic passes through as few rules as possible.
>
> - In the mangle:PREROUTING chain, you can not use the -o flag to specify the 
> output interface for forwarded traffic.  This means that any traffic that is 
> not forwarded will still have to pass through the rules just for forwarded 
> traffic.  Sure, you can add other options to the rule that will help decide 
> what traffic needs to be parsed by the rule(s). If you use the other (what 
> I'll call) more appropriate tables / chains to filter in you will have some 
> inherent separation of which traffic will enter a given table / chain.
>
> - Locally generated packets do not traverse the mangle:PREROUTING chain, 
> thus can not be filtered there.
>
> - You can generate a sub chain (with in a table) that can be called from 
> multiple other chains.  I.e. create a small chain that filters for NetBEUI 
> traffic and jump to it from filter:INPUT / filter:FORWARD / filter:OUTPUT. 
> I.e.
>
> iptables -N Drop_NetBEUI
> iptables -A Drop_NetBEUI -p tcp --sport 137 -j DROP
> iptables -A Drop_NetBEUI -p udp --sport 137 -j DROP
> iptables -A Drop_NetBEUI -p tcp --sport 138 -j DROP
> iptables -A Drop_NetBEUI -p udp --sport 138 -j DROP
> iptables -A Drop_NetBEUI -p tcp --sport 139 -j DROP
> iptables -A Drop_NetBEUI -p udp --sport 139 -j DROP
> iptables -A Drop_NetBEUI -p tcp --sport 445 -j DROP
> iptables -A Drop_NetBEUI -p udp --sport 445 -j DROP
> iptables -A Drop_NetBEUI -p tcp --dport 137 -j DROP
> iptables -A Drop_NetBEUI -p udp --dport 137 -j DROP
> iptables -A Drop_NetBEUI -p tcp --dport 138 -j DROP
> iptables -A Drop_NetBEUI -p udp --dport 138 -j DROP
> iptables -A Drop_NetBEUI -p tcp --dport 139 -j DROP
> iptables -A Drop_NetBEUI -p udp --dport 139 -j DROP
> iptables -A Drop_NetBEUI -p tcp --dport 445 -j DROP
> iptables -A Drop_NetBEUI -p udp --dport 445 -j DROP
> iptables -A Drop_NetBEUI -j RETURN
>
> Then just jump to the chain from any where with in the filter table that you 
> want to.  I.e.
>
> iptables -A INPUT -j Drop_NetBEUI
> iptables -A FORWARD -j Drop_NetBEUI
> iptables -A OUTPUT -j Drop_NetBEUI
>

And again, if all the NetBEUI traffic was blocked in the screening router, 
the firewall would never see it, never have to make a decision about it, 
and it would be the same non-problem for your network, iwth likely less 
overhead and confusion on the firewall and within your rulesets...



Thanks,


Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFsQXgst+vzJSwZikRAt91AKC33W4wtN838rGWn5KS5t8yEANFqQCfYoMQ
bU6Td5OmoTCh49Y17ZAygj0=
=PES5
-----END PGP SIGNATURE-----

Re: Filtering in PREROUTING

[Pascal Hambourg]

Hello,

george a écrit :
> I've seen a few places telling me that you shouldn't filter in the
> mangle table.  However, it seems sensible to me to drop junk packets in
> PREROUTING rather than have to duplicate those rules in both INPUT and
> FORWARD.
> 
> Having done this, I'm seeing packets dropped as invalid when I would
> expect them to be OK (but most traffic is behaving as expected).  Before
> I start digging into this I want to check if filtering in the mangle
> table really is stupid.

My thoughts about filtering in PREROUTING/mangle.

Note :
Most of the following also applies to filtering in mangle/OUTPUT, 
replacing PREROUTING, INPUT and FORWARD with OUTPUT.

* Disadvantages :

- The 'mangle' table was not designed for filtering. The REJECT target 
only exists only in the 'filter' table, so it cannot be used in other 
tables to do filtering. You can only use DROP.

- As pointed out by Grant, in the case of forwarded packets the 
PREROUTING chains ignore the output interface. So any filtering rule 
relying on the output interface cannot be put in PREROUTING.

* Advantages (true or supposed) :

- Avoid duplicating rules in filter/INPUT and filter/FORWARD.
Wrong : as pointed out by Grant, you can put the common rules in 
user-defined chains called from both INPUT and FORWARD.

- Drop "junk" packets (malformed, INVALID state, invalid source or 
destination...) as soon as possible and save the CPU overhead in 
nat/PREROUTING and the routing decision. It may also save memory space 
in the routing cache.
However, packets in the INVALID state already skip the 'nat' table, and 
the routing code can drop some packets with invalid source or 
destination on its own (e.g. rp_filter).

- As Grant and Alexandru pointed out, you can go furthur and drop "junk" 
packets in the 'raw' table and save the connection tracking CPU overhead.

Alexandru wrote :
> If you use conntrack, it is even best to do the filtering in raw table
> in PREROUTING, this way your conntrack table is saved from being filled.

I do not agree : filtering in the 'raw' table would have no effect on 
the size of the connection tracking table because these packets would be 
dropped later anyway and the connection tracking entry cleared. It would 
just save some CPU. However, I agree with Grant : you can save the 
conntrack CPU overhead by using the NOTRACK target in the 'raw' table, 
which it was designed for. If an attacker wants to fill the conntrack 
table, he'd better use "regular" packets.

- When there is a DNAT rule in nat/PREROUTING redirecting packets from a 
publicly visible address to a private hidden address, you may wish to 
prevent direct access to the private address and drop such packets in 
the 'mangle' table before they reach nat/PREROUTING.
Wrong : You can achieve the same result by just marking packets in the 
mangle table and filtering them later in the 'filter' table based on the 
mark. And anyway, is it important to drop such packets, how is it a 
security issue ?

My conclusion :
Early filtering in the 'raw' or 'mangle' table may save some CPU used 
for the routing decision and the 'nat' table.
It may also save some memory space in the routing cache.
It does not save memory space in the connection tracking table.
It is not needed to save CPU for the connection tracking, use NOTRACK 
instead.
It is not needed to avoid rule duplication, use user-defined chains instead.
It does not add security, except when there would be vulnerabilities in 
the routing or connection tracking code.

Re: Filtering in PREROUTING

[george]

On Thu, 2007-01-18 at 20:19 +0100, Pascal Hambourg wrote:
> Hello,
> 
> george a écrit :
> > I've seen a few places telling me that you shouldn't filter in the
> > mangle table.  However, it seems sensible to me to drop junk packets in
> > PREROUTING rather than have to duplicate those rules in both INPUT and
> > FORWARD.
> > 
> > Having done this, I'm seeing packets dropped as invalid when I would
> > expect them to be OK (but most traffic is behaving as expected).  Before
> > I start digging into this I want to check if filtering in the mangle
> > table really is stupid.
> 
> My thoughts about filtering in PREROUTING/mangle.
> 
> Note :
> Most of the following also applies to filtering in mangle/OUTPUT, 
> replacing PREROUTING, INPUT and FORWARD with OUTPUT.
> 
> * Disadvantages :
> 
> - The 'mangle' table was not designed for filtering. The REJECT target 
> only exists only in the 'filter' table, so it cannot be used in other 
> tables to do filtering. You can only use DROP.

I only want DROP :)  The 3 classes of packets I want to drop are:
- broadcasts, mostly from Windows boxes which include Grant's netbeui
example.  These are most frequent and were the trigger for doing this.
- spoofed source address (I don't know if I really need these with
rp-filter enabled, in particular to catch private addresses if they
manage to get in from the Internet.  I may be being too paranoid here)
- some connection-oriented tests on NEW and INVALID (which is where I
started this thread from as I'm seeing packets dropped by the INVALID
check which I wouldn't expect and I wanted to find out if this could be
simply because I had the check in the wrong table)

> 
> - As pointed out by Grant, in the case of forwarded packets the 
> PREROUTING chains ignore the output interface. So any filtering rule 
> relying on the output interface cannot be put in PREROUTING.

Not relevant to me
> 
> * Advantages (true or supposed) :
> 
> - Avoid duplicating rules in filter/INPUT and filter/FORWARD.
> Wrong : as pointed out by Grant, you can put the common rules in 
> user-defined chains called from both INPUT and FORWARD.

I realise this.
> 
> - Drop "junk" packets (malformed, INVALID state, invalid source or 
> destination...) as soon as possible and save the CPU overhead in 
> nat/PREROUTING and the routing decision. It may also save memory space 
> in the routing cache.

That was my thinking.

> However, packets in the INVALID state already skip the 'nat' table, and 
> the routing code can drop some packets with invalid source or 
> destination on its own (e.g. rp_filter).
> 
> - As Grant and Alexandru pointed out, you can go furthur and drop "junk" 
> packets in the 'raw' table and save the connection tracking CPU overhead.

Can't remember if I had a reason not to do this or if I just didn't
realise.  Following my continuing education though I now know that I
couldn't filter on state in raw so I'd like to think that I found that
out before ;)
> 
> Alexandru wrote :
> > If you use conntrack, it is even best to do the filtering in raw table
> > in PREROUTING, this way your conntrack table is saved from being filled.
> 
> I do not agree : filtering in the 'raw' table would have no effect on 
> the size of the connection tracking table because these packets would be 
> dropped later anyway and the connection tracking entry cleared. It would 
> just save some CPU. However, I agree with Grant : you can save the 
> conntrack CPU overhead by using the NOTRACK target in the 'raw' table, 
> which it was designed for. If an attacker wants to fill the conntrack 
> table, he'd better use "regular" packets.
> 
> - When there is a DNAT rule in nat/PREROUTING redirecting packets from a 
> publicly visible address to a private hidden address, you may wish to 
> prevent direct access to the private address and drop such packets in 
> the 'mangle' table before they reach nat/PREROUTING.
> Wrong : You can achieve the same result by just marking packets in the 
> mangle table and filtering them later in the 'filter' table based on the 
> mark. And anyway, is it important to drop such packets, how is it a 
> security issue ?
> 
> My conclusion :
> Early filtering in the 'raw' or 'mangle' table may save some CPU used 
> for the routing decision and the 'nat' table.
> It may also save some memory space in the routing cache.
> It does not save memory space in the connection tracking table.
> It is not needed to save CPU for the connection tracking, use NOTRACK 
> instead.
> It is not needed to avoid rule duplication, use user-defined chains instead.
> It does not add security, except when there would be vulnerabilities in 
> the routing or connection tracking code.

These all look good to me.  I haven't needed NOTRACK before so I'd have
to get that bit straight in my head if I were to go that way.

I'm still not sure that I'm doing anything wrong, just unconventional.
From what I've been told via this list I'm thinking that it would be
sensible to move my broadcast dropping to raw, state checks to filter
and I don't know if I even need the spoofing checks, but if I do I
suspect raw is the place for them.

I am still slightly nervous that by going against the designers'
intentions I might end up with something breaking.  I would hope that
anything dangerous wouldn't be allowed but "of course I didn't check for
that - nobody would do that would they" is a classic reaon for software
flaws :)

Re: Filtering in PREROUTING

[Grant Taylor]

george wrote:
> - broadcasts, mostly from Windows boxes which include Grant's netbeui
> example.  These are most frequent and were the trigger for doing this.

Remember that not all NetBEUI traffic is a broadcast.  In fact, the only 
thing that is a broadcast is traffic looking for other hosts (if you are 
not using NetBIOS Name Server (a.k.a. WINS)) or messages that are meant 
to be broadcast messages to user / computers / domains, i.e. "The server 
is going down for maintenance." messages.

> - spoofed source address (I don't know if I really need these with
> rp-filter enabled, in particular to catch private addresses if they
> manage to get in from the Internet.  I may be being too paranoid here)

RP filter can detect spoofed source traffic from your internal network 
subnet, but not the internet at large.

> These all look good to me.  I haven't needed NOTRACK before so I'd have
> to get that bit straight in my head if I were to go that way.

To my knowledge, NOTRACK is really just used to tell the connection 
tracking system to not track a packet.  There is not really a lot of use 
for this in most installs.  There are only two things that come to mind 
where you would not want / need this.  1)  If you were using TARPIT and 
did not want to tie up CTState table entries.  2)  If you were doing 
some sort of really high traffic for specific services and did not want 
that service to be connection tracked.

> I'm still not sure that I'm doing anything wrong, just unconventional.

I will agree with and not argue with that statement.

> From what I've been told via this list I'm thinking that it would be
> sensible to move my broadcast dropping to raw, state checks to filter
> and I don't know if I even need the spoofing checks, but if I do I
> suspect raw is the place for them.

In accordance with your above statement, I will say that (IMHO) the 
filter table is better, but raw is not wrong.

> I am still slightly nervous that by going against the designers'
> intentions I might end up with something breaking.  I would hope that
> anything dangerous wouldn't be allowed but "of course I didn't check for
> that - nobody would do that would they" is a classic reaon for software
> flaws :)

Well I don't *think* / believe you will run in to any bugs that will 
break things short of a bug in a specific match (extension).  As I 
understand it, most pieces of NetFilter are small modules that just 
check their small data set and return a value.  IPTables it self calls 
small tests in combination with each other and deciding what to do based 
on the return value from the small tests.  Note, this is what I have 
derived being a NetFilter / IPTables user, not from a developers standpoint.



Grant. . . .



Grant. . . .