Re: PHP injection attempt from 200.222.244.154

From: Jez Hancock (jez.hancock_at_gmail.com)
Date: 12/09/04

  • Next message: Francesco: "IIS web server hacked..any tips?" 
    Date: Thu, 9 Dec 2004 01:08:27 +0000
To: barrie@reboot-robot.net

    On Tue, 7 Dec 2004 23:46:21 +0000, Jez Han*** <jez.han***@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 Han***
 - System Administrator / PHP Developer
http://munk.nu/
http://freebsd.munk.nu/      - A FreeBSD Diary
http://ipfwstats.sf.net/        - ipfw peruser traffic logging
  • Next message: Francesco: "IIS web server hacked..any tips?"
    • Quantcast