|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: How should ISPs notify customers about Bots (Was Re: DNS Hijacking
> On Mon, 23 Jul 2007, Joe Greco wrote: > > > > 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' :( 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 -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
|