Security Incidents mailing list archives
Re: PHP injection attempt from 200.222.244.154
From: Jez Hancock <jez.hancock () gmail com>
Date: Thu, 9 Dec 2004 01:08:27 +0000
On Tue, 7 Dec 2004 23:46:21 +0000, Jez Hancock <jez.hancock () gmail com> wrote:
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.
For anyone interested, the perl abuse report script mentioend above can be found here: http://munk.nu/programming/perl/abuse_report.pl I've just added a considerable amount of description to the script (the text is probably longer than the script now :grin:) which describes the problem of reporting abuse. Any comments are welcome: # Overview: # Script came to life after denial of service (DOS) attacks against my network. # Various hosts would initiate packet flood attacks against one or more of my # machines causing the network to grind to a halt whilst the border firewall # handled the incoming packets... whilst the firewall did a fine job of # blocking the flood, the actual bandwidth consumed just in the act of blocking # meant none was left for use by the network... hence a DOS. # # I would obviously get fed up with this if it went on for more than a few # hours, so started manually going about the process of complaining about the # attacks to the attacking host's ISP. This generally went along the lines of: # # find the responsible parties for the attacking IP address - to do this run # a 'host $ip' on the ip address, see if it returns a valid PTR record... # perhaps the PTR record is a fairly simple fully qualified domain (FQDN) like # 'www.munk.nu'. If so we can easily look up the whois info for that domain # and then send abuse reports to the admin/tech contact for the domain. # # More often than not though the IP address either doesn't resolve to a simple # FQDN or doesn't have a PTR record at all. In these cases I'd usually end up # just running a 'whois $ip' on the ip address to find out who owns the IP # block in an attempt to find a responsible party to whom I could complain. # Unfortunately a lot of the time finding someone who'll listen in this way is # hard, especially in areas of the world where internet abuse isn't regulated # or taken seriously that well. # # So after finding the host and whois info for the IP address (or FQDN where # relevant) and finding out who I should send an abuse report to, I could then # go ahead and draft an abuse email to the responsible party. I'd include in # that report every firewall log entry pertaining to the problem IP address - # often this could end up being well over 10MB in logfile entries # (unfortunately most abuse email address responders don't accept compressed # logfile archives). # # After a while this would get very tedious, especially if you have more than # just one or two addresses you need to report in one go (as was the case for # me when the attacks began being 'distributed' across several - presumably # zombie - hosts). Hence I decided to make the process a bit quicker using # this script - which essentially does all of the above. # # Suggested Usage: # This is just suggested usage and lets you 'sanity check' the output before # you send it off to abuse address(es): # # Run in 'pre report' mode first: # # ./abuse_report.pl -i 1.2.3.4 -p # # This will create a directory under the current directory called '1.2.3.4' # with the results of nmap, whois and host queries on the IP address 1.2.3.4. # These results can be used at least to find out what email address(es) to send # abuse repots to. # # Obviously use the 'nmap' part sparingly, I used it to try and detect patterns # in what ports were open on the attacking hosts in an attempt to determine if # the host shared anything in common like running identd servers, malware/bot # daemons or otherwise. # # Next go on to run the script in 'debug' mode, adding the email addresses to # whom the abuse reports would be sent as arguments (which you got from the # whois reports generated in previous step): # # ./abuse_report.pl -i 1.2.3.4 -t "abuse1 () example com abuse2 () example com" -d # # This outputs the abuse message to STDOUT so you can verify it looks ok. Note # this will add on all the firewall log entries, so you may want to pipe it # through a pager to read it easily. # # Finally go on to run the script in 'live' mode. Basically run the command as # above but without the '-d' debug switch. A tip here though I found was to # use the -o switch to save the abuse report email to a file: # # ./abuse_report.pl -i 1.2.3.4 -t "abuse1 () example com abuse2 () example com" -o # some_temp_mailbox_file.mbox # # This way I'd then do 'mutt -f some_temp_mailbox_file.mbox' to open the mbox # formated email, check it for sanity and then if all was well I'd just # 'bounce' the message on to the final recipients in mutt using the 'b' # command. I'd then save a copy of the message for my own admin usage, useful # for followups. # # # That's about it. The script is quite a rough hack, but surprisingly # effective - after I started using it I found I got results very quickly and # the attacks died down a great deal. # Happy abuse reporting! -- 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)