DNS Hijacking by Cox

Tue Jul 24 02:04:42 UTC 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...)