Security Incidents mailing list archives
Re: PHP injection attempt from 200.222.244.154
From: Jez Hancock <jez.hancock () gmail com>
Date: Tue, 7 Dec 2004 23:46:21 +0000
On Tue, 07 Dec 2004 19:24:09 +0000, Barrie Dempster <barrie () reboot-robot net> wrote:
On Sun, 2004-12-05 at 00:00 +0000, Jez Hancock wrote: <snip>I'd thought about doing something similar to KEM Hosting's script above regarding turning tables or automating in some how an abuse complaint procedure. For a while I started to notify the owners of domains that were hosting the injection scripts that they possibly had a problem, but this got tedious quite quickly. Automating the procedure by intercepting the requests for bad URIs and redirecting them to a script that drafts together an abuse report might be interesting and save some time though.I'm not a real fan of automated action against intruders, it's often too easy to abuse it for nefarious purposes.
Well the only part that I foresee being automated is the *drafting* of an abuse report. I should have added that the report/message would then be flagged/forwarded for inspection by a responsible party within the organisation - security officer, owner of boxen, whatever - who could then inspect the drafted abuse report/message for sanity before inspecting the problem further or forwarding the abuse email on. Depending on how successfully the automated abuse report building script is, checking over the report/mail for mistakes should be trivial and just involve as little as approving/sending off the report. I did something similar in a perl script when my network became the target of (relatively small scale - less than a dozen at a time) distributed denial of service attacks a while ago. After detecting a sustained attack from a set of IP addresses - ie a number of unacceptable log entries in the firewall log from certain addresses - I would initiate this script to help me build an abuse report that I could forward to the ISPs responsible for the addresses involved in the attacks. For each address the process of building the report would be cut from 5-10 minutes down to just a minute or two. I'd run the script in 'pre report' mode for an individual IP address first to gather info from whois, nmap, host and other network analysis/research tools. Info from this analysis would be placed in a directory which I could then sift through quickly to find who I wanted to send abuse report(s) to - email addresses basically. I'd then run the script again passing the problem IP address and email addresses to whom the reports would be sent on the command line as arguments. The script would then generate an abuse report containing a boilerplate abuse complaint/report, filling in the 'blanks' with the IP address, email addresses/headers and other relevant info (including all the firewall log entries pertaining to the report - so often the mail was pretty large!). Finally the script would drop the simple email message in a file which I could then check over quickly with a mail client (mutt!) and I could then just 'bounce' the message on to the final recipients. I never really had the need to refine the script further because I never got attacked too often and at the end of the day whilst the attacks were annoying, the fact that the firewall actually blocked them in the first place was enough peace of mind really. I only ran the script when the sheer volume of the traffic generated by the attacks really did deny my network of service for more than a few hours at a time. The script help output was as follows (very simple script/hack really!): Usage: $progname [-h] -i <ip address> -t "<mail addresses>" -l <logfile> -o <outfile> -h Display this help. -i Use ip address <ip address> in the report. -l Extract lines referring to <ip address> from the firewall logfile <logfile>. -t Use email addresses <mail addresses> in the to: and bcc: headers. <mail addresses> should be a list of mail addresses separated by spaces and enclosed with quote marks. -o Print the email message out to <outfile>. -d Print the output to STDOUT instead of to file. -p Make a pre email abuse report - requires an IP address. This option does the following based on the address given with the -i options: - runs an nmap scan on the IP address - runs a whois lookup on the IP address placing results in a subdirectory named after the IP address under the directory specified by the \$basedir variable. Version $VERSION
However you might want to look at mod_security ( http://www.modsecurity.org/ ) as a possible product to achieve your purpose, it's designed to do exactly what you want and a bit more.
Yes that would be the way I'd go about dealing with these injection attempts given my current setup that actually uses mod_security. Presently all I do is have a cronjob script parse the mod_security log for the current day to find out how many of each 'class' of attack have taken place and mail me with a very simple report - just the lines starting 'mod-sec' basically, which gives me a report that looks like: Summary of Entries: mod_security-message: Access denied with code 403. Pattern match "/My_eGallery/" at REQUEST_URI. mod_security-action: 403 mod_security-message: Access denied with code 403. Pattern match "/My_eGallery/" at REQUEST_URI. mod_security-action: 403 mod_security-message: Access denied with code 403. Pattern match "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)" at HEADER. etc etc the relevant log entries are printed out after that. If I was bothered enough and thought it would make a difference I might set to drafting an abuse report along the lines of the above. perl script To be honest though I don't get paid to do this and as I say above, just knowing that these 'attacks' have not been successful is enough really. -- Jez Hancock - System Administrator / PHP Developer http://munk.nu/ http://freebsd.munk.nu/ - A FreeBSD Diary http://ipfwstats.sf.net/ - ipfw peruser traffic logging
Current thread:
- Re: PHP injection attempt from 200.222.244.154 Jez Hancock (Dec 06)
- Re: PHP injection attempt from 200.222.244.154 Barrie Dempster (Dec 07)
- Re: PHP injection attempt from 200.222.244.154 Jez Hancock (Dec 08)
- Re: PHP injection attempt from 200.222.244.154 Jez Hancock (Dec 09)
- Re: PHP injection attempt from 200.222.244.154 James Eaton-Lee (Dec 17)
- Re: PHP injection attempt from 200.222.244.154 Jez Hancock (Dec 08)
- Re: PHP injection attempt from 200.222.244.154 Barrie Dempster (Dec 07)