On Wed, Jan 25, 2012 at 2:11 PM, Damien Hull <[email protected]> wrote: > I just turned of active response this morning... I may leave it off > unless I can fix this problem... >
Write a rule to ignore that specific instance. Something like this (TOTALLY UNTESTED): <rule id="ID_GOES_HERE" level="0"> <if_sid>31101</if_sid> <match>GET /theme/image.php?theme=moodlebook&image=favicon&rev=282&component=theme</match> <description>Ignore our janky theme 404s!</description> </rule> Personally I think you'd be better off with something else looking at your web logs (heresy, I know). Web crap is waaaaaaaay too complicated for a general purpose utility (primarily) worked on by volunteers to grok properly. Use something like mod_security, and have OSSEC watch its logs. > On Wed, Jan 25, 2012 at 8:03 AM, sempai <[email protected]> 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 >> <[email protected]> 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.
