Re: PHP injection attempt from 200.222.244.154

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

  • Next message: H Carvey: "Re: ftp warez server snake ?" 
    Date: Tue, 7 Dec 2004 23:46:21 +0000
To: barrie@reboot-robot.net

    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 Han*** 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 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: H Carvey: "Re: ftp warez server snake ?"
    • Quantcast