Logwatch, webserver logs, PHP malarky
Posted 10-03-2009 at 05:52 AM by unSpawn
As I'm seeing more questions about (badly coded) web applications spawning rogue processes I wonder why people don't read their logs. Attacks require reconnaissance so keeping an eye on anything that looks like a prelude enables you to take measures. And please spend time updating when updates are released, installing apps properly (like not leaving the installation files around when docs remind you not to), hardening (any IDS, mod_security, Gotroot rulesets, mod_evasive or equivalent, PHPIDS, Suhosin, GreenSQL).
If you have any questions regarding this please ask them in the LQ Linux Security forum. We'd be happy to help you along.
Finding preludes to attacks by visual inspection of logfiles is cumbersome and tedious and that's why there is Logwatch to help you as it creates reports you can actually read. Logwatch unfortunately doesn't by default include rules to filter common crack signs like gotroot's mod_security/rootkits.conf but that's easily alleviated.
Locate your scripts/services/http file (might be "/usr/share/logwatch/scripts/services/http" if it's a default installation) and patch it with this:
If there's lines in your webservers logs your Logwatch report will show:
which should be your cue to investigate things immediately.
Note this is a patch against a checkout of the Logwatch CVS. If patching fails (always try testing with --dry-run and the appropriate amount of --fuzz) then check the code at around line 300 between the line starting with "my @exploits = (" and "# Define some useful RE paterns".
Also note that Logwatch takes the --service arg so you could run Logwatch as a daily cronjob on all logs (which will be slow if you've got lots of logs) and something like 'logwatch --detail High --service http --range Today' as a hourly cronjob.
If you have any questions regarding this please ask them in the LQ Linux Security forum. We'd be happy to help you along.
Finding preludes to attacks by visual inspection of logfiles is cumbersome and tedious and that's why there is Logwatch to help you as it creates reports you can actually read. Logwatch unfortunately doesn't by default include rules to filter common crack signs like gotroot's mod_security/rootkits.conf but that's easily alleviated.
Locate your scripts/services/http file (might be "/usr/share/logwatch/scripts/services/http" if it's a default installation) and patch it with this:
Code:
--- http 2008-06-30 22:47:20.000000000
+++ http 2009-10-02 00:00:00.000000000
@@ -334,6 +334,45 @@
'shtml\.exe',
'win\.ini',
'xxxxxxxxxxxxxxxxxxxxxx',
+ 'wget%20',
+ 'perl%20',
+ 'nc%20',
+ 'cd%20',
+ 'python%20',
+ 'rpm%20',
+ 'yum%20',
+ 'apt-get%20',
+ 'emerge%20',
+ 'lynx%20',
+ 'links%20',
+ 'mkdir%20',
+ 'elinks%20',
+ 'cmd%20',
+ 'wget%20',
+ 'lwp-download%20',
+ 'lwp-request%20',
+ 'lwp-mirror%20',
+ 'lwp-rget%20',
+ 'uname',
+ 'cvs%20',
+ 'svn%20',
+ 'sh%20',
+ 'netstat',
+ 'netcat%20',
+ 'rexec%20',
+ 'smbclient%20',
+ 'tftp%20',
+ 'ftp%20',
+ 'ncftp%20',
+ 'curl%20',
+ 'telnet%20',
+ 'gcc%20',
+ 'cc%20',
+ 'whoami',
+ 'killall',
+ 'kill%20',
+ 'rm%20',
+ 'tar%20',
);
#
Code:
Attempts to use known hacks by 5 hosts were logged 35 time(s) from:
000.0.0.0: 16 Time(s)
uname 7 Time(s)
tar%20 1 Time(s)
cd%20 2 Time(s)
perl%20 1 Time(s)
wget%20 4 Time(s)
rm%20 1 Time(s)
000.0.0.0: 10 Time(s)
cd%20 2 Time(s)
perl%20 2 Time(s)
wget%20 4 Time(s)
rm%20 2 Time(s)
Note this is a patch against a checkout of the Logwatch CVS. If patching fails (always try testing with --dry-run and the appropriate amount of --fuzz) then check the code at around line 300 between the line starting with "my @exploits = (" and "# Define some useful RE paterns".
Also note that Logwatch takes the --service arg so you could run Logwatch as a daily cronjob on all logs (which will be slow if you've got lots of logs) and something like 'logwatch --detail High --service http --range Today' as a hourly cronjob.
