You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ed Korthof <ed...@organic.com> on 1997/01/07 03:23:05 UTC
Problems w/ deny
I consider this a bug. Deny from statements are applied only after a request
has been read. This means that a remote host can use a very simple denial of
service attack to completely incapacitate a web server (unless you have a
firewall you can reconfigure to deny from that specific host). The remote host
opens a connection, then never asks for anything. The connection hangs until
you hit TimeOut -- the default is 1200 seconds, but even with a low value it's
possible to kill a server through 10 requests a second which simply hang till
they timeout.
I'm nearly done w/ a patch to prevent more than a configurable number of
connections from a single host; it should be done by Wednesday. Could we
consider including it in the 1.2 release? Given that you can't use "deny from
..." to protect from the above DoS attack, we should have some sort of
protection.
--
-- Ed Korthof | Web Server Engineer --
-- ed@organic.com | Organic Online, Inc --
-- (415) 278-5676 | Fax: (415) 284-6891 --
Re: Problems w/ deny
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 6 Jan 1997, Marc Slemko wrote:
> Has anyone thought of trying to make apache work with tcp wrappers'
> libwrap?
To follow up to this, I made a little addition to http_main.c to use
libwrap to check if the connection should be allowed, and reject it if
not.
Of quite limited normal use, but neat anyway. Isn't entirely clean,
because it needs to be before the server spends much time bothering with
the connection; if you want to be able to use hostnames reverse DNS lookup
is done once at the call to libwrap and once by the server, if enabled.
Same thing for identd queries.
I guess this would help if you had a known host being nasty to your server
and didn't want to use a packet filter, but doesn't do anything to prevent
problems, only to react to them.
Re: Problems w/ deny
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 6 Jan 1997, Cliff Skolnick wrote:
>
> The nasty tools that lock up web server use SYN attacks. Since the SYN
> attack takes place before the TCP three way handshake is complete, the
> application will not even know about it. Protecting against SYN attacks
> is pretty hard, and even those that say they do actually only make a lame
> attempt and stop some but not all. As for firewalls any good SYN bomb
> uses rotating IP source addresses, so not much good. This is a real
> problem that can not be solved 100%, except by changing TCP.
I don't think that is what he is thinking of. I think he is thinking of
the case where you simply open a connection (ie. complete the three-way
handshake) then do nothing. Takes lots more resources on the server side
than the client. Most servers all you need is a few hundred, and the
server can't do anything else even though you aren't requesting anything.
Has anyone thought of trying to make apache work with tcp wrappers'
libwrap?
>
> All the above aside, the idea to limit the number of connections to a
> single host is good. It could really lessen the risks of broken browsers
> and evil robots. As for including it, I don't think the denial of service
> argument is enough to include it in 1.2, next release is better IMHO.
> Anyone who needs to lock out an attack really has to do it at the
> firewall, not in each application.
>
> How about a "late-patch" directory for stuff that just missed the 1.2
> cutoff that is useful and will be included in the next release?
>
> On Mon, 6 Jan 1997, Ed Korthof wrote:
>
> > I consider this a bug. Deny from statements are applied only after a request
> > has been read. This means that a remote host can use a very simple denial of
> > service attack to completely incapacitate a web server (unless you have a
> > firewall you can reconfigure to deny from that specific host). The remote host
> > opens a connection, then never asks for anything. The connection hangs until
> > you hit TimeOut -- the default is 1200 seconds, but even with a low value it's
> > possible to kill a server through 10 requests a second which simply hang till
> > they timeout.
> >
> > I'm nearly done w/ a patch to prevent more than a configurable number of
> > connections from a single host; it should be done by Wednesday. Could we
> > consider including it in the 1.2 release? Given that you can't use "deny from
> > ..." to protect from the above DoS attack, we should have some sort of
> > protection.
> >
> > --
> > -- Ed Korthof | Web Server Engineer --
> > -- ed@organic.com | Organic Online, Inc --
> > -- (415) 278-5676 | Fax: (415) 284-6891 --
> >
>
> --
> Cliff Skolnick, Technical Consultant
> Steam Tunnel Operations
> cliff@steam.com, 415.297.5938
> http://www.steam.com/
>
>
Re: Problems w/ deny
Posted by Cliff Skolnick <cl...@steam.com>.
The nasty tools that lock up web server use SYN attacks. Since the SYN
attack takes place before the TCP three way handshake is complete, the
application will not even know about it. Protecting against SYN attacks
is pretty hard, and even those that say they do actually only make a lame
attempt and stop some but not all. As for firewalls any good SYN bomb
uses rotating IP source addresses, so not much good. This is a real
problem that can not be solved 100%, except by changing TCP.
All the above aside, the idea to limit the number of connections to a
single host is good. It could really lessen the risks of broken browsers
and evil robots. As for including it, I don't think the denial of service
argument is enough to include it in 1.2, next release is better IMHO.
Anyone who needs to lock out an attack really has to do it at the
firewall, not in each application.
How about a "late-patch" directory for stuff that just missed the 1.2
cutoff that is useful and will be included in the next release?
On Mon, 6 Jan 1997, Ed Korthof wrote:
> I consider this a bug. Deny from statements are applied only after a request
> has been read. This means that a remote host can use a very simple denial of
> service attack to completely incapacitate a web server (unless you have a
> firewall you can reconfigure to deny from that specific host). The remote host
> opens a connection, then never asks for anything. The connection hangs until
> you hit TimeOut -- the default is 1200 seconds, but even with a low value it's
> possible to kill a server through 10 requests a second which simply hang till
> they timeout.
>
> I'm nearly done w/ a patch to prevent more than a configurable number of
> connections from a single host; it should be done by Wednesday. Could we
> consider including it in the 1.2 release? Given that you can't use "deny from
> ..." to protect from the above DoS attack, we should have some sort of
> protection.
>
> --
> -- Ed Korthof | Web Server Engineer --
> -- ed@organic.com | Organic Online, Inc --
> -- (415) 278-5676 | Fax: (415) 284-6891 --
>
--
Cliff Skolnick, Technical Consultant
Steam Tunnel Operations
cliff@steam.com, 415.297.5938
http://www.steam.com/
intitial request read timeout
Posted by Rob Hartill <ro...@imdb.com>.
On 7 Jan 1997, Paul Richards wrote:
> The server should wait a fair while since network lag can cause
> problems otherwise.
how many seconds is "a fair while" ? :-)
However many it is, there's not going to be agreement on what to hardcode it
as, so a configurable value is the only solution.
My reasoning is that if a client can't give you the basics in a few seconds
(<=5) then it's not worth the server's resources to wait for it. There are
alternatives to telnet (copy'n'paste as well as trivial perl scripts).
Re: Problems w/ deny
Posted by Paul Richards <p....@elsevier.co.uk>.
Alexei Kosut <ak...@nueva.pvt.k12.ca.us> writes:
> On Tue, 7 Jan 1997, Rob Hartill wrote:
>
> > I think there should be a very small timeout of reading the request +
> > HTTP headers. I don't see why a server should wait more than a few (~5)
> > seconds for the basic request info.
>
> I do: in development, often it is necessary to telnet to the server
> and type in a request (sometimes a rather complex one) manually. This
> can upwards of 30 seconds. However, I agree 20 minutes is ridiculous.
Summarising a few elements of this thread.
The server should wait a fair while since network lag can cause
problems otherwise. 20 minutes sounds like a blunder though and can be
considered a genuine bug that should be fixed for 1.2.
Apache shouldn't concern itself with network attacks. Apache is a web
server not a firewall tool, make it a good web server and rely on
other people to supply good firewalls. If you're getting attacked by a
site then Apache is not the place to try and deal with it.
A feature that allowed you to control the number of simultaneous
connections from a site is a very good one though for a very different
reason, i.e. licensing. I currently control the number of simultaneous
users from a site using cgi scripts, making this possible via the
access control mechanism of the server would be very useful.
--
Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor)
Elsevier Science TIS online journal project.
Email: p.richards@elsevier.co.uk
Phone: 0370 462071 (Mobile), +44 (0)1865 843155
Re: Problems w/ deny
Posted by Rob Hartill <ro...@imdb.com>.
On Mon, 6 Jan 1997, Alexei Kosut wrote:
> On Tue, 7 Jan 1997, Rob Hartill wrote:
>
> > I think there should be a very small timeout of reading the request +
> > HTTP headers. I don't see why a server should wait more than a few (~5)
> > seconds for the basic request info.
>
> I do: in development, often it is necessary to telnet to the server
> and type in a request (sometimes a rather complex one) manually. This
> can upwards of 30 seconds. However, I agree 20 minutes is ridiculous.
Hmmm, I wouldn't consider that a good enough reason to set the Timeout
high. At worst you can paste a complex request into a telnet session.
I once set this timeout to something very low and had to do just that
as a workaround.
Re: Problems w/ deny
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Tue, 7 Jan 1997, Rob Hartill wrote:
> I think there should be a very small timeout of reading the request +
> HTTP headers. I don't see why a server should wait more than a few (~5)
> seconds for the basic request info.
I do: in development, often it is necessary to telnet to the server
and type in a request (sometimes a rather complex one) manually. This
can upwards of 30 seconds. However, I agree 20 minutes is ridiculous.
--
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us> The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/ http://www.apache.org/
Re: Problems w/ deny
Posted by Rob Hartill <ro...@imdb.com>.
On Mon, 6 Jan 1997, Ed Korthof wrote:
> I consider this a bug. Deny from statements are applied only after a request
> has been read. This means that a remote host can use a very simple denial of
> service attack to completely incapacitate a web server (unless you have a
> firewall you can reconfigure to deny from that specific host). The remote host
> opens a connection, then never asks for anything. The connection hangs until
> you hit TimeOut -- the default is 1200 seconds, but even with a low value it's
> possible to kill a server through 10 requests a second which simply hang till
> they timeout.
I think there should be a very small timeout of reading the request +
HTTP headers. I don't see why a server should wait more than a few (~5)
seconds for the basic request info.
> I'm nearly done w/ a patch to prevent more than a configurable number of
> connections from a single host; it should be done by Wednesday. Could we
> consider including it in the 1.2 release?
Mmm, there's a lot of features being proposed when we're supposed to be
in bug-fix mode. Can this go in the patches dir instead ?
Adding a reasonable request reading Timeout I'd consider a bugfix, adding
a resource capping system I'd consider a feature.
if it's big, I'll probably veto it with a recommendation it goes in the
patches directory.
Ben, as release manager can you clarify the position on features/fixes
and give us a timetable to aim at. I feel we're losing direction and
momentum. 1.2 final was supposed to be the same as 1.2b1 + fixes.
rob