> ...although having it in libpcap does mean that applications might, in > theory, be able to capture remotely without having to be changed.
Yeah, that would definitely be nice. > However, if authentication is required for remote capture - which I > suspect a lot of sites would want - that might call for application > changes anyway, unless some form of single sign-on, wherein an identity > token of some sort obtained when you log in can also be used to > authenticate yourself to a remote capture device, can be used. True. Like you suggest later, I'd think some sort of callback might be reasonable though. SSL allows you to register your own cert passwd callbacks, something along those lines. Maybe even a 'challenge' callback for the server and a 'response' for the client? Allow people to define their own auth methods? > There are a number of remote capture protocols already: RMON, the Tazmen > Sniffer Protocol used by Network Chemistry's Neutrino Sensors, the > protocol Microsoft uses in Network Monitor (I don't know whether > anybody's reverse-engineered that or not), and the one that the WinPcap > people are working on: > > http://winpcap.polito.it/docs/man/html/group__remote__help.html > > Libpcap should probably have a mechanism by which support for multiple > protocols can be added, so that multiple such protocols, including yours > (and presumably including "ssh to the remote machine and start up > tcpdump with the capture going to the standard output"), could be supported. As long as I can push my metadata along it (I munge signal and channel info to the head of the frame, as well as gps coords of the remote capture node) I'd actually be pretty willing to adapt my protocol to match a more standard one, if such a one exists/is developed. I hadn't wanted to stomp on the netchem guys by coopting their protocol as well as their idea, and I didn't see anything else. Infact, at the moment, I make no promises that my protocol is even compatible between major releases, simply because I'm the only one that uses it. > There'd be a new API for opening captures; it'd include a mechanism for > supplying information necessary for authenticating yourself with a > remote capture device. I like this idea. I've even thought it would be nice to have some sort of shared mem pipe locally to funnel data between sniffer 'components', for example let Kismet capture the data and control the channel hopping, handle the decryption, and munge all the funny driver-specific stuff down to a standard stream... and then let ethereal attach to that and get a realtime stream of the data Kismet has munged into shape. This would also be a more efficient way of tieing in IDS systems (right now I can export to Snort via a named fifo, but it's sort of klugey). Maybe the latter is just what would be convenient for me and not the world at large, but it's worth thinking of. -m -- There's too much blood in my caffeine system!
pgpF8tbZf6JiQ.pgp
Description: PGP signature
