Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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
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  = sshd and  = sshd2.
Another interesting here below is my last 30 days logs for httpd
--------------------- httpd Begin ------------------------
(..)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  = sshd and  = sshd2.
I don't see any log so I have no idea.
Originally Posted by newbie14
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 ?
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.
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?
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.
What is the best command to verify the services we are running against what is captured by logwatch?
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:
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.
[Sun Aug 04 07:06:53 2013] [error] [client 184.108.40.206] File does not exist: /var/www/html/FastHTTPAuthScanner200test
[Sun Aug 04 07:07:06 2013] [error] [client 220.127.116.11] File does not exist: /var/www/html/admin
[Sun Aug 04 07:07:24 2013] [error] [client 18.104.22.168] File does not exist: /var/www/html/~root
[Sun Aug 04 07:07:41 2013] [error] [client 22.214.171.124] File does not exist: /var/www/html/configuration_administrator
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 ?