No amount of IRC redirection is going to remove bots and fix their
compromised computers.
... JG
> > I can't help but notice you totally avoided responding to what I
wrote;
> > I would have to take this to mean that you know that it is
fundamentally
> > unreasonable to expect users to set up their own recursers to work
around
> > ISP recurser brokenness (which is essentially what this is).
>
> Its more resonable to expect users to know how to remove bots and
fix
> their compromised computers?
No amount of IRC redirection is going to remove bots and fix their
compromised computers.... JG
I disagree. A lot of the compromised computers are still using the old
versions of like Phatbot, agobot, rxbot, all of which have the remove
commands. Placing the .remove in the subject line will effectively
remove the bots as they join the channels. The .remove will effectively
completely remove the bot from their computer, not everything else, but
alteast that bot instance is done. Its one way a lot of IRC networks get
rid of the botnets started on their networks, simply glineing them
causes them to keep trying to reconnect. Granted it won't stop the more
experienced script kiddies, but it will certainly stop the ones who use
the preconfigured scripts because they don't know what the soruce code
means. As many have said this is more about numbers. The number of
infected computers within their network used to DDoS and Spam compared
to the number of legitimate IRC users. Unfortunately the number of
zombies outweighs the good.
Raymond Corbin
Support Analyst
HostMySite.com
No amount of IRC redirection is going to remove bots and fix their
compromised computers.... JG
Let's not confuse two different forms of IRC redirection, one which I think
is perfectly okay and one which is definitely not okay.
In the first type, the redirection is an immediate response to a threat that
is not completely understood. Clients that connect to the target of the
redirect are studied. Legitimate clients are separated from compromised ones
as quickly as practically possible.
Legitimate clients are given a message, if possible, that the service they
are trying to use is temporarily unavailable due to a current threat. If
there is some other way they can access the service (for example, direct
entry of the IP), they are informed of that.
Compromised clients are tracked and, where possible, notified. The current
level of the threat is tracked, and when it is sufficiently minimal, the
redirect is removed.
This model is perfectly reasonable as a response to all kinds of threats.
This includes cases where a traffic has to be blocked or redirected due to a
new attack.
The second form is the one that causes a problem. In this case, no attempt
is made to study or understand the threat once a way to block it is found.
Collateral damage is ignored, no effort is made to minimize inconvenience to
legitimate users. No effort is made to notify compromised users. The filter
or redirect is left in place indefinitely, until and unless a large number
of complaints is received. The threat is not even monitored.
The filter/redirect is considered a permanent solution. While it may
officially be regarded as temporary, it is effectively left there and
forgotten.
Now these are two very different approaches to a threat. However, they both
can involve hijacking, filtering, or redirection. I used to work as a
consultant, helping companies negotiate contracts with ISPs. One thing I
always did was make it clear that the first type of response was perfectly
permissible, even if it harmed us, but the second was not, even if it did
not harm us.
DS