iptables denial of services

iptables denial of services

[Jorge Garcia]

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

Hi, i mhere again talking about iptables security, im wriiting an article on this so i want that this artticle have full details about security risks in iptables.
I saw in the net that for examples servers like apache or smtp stop his services after a determinated numbers of connections at the same time.
Is this a problem in iptables firewall??i mean does iptables stop filtering after handling a lot of traffic?
The other thing i saw in the net is that it is possible to send a lot of traffic to full the log messabges of iptables and the firewall will stpo filtering so a hacker could acces to different services on the net, i didnt find any code or proof of concept of this but i want to know if this is possible.
Another thing is that vulnerabilities in the netfilter webpages are very intresting but they are all old, and it seems to not work in actual kernels, i wanna know if there are new vulnerabilities and were to find it.
Any security information about linux firewall will be accept and will help me a lot.
Thanx again and soorry for asking this stuff that maybe is off topic.

http://www.latinmail.com - La forma más cómoda de enviar y recibir tus e-mails

Re: iptables denial of services

[Ozgur AKAN]

Jorge Garcia wrote:

>I saw in the net that for examples servers like apache or smtp stop his services after a determinated numbers of connections at the same time.
>Is this a problem in iptables firewall??i mean does iptables stop filtering after handling a lot of traffic?
>
I think just the opposite would occur. The load of linux os raises to a 
degree that firewall can not answer any more requests.

>The other thing i saw in the net is that it is possible to send a lot of traffic to full the log messabges of iptables and the firewall will stpo filtering so a hacker could acces to different services on the net,
>
If you mean creating too much log and filling the disk space, there is a 
limit option which can limit the number of packets to log in a period of 
time.

-- 
Ozgur Akan

Re: iptables denial of services

[Henrik Nordstrom]

On Thu, 15 Apr 2004, Jorge Garcia wrote:

> I saw in the net that for examples servers like apache or smtp stop his services after a determinated numbers of connections at the same time.

This is called connection flooding. Related to SYN flooding but harder to 
protect from.

You can use the connlimit match from iptables patch-o-matic-ng to help 
reducing this problem but it is not a universal fix to the problem.

> Is this a problem in iptables firewall??i mean does iptables stop filtering after handling a lot of traffic?

No, but it may start dropping packets if overloaded.

If you are doing connection tracking then there is also an analogy to the
connection flooding, where conntrack will not accept new sessions when a
huge number of connetions is already established and this will most likely
result in those new sessions to dropped by your firewall. But it is not a
risk that filtering stops, only that new connections may not be accepted 
for a while. The number of sessions involved is considerably higher than 
on a server so your servers will most likely be dead long before the limit 
in conntrack can be reached.

> The other thing i saw in the net is that it is possible to send a lot of
> traffic to full the log messabges of iptables and the firewall will stpo
> filtering so a hacker could acces to different services on the net, i
> didnt find any code or proof of concept of this but i want to know if
> this is possible.

If the kernel log buffer gets full then the older not yet written to disk
log messages is lost. The filtering is completely unaffected, but some of 
the audit trails of who did what may have been lost..

> Another thing is that vulnerabilities in the netfilter webpages are very
> intresting but they are all old, and it seems to not work in actual
> kernels, i wanna know if there are new vulnerabilities and were to find
> it.

As soon as a vulnerability is made known to the netfilter developers a 
solution is developed, usually within a day from the problem becomes 
known. This solution is then pushed for inclusion in the next kernel 
release.

There has not been any vulnerabilities in quite some time, and is why all 
the vulnerabilities on the netfilter.org homepage is old and not relevant 
to the current kernels.

> Any security information about linux firewall will be accept and will help me a lot.

As with all firewalls the key is making a correct ruleset.

Regards
Henrik

Re: iptables denial of services

[Friedrich Lobenstock]

Henrik Nordstrom wrote on 16.04.2004 12:03 MET:
> On Thu, 15 Apr 2004, Jorge Garcia wrote:
> 
>>Is this a problem in iptables firewall??i mean does iptables stop filtering after handling a lot of traffic?
> 
> No, but it may start dropping packets if overloaded.
> 
> If you are doing connection tracking then there is also an analogy to the
> connection flooding, where conntrack will not accept new sessions when a
> huge number of connetions is already established and this will most likely
> result in those new sessions to dropped by your firewall. But it is not a
> risk that filtering stops, only that new connections may not be accepted 
> for a while. The number of sessions involved is considerably higher than 
> on a server so your servers will most likely be dead long before the limit 
> in conntrack can be reached.

What if the server you are talking about is a server farm? Then an iptables 
gateway that does connection track on the way may as well "die" before the 
servers "die" because of overload.

Can you give some details about those limits? Are there any numbers 
availabe that relate that to memory/cpu/....?

-- 
MfG / Regards
Friedrich Lobenstock

Re: iptables denial of services

[Henrik Nordstrom]

On Sat, 17 Apr 2004, Friedrich Lobenstock wrote:

> What if the server you are talking about is a server farm? Then an iptables 
> gateway that does connection track on the way may as well "die" before the 
> servers "die" because of overload.

If you have a very large farm and does not tune conntrack accordingly then
yes this can happen. It will not die, but it may be the case that it does
not accept as many sessions as your server farm and thereby not allowing
the server farm to be fully utilized.

> Can you give some details about those limits? Are there any numbers 
> availabe that relate that to memory/cpu/....?

The default number of sessions is based on amount of memory but can
easily be tuned at boot time.. or even runtime but then with a slight
performance penalty.

http://www.netfilter.org/documentation/FAQ/netfilter-faq-3.html#ss3.7

Regards
Henrik

question regarding iptables tuning (was Re: iptables denial of services)

[Friedrich Lobenstock]

Henrik Nordstrom wrote on 17.04.2004 18:49 MET:
> On Sat, 17 Apr 2004, Friedrich Lobenstock wrote:
> 
>>Can you give some details about those limits? Are there any numbers 
>>availabe that relate that to memory/cpu/....?
> 
> The default number of sessions is based on amount of memory but can
> easily be tuned at boot time.. or even runtime but then with a slight
> performance penalty.
> 
> http://www.netfilter.org/documentation/FAQ/netfilter-faq-3.html#ss3.7

Thanks, but can you give some background info about the hash size parameter 
of ip_conntrack as the description on the page above is rather lacking any 
reasons:
- Is this parameter automatically sized according to the amount of
   installed memory?
- How is it related to ip_conntrack_max?
- What's the amount of memory that is allocated based on this
   parameter?

Any suggestions for those parameters that are based on your experiences?

-- 
MfG / Regards
Friedrich Lobenstock

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Henrik Nordstrom]

On Sat, 17 Apr 2004, Friedrich Lobenstock wrote:

> Thanks, but can you give some background info about the hash size parameter 
> of ip_conntrack as the description on the page above is rather lacking any 
> reasons:
> - Is this parameter automatically sized according to the amount of
>    installed memory?

Yes.

> - How is it related to ip_conntrack_max?

ip_conntrack_max = 8 * hah_size

> - What's the amount of memory that is allocated based on this
>    parameter?

Depends a little on what conntrack & nat helpers etc you enabled when the
kernel is built. In my kernel each conntrack currently uses ca 384 bytes, 
most others probably use less..

The amount of memory allocated based on the hash size is pretty marginal, 
what one needs to keep track of is the total number of connections as this 
is the bulk of the memory usage.

As for suggested defaults: If this is a general purpose server then the
automatic defaults. On a dedicated firewall scale the memory and conntrack
based on how many concurrent sessions you need to support but I would not
recommend to assign more than 50% of your memory to conntrack.

Regards
Henrik

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Friedrich Lobenstock]

Henrik Nordstrom wrote on 17.04.2004 20:18 MET:
> On Sat, 17 Apr 2004, Friedrich Lobenstock wrote:
> 
> 
>>Thanks, but can you give some background info about the hash size parameter 
>>of ip_conntrack as the description on the page above is rather lacking any 
>>reasons:
>>- Is this parameter automatically sized according to the amount of
>>   installed memory?
> 
> Yes.
> 
> 
>>- How is it related to ip_conntrack_max?
> 
> ip_conntrack_max = 8 * hah_size

What is the downside if that equation is not fullfilled by running
   echo "xxxx" > /proc/sys/net/ipv4/ip_conntrack_max
without setting the hashsize=yyyy parameter?


>>- What's the amount of memory that is allocated based on this
>>   parameter?
> 
> Depends a little on what conntrack & nat helpers etc you enabled when the
> kernel is built. In my kernel each conntrack currently uses ca 384 bytes, 
> most others probably use less..

Wouldn't it be good if ip_conntrack exports that size via /proc? Would help 
the average user to estimate the influence of increasing ip_conntrack_max.

> The amount of memory allocated based on the hash size is pretty marginal, 
> what one needs to keep track of is the total number of connections as this 
> is the bulk of the memory usage.

So the hash size also limits the amount of connections?

> As for suggested defaults: If this is a general purpose server then the
> automatic defaults. On a dedicated firewall scale the memory and conntrack
> based on how many concurrent sessions you need to support but I would not
> recommend to assign more than 50% of your memory to conntrack.

And why if I may ask? Management overhead, or what?
For example a machine with 1GB RAM router only, couldn't we assign eg. 
768MB to conntrack?

Another side question, can you add this information to the netfilter FAQ?

-- 
MfG / Regards
Friedrich Lobenstock

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Henrik Nordstrom]

On Sat, 17 Apr 2004, Friedrich Lobenstock wrote:

> What is the downside if that equation is not fullfilled by running
>    echo "xxxx" > /proc/sys/net/ipv4/ip_conntrack_max
> without setting the hashsize=yyyy parameter?

Overpopulated hash leading to poorer performance than if the hash size is 
tuned accordingly.

> > Depends a little on what conntrack & nat helpers etc you enabled when the
> > kernel is built. In my kernel each conntrack currently uses ca 384 bytes, 
> > most others probably use less..
> 
> Wouldn't it be good if ip_conntrack exports that size via /proc? Would help 
> the average user to estimate the influence of increasing ip_conntrack_max.

It isn't that hard to figure out how much memory conntrack is using by
reading the slab allocation statistics...

> > The amount of memory allocated based on the hash size is pretty marginal, 
> > what one needs to keep track of is the total number of connections as this 
> > is the bulk of the memory usage.
> 
> So the hash size also limits the amount of connections?

The hash size is only about performance.

The only down side of a oversized hash is somewhat greater memory usage
and a slight waste of cache space. The downside of a too small hash is 
higher CPU usage due to overly long hash chains. Nothing inherent to 
iptables but a general aspect of hashing.

The only thing limiting the amount of connections is ip_conntrack_max. 
This controls the maximum number of connections conntrack will track.

> > As for suggested defaults: If this is a general purpose server then the
> > automatic defaults. On a dedicated firewall scale the memory and conntrack
> > based on how many concurrent sessions you need to support but I would not
> > recommend to assign more than 50% of your memory to conntrack.
> 
> And why if I may ask? Management overhead, or what?

You do not want the kernel to run out of memory, and you want to be able 
to run some userspace processes..

> For example a machine with 1GB RAM router only, couldn't we assign eg. 
> 768MB to conntrack?

You could. And it would probably work.

> Another side question, can you add this information to the netfilter FAQ?

Probably. You are welcome to send an update. You have equal ability as me 
to update the FAQ.

Regards
Henrik

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Pablo Neira]

Hi Friedrich,

Friedrich Lobenstock wrote:

> Any suggestions for those parameters that are based on your experiences?

maybe this could be interesting for you, it's related to conntrack system.

http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
http://bei.bof.de/

I don't know how up to date they are, actually they are still in my 
queue of things to be read ;-).

regards,
Pablo

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Friedrich Lobenstock]

Pablo Neira wrote on 17.04.2004 21:08 MET:
> Hi Friedrich,
> 
> Friedrich Lobenstock wrote:
> 
>> Any suggestions for those parameters that are based on your experiences?
> 
> 
> maybe this could be interesting for you, it's related to conntrack system.
> 
> http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
> http://bei.bof.de/
> 
> I don't know how up to date they are, actually they are still in my 
> queue of things to be read ;-).

BIG THANKS for the links!

May I suggest to add the first link to the faq?

-- 
MfG / Regards
Friedrich Lobenstock

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Friedrich Lobenstock]

Friedrich Lobenstock wrote on 17.04.2004 21:58 MET:
> Pablo Neira wrote on 17.04.2004 21:08 MET:
> 
>> Hi Friedrich,
>>
>> Friedrich Lobenstock wrote:
>>
>>> Any suggestions for those parameters that are based on your experiences?
>>
>>
>>
>> maybe this could be interesting for you, it's related to conntrack 
>> system.
>>
>> http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
>> http://bei.bof.de/
>>
>> I don't know how up to date they are, actually they are still in my 
>> queue of things to be read ;-).
> 
> 
> BIG THANKS for the links!
> 
> May I suggest to add the first link to the faq?
> 

As the hash algorithm needs the hash size to be prime, here a link to find 
a fitting one http://www.prime-numbers.org/ which should be linked right 
after the above mentioned link.

-- 
MfG / Regards
Friedrich Lobenstock

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Martin Josefsson]

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

On Sat, 2004-04-17 at 22:18, Friedrich Lobenstock wrote:

> As the hash algorithm needs the hash size to be prime, here a link to find 
> a fitting one http://www.prime-numbers.org/ which should be linked right 
> after the above mentioned link.

The new hashfunction (jenkins) doesn't need that (2.4 and 2.6 has it).
It's very happy with 2^n sizes, in fact it's happy with all sizes :)

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Friedrich Lobenstock]

Martin Josefsson wrote on 17.04.2004 22:33 MET:
> On Sat, 2004-04-17 at 22:18, Friedrich Lobenstock wrote:
> 
>>As the hash algorithm needs the hash size to be prime, here a link to find 
>>a fitting one http://www.prime-numbers.org/ which should be linked right 
>>after the above mentioned link.
> 
> The new hashfunction (jenkins) doesn't need that (2.4 and 2.6 has it).
> It's very happy with 2^n sizes, in fact it's happy with all sizes :)

Since which official kernel 2.4 release do we have the new hash? If it is 
just 2.4.24 or up then you should still need to mention this fact about the 
prime number. See the one guy posting about kernel 2.4.20.

PS: Please respect the "Reply-to". Thanks!

-- 
MfG / Regards
Friedrich Lobenstock

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Martin Josefsson]

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

On Sat, 2004-04-17 at 22:41, Friedrich Lobenstock wrote:

> > The new hashfunction (jenkins) doesn't need that (2.4 and 2.6 has it).
> > It's very happy with 2^n sizes, in fact it's happy with all sizes :)
> 
> Since which official kernel 2.4 release do we have the new hash? If it is 
> just 2.4.24 or up then you should still need to mention this fact about the 
> prime number. See the one guy posting about kernel 2.4.20.

I don't remember since which kernel. Tell the person who wrote that
document to update it.
Please don't mention kernel 2.4.20, conntrack is horribly broken in
2.4.20 unless patched...

> PS: Please respect the "Reply-to". Thanks!

Only if you respect mine (or the lack of one) :)

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Friedrich Lobenstock]

Martin Josefsson wrote on 17.04.2004 22:58 MET:
> On Sat, 2004-04-17 at 22:41, Friedrich Lobenstock wrote:
> 
> 
>>>The new hashfunction (jenkins) doesn't need that (2.4 and 2.6 has it).
>>>It's very happy with 2^n sizes, in fact it's happy with all sizes :)
>>
>>Since which official kernel 2.4 release do we have the new hash? If it is 
>>just 2.4.24 or up then you should still need to mention this fact about the 
>>prime number. See the one guy posting about kernel 2.4.20.
> 
> I don't remember since which kernel. Tell the person who wrote that
> document to update it.

I just got this link from Pablo and I am not a netfilter developer, so 
someone with higher professiency in the netfilter area might want to do that.

> Please don't mention kernel 2.4.20, conntrack is horribly broken in
> 2.4.20 unless patched...

I am not using it but I just wanted to show you that you can not expect 
that the versions without the improved hash are not deployed anymore.

-- 
MfG / Regards
Friedrich Lobenstock

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Herve Eychenne]

On Sat, Apr 17, 2004 at 10:58:14PM +0200, Martin Josefsson wrote:

> On Sat, 2004-04-17 at 22:41, Friedrich Lobenstock wrote:

> > > The new hashfunction (jenkins) doesn't need that (2.4 and 2.6 has it).
> > > It's very happy with 2^n sizes, in fact it's happy with all sizes :)

Too bad I didn't hear that from anyone when I posted the link to my
document some months ago...

> > Since which official kernel 2.4 release do we have the new hash? If it is 
> > just 2.4.24 or up then you should still need to mention this fact about the 
> > prime number. See the one guy posting about kernel 2.4.20.

> I don't remember since which kernel. Tell the person who wrote that
> document to update it.
> Please don't mention kernel 2.4.20, conntrack is horribly broken in
> 2.4.20 unless patched...

I've checked, and the change in hash algorithm appeared in 2.4.21.
I have updated the document accordingly.

Here is the new version:
http://www.wallfire.org/misc/netfilter_conntrack_perf.txt

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Friedrich Lobenstock]

Herve Eychenne wrote on 22.04.2004 14:23 MET:
> 
> I've checked, and the change in hash algorithm appeared in 2.4.21.
> I have updated the document accordingly.
> 
> Here is the new version:
> http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
> 

Hmmmm....."Last changes on 12/02/2003" ?

PS: A BIG THANKS for that document. I has helped me a lot getting a better 
understanding of the matter.

-- 
MfG / Regards
Friedrich Lobenstock

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Tarek W.]

On Sat, 2004-04-17 at 22:58, Friedrich Lobenstock wrote:
> Pablo Neira wrote on 17.04.2004 21:08 MET:
> > Hi Friedrich,
> > 
> > Friedrich Lobenstock wrote:
> > 
> >> Any suggestions for those parameters that are based on your experiences?
> > 
> > 
> > maybe this could be interesting for you, it's related to conntrack system.
> > 
> > http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
> > http://bei.bof.de/
> > 
> > I don't know how up to date they are, actually they are still in my 
> > queue of things to be read ;-).
> 
> BIG THANKS for the links!
> 
> May I suggest to add the first link to the faq?

it will be, the answer will also reflect this thread... unfortunately,
there remains the matter of a missing Makefile to generate the FAQ from
the latest xml sources, if anybody would like to contribute one, please
submit it to this list.

if anybody would like to take a peek at the latest FAQ in html, it's
available at http://ticallion.lonecoder.net/pub/faq/, when the Makefile
issue is resolved, it will be available at netfilter.org

Re: question regarding iptables tuning (was Re: iptables denial of services)

[Tarek W.]

On Sat, 2004-04-17 at 22:58, Friedrich Lobenstock wrote:
> Pablo Neira wrote on 17.04.2004 21:08 MET:
> > Hi Friedrich,
> > 
> > Friedrich Lobenstock wrote:
> > 
> >> Any suggestions for those parameters that are based on your experiences?
> > 
> > 
> > maybe this could be interesting for you, it's related to conntrack system.
> > 
> > http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
> > http://bei.bof.de/
> > 
> > I don't know how up to date they are, actually they are still in my 
> > queue of things to be read ;-).
> 
> BIG THANKS for the links!
> 
> May I suggest to add the first link to the faq?

it will be, the answer will also reflect this thread... unfortunately,
there remains the matter of a missing Makefile to generate the FAQ from
the latest xml sources, if anybody would like to contribute one, please
submit it to this list.

if anybody would like to take a peek at the latest FAQ in html, it's
available at http://ticallion.lonecoder.net/pub/faq/, when the Makefile
issue is resolved, it will be available at netfilter.org