[Logwatch] Cannot get $HTTP_IGNORE_IPS in http.conf to work

Bjorn L. bl_logwatch2 at mblmail.net
Tue Dec 25 23:12:34 MST 2007


 From the http script, looks like that $HTTP_IGNORE_IPS does
NOT affect that part of the httpd report.

We used to have a variable that I thought turned off the
code for 'exploit' strings.  The variable is in the config
file, but not referenced in the script.  The variable is
$HTTP_IGNORE_ERROR_HACKS.

I've changed the http script to reference that variable.
Download the current http from cvs, and try it again.

My opinion is that this 'exploits' code is not suitable
for Logwatch.  There are several reasons:

- Logwatch is not dynamic enough to keep up with potential
   exploits - it is not updated often enough for that.

- The Logwatch developers do not necessarily know, nor are
   notified about, what the latest and current exploits are,
   anyway.

- And even if that was the case, Logwatch does not prevent
   accesses - it just flags them after the fact (and usually,
   not even the same day).

- Logwatch lacks other run-time context, so that legitimate
   accesses may get flagged as hack attempts because of the
   simplistic regular expression matches Logwatch performs.

The code remains there for historical reasons.

As an aside, you don't need to copy the whole configuration
file to the /etc/logwatch directory.  So, for example, to
activate the above variable, you can have a single line
in the file /etc/logwatch/conf/services/http.conf:
$HTTP_IGNORE_ERROR_HACKS = 1


Bob McClure wrote:
> My client has three web servers and has contracted a security outfit
> to probe them for vulnerabilities.  As a result that throws a lot of
> chaff into the logwatch report for httpd.  I am trying to filter that
> stuff out so I can read the report again.
> 
> The environment is:
> 
> - Red Hat ES4, kept up to date
> - Logwatch v7.3.6 installed via RPM
> 
> I have copied /usr/share/logwatch/default.conf/services/http.conf to
> /etc/logwatch/conf/services/http.conf and customized it by adding a
> line specifying $HTTP_IGNORE_IPS.  I won't bore you with the log regex
> I put in there (which does The Right Thing(tm) when used as an
> argument to egrep), because I put a single IP in there for testing, like:
> 
> $HTTP_IGNORE_IPS = ^12\.34\.56\.178
> 
> and the logwatch report still comes up with:
> 
>  A total of 3 sites probed the server 
>     12.34.56.178
>     12.34.56.179
>     12.34.56.180
> 
>  A total of 802 possible successful probes were detected (the following URLs
>  contain strings that match one or more of a listing of strings that
>  indicate a possible exploit):
>  
>     /?course_intro=index.htm&know_your_boat=course%2Fp1-subtable.htm&before_getting_underway=course%2Fp2-subtable.htm&operating_your_boat=course%2Fp3-subtable.%2Fboot.ini&select=course%2Fp4-subtable.htm&boating_emergencies=course%2Fp5-subtable.htm&enjoying_water_sports=course%2Fp6-subtable.htm&chapter_reviews=chap_rev%2Fexer_chap1.htm&glossary=course%2Fglossary.htm%23AGROUND&tests=..%2Fcgi-local%2Fexam%2Fpractice.cgi%3Fst%3Din HTTP Response 200 
>     /../../../../../../../../../includes/admin/includes/admin/category.php? HTTP Response 302 
>       .
>       .
>       .
>     [MUCH more snipped]
> 
> Does $HTTP_IGNORE_IPS not affect that part of the httpd report, or
> have I committed some blunder (not unusual)?
> 
> Cheers,


More information about the Logwatch mailing list