The problem is that the 404 is not for the static file favicon.ico, but for a .php script that is passed favicon.ico as an argument and returns a 404. Either /theme/image.php does not exist, or it is written to return a 404 when passed a non-existent filename as an argument. In any case, I think the active response is acting appropriately by taking action against repeated 404's on a php script, don't you? The solution then is webserver-side; either rewrite requests for favicon.ico, rewrite the php, or, simplest of all, upload a favicon.ico, even a blank one. Maybe configure your webserver to ignore or not log favicon requests. Something that actually addresses the 404 error itself.
Cheers, --ScottVR On Jan 25, 2012, at 1:11 PM, Damien Hull <dh...@section9.us> wrote: > I just turned of active response this morning... I may leave it off > unless I can fix this problem... > > On Wed, Jan 25, 2012 at 8:03 AM, sempai <sem...@hellyeah.com> wrote: >> I alert and block on many but not all web servers for precisely this reason, >> but I knew what Active Response did before I turned it on and complained >> about it working. >> >> There are a lot of vulnerability probes and assessment tools that look >> specifically for certain urls and generate 404s while doing so. It's a >> high-value signature, but requires more than rudimentary understanding of >> web servers. >> >> On Wed, 25 Jan 2012 08:33:15 -0600, Steven Stern wrote: >> >> I get a lot of 404 alerts, and I let OSSEC block access when it's >> multiples from the same IP. Typically, they're looking for phpmyadmin or >> other common (and probably poorly secured tools) in a number of locations. >> >> On 01/24/2012 11:33 PM, Damien Hull wrote: >> >> It looks like someone was requesting thee favicon and the server replied >> with "404"... How does that equal a level 10 alert? Anyway, here's the log >> info. GET >> /theme/image.php?theme=moodlebook&image=favicon&rev=282&component=theme >> HTTP/1.1" 404 290 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; >> Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR >> 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3; IPH 1.1.21.4019)" On >> Tue, Jan 24, 2012 at 10:32 AM, Jason 'XenoPhage' Frisvold >> <xenoph...@godshell.com> wrote: >> >> On Jan 24, 2012, at 8:37 AM, Joe Gedeon wrote: >> >> You should look at your logs and see what is triggering the 400's and fix >> that issue if it is a server side issue. >> >> Agreed. Basically, the web browser is trying to obtain something from the >> server that's just not there. Thus, 400 errors are triggered. As a result, >> OSSEC sees a bunch of these fly by and considers it an attack. It's far >> better to fix the underlying problem than to alter OSSEC to ignore such >> things.
