I have a test system up and running. Anyone want to write a mod_perl handler to
redirect
to a warning page if the clients IP is in the list? I'm not really sure which phase
would be the least intrusive into existing applications.
telnet www.swiftcamel.com 2222
Then hit enter and you'll see the latest list of servers that have attempted the hack
including the number of attempts per IP address (comma seperated). I only list servers
if we've received more than 1 attempt on different web servers. I've used our logs to
compile the initial list. (quite scary how many machines out there are infected.)
You can also dump a list of IP addresses once you connect (one per line) and they will
be added into the database. Blank line ends reception. Optionally you can add the
requested URI after the IP address on the same line seperated by a comma and it too
will
be logged. I'm working on a web interface to search the list of IP's.
grep default.ida access_log | mail -s 'codered' [EMAIL PROTECTED]
and we'll add the IP's you logged to the system.
Jim Smith wrote:
> On Mon, Aug 06, 2001 at 02:46:54PM +0100, Mark Maunder wrote:
> > AFAIK most large backbone routers out there dont support application layer
> > filtering e.g. filtering based on what type of http request it is, or what is
> > requested. Too much CPU overhead methinks.
>
> Of course, for those of us in state universities, content filtering makes
> us uneasy wrt first amendment rights, besides the CPU overhead. Losing
> legitemate content is too much a risk. It is far easier to cut the
> infected machines off the network until they are fixed.
>
>
> > Some examples: In the case of the user having a dynamically assigned IP address,
> > the next person assigned that IP who hits any site subscribing to the realtime web
> > blackhole list (Lets call it RWBL) will see a polite message saying "this IP has
> > been used for a hack attempt" (with explanation on how to get it unblocked) and
> > will hopefully report it to their ISP. In the case of the user having a static IP
> > - well either their server was hacked, or they are the hacker, in which case the
> > effect will be similar - user will either stop hacking (or patch their server) or
> > risk being permanently banned from surfing any site subscribing to the RWBL.
> [snip]
> > Any suggestions on where to implement this in the server to ensure minimal
> > reconfiguration and impact to existing mod_perl handlers? It needs to be able to
> > block a request based on the contents of a text file or type of request and chuck
> > out an explanation page. Also needs to be able to append hack attempts into the
> > text file when the IP is not listed. The text file can be stored in the server
> > root somewhere (like robots.txt) and is gathered once daily by the central system.
> > The logic that will be used in the central system to ban IP's can be something
> > like 'if more than X number of hack attempts have been logged by different servers
> > from a particular IP, it's banned'. Perhaps X can be 7.
>
> If based on IP, use DNS - that's how the email RBLs are implemented.
> Makes a central database easy to maintain. Take a look at the Sendmail
> rulesets for the RBLS. :)
>
> --jim
--
Mark Maunder
Senior Architect
SwiftCamel Software
http://www.swiftcamel.com
mailto:[EMAIL PROTECTED]
