Theoretical question: need for filter table in the POSTROUTING chain

Theoretical question: need for filter table in the POSTROUTING chain

[Gáspár Lajos]

Hi all,

I am facing an interesting problem.
I would like to filter some destination IP-s both on the FORWARD and the 
OUTPUT chains... (For example to stop requests to private IP 
destinations leave our system.)
I would like to use the REJECT target...
It would be nince if there would be a filter table in the POSTROUTING 
chain...

What do you think?

Thanx:

Swifty

Re: Theoretical question: need for filter table in the POSTROUTING chain

[Grant Taylor]

On 08/25/11 06:40, Gáspár Lajos wrote:
> I would like to filter some destination IP-s both on the FORWARD and the
> OUTPUT chains... (For example to stop requests to private IP
> destinations leave our system.)
> I would like to use the REJECT target...
> It would be nince if there would be a filter table in the POSTROUTING
> chain...
>
> What do you think?

How about putting a reject route in the kernel routing table?

That will very easily prevent the packets from leaving your system.

Further, I think the kernel will (by default) send an ICMP packet 
indicating that there is no route.

IPTables is great, but sometimes it's better to use a different technology.



Grant. . . .


P.S.  Here's a series of commands that I run on my systems.

route add -net 0.0.0.0 netmask 255.0.0.0 reject
route add -net 10.0.0.0 netmask 255.0.0.0 reject
route add -net 169.254.0.0 netmask 255.255.0.0 reject
route add -net 172.16.0.0 netmask 255.240.0.0 reject
route add -net 192.0.2.0 netmask 255.255.255.0 reject
route add -net 192.168.0.0 netmask 255.255.0.0 reject
route add -net 198.51.100.0 netmask 255.255.255.0 reject
route add -net 203.0.113.0 netmask 255.255.255.0 reject

Re: Theoretical question: need for filter table in the POSTROUTING chain

[Gáspár Lajos]

> How about putting a reject route in the kernel routing table?
Yeah.. that is an alternative...
But:
  - I want to REJECT any tcp sessions with tcp-reset,
  - and any other protocoll with icmp-admin-prohibited.
  - I would like to do it in iptables/netfilter.

The main question is: Why do not we have such a table in the POSTROUTING 
chain?
>
> That will very easily prevent the packets from leaving your system.
>
> Further, I think the kernel will (by default) send an ICMP packet 
> indicating that there is no route.
As I know this is true...
>
> IPTables is great, but sometimes it's better to use a different 
> technology.
>
>
>
> Grant. . . .
>
>
> P.S.  Here's a series of commands that I run on my systems.
>
> route add -net 0.0.0.0 netmask 255.0.0.0 reject
> route add -net 10.0.0.0 netmask 255.0.0.0 reject
> route add -net 169.254.0.0 netmask 255.255.0.0 reject
> route add -net 172.16.0.0 netmask 255.240.0.0 reject
> route add -net 192.0.2.0 netmask 255.255.255.0 reject
> route add -net 192.168.0.0 netmask 255.255.0.0 reject
> route add -net 198.51.100.0 netmask 255.255.255.0 reject
> route add -net 203.0.113.0 netmask 255.255.255.0 reject
>
I have similar rules in my iptables firewall script. And you can put the 
rules above in a table with the "ip route add table..." thing. And after 
that you can "call" them with "ip rule ..." rules.

Thanx for your reply! :D


Swifty

Re: Theoretical question: need for filter table in the POSTROUTING chain

[Jan Engelhardt]

On Thursday 2011-08-25 17:30, Gáspár Lajos wrote:

>
>> How about putting a reject route in the kernel routing table?
> Yeah.. that is an alternative...
> But:
> - I want to REJECT any tcp sessions with tcp-reset,
> - and any other protocoll with icmp-admin-prohibited.
> - I would like to do it in iptables/netfilter.
>
> The main question is: Why do not we have such a table in the POSTROUTING chain?

If they did not go through nat, the packet's computed state was most 
likely INVALID or UNTRACKED to begin with. And that you can already 
filter for in FORWARD.

Re: Theoretical question: need for filter table in the POSTROUTING chain

[Gáspár Lajos]

Hi,

2011-08-26 09:56 keltezéssel, Jan Engelhardt írta:
>>
>>> How about putting a reject route in the kernel routing table?
>> Yeah.. that is an alternative...
>> But:
>> - I want to REJECT any tcp sessions with tcp-reset,
>> - and any other protocoll with icmp-admin-prohibited.
>> - I would like to do it in iptables/netfilter.
>>
>> The main question is: Why do not we have such a table in the POSTROUTING chain?
> If they did not go through nat, the packet's computed state was most
> likely INVALID or UNTRACKED to begin with. And that you can already
> filter for in FORWARD.
I do not get it...
If a packet comes from the network then it is either goes to FORWARD or 
to INPUT...  (You can forget INPUT for now.) And there we have nat...
If a packet comes from the local computer then it leaves out on the 
OUTPUT chain... And there we have nat again...
So every packet should be tracked at the POSTROUTING chain...

Yes, I can filter at the FORWARD and the OUTPUT chain... But why can't I 
at the POSTROUTING???
I do not seek alternatives... (I found them... :D) I want to know why it 
is not "enabled" ???

Thanx

Swifty

Re: Theoretical question: need for filter table in the POSTROUTING chain

[Jan Engelhardt]

On Friday 2011-08-26 11:13, Gáspár Lajos wrote:
>>>
>>> The main question is: Why do not we have such a table in the POSTROUTING
>>> chain?
>>
>>If they did not go through nat, the packet's computed state was most
>>likely INVALID or UNTRACKED to begin with. And that you can already
>>filter for in FORWARD.
>
>I do not get it... If a packet comes from the network then it is
>either goes [...] to FORWARD And there we have nat... If a packet
>comes from the local computer then it leaves out on the OUTPUT
>chain... And there we have nat again... So every packet should be
>tracked at the POSTROUTING chain...

Not every packet is tracked (cf. INVALID/UNTRACKED as I said above).

>Yes, I can filter at the FORWARD and the OUTPUT chain... But why
>can't I at the POSTROUTING??? I do not seek alternatives... (I found
>them... :D) I want to know why it is not "enabled" ???

Nobody needed it so far, because people can filter in FORWARD, and
active hooks have an associated runtime cost.

RE: Theoretical question: need for filter table in the POSTROUTING chain

[Christian Benvenuti (benve)]

> -----Original Message-----
> From: netfilter-owner@vger.kernel.org [mailto:netfilter-
> owner@vger.kernel.org] On Behalf Of Gáspár Lajos
> Sent: Friday, August 26, 2011 2:13 AM
> To: Jan Engelhardt
> Cc: netfilter list
> Subject: Re: Theoretical question: need for filter table in the
> POSTROUTING chain
> 
> Hi,
> 
> 2011-08-26 09:56 keltezéssel, Jan Engelhardt írta:
> >>
> >>> How about putting a reject route in the kernel routing table?
> >> Yeah.. that is an alternative...
> >> But:
> >> - I want to REJECT any tcp sessions with tcp-reset,
> >> - and any other protocoll with icmp-admin-prohibited.
> >> - I would like to do it in iptables/netfilter.
> >>
> >> The main question is: Why do not we have such a table in the
> POSTROUTING chain?
> > If they did not go through nat, the packet's computed state was most
> > likely INVALID or UNTRACKED to begin with. And that you can already
> > filter for in FORWARD.
> I do not get it...
> If a packet comes from the network then it is either goes to FORWARD or
> to INPUT...  (You can forget INPUT for now.) And there we have nat...
> If a packet comes from the local computer then it leaves out on the
> OUTPUT chain... And there we have nat again...
> So every packet should be tracked at the POSTROUTING chain...
> 
> Yes, I can filter at the FORWARD and the OUTPUT chain... But why can't
> I
> at the POSTROUTING???

By adding filtering support to the POSTROUTING hook you only get one
benefit:

  Rules that apply to both locally generated traffic (OUTPUT)
  and forwarded traffic (FORWARD) do not need to be duplicated.

Right? You do not get any other benefit. In some cases this may
help to simplify the configuration, I agree.
However, _usually_, you have distinct sets of rules for locally
generated traffic and forwarded traffic, the overlapping is not
that much. On top of that:

- By adding one extra check (ie filter table) where you do
  not need it (POSTROUTING) - because you can achieve the
  same result by using another hook - you would waste CPU cycles.

- Since we are talking about filtering (not NAT), if you apply
  filtering earlier in the data path (ie OUTPUT/FORWARD instead
  of POSTROUTING) you save again some CPU cycles.

Anyway, adding such support is simple (if patching iptables
and the kernel is an option you can consider). It is just matter
of telling netfilter (and iptables) to use the filter table
_also_ for the POSTROUTING hook (recompile, etc).

/Chris

> I do not seek alternatives... (I found them... :D) I want to know why
> it is not "enabled" ???
> Thanx
> 
> Swifty
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Theoretical question: need for filter table in the POSTROUTING chain

[Jan Engelhardt]

On Friday 2011-08-26 23:16, Christian Benvenuti (benve) wrote:
>> 
>> Yes, I can filter at the FORWARD and the OUTPUT chain... But why can't
>> I
>> at the POSTROUTING???
>
>By adding filtering support to the POSTROUTING hook you only get one
>benefit:
>
>  Rules that apply to both locally generated traffic (OUTPUT)
>  and forwarded traffic (FORWARD) do not need to be duplicated.
>
>Right?

Yeah, and the rule duplication can be solved by jumping to a 
shared user-defined chain from both OUTPUT and FORWARD.