With the existence of the mangle table, how useful is the filter table?
Other than requiring the REJECT target to be ported to the mangle table, is
the filter table faster than the mangle table?
If not, then shouldn't the filter table be obsoleted to avoid confusion?
Thanks!
--
Al
Please send mails discussing netfilter to netfilter-devel.
Al Boldi wrote:
> With the existence of the mangle table, how useful is the filter table?
>
> Other than requiring the REJECT target to be ported to the mangle table, is
> the filter table faster than the mangle table?
There are some minor differences in ordering (mangle comes before
DNAT, filter afterwards), but for most rulesets thats completely
irrelevant. The only difference that really matters is that mangle
performs rerouting in LOCAL_OUT for packets that had their routing
key changed, so its really a superset of the filter table. If you
want to use REJECT in the mangle table, you just need to remove the
restriction to filter, it works fine. I would prefer to also remove
the restriction of MARK, CONNMARK etc. to mangle, they're used for
more than just routing today so that restriction also doesn't make
much sense. Patches for this are welcome.
> If not, then shouldn't the filter table be obsoleted to avoid confusion?
That would probably confuse people. Just don't use it if you don't
need to.
Patrick McHardy wrote:
> Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[email protected] is bouncing me.
> Al Boldi wrote:
> > With the existence of the mangle table, how useful is the filter table?
> >
> > Other than requiring the REJECT target to be ported to the mangle table,
> > is the filter table faster than the mangle table?
>
> There are some minor differences in ordering (mangle comes before
> DNAT, filter afterwards), but for most rulesets thats completely
> irrelevant. The only difference that really matters is that mangle
> performs rerouting in LOCAL_OUT for packets that had their routing
> key changed, so its really a superset of the filter table. If you
> want to use REJECT in the mangle table, you just need to remove the
> restriction to filter, it works fine. I would prefer to also remove
> the restriction of MARK, CONNMARK etc. to mangle, they're used for
> more than just routing today so that restriction also doesn't make
> much sense. Patches for this are welcome.
Something like this (untested):
--- ipt_REJECT.bak.c 2007-10-12 08:25:17.000000000 +0300
+++ ipt_REJECT.c 2007-10-12 08:31:44.000000000 +0300
@@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
static inline void send_unreach(struct sk_buff *skb_in, int code)
{
+ if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
}
@@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
.family = AF_INET,
.target = reject,
.targetsize = sizeof(struct ipt_reject_info),
- .table = "filter",
- .hooks = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
- (1 << NF_IP_LOCAL_OUT),
.checkentry = check,
.me = THIS_MODULE,
};
> > If not, then shouldn't the filter table be obsoleted to avoid confusion?
>
> That would probably confuse people. Just don't use it if you don't
> need to.
The problem is that people think they are safe with the filter table, when in
fact they need the prerouting chain to seal things. Right now this is only
possible in the mangle table.
Thanks!
--
Al
Patrick McHardy wrote:
> Al Boldi wrote:
> > Patrick McHardy wrote:
> >>Please send mails discussing netfilter to netfilter-devel.
> >
> > Ok. I just found out this changed to vger. But
> > [email protected] is bouncing me.
>
> Seems to work, I got your mail on netfilter-devel.
Looks like it works sometimes. Added lkml as a backup...
> >>Al Boldi wrote:
> >>>With the existence of the mangle table, how useful is the filter table?
> >>>
> >>>Other than requiring the REJECT target to be ported to the mangle
> >>> table, is the filter table faster than the mangle table?
> >>
> >>There are some minor differences in ordering (mangle comes before
> >>DNAT, filter afterwards), but for most rulesets thats completely
> >>irrelevant. The only difference that really matters is that mangle
> >>performs rerouting in LOCAL_OUT for packets that had their routing
> >>key changed, so its really a superset of the filter table. If you
> >>want to use REJECT in the mangle table, you just need to remove the
> >>restriction to filter, it works fine. I would prefer to also remove
> >>the restriction of MARK, CONNMARK etc. to mangle, they're used for
> >>more than just routing today so that restriction also doesn't make
> >>much sense. Patches for this are welcome.
> >
> > Something like this (untested):
> >
> > --- ipt_REJECT.bak.c 2007-10-12 08:25:17.000000000 +0300
> > +++ ipt_REJECT.c 2007-10-12 08:31:44.000000000 +0300
> > @@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
> >
> > static inline void send_unreach(struct sk_buff *skb_in, int code)
> > {
> > + if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
> > icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
> > }
> >
> > @@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
> > .family = AF_INET,
> > .target = reject,
> > .targetsize = sizeof(struct ipt_reject_info),
> > - .table = "filter",
> > - .hooks = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
> > - (1 << NF_IP_LOCAL_OUT),
> > .checkentry = check,
> > .me = THIS_MODULE,
> > };
>
> That includes an unrelated change, I meant to simply remove the filter
> table restriction.
>
> >>>If not, then shouldn't the filter table be obsoleted to avoid
> >>> confusion?
> >>
> >>That would probably confuse people. Just don't use it if you don't
> >>need to.
> >
> > The problem is that people think they are safe with the filter table,
> > when in fact they need the prerouting chain to seal things. Right now
> > this is only possible in the mangle table.
>
> Why do they need PREROUTING?
Well, for example to stop any transient packets being forwarded. You could
probably hack around this using mark's, but you can't stop the implied route
lookup, unless you stop it in prerouting.
Thanks!
--
Al
Al Boldi wrote:
>>>The problem is that people think they are safe with the filter table,
>>>when in fact they need the prerouting chain to seal things. Right now
>>>this is only possible in the mangle table.
>>
>>Why do they need PREROUTING?
>
>
> Well, for example to stop any transient packets being forwarded. You could
> probably hack around this using mark's, but you can't stop the implied route
> lookup, unless you stop it in prerouting.
This also works fine in FORWARD with a little extra overhead.
If you really have to save resources, you should use PREROUTING/raw
to also avoid the creation of a connection tracking entry.
On Oct 12 2007 00:31, Al Boldi wrote:
>
>With the existence of the mangle table, how useful is the filter table?
A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
in the end, my proposal was something like
http://jengelh.hopto.org/GFX0/nf_proposal2.svg
Patrick McHardy wrote:
> Al Boldi wrote:
> >>>The problem is that people think they are safe with the filter table,
> >>>when in fact they need the prerouting chain to seal things. Right now
> >>>this is only possible in the mangle table.
> >>
> >>Why do they need PREROUTING?
> >
> > Well, for example to stop any transient packets being forwarded. You
> > could probably hack around this using mark's, but you can't stop the
> > implied route lookup, unless you stop it in prerouting.
>
> This also works fine in FORWARD with a little extra overhead.
> If you really have to save resources, you should use PREROUTING/raw
> to also avoid the creation of a connection tracking entry.
Yes sure, if you use nat. But can you see how forcing people into splitting
their rules across tables adds complexity. And without ipt_REJECT patch,
they can't even use REJECT in prerouting, which forces them to do some
strange hacks.
IMHO, we should make things as easily configurable as possible, and as things
stand right now, the filter-table is completely useless for 99% of
use-cases.
Thanks!
--
Al
Al Boldi wrote:
> Patrick McHardy wrote:
>
>>Al Boldi wrote:
>>
>>>Well, for example to stop any transient packets being forwarded. You
>>>could probably hack around this using mark's, but you can't stop the
>>>implied route lookup, unless you stop it in prerouting.
>>
>>This also works fine in FORWARD with a little extra overhead.
>>If you really have to save resources, you should use PREROUTING/raw
>>to also avoid the creation of a connection tracking entry.
>
>
> Yes sure, if you use nat.
Conntrack.
> But can you see how forcing people into splitting
> their rules across tables adds complexity. And without ipt_REJECT patch,
> they can't even use REJECT in prerouting, which forces them to do some
> strange hacks.
>
> IMHO, we should make things as easily configurable as possible, and as things
> stand right now, the filter-table is completely useless for 99% of
> use-cases.
Sure, as I said, patches to remove the arbitary restrictions to
tables are welcome, but please do this for all targets and
matches which allow this, not only REJECT. And if you include a
seperate (tested) patch for the IPv4 and IPv6 REJECT targets
I'll consider it as well.
Jan Engelhardt wrote:
> On Oct 12 2007 00:31, Al Boldi wrote:
> >With the existence of the mangle table, how useful is the filter table?
>
> A similar discussion was back in March 2007.
> http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
> http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>
> in the end, my proposal was something like
> http://jengelh.hopto.org/GFX0/nf_proposal2.svg
Any chance you could publish this as something readable like text/html?
Thanks!
--
Al
On Oct 12 2007 16:30, Al Boldi wrote:
>Jan Engelhardt wrote:
>> On Oct 12 2007 00:31, Al Boldi wrote:
>> >With the existence of the mangle table, how useful is the filter table?
>>
>> A similar discussion was back in March 2007.
>> http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
>> http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>>
>> in the end, my proposal was something like
>> http://jengelh.hopto.org/GFX0/nf_proposal2.svg
>
>Any chance you could publish this as something readable like text/html?
Like, image/png?
http://jengelh.hopto.org/GFX0/nf_proposal2.png
Jan Engelhardt wrote:
> On Oct 12 2007 16:30, Al Boldi wrote:
>>>>
>>>>With the existence of the mangle table, how useful is the filter table?
>>>
>>>A similar discussion was back in March 2007.
>>>http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
>>>http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>>>
>>>in the end, my proposal was something like
>>>http://jengelh.hopto.org/GFX0/nf_proposal2.svg
>>
>>Any chance you could publish this as something readable like text/html?
>
>
> Like, image/png?
> http://jengelh.hopto.org/GFX0/nf_proposal2.png
The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and "built-in"
chains. The only built-in tables will be those that need extra
processing (mangle/nat). So it should be possible to set up tables
basically any way you desire.
On Oct 12 2007 15:48, Patrick McHardy wrote:
>
>The netlink based iptables successor I'm currently working on allows to
>dynamically create tables with user-specified priorities and "built-in"
>chains. The only built-in tables will be those that need extra
>processing (mangle/nat). So it should be possible to set up tables
>basically any way you desire.
Will ebtables move a bit closer to iptables?
Jan Engelhardt wrote:
> On Oct 12 2007 15:48, Patrick McHardy wrote:
>
>>The netlink based iptables successor I'm currently working on allows to
>>dynamically create tables with user-specified priorities and "built-in"
>>chains. The only built-in tables will be those that need extra
>>processing (mangle/nat). So it should be possible to set up tables
>>basically any way you desire.
>
>
> Will ebtables move a bit closer to iptables?
I didn't get to that part yet, but yes, thats one of the goals.
Patrick McHardy wrote:
> Jan Engelhardt wrote:
> > On Oct 12 2007 16:30, Al Boldi wrote:
> >>>>With the existence of the mangle table, how useful is the filter
> >>>> table?
> >>>
> >>>A similar discussion was back in March 2007.
> >>>http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
> >>>http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
> >>>
> >>>in the end, my proposal was something like
> >>>http://jengelh.hopto.org/GFX0/nf_proposal2.svg
> >>
> >>Any chance you could publish this as something readable like text/html?
> >
> > Like, image/png?
> > http://jengelh.hopto.org/GFX0/nf_proposal2.png
>
> The netlink based iptables successor I'm currently working on allows to
> dynamically create tables with user-specified priorities and "built-in"
> chains. The only built-in tables will be those that need extra
> processing (mangle/nat). So it should be possible to set up tables
> basically any way you desire.
Wow! How soon can we expect this to surface on mainline?
Thanks a lot!
--
Al
Patrick McHardy wrote:
> Al Boldi wrote:
> > But can you see how forcing people into splitting
> > their rules across tables adds complexity. And without ipt_REJECT
> > patch, they can't even use REJECT in prerouting, which forces them to do
> > some strange hacks.
> >
> > IMHO, we should make things as easily configurable as possible, and as
> > things stand right now, the filter-table is completely useless for 99%
> > of use-cases.
>
> Sure, as I said, patches to remove the arbitary restrictions to
> tables are welcome, but please do this for all targets and
> matches which allow this, not only REJECT. And if you include a
> seperate (tested) patch for the IPv4 and IPv6 REJECT targets
> I'll consider it as well.
Sounds fair. All we need now is for someone to kindly submit these rather
straight forward patches.
Thanks!
--
Al
Al Boldi wrote:
> Patrick McHardy wrote:
>
>> The netlink based iptables successor I'm currently working on allows to
>> dynamically create tables with user-specified priorities and "built-in"
>> chains. The only built-in tables will be those that need extra
>> processing (mangle/nat). So it should be possible to set up tables
>> basically any way you desire.
>>
>
> Wow! How soon can we expect this to surface on mainline?
I can't tell at this point, there's still too much work to do
for a realistic estimate. I'll post patches to netfilter-devel
as soon as its good enough for some real testing.
Al Boldi wrote:
> Patrick McHardy wrote:
>> Please send mails discussing netfilter to netfilter-devel.
>
> Ok. I just found out this changed to vger. But
> [email protected] is bouncing me.
>
>> Al Boldi wrote:
>>> With the existence of the mangle table, how useful is the filter table?
>>>
>>> Other than requiring the REJECT target to be ported to the mangle table,
>>> is the filter table faster than the mangle table?
>> There are some minor differences in ordering (mangle comes before
>> DNAT, filter afterwards), but for most rulesets thats completely
>> irrelevant. The only difference that really matters is that mangle
>> performs rerouting in LOCAL_OUT for packets that had their routing
>> key changed, so its really a superset of the filter table. If you
>> want to use REJECT in the mangle table, you just need to remove the
>> restriction to filter, it works fine. I would prefer to also remove
>> the restriction of MARK, CONNMARK etc. to mangle, they're used for
>> more than just routing today so that restriction also doesn't make
>> much sense. Patches for this are welcome.
>
> Something like this (untested):
>
> --- ipt_REJECT.bak.c 2007-10-12 08:25:17.000000000 +0300
> +++ ipt_REJECT.c 2007-10-12 08:31:44.000000000 +0300
> @@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
>
> static inline void send_unreach(struct sk_buff *skb_in, int code)
> {
> + if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
> icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
> }
>
> @@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
> .family = AF_INET,
> .target = reject,
> .targetsize = sizeof(struct ipt_reject_info),
> - .table = "filter",
> - .hooks = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
> - (1 << NF_IP_LOCAL_OUT),
> .checkentry = check,
> .me = THIS_MODULE,
> };
>
>>> If not, then shouldn't the filter table be obsoleted to avoid confusion?
>> That would probably confuse people. Just don't use it if you don't
>> need to.
>
That is a most practical suggestion.
> The problem is that people think they are safe with the filter table, when in
> fact they need the prerouting chain to seal things. Right now this is only
> possible in the mangle table.
>
I'm not sure what you think is unsafe about using the filter table, and
the order of evaluation issues certainly seem to suggest that some
actions would take a major rethink at least. Perhaps you could avoid
breaking all of the setups which currently work, rather than force
everyone to do things differently because you feel that your way is better.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Bill Davidsen wrote:
>>>> If not, then shouldn't the filter table be obsoleted to avoid
>>>> confusion?
>>> That would probably confuse people. Just don't use it if you don't
>>> need to.
>>
> That is a most practical suggestion.
>
>> The problem is that people think they are safe with the filter table,
>> when in fact they need the prerouting chain to seal things. Right now
>> this is only possible in the mangle table.
>>
> I'm not sure what you think is unsafe about using the filter table, and
> the order of evaluation issues certainly seem to suggest that some
> actions would take a major rethink at least. Perhaps you could avoid
> breaking all of the setups which currently work, rather than force
> everyone to do things differently because you feel that your way is better.
>
It was my intention to suggest that unintentional breakage of existing
setups should be avoided, not that removing the filter table was some
evil plot. ;-)
On rereading my original post I failed to make that clear, please take
it as intended.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Bill Davidsen wrote:
> Bill Davidsen wrote:
> >>>> If not, then shouldn't the filter table be obsoleted to avoid
> >>>> confusion?
> >>>
> >>> That would probably confuse people. Just don't use it if you don't
> >>> need to.
> >
> > That is a most practical suggestion.
> >
> >> The problem is that people think they are safe with the filter table,
> >> when in fact they need the prerouting chain to seal things. Right now
> >> this is only possible in the mangle table.
> >
> > I'm not sure what you think is unsafe about using the filter table, and
> > the order of evaluation issues certainly seem to suggest that some
> > actions would take a major rethink at least. Perhaps you could avoid
> > breaking all of the setups which currently work, rather than force
> > everyone to do things differently because you feel that your way is
> > better.
>
> It was my intention to suggest that unintentional breakage of existing
> setups should be avoided, not that removing the filter table was some
> evil plot. ;-)
> On rereading my original post I failed to make that clear, please take
> it as intended.
Sure, the idea was to mark the filter table obsolete as to make people start
using the mangle table to do their filtering for new setups. The filter
table would then still be available for legacy/special setups. But this
would only be possible if we at least ported the REJECT target to mangle.
Thanks!
--
Al
On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
> Sure, the idea was to mark the filter table obsolete as to make people start
> using the mangle table to do their filtering for new setups. The filter
> table would then still be available for legacy/special setups. But this
> would only be possible if we at least ported the REJECT target to mangle.
That's *half* the battle. The other half is explaining why I should move
from a perfectly functional setup that uses the filter table. What gains
do I get from doing so? What isn't working that I don't know about? etc?
In other words - why do I want to move from filter to mangle?
On Oct 20 2007 00:47, [email protected] wrote:
>> Sure, the idea was to mark the filter table obsolete as to make people start
>> using the mangle table to do their filtering for new setups. The filter
>> table would then still be available for legacy/special setups. But this
>> would only be possible if we at least ported the REJECT target to mangle.
>
>That's *half* the battle. The other half is explaining why I should move
>from a perfectly functional setup that uses the filter table. What gains
>do I get from doing so? What isn't working that I don't know about? etc?
>
>In other words - why do I want to move from filter to mangle?
Packet processing time.
Compare previous:
packet goes through mangle, then is dropped in filter
Compare afterwards:
packet is already dropped in mangle
=> less code to run through
[email protected] wrote:
> On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
> > Sure, the idea was to mark the filter table obsolete as to make people
> > start using the mangle table to do their filtering for new setups. The
> > filter table would then still be available for legacy/special setups.
> > But this would only be possible if we at least ported the REJECT target
> > to mangle.
>
> That's *half* the battle. The other half is explaining why I should move
> from a perfectly functional setup that uses the filter table. What gains
> do I get from doing so? What isn't working that I don't know about? etc?
>
> In other words - why do I want to move from filter to mangle?
This has already been explained in this thread; here it is again:
Al Boldi wrote:
>>>The problem is that people think they are safe with the filter table,
>>>when in fact they need the prerouting chain to seal things. Right now
>>>this is only possible in the mangle table.
>>
>>Why do they need PREROUTING?
>
> Well, for example to stop any transient packets being forwarded. You could
> probably hack around this using mark's, but you can't stop the implied
> route lookup, unless you stop it in prerouting.
Basically, you have one big unintended gaping whole in your firewall, that
could easily be exploited for DoS attacks at the least, unless you put in
specific rules to limit this.
Plus, it's outrageously incorrect to accept invalid packets, just because
your filtering infrastructure can only reject packets after they have been
prerouted.
Thanks!
--
Al
On Sun, 21 Oct 2007 07:31:58 +0300, Al Boldi said:
> > Well, for example to stop any transient packets being forwarded. You could
> > probably hack around this using mark's, but you can't stop the implied
> > route lookup, unless you stop it in prerouting.
>
> Basically, you have one big unintended gaping whole in your firewall, that
> could easily be exploited for DoS attacks at the least, unless you put in
> specific rules to limit this.
OK, the light bulb just went on... ;)
We actually *do* have an issue with the flip side of that - it's a frikking
pain to make packets that show up on eth0 with a destination of 127.0.0.1
go away un-noticed - or at least I'm assuming it's the flip side of the same
issue.
Al Boldi wrote:
> [email protected] wrote:
>> On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
>>> Sure, the idea was to mark the filter table obsolete as to make people
>>> start using the mangle table to do their filtering for new setups. The
>>> filter table would then still be available for legacy/special setups.
>>> But this would only be possible if we at least ported the REJECT target
>>> to mangle.
>> That's *half* the battle. The other half is explaining why I should move
>> from a perfectly functional setup that uses the filter table. What gains
>> do I get from doing so? What isn't working that I don't know about? etc?
>>
>> In other words - why do I want to move from filter to mangle?
>
> This has already been explained in this thread; here it is again:
>
> Al Boldi wrote:
>>>> The problem is that people think they are safe with the filter table,
>>>> when in fact they need the prerouting chain to seal things. Right now
>>>> this is only possible in the mangle table.
>>> Why do they need PREROUTING?
>> Well, for example to stop any transient packets being forwarded. You could
>> probably hack around this using mark's, but you can't stop the implied
>> route lookup, unless you stop it in prerouting.
>
> Basically, you have one big unintended gaping whole in your firewall, that
> could easily be exploited for DoS attacks at the least, unless you put in
> specific rules to limit this.
>
Well... true enough on a small firewall machine with a really fast link,
maybe. I like your point about efficiency better, it's more logical,
like putting an ACCEPT of established connections before a lot of low
probability rules. The only time I have seen rules actually bog a
machine was when a major ISP sent out a customer "upgrade" with a bug
which caused certain connections to be SYN-SYN/ACK-RST leaving half open
sockets. They sent out 160k of them and the blocking list became very
long as blocking rules were added.
> Plus, it's outrageously incorrect to accept invalid packets, just because
> your filtering infrastructure can only reject packets after they have been
> prerouted.
>
As long as the filter table doesn't go away, sometimes things change
after PREROUTING, like NAT, and additional rules must be used.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
