Question, my modifed -j LOG

Question, my modifed -j LOG

[Joakim Axelsson]

In my effort to try to make my router's firewall some what better i have
been thinking of modifying -j LOG in some ways:

The --log-prefix is way to short only allowing 30 characters. I have a huge
firewall with over 10000 rules (of couse not every packet using every rule).
Its impossible to keep track on where the packet is unless i supply the
table (filter,nat,mangle,raw) and the chain name in --log-prefix. Even if i
try to keep this short there is very little, if no room, left for a reason
to fit in --log-prefix. Simple solution for me is to modify -j LOG to handle
a longer --log-prefix.

Then i was thinking of another solution. Perhaps i could add one or two
options which beside the user supplied --log-prefix also prints the table
name and the chain name. It's easy to find the table name. Just store it in
userdata when the checkentry code runs. However, i havn't found a way to get
the chain name.

Mind that i'm also thinking of (yes wrongly) making my new -j LOG into a -m
log. A match that always matches. This will reduce the number of chains i
need alot. I can see that match->checkentry is given the struct ipt_entry.
But i can't figure out how to get the chain name for there.

To explain why i want to make it a match is because i very often have these
protectors in my firewall:

iptables -N chain_tcpsyn
iptables -A chain_tcpsyn -m limit --limit 1000/s -j RETURN
iptables -A chain_tcpsyn -m limit 1/s -j LOG --log-prefix "FW raw chain_tcpsyn"
iptables -A chain_tcpsyn -j DROP

iptables -N chain
iptables -A chain -p tcp --syn -j chain_tcpsyn
iptables -A chain -p tcp --syn -j RETURN
iptables -A chain -p tcp -j chain_tcp
iptables -A chain -p tcp -j RETURN
... udp icmp ...
iptables -A chain -j chain_otherprotocols


This gives me alot of chains and alot of rules. Mind also that i have _alot_
of interface on this router and even more of these limiters to keep the
machine alive during DDoSes. (I use a perl-script to generete a file which
can be loaded with iptables-restore.)

I have reduced the above by making a better and more accurate limit match
called only 'lim'. This lim can invert the match and only match those
packets that overlimits. Along with a possbile -m log (that in it self
limits the logger so kernel wont be flooded with logging messages) i could
reduce the above to:

iptables -N chain
iptables -A chain -p tcp --syn \
                  -m lim --lim-packets ! 1000/s \
                  -m log --log-lim 1/s --log-prefix "FW raw chain tcpsyn" \
                  -j DROP
iptables -A chain -p tcp --syn -j RETURN
...

I havn't figured a way to nicely remove that last -j RETURN. But it will
aleast save alot of rules and chains by the above idea.

Thx for any reply.

-- 
/Joakim Axelsson A.K.A Gozem@EFnet

Re: Question, my modifed -j LOG

[Jan Engelhardt]

>The --log-prefix is way to short only allowing 30 characters. I have a huge
>firewall with over 10000 rules (of couse not every packet using every rule).

>From a FW designer's POV, I would say you have got too much rules. I have like 
what... `iptables -L -v | wc -l` == 63, and I am sure you can reduce it too.

>Its impossible to keep track on where the packet is unless i supply the
>table (filter,nat,mangle,raw) and the chain name in --log-prefix. Even if i
>try to keep this short there is very little, if no room, left for a reason
>to fit in --log-prefix. Simple solution for me is to modify -j LOG to handle
>a longer --log-prefix.

There is a -j TRACK, but I have not used it yet. (I apparently forgot to patch 
it in, and now I am too lazy to touch my kernel again for some weeks.)

>Mind that i'm also thinking of (yes wrongly) making my new -j LOG into a -m
>log. A match that always matches. This will reduce the number of chains i
>need alot. I can see that match->checkentry is given the struct ipt_entry.

Interestingly enough, ebtables follows exactly this approach - i.e. there are 
no "non-terminating targets", but ebtable's -j only has absolute verdicts and 
everything else is kinda "by the way", e.g.
  ebtables -A INPUT -j CONTINUE --log (the only non-terminating thing is 
  CONTINUE)

OTOH, I find the iptables way better with -j LOG. To reduce the number of 
chains, you should really look into the goto target. It's awesome (see AS_IPFW 
soon).

>To explain why i want to make it a match is because i very often have these
>protectors in my firewall:
>
>iptables -N chain_tcpsyn
>iptables -A chain_tcpsyn -m limit --limit 1000/s -j RETURN
>iptables -A chain_tcpsyn -m limit 1/s -j LOG --log-prefix "FW raw chain_tcpsyn"
>iptables -A chain_tcpsyn -j DROP

This chain is ok..

>iptables -N chain
>iptables -A chain -p tcp --syn -j chain_tcpsyn
>iptables -A chain -p tcp --syn -j RETURN
>iptables -A chain -p tcp -j chain_tcp
>iptables -A chain -p tcp -j RETURN

You would benefit from goto. See:

ipt -A chain -p tcp --syn -g chain_tcpsyn
ipt -A chain -p tcp -g chain_tcp
ipt -A chain -p udp -g chain_udp
ipt -A chain -p icmp -g chain_icmp
ipt -A chain -j LOG --log-prefix "what a protocol is that?"
ipt -A chain -j DROP

to give an example...

>This gives me alot of chains and alot of rules. Mind also that i have _alot_
>of interface on this router and even more of these limiters to keep the
>machine alive during DDoSes. (I use a perl-script to generete a file which
>can be loaded with iptables-restore.)

Do not make yourself a favorable DDOS target.
(And try hashlimit if you need something spicy single-host-based.)

>I have reduced the above by making a better and more accurate limit match
>called only 'lim'. This lim can invert the match and only match those
>packets that overlimits. Along with a possbile -m log (that in it self

Uh huh, you could have done that also with another chain

  ipt -A chain -p tcp -m lim --lim-packets 1000/s -j RETURN
  ipt -A chain -j LOG --log-prefix "uhoh, too much packets"

of course, this would work against your trying to reduce chains/rules. And if 
you're already coding the "!" of -m lim, why not modify -m limit to support 
"!" instead of creating yet another match module?

>limits the logger so kernel wont be flooded with logging messages) i could
>reduce the above to:
>
>iptables -N chain
>iptables -A chain -p tcp --syn \
>                  -m lim --lim-packets ! 1000/s \
>                  -m log --log-lim 1/s --log-prefix "FW raw chain tcpsyn" \
>                  -j DROP
>iptables -A chain -p tcp --syn -j RETURN
>...
>
>I havn't figured a way to nicely remove that last -j RETURN. But it will
>aleast save alot of rules and chains by the above idea.


Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: Question, my modifed -j LOG

[Joakim Axelsson]

2005-08-20 22:01:53+0200, Jan Engelhardt <jengelh@linux01.gwdg.de> ->
> 
> >The --log-prefix is way to short only allowing 30 characters. I have a huge
> >firewall with over 10000 rules (of couse not every packet using every rule).
> 
> >From a FW designer's POV, I would say you have got too much rules. I have like 
> what... `iptables -L -v | wc -l` == 63, and I am sure you can reduce it too.
> 

Its a _very_ large router infront of a student network. It house sover 2000
computers behind it and has a traffic amount between 50Mbit and 400Mbit
(night and day) for each of the 2 large main interface. Now the machine has
and additionally 30 interfaces. Most of them virtual VLAN interfaces. Point
is, this is a _very large_ routing machine. The machines work can't be done
in 63 rules. No way. Not with all the functions i have. The large amount of
interfaces are the reason i have made a perl-script that generates a
iptables-restore:able file as alot of the firewalling are done for each
interface but with slithly different paramters such as ip-range, limiters
and other things.

> >Its impossible to keep track on where the packet is unless i supply the
> >table (filter,nat,mangle,raw) and the chain name in --log-prefix. Even if i
> >try to keep this short there is very little, if no room, left for a reason
> >to fit in --log-prefix. Simple solution for me is to modify -j LOG to handle
> >a longer --log-prefix.
> 
> There is a -j TRACK, but I have not used it yet. (I apparently forgot to patch 
> it in, and now I am too lazy to touch my kernel again for some weeks.)
> 

Yeah, come to think about that afterwards i sent he mail, havn't had time to
check it tho.

> >Mind that i'm also thinking of (yes wrongly) making my new -j LOG into a -m
> >log. A match that always matches. This will reduce the number of chains i
> >need alot. I can see that match->checkentry is given the struct ipt_entry.
> 
> Interestingly enough, ebtables follows exactly this approach - i.e. there are 
> no "non-terminating targets", but ebtable's -j only has absolute verdicts and 
> everything else is kinda "by the way", e.g.
>   ebtables -A INPUT -j CONTINUE --log (the only non-terminating thing is 
>   CONTINUE)
> 
> OTOH, I find the iptables way better with -j LOG. To reduce the number of 
> chains, you should really look into the goto target. It's awesome (see AS_IPFW 
> soon).
> 

Seen it, however im running on a 2.4.23-kernel. (It will take weeks to test
and patch a new 2.6-kernel not even knowing if it will crash. A crach isn't
affordable on this router.) Need to backport it then and it still wont
really solve the problem as i which to reduce the flow most packets takes.
In both mine existing and your solution the packets we want to save will
still take the jump to chain_tcpsyn and then back. In your solution back
"two step", in mine back the two steps by yet another match. My better
solution wont jump at all, however needing another (fast) match, the RETURN.

> >To explain why i want to make it a match is because i very often have these
> >protectors in my firewall:
> >
> >iptables -N chain_tcpsyn
> >iptables -A chain_tcpsyn -m limit --limit 1000/s -j RETURN
> >iptables -A chain_tcpsyn -m limit 1/s -j LOG --log-prefix "FW raw chain_tcpsyn"
> >iptables -A chain_tcpsyn -j DROP
> 
> This chain is ok..
> 
> >iptables -N chain
> >iptables -A chain -p tcp --syn -j chain_tcpsyn
> >iptables -A chain -p tcp --syn -j RETURN
> >iptables -A chain -p tcp -j chain_tcp
> >iptables -A chain -p tcp -j RETURN
> 
> You would benefit from goto. See:
> 
> ipt -A chain -p tcp --syn -g chain_tcpsyn
> ipt -A chain -p tcp -g chain_tcp
> ipt -A chain -p udp -g chain_udp
> ipt -A chain -p icmp -g chain_icmp
> ipt -A chain -j LOG --log-prefix "what a protocol is that?"
> ipt -A chain -j DROP
> 
> to give an example...
> 
> >This gives me alot of chains and alot of rules. Mind also that i have _alot_
> >of interface on this router and even more of these limiters to keep the
> >machine alive during DDoSes. (I use a perl-script to generete a file which
> >can be loaded with iptables-restore.)
> 
> Do not make yourself a favorable DDOS target.
> (And try hashlimit if you need something spicy single-host-based.)
> 

That is not for me to deside. This is not a company firewall. It's student
running thier own machines behind. DoSes are a fact, we just have to handle
them. We have _alot_ of bandwidth to play with. Not just enough CPU :-/

> >I have reduced the above by making a better and more accurate limit match
> >called only 'lim'. This lim can invert the match and only match those
> >packets that overlimits. Along with a possbile -m log (that in it self
> 
> Uh huh, you could have done that also with another chain
> 
>   ipt -A chain -p tcp -m lim --lim-packets 1000/s -j RETURN
>   ipt -A chain -j LOG --log-prefix "uhoh, too much packets"
> 
> of course, this would work against your trying to reduce chains/rules. And if 
> you're already coding the "!" of -m lim, why not modify -m limit to support 
> "!" instead of creating yet another match module?
> 

This new -m lim can do much more than -m limit. First -m limit doesn't work
good if speeds above 100/s. It simply doesn't calculate correctly due to the
dividing factors of the algorithm. My new algortim is very exact. Also,
this new -m lim can do much more like a blackout for a period if the limit is
hit. Also a --lim-bytes. Yes i know a shapers in tc will do that better, but
a short hack will do the trick nice and easy some times better.

> >limits the logger so kernel wont be flooded with logging messages) i could
> >reduce the above to:
> >
> >iptables -N chain
> >iptables -A chain -p tcp --syn \
> >                  -m lim --lim-packets ! 1000/s \
> >                  -m log --log-lim 1/s --log-prefix "FW raw chain tcpsyn" \
> >                  -j DROP
> >iptables -A chain -p tcp --syn -j RETURN
> >...
> >
> >I havn't figured a way to nicely remove that last -j RETURN. But it will
> >aleast save alot of rules and chains by the above idea.
> 
> 
> Jan Engelhardt
> -- 
> | Alphagate Systems, http://alphagate.hopto.org/

-- 
/Joakim Axelsson A.K.A Gozem@EFnet

Re: Question, my modifed -j LOG

[Joakim Axelsson]

2005-08-20 22:25:52+0200, Joakim Axelsson <gozem@gozem.se> ->
> > >Its impossible to keep track on where the packet is unless i supply the
> > >table (filter,nat,mangle,raw) and the chain name in --log-prefix. Even if i
> > >try to keep this short there is very little, if no room, left for a reason
> > >to fit in --log-prefix. Simple solution for me is to modify -j LOG to handle
> > >a longer --log-prefix.
> > 
> > There is a -j TRACK, but I have not used it yet. (I apparently forgot to patch 
> > it in, and now I am too lazy to touch my kernel again for some weeks.)
> > 
> 
> Yeah, come to think about that afterwards i sent he mail, havn't had time to
> check it tho.
> 

I checked TRACE. It adds chainname and rulenum to the ipt_entry. ipt_entry
is passed to an -j TARGET, but only ipt_entry->ipt_ip is passed to an -m
match. As far as i can see there is no good way to get that ipt_entry for
the match. Perhaps using the hook_mask? Seems to be the ipt_entry->comefrom.
Don't see a way to use that. Can somebody explain the hook_mask better for
me?

Anyway, i think the best way to solve this, is to set the chainname in the
match's matchdata in userspace. Now, the parse-function doesn't get any info
in userspace on the chain name, but it does get the argv-array. So we can
scan the commandline. Ugly ugly, be will do the trick with least other
(possible unstable) (kernel-)hacking.

Or i could hack a half global area that the rule-traversing code can write
to. Saving the name of the chainname (or just a pointer to the current
ipt_entry). This would also solve another problem/feature i've been thinking
of. What if matches/targets could make a note on the packet which -j LOG
could print. This would make it easy for modules as -m unclean and perhaps
-m recent to express a more exact reason for the packet to match or not. The
next rule in line could then use it, either overwrite it with its own reason
or in the case of -j LOG. Print it. This field would be a simple string, or
even just a char*, being pointed to static strings with reasons that the
different modules have in stock.


-- 
/Joakim Axelsson A.K.A Gozem@EFnet

Re: Question, my modifed -j LOG

[Jan Engelhardt]

>Its a _very_ large router infront of a student network. It house sover 2000
>computers behind it and has a traffic amount between 50Mbit and 400Mbit
>(night and day) for each of the 2 large main interface. Now the machine has
>and additionally 30 interfaces. Most of them virtual VLAN interfaces. Point
>is, this is a _very large_ routing machine. The machines work can't be done
>in 63 rules. No way. Not with all the functions i have. The large amount of

The question is: how different do all these 2000+ hosts need to be classified?
I can't think of anything but to let everything through with possibly 
exceptions like SMTP and HTTP (going over proxies there).

>interface but with slithly different paramters such as ip-range, limiters
>and other things.

Other things like?
Matching by interface might eliminate the need to test ipaddr/iprange.
Matching by ipaddr/iprange might eliminate the need to test interface.
Discrete logic is the key ;)

>Seen it, however im running on a 2.4.23-kernel. (It will take weeks to test
>and patch a new 2.6-kernel not even knowing if it will crash.

You know that 2.4.31 is current, and .23 is more error prone to security flaws
(oh, did you mention you are a DDOS target? Think again!)

>A crach isn't affordable on this router.

Just have a fast recover lane. :)

>Need to backport it then and it still wont really solve the problem as i which
>to reduce the flow most packets takes. In both mine existing and your solution
>the packets we want to save will still take the jump to chain_tcpsyn and then
>back.

A goto does not come back.

>In your solution back "two step", in mine back the two steps by yet
>another match. My better solution wont jump at all, however needing another
>(fast) match, the RETURN.

How do you know two packet comparisons are faster than a iptable stack jump?
Given that each operation was valued "1" and that the first rule of
"chain_tcpsyn" always matches for our hypothesis...

>>>iptables -N chain_tcpsyn
>>>iptables -A chain_tcpsyn -m limit (+1) --limit 1000/s (+1) -j RETURN (+1)
>>>iptables -A chain_tcpsyn -m limit 1/s -j LOG --log-prefix "FW raw chain_tcpsyn"
>>>iptables -A chain_tcpsyn -j DROP
>> 
>>>iptables -N chain
>>>iptables -A chain -p tcp (+1) --syn (+1) -j chain_tcpsyn (+1)
>>>iptables -A chain -p tcp (+1) --syn (+1) -j RETURN (+1)
>>>iptables -A chain -p tcp -j chain_tcp
>>>iptables -A chain -p tcp -j RETURN
>> 
>>ipt -A chain -p tcp (+1) --syn (+1) -g chain_tcpsyn (+1)
>>ipt -A chain -p tcp -g chain_tcp
>>ipt -A chain -p udp -g chain_udp

... in your case, you would need

  -p tcp --syn -j chain_tcpsyn
  -m limit --limit 1000/s -j RETURN
  -p tcp --syn -j RETURN
  == 9 operations

to exit finish the chain named "chain", while I need

  -p tcp --syn -g chain_tcpsyn
  -m limit --limit 1000/s -j RETURN
  == 6 operations to do so.

In fact, you do 3 jumps (one enter, two exits) while I do only 2 (one goto and
one exit). And a goto is usually less expensive than a jump since it does not
push a return-chain onto the netfilter stack.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: Question, my modifed -j LOG

[Carl-Daniel Hailfinger]

Jan Engelhardt schrieb:
>>> From a FW designer's POV, I would say you have got too much rules.
>> 
>>Its a _very_ large router infront of a student network. It house sover 2000
>>computers behind it and has a traffic amount between 50Mbit and 400Mbit
>>(night and day) for each of the 2 large main interface. Now the machine has
>>and additionally 30 interfaces. Most of them virtual VLAN interfaces. Point
>>is, this is a _very large_ routing machine. The machines work can't be done
>>in 63 rules. No way. Not with all the functions i have. The large amount of
> 
> The question is: how different do all these 2000+ hosts need to be classified?
> I can't think of anything but to let everything through with possibly 
  ^^^^^^^^^^^^^^^^^^^^^^^^^
> exceptions like SMTP and HTTP (going over proxies there).

You haven't yet managed such a big student network, right? Especially if
the same IP range also includes non-students living in the same buildings,
being able to freely roam and still get access to their own services and
having different rules, shaping based on traffic history, IP, port and
building they're sitting in, DoS protection for the hosts behind, limits
on filesharing, redirection of a few services, exceptions to all the
rules above because of people being "important", load distribution etc.
Even with a tree-based approach using goto, ipsets and other useful tools
to shorten chain length, you may end up with >200 iptables rules in your
set plus >100 ebtables rules plus >100 tc rules and still have some work
to do. And in such a scenario most of the logic is in userspace to keep
the ruleset in the kernel short.

Some things in reality can be simplified. Some others are already as
simple as possible.

Please don't criticize other people before understanding their problems.

And please don't strip the author of quoted text.

Regards,
Carl-Daniel

Re: Question, my modifed -j LOG

[Peter Surda]

On Sun, 21 Aug 2005 02:27:03 +0200 Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2005@gmx.net> wrote:

>Jan Engelhardt schrieb:
>> The question is: how different do all these 2000+ hosts need to be
>> classified?
>> I can't think of anything but to let everything through with possibly
>  ^^^^^^^^^^^^^^^^^^^^^^^^^
>> exceptions like SMTP and HTTP (going over proxies there).
>You haven't yet managed such a big student network, right?
Well, he perhaps hadn't, but I did and still do, several of them.

>being able to freely roam and still get access to their own services and
>having different rules, shaping based on traffic history, IP, port and
>building they're sitting in, DoS protection for the hosts behind, limits
>on filesharing, redirection of a few services, exceptions to all the
>rules above because of people being "important", load distribution etc.
I thought this for several years too. Then I discovered WRR and was able to
achieve much better results (both subjective perception of users and
measurements), not to mention that the required administration is much lower.

>Please don't criticize other people before understanding their problems.
You are of course right, original poster's situation seems very complex and such
a large amount of rules may be justified.

Furthermore may I suggest that only development be discussed here and not "how
to use iptables properly"? LARTC might be a better place for that.

>Regards,
>Carl-Daniel
Yours sincerely,
Peter

-- 
http://www.shurdix.org - Linux distribution for routers and firewalls

Re: Question, my modifed -j LOG

[Joakim Axelsson]

2005-08-21 00:38:53+0200, Jan Engelhardt <jengelh@linux01.gwdg.de> ->
> 
> >Its a _very_ large router infront of a student network. It house sover 2000
> >computers behind it and has a traffic amount between 50Mbit and 400Mbit
> >(night and day) for each of the 2 large main interface. Now the machine has
> >and additionally 30 interfaces. Most of them virtual VLAN interfaces. Point
> >is, this is a _very large_ routing machine. The machines work can't be done
> >in 63 rules. No way. Not with all the functions i have. The large amount of
> 
> The question is: how different do all these 2000+ hosts need to be classified?
> I can't think of anything but to let everything through with possibly 
> exceptions like SMTP and HTTP (going over proxies there).
> 

Please do not debate my networks firewall setup. It is complex. OK. Please
just try to solve my little problem by eleminating the number for chains
needed. 

> >interface but with slithly different paramters such as ip-range, limiters
> >and other things.
> 
> Other things like?
> Matching by interface might eliminate the need to test ipaddr/iprange.
> Matching by ipaddr/iprange might eliminate the need to test interface.
> Discrete logic is the key ;)
> 

OK, here is the resulting file that i load for only -t raw. Its not perfect
yet. Far away from it. It already has some custom made modules by me.
ACCOUNT and SPEED are the obvious ones. Others are the -m lim.

http://www.gozem.se/~gozem/test

bogus can be more optimized. I know. Havn't come that far yet.

Some of it has been cut to keep the secret of excatly how the firewall
works. :-/ Some things are there and look empty. There are hook for other
script to add and remove rules as needed. This is specially try for *_zap
and *_harddrop chains.

> >Seen it, however im running on a 2.4.23-kernel. (It will take weeks to test
> >and patch a new 2.6-kernel not even knowing if it will crash.
> 
> You know that 2.4.31 is current, and .23 is more error prone to security flaws
> (oh, did you mention you are a DDOS target? Think again!)
> 

The router has never ever crashed in some 18 months now. Im not about to
trade that for a possible unstable kernel. Its not needed. Well, it is not
as the traffic amount pushes the CPU to 100%. However, you get the idea.
There is nothing to say that i need to upgrade the router just because a
kernels version is old. Its heavily patched. The machine it self is well
protected and drops absolutly everything on -t filter -A INPUT unless your
coming from a private management vlan.

> >A crach isn't affordable on this router.
> 
> Just have a fast recover lane. :)
> 

Not an option.

> >Need to backport it then and it still wont really solve the problem as i which
> >to reduce the flow most packets takes. In both mine existing and your solution
> >the packets we want to save will still take the jump to chain_tcpsyn and then
> >back.
> 
> A goto does not come back.
> 

Both with and without goto an extra chain per "class" of limiter (the
chain_tcpsyn, chain_tcp and so on chains in my example) are needed. Thats
what i meant.

> >In your solution back "two step", in mine back the two steps by yet
> >another match. My better solution wont jump at all, however needing another
> >(fast) match, the RETURN.
> 
> How do you know two packet comparisons are faster than a iptable stack jump?
> Given that each operation was valued "1" and that the first rule of
> "chain_tcpsyn" always matches for our hypothesis...
> 

I don't. I want to eliminated them both.

> >>>iptables -N chain_tcpsyn
> >>>iptables -A chain_tcpsyn -m limit (+1) --limit 1000/s (+1) -j RETURN (+1)
> >>>iptables -A chain_tcpsyn -m limit 1/s -j LOG --log-prefix "FW raw chain_tcpsyn"
> >>>iptables -A chain_tcpsyn -j DROP
> >> 
> >>>iptables -N chain
> >>>iptables -A chain -p tcp (+1) --syn (+1) -j chain_tcpsyn (+1)
> >>>iptables -A chain -p tcp (+1) --syn (+1) -j RETURN (+1)
> >>>iptables -A chain -p tcp -j chain_tcp
> >>>iptables -A chain -p tcp -j RETURN
> >> 
> >>ipt -A chain -p tcp (+1) --syn (+1) -g chain_tcpsyn (+1)
> >>ipt -A chain -p tcp -g chain_tcp
> >>ipt -A chain -p udp -g chain_udp
> 
> ... in your case, you would need
> 
>   -p tcp --syn -j chain_tcpsyn
>   -m limit --limit 1000/s -j RETURN
>   -p tcp --syn -j RETURN
>   == 9 operations
> 
> to exit finish the chain named "chain", while I need
> 
>   -p tcp --syn -g chain_tcpsyn
>   -m limit --limit 1000/s -j RETURN
>   == 6 operations to do so.
> 
> In fact, you do 3 jumps (one enter, two exits) while I do only 2 (one goto and
> one exit). And a goto is usually less expensive than a jump since it does not
> push a return-chain onto the netfilter stack.
> 

And my solution of:

ipt -A chain -p tcp --syn -m lim --lim-packets ! 1000/s -m log -j DROP
ipt -A chain -p tcp --syn -j RETURN

tcp, syn, lim,
tcp, syn, RETURN

will also be 6 operations for packets that passes (normal flow). And i don't
need chain_tcpsyn and so on. Saving memory. Loading my configuration on a
live router takes a few seconds due to the amount of rules.

And also, a jump might be very costly if the jump is so far away in memory
that a cache miss is triggered. This is not unlikly at all as i have so many
rules. Its very unlikly (or atleast much less unlikly) to happen with two
rules after each other. It's ok to do a jump/goto on packets that do not
meat the standard flow however. 

You can't compare each operation as equal cost either. It far more
inexpensive todo a --syn match than a limit (which handles spinlocks) and/or
a jump/goto which might trigger a cache miss.

I know of other places that -g goto can be very handy in my firewall. I will
add it where it suits later as the patching needed in kernel was just a few
lines.

> 
> 
> Jan Engelhardt
> -- 
> | Alphagate Systems, http://alphagate.hopto.org/

Thank you for your kind answers and tyring to help.

However, my original question is stuck. I want to make a -m log which can
printk me the current chain i'm in. Or if that helps you, i want a -m
chain_debug that prints the chain, for any purpose.

I also saw a way of actaully removing the above needed extra line with -j
RETURN when i was studing the ip_tables.c code. Ugly but will work. If i
modify the IPT_MATCH_ITERATE define (which will iterate over all matches for
a rule and break if any of them don't match) to handle that any of them
returns a negative value (like IPT_RETURN). I can add a match that will add
a verdict of IPT_NEXTRETURN. If the next match doesn't match not only
aborts the matching, it also alters the verdict to IPT_RETURN. Meaning:

ipt -A chain -p tcp --syn 
             -m return --return-if-next-match-fail \
             -m limit --lim-packets ! 1000/s \
             -m log --log-prefix "DROPing overlimits" \
             -j DROP
ipt -A chain -p tcp ...
ipt -A chain -p udp ...
...

Now i have ONE rule per matching class and limiter. Just what i wanted. Some
ugly hack perhaps, but i do this so often in my firewall (not just in -i
raw) that it might be just okej.

-- 
/Joakim Axelsson A.K.A Gozem@EFnet

Re: Question, my modifed -j LOG

[Jan Engelhardt]

On Aug 21 2005 06:37, Joakim Axelsson wrote:
>>>Its a _very_ large router infront of a student network. It house sover 2000
>>>computers behind it and has a traffic amount between 50Mbit and 400Mbit
>>>[...]

>Please do not debate my networks firewall setup. It is complex. OK. Please
>just try to solve my little problem by eleminating the number for chains
>needed. 

Maybe we misunderstood because I was not clear - the rules being _traversed_ 
should best be low; that the total number of rules may drop then is a side 
effect, but always welcome.

>url

This looks ok - "big networks" always sound like

  -d 1.2.3.4(/32) -p tcp --do somethign here
  -d 1.2.3.4(/32) -p udp
  -d 1.2.3.5(/32) -p ...
  -d 1.2.3.6(/32) -p ...

(which is really inefficient for a single ip if done for all possible ipaddrs, 
in which case I would probably propose a 4-level digital tree approach.)

>And also, a jump might be very costly if the jump is so far away in memory
>that a cache miss is triggered. This is not unlikly at all as i have so many

This is not a jump at the assembler level, or to put it another way, a -j call 
is not just push-and-pop. If you look at the goto linux.patch, you'll find 
that it adds

   if (table_base + v
        != (void *)e + e->next_offset && !(e->ip.flags & IPT_F_GOTO)) 

the !(e->ip.flags & IPT_F_GOTO) part only, so in case of -g, the whole if() 
body is not run at all.

>However, my original question is stuck. I want to make a -m log which can
>printk me the current chain i'm in. Or if that helps you, i want a -m
>chain_debug that prints the chain, for any purpose.

I have looked into the code, and it seems to me that in the end, there are 
only "tables" with "rules" (indexed by number), so...

  -t filter -A INPUT -j mychain
  -t filter -A mychain -j LOG

will probably end up as

  filter[0] = jump to [2]
  filter[1] = return
  filter[2] = log
  filter[3] = return

so the record of the chain name is dropped early - probably at the 
user<->kernelspace gate. I am deriving this assumption from

  e = get_entry(table_base, v)

where v is an integer.

>ipt -A chain -p tcp --syn 
>             -m return --return-if-next-match-fail \
>             -m limit --lim-packets ! 1000/s \
>             -m log --log-prefix "DROPing overlimits" \
>             -j DROP
>ipt -A chain -p tcp ...
>ipt -A chain -p udp ...
>...
>
>Now i have ONE rule per matching class and limiter. Just what i wanted. Some
>ugly hack perhaps, but i do this so often in my firewall (not just in -i
>raw) that it might be just okej.

An interesting thing indeed.
Oh btw the proper syntax for inverts should be ! --lim-packes 1000/s


>/Joakim Axelsson A.K.A Gozem@EFnet


Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/

Re: Question, my modifed -j LOG

[Carl-Daniel Hailfinger]

Joakim Axelsson schrieb:
> The router has never ever crashed in some 18 months now. Im not about to
> trade that for a possible unstable kernel. Its not needed. Well, it is not
> as the traffic amount pushes the CPU to 100%.

Since the student network I'm managing is comparable in size to yours
and we're going to get 1000 MBit upstream soon, I'd be interested in
your experiences regarding netfilter scalability. Did you profile that
machine to see where it spends most of its time? How big is the latency
introduced by the ruleset? And do you have data about CPU utilization
vs. network load?
Could submit your local patches to pom-ng or at least mail them to me?
I'd like to have a look and find out what can help in my situation.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: Question, my modifed -j LOG

[Joakim Axelsson]

2005-08-21 20:30:26+0200, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net> ->
> Joakim Axelsson schrieb:
> > The router has never ever crashed in some 18 months now. Im not about to
> > trade that for a possible unstable kernel. Its not needed. Well, it is not
> > as the traffic amount pushes the CPU to 100%.
> 
> Since the student network I'm managing is comparable in size to yours
> and we're going to get 1000 MBit upstream soon, I'd be interested in
> your experiences regarding netfilter scalability. Did you profile that
> machine to see where it spends most of its time? How big is the latency
> introduced by the ruleset? And do you have data about CPU utilization
> vs. network load?

I have _alot_ of data as i have alot of measuring points in my netfilter
setup. However, i can't profile it. Its running sharp and i can go around
and play with it. I have to make educated guesses on where to but in some
effort in trying to save some CPU. In general however (atleast with 2.4.23)
uses the netfilter very much cpu of the totalt routing. Something like 70-80%
of the load is just netfilter. Specially is it easy to DoS the machine by
bringing alot of --state NEW packets. Thats why i try to enforce alot of
"smart" limiters in -t raw before those packets hit the conntrack code.

> Could submit your local patches to pom-ng or at least mail them to me?
> I'd like to have a look and find out what can help in my situation.
> 

I can submit my -m lim, -j ACCOUNT and -j SPEED. Upcoming is also a -m
norm(alizer) and as i have been speaking of a -m log. Also a -m srcdst which
matches either the src IP or the dst IP to some specified data (I have alot
of rules regarding some IP that doesn't matter in which direction the
packets is taking.). I also have plans for splitting up -m unclean in
different workareas, making it more suitable and not just a "dangerous
module to use, unless you know what your doing". I don't like getting its
reason printk()-logged beside the packets -j LOG.

However, in general i have to speak with my boss first before handing out
the entire or parts of the routers config and netfilter scripts i have. I
have done them during work hours and thus they belong the my employe. The
code in netfilter however, have i choosed to do in my own time, just so i
can submit them.

I have been waiting because i want to try them in 2.6 first before submit.
I'll se if i find time to finally wrap them up for pom-ng this coming week.

> Regards,
> Carl-Daniel
> -- 
> http://www.hailfinger.org/

-- 
/Joakim Axelsson A.K.A Gozem@EFnet

Re: Question, my modifed -j LOG

[Robbie Dinn]

Joakim Axelsson wrote:
> The --log-prefix is way to short only allowing 30 characters. I have a huge
> firewall with over 10000 rules (of couse not every packet using every rule).
> Its impossible to keep track on where the packet is unless i supply the
> table (filter,nat,mangle,raw) and the chain name in --log-prefix. Even if i
> try to keep this short there is very little, if no room, left for a reason
> to fit in --log-prefix. Simple solution for me is to modify -j LOG to handle
> a longer --log-prefix.

How about using an unmodified iptables --log-prefix , but instead of
using the long string with the full information in it, substitute
that string with it's (fixed length) hash. You could then postprocess
the logfiles to replace the hash with the original text.

i.e. change the problem from a kernel hacking exercise into a boring
scripting/text filtering exercise.

I suspect this isn't the answer you are looking for, but it might do
the job.