How should ISPs notify customers about Bots (Was Re: DNS Hijacking

Mailman List Mirror (Read Only)
1

> I think there's a bit of a difference, in that when you're using every
> commercial WiFi hotspot and hotel login system, that they redirect
> everything. Would you truly consider that to be the same thing as one
> of those services redirecting "www.cnn.com" to their own ad-filled news
> page?

Let's get "real." That's not what those ISPs are doing in this case.

I never said it was, but if you don't want to compare the situations
using reasonable comparisons (redirecting one thing is different than
redirecting all), then I have no interest in debating with you, and you
"win" for some sucky definition of "win."

They aren't pretending to be the real IRC server (the redirected IRC
server indicates its not the real one). The ISP isn't send ad-fill
messages. The irc.foonet.com server clearly sends several cleaning
commands used by several well-known, and very old, Bots. I might have
given the server a different name, but its obviously not trying to
impersonate the real irc server.

So how do you connect to the real IRC server, then? Remember that most
end users are not nslookup-wielding shell commandos who can figure out
whois and look up the IP.

And what happens when the ISP redirects by IP instead, if we're going to
play that game?

Do you prefer ISPs to break everything, including the users VOIP service
(can't call 9-1-1), e-mail service (can't contact the help desk), web
service (can't look for help)? Or should the ISP only disrupt the minimum
number of services needed to clean the Bot?

All right, here we go. Please explain the nature of the bot on my freshly
installed (last night) FreeBSD 6.2R box.

# ls -ld /; date; uname -r; uname -s
drwxr-xr-x 28 root wheel 512 Jul 22 23:04 /
Mon Jul 23 10:56:57 CDT 2007
6.2-RELEASE
FreeBSD
# echo "nameserver 68.4.16.30" > /etc/resolv.conf
# host irc.vel.net
irc.vel.net has address 70.168.71.144

Hint: there is no bot. My traffic is being redirected regardless. Were I
a Cox customer (and I'm not), I'd be rather ticked off.

Interfering with services in order to clean a bot would be a much more
plausible excuse if there was a bot. There is no bot.

So, to reiterate your own point:

Or should the ISP only disrupt the minimum
number of services needed to clean the Bot?

Yes, exactly. And that's obviously not what Cox is doing.

... JG

2

If those users are so technically unsophisticated, do you really expect the other users with infected computers to figure out how to disinfect their computer and remove the Bots instead?

So you have potentially tens of thousands of infected computers with Bots making connections to an IRC server. You know many of those bots are well-known, old bots that have built-in removal commands. But 99% of those users don't have the technical knowledge to clean their machine themselves or know what a Bot is. On the other hand, you have 1% of users are sophisticated enough to use IRC servers. And a few percentage of overlap between the two groups.

What do you do?
   a. nothing
   b. terminate tens of thousands of user accounts (of users who are mostly "innocent" except their computer was compromised)
   c. block all IRC
   d. redirect IRC connections to a few servers known to be used by Bots
   e. something else

3

Hint: there is no bot. My traffic is being redirected regardless. Were I
a Cox customer (and I'm not), I'd be rather ticked off.

Hint: the bots are on computers connecting to the irc server, not the irc server.

Interfering with services in order to clean a bot would be a much more
plausible excuse if there was a bot. There is no bot.

So are you claiming no bots ever try to connect to that server?

4

%age of freshly installed freebsd 6.2R boxes v/s random windows boxes
on cox cable?

Like anything else, its a numbers game.

5

Given how often compromised computers have *multiple* installs of badware on
them, just cleaning off *one* bot that happens to be old enough to respond to
their cleaning script is not magically making their system actually safe.
There's probably *other* stuff on the box as well.

So just waving a mostly-ineffective magic wand at *part* of the problem isn't
doing anybody any favors. Maybe you *should* be doing something drastic enough
to make the user sit up and take notice and *do* something...

(Disclaimer - I can get away with doing that, as "user bails for another
provider and takes his revenue with them instead of fixing the problem" isn't
an issue for my revenue stream. YMMV. :slight_smile: