I just want it to stop sucking my bandwidth and filling my access
logs, so I took a totally different approach in minimizing the
problem.
On just one of my machines, I have 5 hosts each on it's own IP.
I added a 6's server that only listens to local connections. On
the 5 main servers, I have
this is just too annoying.
Indeed. Hasn't anyone ever heard of doing a head to see if you're
attacking a real IIS server before sending a few hundred requests?
Rusty
--
Rusty Brooks : http://www.rustybrooks.org/
Spewing wisdom from every orifice
Right. Well, code red just tried one URL. This one checks about a
hundred places per attacking host to see if you're vulnerable.
It's actually slowing things down on our websites pretty noticably.
--
Rusty Brooks : http://www.rustybrooks.org/
The web server will respond with some amount of traffic. I'd imagine the
302 redirect response would be shorter, overall, than a 404 response with
a not found page--especially if the site has a custom 404 page.
If the worm actually follows the redirect it will end up talking to itself
and,
Here's another version:
http://www.rubylane.com/public/nimda.tcl.txt
This adds a 60-second delay before the redirect and has a maximum # of
connections that will be held up on your server. I have our server
set to hold up to 10 attackers. Once this limit is exceeded the
redirect is issued
It appears that delaying this worm on one system is effective, but it is
multi-threaded to some extent because a single attacker is simultaneously
attacking a couple of our machines.
I have 3 in jail on one server, 7 on another, and 3 on another...
Jim
The attack code isn't multi-threaded: if
Jim Wilcoxson wrote:
Here's another version:
I was thinking you might also need a trace filter break.
I placed the following script in the private tcl/init.tcl file, to
ensure that it is the first filter that runs, however, it seems that
the rp_filter is still executing at least to run
