Re: module to hit back at default.ida atack ?
Angel R Rivera writes: Angel how about a way to tell it not to report an ip?? i just Angel reported on myself. :) That feature is in the latest version (1.07), thanks to David Young. DeWitt So *that's* why Reuven has CodeRed.pm CC him on the warning DeWitt emails. DeWitt And I thought he was just nuts. ;) I am nuts -- but in this particular case, I was just naive and foolish to think that people would change the $cc_address variable at the top of the program. So I've been flooded by a ridiculous number of e-mail messages from people who didn't change that variable. Version 1.08, which I hope to put out tonight or tomorrow, will improve the configuration a bit, and will also improve on the documentation. Reuven
Re: module to hit back at default.ida atack ?
Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. [snip] ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... Well you might think it's fun but there are those who'd say it's criminal. Sorry, you're right. I meant fun in the same way that Looney Toons and Wilie Coyote. Funny to watch a cartoon fall off a cliff, but not necessarily funny in life. Please don't promote irresponsible ideas on the mod_perl List. My bad script kiddies, go away, grow up, be responsible, and look to other security oriented lists such as incidents and bugtraq for bad ideas. -sc PS line type=fine personal_opinion=trueBad ideas aren't bad, execution of bad ideas is bad./line -- Sean Chittenden PGP signature
Re: module to hit back at default.ida atack ?
Perhaps we should just keep a central database of where the attempts are coming from. We could even extend it to work like the RBL - connects are not allowed from IP's that have attempted the exploit (an explanation page appears instead of the requested page) and are listed in our blacklist. That might force ISP's to kick the k1dd13z off their system. We could host the db on a webpage (searchable) and make it available for download by the script that does the banning on a daily/hourly basis. We could probably extend this to cover a few other exploits if this works. Would anyone use this? Sean Chittenden wrote: Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. [snip] ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... Well you might think it's fun but there are those who'd say it's criminal. Sorry, you're right. I meant fun in the same way that Looney Toons and Wilie Coyote. Funny to watch a cartoon fall off a cliff, but not necessarily funny in life. Please don't promote irresponsible ideas on the mod_perl List. My bad script kiddies, go away, grow up, be responsible, and look to other security oriented lists such as incidents and bugtraq for bad ideas. -sc PS line type=fine personal_opinion=trueBad ideas aren't bad, execution of bad ideas is bad./line -- Sean Chittenden Part 1.2Type: application/pgp-signature -- Mark Maunder Senior Architect SwiftCamel Software http://www.swiftcamel.com mailto:[EMAIL PROTECTED]
Re: module to hit back at default.ida atack ?
From: Mark Maunder [EMAIL PROTECTED] Perhaps we should just keep a central database of where the attempts are coming from. We could even extend it to work like the RBL - connects are not allowed from IP's that have attempted the exploit Would that really help anything? The traffic would still be reaching your server and clogging up the net, the only difference is that you'd be returning an access denied response rather than a 404. What would really help is if all the ISPs out there put filters on their routers to catch these requests as close to their source as possible.
Re: module to hit back at default.ida atack ?
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. 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. To get off the black-hole list is a similar process to getting off the current mail RBL list. Send a request explaining the cause of the hack-attempt and assurances that a remedy is in place, or will be shortly. 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. Also a list of banned request URI's can be made available for download for use by the RWBL checker running on each server out there. That will allow us to adapt to different worms or exploits. David Young wrote: From: Mark Maunder [EMAIL PROTECTED] Perhaps we should just keep a central database of where the attempts are coming from. We could even extend it to work like the RBL - connects are not allowed from IP's that have attempted the exploit Would that really help anything? The traffic would still be reaching your server and clogging up the net, the only difference is that you'd be returning an access denied response rather than a 404. What would really help is if all the ISPs out there put filters on their routers to catch these requests as close to their source as possible. -- Mark Maunder Senior Architect SwiftCamel Software http://www.swiftcamel.com mailto:[EMAIL PROTECTED]
Re: module to hit back at default.ida atack ?
What would really help is if all the ISPs out there put filters on their routers to catch these requests as close to their source as possible. Hey. Real quick, this discussion is getting a tad off topic, but, in terms of security, the ideal way to handle this is and prevent future spread of such worms for all of the IIS users in the crowd: * setup a bank of webservers * setup your scripts to use a proxy server * put a firewall before your webservers and proxy servers * deny all traffic FROM your webservers to port 80 and 443 * allow all traffic from your proxy server Cheers. Now can we get back to mod_perl? -sc -- Sean Chittenden PGP signature
Re: module to hit back at default.ida atack ?
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 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]
Re: module to hit back at default.ida atack ?
On Mon, 6 Aug 2001, Mark Maunder wrote: 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 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). So what your saying is that you have a list of potentially rooted machines that you are making publically available... Doesn't sound like such a good idea to me... Cees
Re: module to hit back at default.ida atack ?
On Tue, Aug 07, 2001 at 08:18:18PM +1000, Cees Hek wrote: So what your saying is that you have a list of potentially rooted machines that you are making publically available... Doesn't sound like such a good idea to me... So *that's* why Reuven has CodeRed.pm CC him on the warning emails. And I thought he was just nuts. ;) -DeWitt
Re: module to hit back at default.ida atack ?
how about a way to tell it not to report an ip?? i just reported on myself. :) At 07:32 PM 8/6/2001 -0400, DeWitt Clinton wrote: On Tue, Aug 07, 2001 at 08:18:18PM +1000, Cees Hek wrote: So what your saying is that you have a list of potentially rooted machines that you are making publically available... Doesn't sound like such a good idea to me... So *that's* why Reuven has CodeRed.pm CC him on the warning emails. And I thought he was just nuts. ;) -DeWitt Angel R. Rivera, [EMAIL PROTECTED] - The Home of the Original Brotherhood/Sisterhood of the Wolf http://www.wolf.com/botw-sotw/ -
Re: module to hit back at default.ida atack ?
Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. I remember a post on incidents or bugtraq where someone started pumping crap data back at the virus and eventually the NT system crashed. I haven't tried this, but it might be worth a shot to look in the archives and see if you can replicate this persons's results. ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... at the same time, because no one else has done something like this suggests that it may not work. YMMV. -sc -- Sean Chittenden PGP signature
Re: module to hit back at default.ida atack ?
H I, On Sun, 5 Aug 2001, Sean Chittenden wrote: Anybody know of any module I can use to hit back at these default.ida bozos (i.e. keep them away from my IP addresses ?). I'm running apache/modperl on Win32. [snip] ::grin:: In the post he mentioned about trashing the kernel on NT so this might be kinda fun... Well you might think it's fun but there are those who'd say it's criminal. Please don't promote irresponsible ideas on the mod_perl List. 73, Ged.
