Logwatch now showing
 

Hi,
I notice suddenly my logwatch is not showing me anything with regards to httpd whereas there are so many activities going on and it also not showing the ssh login log either. Anything wrong because I am using the same command throughout and earlier I use to have thing. Here is my command just say for last 10 days.

logwatch --detail High --service All --range -10 --archives --numeric > ~/logwatch.test

I explained before to you how you can use logwatch in --debug mode and grep for things to find out what gets processed.

Dear Unspawn,
Ok the debug is helpful and I notice it look into my httpd and ssh logs. So for the benefit of the rest my earlier mistake was not putting days is should be logwatch --detail High --service All --range '-10 days' --archives --numeric > ~/logwatch.test. It got some more discovery made and puzzles me it shows that it is picking the ssh during debug but when I generate the log there is no ssh entries shown. I can see in my debug mode All Services: is showing me this [74] = sshd and [75] = sshd2.

Another interesting here below is my last 30 days logs for httpd


Here is my last 21 days.


Can you see the difference why isn't that the last 30 days have a full coverage and should be covering what is shown in the last 21 days ?

I don't see any log so I have no idea.


If those requests were made in the first week then the report covering the last three weeks wouldn't show them?

BTW please review your Apache configuration because if you're still running mod_proxy I'm gonna smack you.

Dear Unspawn,
I have email you my file (logwatch240813_debug) with the debug capability because its not allowed to be uploaded here due to file size. Back to report coverage. Ok with regards to the report if say I need for the last 30 days I guess I must put the between which I got it after doing some reading where if I just put -21 days will just the last 21st day and -30 days will be just the 30th day. Can you see why my sshd or fail2ban is not being reported too in the logwatch?

I have also attached the httpd.conf file where I have double check all those with proxy I have commented it out. Any chance for other loop hole?

No, that is not OK. You really should not email me files without me explicitly requesting it.

Dear Unspawn,
Sorry for the mistake it shall not happen again.

OK. I'll get on it when I find the time.

Dear Unspawn,
Many apology for my mistake and extremely sorry for that hope is forgiven. Sorry.

Start by defining (in /etc/logwatch/conf/logwatch.conf) only the services you actually run?
And it seems you correctly disabled all mod_proxy* DSO's.

Dear Unspawn,
I dont get you by what you saying here defining. But I know my mistake because when I run with range as 'between -30 days and today' it is showing correctly. So I guess is nothing is wrong with the logwatch all is ok fine. But how about proxy what else can I do to stop further proxy attacks.

I mean that if you do not run a service (say Pluto or sshd2) then you should not (need to) run that check. In your case you run sshd and not sshd2.


Check your actual (error) log file for any proxy (error) lines?

Dear Unspawn,
What is the best command to verify the services we are running against what is captured by logwatch? I will go through my http error log and get back to you if anything on proxy.

I don't know any better way than to manually compare contents of /usr/share/logwatch/scripts/services with what your package management says you have.
Doing it this way probably is NOT SAFE OR ALL-ENCOMPASSING:

Dear Unspawn,
Further to your advice I went through all the http error and access log which have been zipped. Below is what I find in the error log.

Here is what I found in the access log. Looks like they have managed to connect via this httpd right? How to stop this now ?


But then in logwatch I do see this line.

Sure the "GET / HTTP/1.1" with return code 200 is OK and it may look like the www.fbi.gov request got through except the content length for that page is about 50kb and not 30 bytes as the line claims: http://wiki.apache.org/httpd/FAQ#Why...y_log_files.3F


That likely was the CONNECT request.

Dear Unspawn,
Yes I have read the wiki pages it say it have to serve the minimal right. SO when it hit the connect it gets this HTTP/1.0" 405 235. Can I say that my proxy is not enabled and thus they can go through the next level? I also notice things like this. Is there anything else I can do to further hardened it. No doubt all this looks failed but I dont want to take chances.

There's no "next level": if proxying is disabled then they can't use it.


Grep your access / error logs for the complete line. Notice the requesting IP address. Then grep your logs for that IP address. Post those lines.


Basically you're running a development environment only specific users should be able to view so white listing your customers IP ranges (firewall or per service) would help cut down probes quite drastically.

Dear Unspawn,
I am not good with grep so I just zip and download the both acces and error log files. Below are the results from the access and error log files.

Access log. Actually the one with f=/etc/passwd its by myself trying to bypass and achieve the passwd file but it lucky failed to show up. The other one is not by me.

"


Error log is as follows.


I notice this File does not exist: /var/www/html/favicon.ico
[Mon Jul 22 23:27:24 2013] [error] [client 11.22.33.44] File does not exist: /var/www/html/tmm1/images/logo.jpg. I have never refered to my site any of the favicon.ico but I got a lot of this error. Any resolution to it ?

Most result in a 404 so that's good.



That's OK.

Dear Unspawn,
So what can be done with the 404 then anything further need to be strengthen here ? Actually what is this favicon.ico nothing serious I see many times this error ?

To cut things short: white list your customers IP ranges.

Dear Unspawn,
We have now moved this server from a development into production. The problem with white list is that we have to really build a lot of contraints and at times I notice some country the range show some strange range and mostly those coming from mobile phone connections? Are those 404 post danger ?

Infact I got whole list of 404 as below.

No.