billn at billn.net
Sun Mar 13 13:32:11 UTC 2005
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.
More information about the NANOG