Hi everyone,
I posted this once on Pike list, and got no reply, so I am trying here, perhaps devel list is better place...
I found that it is impossible to specify backlog parameter when using Stdio.Port - it is hardcoded to 16384. Actually, the questions are - what should I do to actually limit backlog value? And - why it is hardcoded?
Problem with current implementation: it is relatively easy to make a DoS attack against everything that listening through Stdio.Port (most used apps: Roxen & Caudium). Any comments? :) Regards, /Al
The DoS would be that a client establishes connections faster than the server handles them? How would a shorter backlog make such a DoS less severe? Afaics the only effect would be that the DoS frequency would be different (shorter connection queue => takes less time to fill it => shorter but more frequent DoS intervals).
As for why it's hardcoded I don't know. I suspect it's only because the author thought noone would feel the need to to twiddle it (which apparently was incorrect).
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-22 00:24: Subject: Stdio.port listen() backlog again...
Hi everyone,
I posted this once on Pike list, and got no reply, so I am trying here, perhaps devel list is better place...
I found that it is impossible to specify backlog parameter when using Stdio.Port - it is hardcoded to 16384. Actually, the questions are - what should I do to actually limit backlog value? And - why it is hardcoded?Problem with current implementation: it is relatively easy to make a DoS attack against everything that listening through Stdio.Port (most used apps: Roxen & Caudium).
Any comments? :)
Regards, /Al
/ Brevbäraren
On Wed, Jan 22, 2003 at 01:30:01AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
The DoS would be that a client establishes connections faster than the server handles them? How would a shorter backlog make such a DoS less severe?
Shorter backlog would cause connections to be rejected on the OS level, so those will never reach the server (application) itself. Those rejected sockets (slots) would be freed quicker, since no connections will be established.
On the other hand, when application has to handle all connections, it will be significantly slower and will use much more resources (since it is interpreted anyway).
the author thought noone would feel the need to to twiddle it (which apparently was incorrect).
Is it planned to be fixed? It can be done easily, even without losing compatibility - by adding one parameter (or function).
Additionally, it would be good to limit number of connects (sessions), not only for web servers but for other session-based apps, completely transparently to the application itself (it was original intent for backlog parameter).
Regards, /Al
The DoS would be that a client establishes connections faster than the server handles them? How would a shorter backlog make such a DoS less severe?
Shorter backlog would cause connections to be rejected on the OS level, so those will never reach the server (application) itself. Those rejected sockets (slots) would be freed quicker, since no connections will be established.
How would that improve anything? Other users would get connection refused instead of having to wait for a somewhat slower server. Some service is better than none.
/ Henrik Grubbström (Lysator)
Previous text:
2003-01-22 02:23: Subject: Re: Stdio.port listen() backlog again...
On Wed, Jan 22, 2003 at 01:30:01AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
The DoS would be that a client establishes connections faster than the server handles them? How would a shorter backlog make such a DoS less severe?
Shorter backlog would cause connections to be rejected on the OS level, so those will never reach the server (application) itself. Those rejected sockets (slots) would be freed quicker, since no connections will be established.
On the other hand, when application has to handle all connections, it will be significantly slower and will use much more resources (since it is interpreted anyway).
the author thought noone would feel the need to to twiddle it (which apparently was incorrect).
Is it planned to be fixed? It can be done easily, even without losing compatibility - by adding one parameter (or function).
Additionally, it would be good to limit number of connects (sessions), not only for web servers but for other session-based apps, completely transparently to the application itself (it was original intent for backlog parameter).
Regards, /Al
/ Brevbäraren
It it might decrease the load and memory usage on the server a little, which is nice for users that use it for something different than http.
I don't think it matter much, though.
And don't forget that in a traditional unix, it's possible to decrease the backlog below 7, but it's not possible to use a larger backlog; all values for backlog parameter that are larger than seven simply mean seven.
I don't know if that limit is changed in more modern incarnations, but I think the point of using a large value for the backlog parameter is simply to make sure that you use the largest backlog that is supported by the kernel. Which is often 7, or some similarly small number.
/ Niels Möller ()
Previous text:
2003-01-22 10:35: Subject: Re: Stdio.port listen() backlog again...
The DoS would be that a client establishes connections faster than the server handles them? How would a shorter backlog make such a DoS less severe?
Shorter backlog would cause connections to be rejected on the OS level, so those will never reach the server (application) itself. Those rejected sockets (slots) would be freed quicker, since no connections will be established.
How would that improve anything? Other users would get connection refused instead of having to wait for a somewhat slower server. Some service is better than none.
/ Henrik Grubbström (Lysator)
The maximum is 128 on Linux. The man page mentions that it's only 5 on BSD and some derived systems.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-22 10:43: Subject: Re: Stdio.port listen() backlog again...
It it might decrease the load and memory usage on the server a little, which is nice for users that use it for something different than http.
I don't think it matter much, though.
And don't forget that in a traditional unix, it's possible to decrease the backlog below 7, but it's not possible to use a larger backlog; all values for backlog parameter that are larger than seven simply mean seven.
I don't know if that limit is changed in more modern incarnations, but I think the point of using a large value for the backlog parameter is simply to make sure that you use the largest backlog that is supported by the kernel. Which is often 7, or some similarly small number.
/ Niels Möller ()
The Solaris manpage says:
NOTES There is currently no backlog limit.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-01-22 17:19: Subject: Re: Stdio.port listen() backlog again...
The maximum is 128 on Linux. The man page mentions that it's only 5 on BSD and some derived systems.
/ Martin Stjernholm, Roxen IS
On Wed, Jan 22, 2003 at 10:40:03AM +0100, Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum wrote:
How would that improve anything? Other users would get connection refused instead of having to wait for a somewhat slower server. Some service is better than none.
If server is under heavy load, especially in case of DoS, it will protect the server and the system from complete overloading and/or using all available resources.
Also please think about some OS limitations - a thousands of open sockets may prevent the system from accepting _other_ connections, not only directed to the application itself.
And again - I already said that presence of backlog would allow to place artifical limits to number of active sessions, completely transparent to the application itself.
Regards, /Al
No, it does not in any way make it possible to limit the number of active sessions.
The backlog size does not change the number of connections that can be opened. At all.
/ Per Hedbor ()
Previous text:
2003-01-22 15:31: Subject: Re: Stdio.port listen() backlog again...
On Wed, Jan 22, 2003 at 10:40:03AM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
How would that improve anything? Other users would get connection refused instead of having to wait for a somewhat slower server. Some service is better than none.
If server is under heavy load, especially in case of DoS, it will protect the server and the system from complete overloading and/or using all available resources.
Also please think about some OS limitations - a thousands of open sockets may prevent the system from accepting _other_ connections, not only directed to the application itself.
And again - I already said that presence of backlog would allow to place artifical limits to number of active sessions, completely transparent to the application itself.
Regards, /Al
/ Brevbäraren
On Wed, Jan 22, 2003 at 03:55:03PM +0100, Per Hedbor () @ Pike (-) developers forum wrote:
The backlog size does not change the number of connections that can be opened. At all.
OK, not opened - waiting to be accepted. Currently there is no way to notify the client that service is unavailable due to high server load, with backlog we can do this.
Otherwise the server has to accept every connection and immediately close it (not every protocol supports "5xx Service not available").
Well, but now I would like to ask - the Pike team is strongly against backlog parameter or what? :) If against, I would like to know why.
Regards, /Al
Well, but now I would like to ask - the Pike team is strongly against backlog parameter or what? :) If against, I would like to know why.
I don't think anyone has argued against the parameter yet.
/ Peter Bortas
Previous text:
2003-01-22 16:12: Subject: Re: Stdio.port listen() backlog again...
On Wed, Jan 22, 2003 at 03:55:03PM +0100, Per Hedbor () @ Pike (-) developers forum wrote:
The backlog size does not change the number of connections that can be opened. At all.
OK, not opened - waiting to be accepted. Currently there is no way to notify the client that service is unavailable due to high server load, with backlog we can do this.
Otherwise the server has to accept every connection and immediately close it (not every protocol supports "5xx Service not available").
Well, but now I would like to ask - the Pike team is strongly against backlog parameter or what? :) If against, I would like to know why.
Regards, /Al
/ Brevbäraren
I don't think anyone has argued against the parameter yet.
However, people using it should be very aware of the fact that it is in no way guaranteed to actually limit the backlog.
I just ran a small test-program on NT, and no limitation took place, even when I configured the backlog to be 0.
Other OS:es might very well exhibit similar behaviours.
/ Per Hedbor ()
Previous text:
2003-01-22 16:18: Subject: Re: Stdio.port listen() backlog again...
Well, but now I would like to ask - the Pike team is strongly against backlog parameter or what? :) If against, I would like to know why.
I don't think anyone has argued against the parameter yet.
/ Peter Bortas
That is an argument against, I suppose.
/ Martin Nilsson (Åskblod)
Previous text:
2003-01-22 17:20: Subject: Re: Stdio.port listen() backlog again...
I don't think anyone has argued against the parameter yet.
However, people using it should be very aware of the fact that it is in no way guaranteed to actually limit the backlog.
I just ran a small test-program on NT, and no limitation took place, even when I configured the backlog to be 0.
Other OS:es might very well exhibit similar behaviours.
/ Per Hedbor ()
Not really. Pike already has support for a lot of things that aren't equally well supported on all platforms.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-22 20:06: Subject: Re: Stdio.port listen() backlog again...
That is an argument against, I suppose.
/ Martin Nilsson (Åskblod)
You should be able to shoot yourself in the foot if you want to. :)
/ Mirar
Previous text:
2003-01-22 17:20: Subject: Re: Stdio.port listen() backlog again...
I don't think anyone has argued against the parameter yet.
However, people using it should be very aware of the fact that it is in no way guaranteed to actually limit the backlog.
I just ran a small test-program on NT, and no limitation took place, even when I configured the backlog to be 0.
Other OS:es might very well exhibit similar behaviours.
/ Per Hedbor ()
The argument has mostly been about the effect of the backlog in a DoS attack, not against making it configurable.
I model the situation like this: A factor k of all incoming connections are DoS generators during an attack. The server handles the connections slower than they come in, and the backlog becomes full so connections get rejected with a factor l. Of those rejected connections would the same factor k as above be DoS generators. The longer backlog don't affect the speed in which the server is processing the incoming connections. So barring transient effects none of this is affected by the backlog length.
The only effect I can see is that the longer backlog in itself consumes more system resources. With a reasonable queue implementation, the only resource that can be significantly taxed would be the available port numbers for incoming connections. So it could affect connections to other applications on the server, as you've pointed out. But besides that the DoS would be just as bad anyway.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-22 16:12: Subject: Re: Stdio.port listen() backlog again...
On Wed, Jan 22, 2003 at 03:55:03PM +0100, Per Hedbor () @ Pike (-) developers forum wrote:
The backlog size does not change the number of connections that can be opened. At all.
OK, not opened - waiting to be accepted. Currently there is no way to notify the client that service is unavailable due to high server load, with backlog we can do this.
Otherwise the server has to accept every connection and immediately close it (not every protocol supports "5xx Service not available").
Well, but now I would like to ask - the Pike team is strongly against backlog parameter or what? :) If against, I would like to know why.
Regards, /Al
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (�skblod) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Niels M�ller () ＠ Pike (-) developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum