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

Mailman List Mirror (Read Only)
1

> > > Yes, when there are better solutions to the problem at hand.
> >
> > Please enlighten me.
>
> Intercept and inspect IRC packets. If they join a botnet channel, turn on
> a flag in the user's account. Place them in a garden (no IRC, no nothing,
> except McAfee or your favorite AV/patch set).

Pleaes do this at 1Gbps, really 2Gbps today and 20gbps shortly, in a cost
effective manner.

Mmmmm... okay. Would you like solution #1 or solution #2? (You can pay
for solutions above and beyond that)

Solution #1: you know you need to intercept "irc.vel.net", so you inject
an IGP /32 route for the corresponding IP address, and run it through your
IDS sensor. Now, you're not going to be able to claim that you actually
have even 100Mbps of traffic bound for that destination, so that's well
within the capabilities of modern IDS systems. This has the added benefit
of not hijacking someone's namespace, AND not breaking normal
communications with the remote site.

Bonus points for doing it on Linux or FreeBSD and selectively port
forwarding actual observed bot clients to a local cleansing IRCD, then
mailing off the problem IP to support so they can contact the customer
about AV and bot cleansing software, etc.

Oh, you were going to claim that your routers can't handle a few extra /32
routes? I guess I have no help for you there. You win. So on to #2.

Solution #2: You really can't handle a few extra /32 routes? Then go
ahead, and hijack that DNS, but run it to a transparent proxy server
that is in compliance with the ideas outlined above.

Cost effective? One FreeBSD box, some freely available tools, and some
time by some junior engineer with a little IRC experience, and you have
a great tool available, which doesn't inconvenience legitimate users but
does accomplish *MORE* than what Cox did.

Please also do this on encrypted control channels or
channels not 'irc', also please stay 'cost effective'.

So I'm supposed to invent a solution that does WAY MORE than what Cox
was trying to accomplish, and then you'll listen? Forget that (or
pay me).

Additionally,
please do NOT require in-line placement unless you can do complete
end-to-end telco-level testing (loops, bit pattern testing, etc),

Ok.

also
it'd be a good idea to have a sensible management interface for these
devices (serial port 9600 8n1 at least along with a scriptable
ssh/telnet/text-ish cli).

Ok.

Looking at DPI (which is required for your solution to work) you are still
talking about paying about 500k/edge-device for a carrier-grade DPI
solution that can reliably do +2gbps line-rate inspection and actions.

Yeah, I see that. Not. (I do see your blind spot, though.)

This quickly becomes non-cost-effective if your network is more than 1
edge device and less than 500k customers... Adding cost (operational cost
you can only recover via increased user fees) is going to make this not
deployable in any real network.

Uh huh.

> Wow, I didn't even have to strain myself.

sarcasim aside, this isn't a simple problem and at scale the solutions
trim down quickly away from anything that seems 'great' :frowning: using DNS
and/or routing tricks to circumvent known bad behaviours are the only
solutions that seem to fall out. Yes they aren't subscriber specific, but
you can't get to subscriber specific capabilities without a fairly large
cost outlay.

That's not true.

The problem is isolating the traffic in question. Since you DO NOT HAVE
GIGABITS OF TRAFFIC destined for IRC servers, this becomes a Networking
101-style question. A /32 host route is going to be effective.
Manipulating DNS is definitely the less desirable method, because it has
the potential for breaking more things. But, hey, it can be done, and
with an amount of effort that isn't substantially different from the
amount of work Cox would have had to do to accomplish what they did.

... JG

2

Yup - though I still dont see much point in specialcasing IRC. It
would probably be much more cost effective in the long run to have
something rather more comprehensive.

Yes there are a few bots around still using IRC but a lot of them have
moved to other, better things (and there's fun "headless" bots too,
hardcoded with instructions and let loose so there's no C&C, no
centralized domain or dynamic dns for takedown.. you want to make a
change? just release another bot into the wild).

3

Actually, it's requires a bit more planning and effort, especially if one gets into sinkholing and then reinjecting, which necessitates breaking out of the /32 routing loop post-analysis/-proxy. It can and is done, but performing DNS poisoning with an irchoneyd setup is quite a bit easier. And in terms of the amount of traffic headed towards the IRC servers in question - the miscreants DDoS one another's C&C servers all the time, so it pays to be careful what one sinkholes, backhauls, and re-injects not only in terms of current traffic, but likely traffic.

In large networks, scale is also a barrier to deployment. Leveraging DNS can provide a pretty large footprint over the entire topology for less effort, IMHO.

Also, it appears (I've no firsthand knowledge of this, only the same public discussions everyone else has seen) that the goal wasn't just to classify possibly-botted hosts, but to issue self-destruct commands for several bot variations which support this functionality.

[Note: This is not intended as commentary as to whether or not the DNS poisoning in question was a Good or Bad Idea, just on the delta of effort and other operational considerations of DNS poisoning vs. sinkholing/re-injection.]

Public reports that both Cox and Time-Warner performed this activity nearly simultaneously; was it a coordinated effort? Was this a one-time, short-term measure to try and de-bot some hosts? Does anyone have any insight as to whether this exercise has resulted in less undesirable activity on the networks in question?

4

Since it was a false positive, isn't the correct answer to not include
irc.vel.net in the Bot C&C list rather than trying to come up with more convoluted solutions?

Is it that much different than when a group makes a mistake implementing a USENET Death Penalty, SPAMHAUS DROP list, Bogon lists, Walled Gardens, even BCP38++, etc? Anytime you expect ISPs to do more than forward packets (and right or wrong some vocal groups and politicians think ISPs should do even more to stop network abuse), there is always a chance someone or something will make a mistake.

5

I tried to be nice and non-sarcastic. I outlined requirements from a real
network security professional on a large transit IP network. You
completely glossed over most of it and assumed a host of things that
weren't in the requirements. I'm sorry that i didn't get my point across
to you, please have a nice day.

-Chris