> So in the bro-based system (which sounds higher resolution) the final > logged data was second-precision timestamps on full connection tuples? It's not higher-resolution, it just has different defaults. I can configure bro to capture/retain anything I want, up to and including every datagram passing through the interface. > So if I have a connection to a Tor Guard node opened for 8 hours, at the > end of the session, your system would record a single record with: > (my_ip,my_port,guard_ip,guard_port,tx,rx,timestamp_open,timestamp_close) Not a single record, no. Have a read of the docs, or try it for yourself: https://www.bro.org/documentation/index.html You can just set bro up to capture packets on your local machine or network. > I think any system that is storing connection-level data (as opposed to > one record per timeslice of activity on a tuple) is likely to be rather > easy to defend against correlation. As I alluded to earlier, these systems typically work with network flows, not TCP connections. > Well, it seems harder to store a full connection tuple for open until > close, because you have no idea when the connection actually closed > (unless you are recording a tuple for every second during which there is > any activity, or similar). The raw capture is usually the latter; sometimes with stateful monitors these are postprocessed/aggregated into connections, depending on configuration. Again, the docs are out there and you can just run the system for yourself - I recommend setting it up on your home network for a week and seeing what you get. :) -- OpenPGP: 6FB7 ED25 BFCF 3E22 72AE 6E8C 47D4 CE7F 6B9F DF57
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays