On Sat, 12 Mar 2005, John Kristoff wrote:
Tallying then just the TCP 6667 traffic, perhaps eliminating very short lived or small flows, should be a good indicator of IRC traffic usage, but tagging those as potential sources for problems may be
Yes and no, in my experience. Depending on the drone, some connect to a server and stay connected. You could say the inverse is true, and look for long connections, but that will likely snare you legitimate traffic from the screen-running nerd set.
difficult. Perhaps in environments where IRC as an application is strictly forbidden or blocked this will work well, but on more open and larger network this may waste time, not save it. Since in the latter case, figuring out what is legit and what is not will likely be a lot of leg work.
This is why I suggested a snort filter, to actually inspect the packet traffic. Watching IRC traffic is only valid so long as the standard ports are being honored. What about bounces, and non-standard traffic? You need to go after the single common property, the protocol itself. Even so, you're still in an arms race.
You can automate some of this further, by building white lists or black lists of IRC server addresses. A white list doesn't tend to scale very well. A black list scales better, but you have to get those black listed addresses and doing that part is harder. There are some people/groups who spend time finding black list hosts so leveraging their data can be very useful and time saving.
This will backfire, in my opinion. Many drone nets hide in plain sight, connecting to public IRC networks where they can't reliably be traced to an authoritative user. You'll bejuggling access to public resources, and that's a waste of energy, I think. - billn