North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: DNS Hijacking by Cox
On 7/23/07, Perry Lorier <[email protected]> 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 [...]
doing it. 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 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.
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).
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. Also the constant reconnects themselves can almost overwhelm a server. I almost want to submit patches to the
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.
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...
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...