> For example, we had a problem report on #apache a couple of days ago
> which turned out, after considerable investigation, to be the result
> of a single host ip issuing hundreds of request connections in a few
> minutes. Whether this was a deliberate attack or simply a buggy
> client is not clear (to me) but the temporary solution of blocking
> the ip address was certainly within the server admin's abilities.
That could have easily just been one of these 'commercial'
companies that are just testing sites for 'availabilty' and
publishing the results. There are lots of these.
Only one example...
http://www.internethealthreport.com
These guys might hit you hard and fast at any moment
and they aren't sending any data... they just want to
see how fast you can 'answer the phone' and they
turn that into a 'site health' statistic.
Roy was right in his previous message.
Apache USED to try and log something for all
broken inbound connect requests but that, itself,
turned into a 'please fix this right away' bug report
when people's log files went through the roof.
In the case you just mentioned... it is going to take
a special 'filter' to 'sense' that a possible DOS
attack is in progress. Just fair amounts of 'dataless'
connection requests from one or a small number of orgins
doesn't qualify. There are plenty of official
algorithms around now to 'sense' most of these
brute force attacks and ( only then ) pop you an
'alert' or something.
Just relying on a gazillion entries in a log file isn't
the right way to 'officially' distinguish a DOS attack
from just ( as Roy says ) 'life on the Internet'.
All major browsers will abandon pending connect threads
for a web page whenever you hit the BACK button, as well.
Connects in progress at the socket level will still complete
but no data will be sent because the threads have all died.
Happens 24x7x365.
The 5 second rule still applies.
If people don't see good content showing up within 5 seconds
they will click away from you and all the threads pending
connects to you die immediately.... but all you might
see are tons of 'dataless' connect completions on your end.
It's not worth logging any of it.
Yours...
Kevin Kiley
In a message dated 10/25/2004 11:23:24 PM Central Daylight Time, [EMAIL PROTECTED] writes:
> This is not an error that the server admin can solve -- it is normal
> life on the Internet. We really shouldn't be logging it except when
> on DEBUG level.
That was my first reaction, too. However, Ivan Ristic pointed out that
(in some cases, anyway) it is the result of a DoS attack, and there may
be something a server admin can do about it. Or, if not, at least they
might know why their server is suddenly performing badly.
For example, we had a problem report on #apache a couple of days ago
which turned out, after considerable investigation, to be the result
of a single host ip issuing hundreds of request connections in a few
minutes. Whether this was a deliberate attack or simply a buggy
client is not clear (to me) but the temporary solution of blocking
the ip address was certainly within the server admin's abilities.
