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 Hancock 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 Hancock
- System Administrator / PHP Developer
http://munk.nu/
http://freebsd.munk.nu/ - A FreeBSD Diary
http://ipfwstats.sf.net/ - ipfw peruser traffic logging
