On 7/23/07, Perry Lorier <perry@coders.net> wrote:
With my Undernet admin hat on, we have regular issues with botnets and the like for years and probably will for the foreseeable future.
In my personal experience we see a new "crop" of script kiddies about every 6 months to a year. Generally they start with whatever publically available tools they can get their hands on [...]
Agreed
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. 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). 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 verify 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. 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.
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. 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. (Plus there's no automated tool I'm aware of an IRC network can use that says "mass-firewall all channel members of channel #botnet for 96 hours, on all servers, even if all admins of the IRC network ceded some firewall control to other admins)
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... Or the IRC server could be designed as to impose a delay before transmitting the 465 numeric to notify the bot that they are banned. Maybe you drop them from the IRC network, send the 465 numeric, and leave the connection open for a few minutes. Until the bot gets the disconnect, the probability of a reconnect is essentially 0%.... Malware is generally too dumb to notice the connection is "hung" and all its messages are silently going to /dev/null. I used to have an alternative to /KILL called /HURT or /HUSH, which instead of disconnecting a user, would cause IRCD to blackhole the session and yet pretend to hold the connection open. I never met a bot that automatically noticed this had happened and responded by dropping/attempting to reconnect... -- -J