North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: DNS Hijacking by Cox

  • From: Perry Lorier
  • Date: Mon Jul 23 22:13:20 2007



doing it[1].  If you're interested in finding people that Undernet
detects as being open proxies or such like, put an IDS rule looking for
":[^ ]* 465 [^ ]* :AUTO ".

I'm not so sure Undernet is the only IRC network to ever begin a banned reason message with the word "AUTO".

I suspect it would be most useful if "detected drones" by most major IRC network
would be visible to cooperating ISPs for further analysis, not just Undernet.



What I would see as ideal is for some form of "detected BOT" incident reporting protocol to be utilized at both ends.

I'd love to see this. Undernet tried doing something similar a few years ago and it didn't really seem to pan out the way we'd hoped. Having this hosted by some independent third party would be great. Are there any trusted security organisations that are interested in running this? It's fairly easy to parse undernet's logs into some kind of sane format that can be submitted.


Rather than use IDS to snoop for our "user banned" messages, let IRC
networks run their automated bot detection methods, and when a bot is found,
post that fact to a short-term real-time incident database of some
sort that would
limit visibility of the information (to the ISP responsible, or to
someone asking a
Yes/No question about a specific ip address and approximate date & time).

One of the problems here is that responsible networks are happy to report and deal with these drones. The kiddies learn this pretty quickly and just set up an IRC server on a hacked box somewhere and use that. These are the bot networks that are used by kiddies that have graduated from annoying to dangerous.


The ISP would then be able to use the database as a geiger counter and
apply more exhaustive (CPU-intensive) monitoring to the activities of
a bot-reported connection for a short time, and ascertain if they can
> erify the "user is a bot" claim, and maybe take some abuse response if
> the user is actually infected with a spambot or floodbot.

Due to the massive volume, automation would be a must, however.


This relies on the IRC network's bot detection heuristics being kept
up to date, but
for the IRC networks' sake, they already have to be.

People are busy keeping these up to date all the time as you point out.


And unfortunately also relies on someone maintaining a database, that
could be costly, and would all be a waste if no ISP was able to utilize
> it to actually isolate bot-infected computers, or if no IRC network
> actually reported to the DB.

IRC networks in general are extremely keen to do anything they can to get rid of these bots. The interesting question is if ISP's would sign on to such a service.

them harder to find and ban.[2]  Also the constant reconnects themselves
can almost overwhelm a server.  I almost want to submit patches to the

Not just "almost"; the constant reconnects are themselves a DDoS against the server that has banned them, or the entire network, depending on the "target" of the reconnects.

Merely perhaps, an unintentional one, rather than deliberate attack.

Use of firewall rules in addition to ordinary K-Lines should serve well
to mitigate some of the incidental reconnect spam's negative impacts on IRCD.

Yeah, many servers run a script that counts number of incoming syns, and if they exceed a certain threshold firewall the source IP.


Firewall rules are just impossible to implement across all servers on most IRC
networks, as each server is administered independently, and contacts to make
the necessary changes are not likely to all be available or on IRC at the same
time.

Yeah, but automated "if you see too many syn's from a certain source ip, just firewall it" systems give a fairly reasonable approximation to this.


botnet codebases to implement exponential back off, or infact /any/ kind
of reasonable delay between connection attempts.

I suspect boxes IRC Servers run on should enforce something like "sane delay",
such as with "new connection throttling" at the OS level.


By that I mean, for instance, more than 3 connects to port 6667 in 60
seconds would
be met with all SYN packets dropped from that source for a few minutes
thereafter...

Yeah some already do this. That and just ratelimit limit syn's (if you ban 10k clients off your network, they all try and reconnect immediately usually to the first server in their list...)