Re: PHP injection attempt from 200.222.244.154

[Jez Hancock <jez.hancock () gmail com>]

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