Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: PHP injection attempt from 200.222.244.154 |
|---|---|
| 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
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: ftp warez server snake ?, M. Shirk |
|---|---|
| Next by Date: | IIS web server hacked..any tips?, Francesco |
| Previous by Thread: | Re: PHP injection attempt from 200.222.244.154, Jez Hancock |
| Next by Thread: | Re: PHP injection attempt from 200.222.244.154, James Eaton-Lee |
| Indexes: | [Date] [Thread] [Top] [All Lists] |