* input filter
@ 2005-01-04 22:35 Bhasker Allam
2005-01-05 15:48 ` Jason Opperisano
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Bhasker Allam @ 2005-01-04 22:35 UTC (permalink / raw)
To: netfilter
Hi,
I am a newbie and I was reading the howto for packet
filter. The howto has the following picture:
Incoming / \ Outgoing
-->[Routing ]--->|FORWARD|------->
[Decision] \_____/ ^
| |
v ____
___ / \
/ \ |OUTPUT|
|INPUT| \____/
\___/ ^
| |
----> Local Process ----
The input filtering is done only for local bound
packets and after the routing decision. Is the above
true ? Is there a facility to perform input filtering
before the routing decision ? Thanks.
Bhasker.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: input filter
2005-01-04 22:35 input filter Bhasker Allam
@ 2005-01-05 15:48 ` Jason Opperisano
2005-01-05 17:06 ` Sky
2005-01-05 17:17 ` Georgi Alexandrov
2 siblings, 0 replies; 6+ messages in thread
From: Jason Opperisano @ 2005-01-05 15:48 UTC (permalink / raw)
To: netfilter
On Tue, Jan 04, 2005 at 02:35:20PM -0800, Bhasker Allam wrote:
> Hi,
> I am a newbie and I was reading the howto for packet
> filter. The howto has the following picture:
>
> Incoming / \ Outgoing
> -->[Routing ]--->|FORWARD|------->
> [Decision] \_____/ ^
> | |
> v ____
> ___ / \
> / \ |OUTPUT|
> |INPUT| \____/
> \___/ ^
> | |
> ----> Local Process ----
>
> The input filtering is done only for local bound
> packets and after the routing decision. Is the above
> true ?
yes.
> Is there a facility to perform input filtering
> before the routing decision ? Thanks.
yes: -t mangle PREROUTING
-j
--
"Look, just give me some inner peace, or I'll mop the floor with ya!"
--The Simpsons
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: input filter
2005-01-04 22:35 input filter Bhasker Allam
2005-01-05 15:48 ` Jason Opperisano
@ 2005-01-05 17:06 ` Sky
2005-01-05 17:17 ` Georgi Alexandrov
2 siblings, 0 replies; 6+ messages in thread
From: Sky @ 2005-01-05 17:06 UTC (permalink / raw)
To: Bhasker Allam; +Cc: netfilter
Bhasker Allam wrote:
> Hi,
> I am a newbie and I was reading the howto for packet
> filter. The howto has the following picture:
>
> Incoming / \ Outgoing
> -->[Routing ]--->|FORWARD|------->
> [Decision] \_____/ ^
> | |
> v ____
> ___ / \
> / \ |OUTPUT|
> |INPUT| \____/
> \___/ ^
> | |
> ----> Local Process ----
>
> The input filtering is done only for local bound
> packets and after the routing decision. Is the above
> true ?
Yes, done for only for packets which are not forward (so
packets which are for you).
>Is there a facility to perform input filtering
> before the routing decision ? Thanks.
>
> Bhasker.
Of course, see NAT, mangling, masquerading.
(http://iptables-tutorial.frozentux.net/ is good.)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: input filter
2005-01-04 22:35 input filter Bhasker Allam
2005-01-05 15:48 ` Jason Opperisano
2005-01-05 17:06 ` Sky
@ 2005-01-05 17:17 ` Georgi Alexandrov
2005-01-05 22:30 ` Bhasker Allam
2 siblings, 1 reply; 6+ messages in thread
From: Georgi Alexandrov @ 2005-01-05 17:17 UTC (permalink / raw)
To: netfilter; +Cc: allambhasker
Bhasker Allam wrote:
>Hi,
>I am a newbie and I was reading the howto for packet
>filter. The howto has the following picture:
>
>Incoming / \ Outgoing
> -->[Routing ]--->|FORWARD|------->
> [Decision] \_____/ ^
> | |
> v ____
> ___ / \
> / \ |OUTPUT|
> |INPUT| \____/
> \___/ ^
> | |
> ----> Local Process ----
>
>The input filtering is done only for local bound
>packets and after the routing decision. Is the above
>true ?
>
yes.
>Is there a facility to perform input filtering
>before the routing decision ? Thanks.
>
>
>
How come you know if it is INPUT or FORWARD before the routing decision ?
Won't the "routing decision" decide if the packet(s) will be destined
for INPUT (to the local machine) or FORWARD (for the machines behind
you/gw/fw).
The two chains and tables that are hit by incoming packets before the
routing decision are:
1. table mangle, chain PREROUTING (from the iptables-tutorial: "This
chain is normally used for mangling packets, i.e., changing TOS and so on.")
then:
2: table nat, chain PREROUTING (from the iptables-tutorial: "This chain
is used for DNAT mainly. Avoid filtering in this chain since it will be
bypassed in certain cases.")
If you explain better your situation i'm sure we'll find reasonable
solution for your filtering needs ;-)
>Bhasker.
>
>
>
Georgi Alexandrov.
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: input filter
2005-01-05 17:17 ` Georgi Alexandrov
@ 2005-01-05 22:30 ` Bhasker Allam
2005-01-06 16:08 ` Jason Opperisano
0 siblings, 1 reply; 6+ messages in thread
From: Bhasker Allam @ 2005-01-05 22:30 UTC (permalink / raw)
To: Georgi Alexandrov, netfilter; +Cc: allambhasker
There are a few situations that I can think of:
- A spurious host/hosts sending garbage packets. If I
know either source IP/subnet or mac address I can put
in a filter and drop all the packets from spurious
souces with minimal effort. Why should I spend cycles
doing the route lookup ?
- I could do policy based routing. That is, I want
packets from interface X or subnet S to go out on
interface Y all the rest go via the normal routing
path. From what I read this is not possible now.
- If I use my linux box a router I could have policies
on different interface to do different things. For
example, I might not want packets arriving from
certain sources to reach certain destinations. It does
not matter whether I am forwarding or not. You could
say I could put that in the output filter, but my
argument why should I have go through route lookup if
I don't have to ?
Hope these requirements make sense to you. As I said
earlier, I am a newbie to linux networking. Pardon me
if there are other ways of doing the above using
netfilter.
bhasker.
--- Georgi Alexandrov <tehlists@hotpop.com> wrote:
> Bhasker Allam wrote:
>
> >Hi,
> >I am a newbie and I was reading the howto for
> packet
> >filter. The howto has the following picture:
> >
> >Incoming / \ Outgoing
> > -->[Routing ]--->|FORWARD|------->
> > [Decision] \_____/ ^
> > | |
> > v ____
> > ___ / \
> > / \ |OUTPUT|
> > |INPUT| \____/
> > \___/ ^
> > | |
> > ----> Local Process ----
> >
> >The input filtering is done only for local bound
> >packets and after the routing decision. Is the
> above
> >true ?
> >
> yes.
>
> >Is there a facility to perform input filtering
> >before the routing decision ? Thanks.
> >
> >
> >
> How come you know if it is INPUT or FORWARD before
> the routing decision ?
> Won't the "routing decision" decide if the packet(s)
> will be destined
> for INPUT (to the local machine) or FORWARD (for the
> machines behind
> you/gw/fw).
>
> The two chains and tables that are hit by incoming
> packets before the
> routing decision are:
> 1. table mangle, chain PREROUTING (from the
> iptables-tutorial: "This
> chain is normally used for mangling packets, i.e.,
> changing TOS and so on.")
> then:
> 2: table nat, chain PREROUTING (from the
> iptables-tutorial: "This chain
> is used for DNAT mainly. Avoid filtering in this
> chain since it will be
> bypassed in certain cases.")
>
> If you explain better your situation i'm sure we'll
> find reasonable
> solution for your filtering needs ;-)
>
> >Bhasker.
> >
> >
> >
> Georgi Alexandrov.
>
> >__________________________________________________
> >Do You Yahoo!?
> >Tired of spam? Yahoo! Mail has the best spam
> protection around
> >http://mail.yahoo.com
> >
> >
> >
> >
>
>
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: input filter
2005-01-05 22:30 ` Bhasker Allam
@ 2005-01-06 16:08 ` Jason Opperisano
0 siblings, 0 replies; 6+ messages in thread
From: Jason Opperisano @ 2005-01-06 16:08 UTC (permalink / raw)
To: netfilter
On Wed, Jan 05, 2005 at 02:30:43PM -0800, Bhasker Allam wrote:
> There are a few situations that I can think of:
>
> - A spurious host/hosts sending garbage packets. If I
> know either source IP/subnet or mac address I can put
> in a filter and drop all the packets from spurious
> souces with minimal effort. Why should I spend cycles
> doing the route lookup ?
-t mangle PREROUTING is an acceptable place to do "first things first"
filtering/packet scrubbing. it's where i do things like anti-spoofing
rules and invalid TCP flag combo rules.
> - I could do policy based routing. That is, I want
> packets from interface X or subnet S to go out on
> interface Y all the rest go via the normal routing
> path. From what I read this is not possible now.
whatcha been reading? it's certainly possible:
http://lartc.org/howto/lartc.rpdb.html
> - If I use my linux box a router I could have policies
> on different interface to do different things. For
> example, I might not want packets arriving from
> certain sources to reach certain destinations. It does
> not matter whether I am forwarding or not. You could
> say I could put that in the output filter, but my
> argument why should I have go through route lookup if
> I don't have to ?
you're starting to toe the line as to what should go in your normal
filter rules here--but that's just IMHO.
-j
--
"Beer. Now there's a temporary solution."
--The Simpsons
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-01-06 16:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-04 22:35 input filter Bhasker Allam
2005-01-05 15:48 ` Jason Opperisano
2005-01-05 17:06 ` Sky
2005-01-05 17:17 ` Georgi Alexandrov
2005-01-05 22:30 ` Bhasker Allam
2005-01-06 16:08 ` Jason Opperisano
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.