| From time to time users would like to capture packets/frames on the network layer, e.g. to analyze the behaviour of the programs they use or develop or to get some network layer statistics. Usually, this can be done with a packet capturing facility supplied by most operating systems, e.g. the libpcap library. Some tools use this library and give the user a higher level interpratation of captured packets, e.g. tcpdump(8) or ethereal(1). Since the ability to capture arbitrary packets would allow users to snoop for sensitive data, the operating system interface for packet capturing is usually limited to superuser access. On IBR Linux hosts, however, we have a program that allows users to get packet captures with some limitations: tcpdump-user. This is a wrapper around tcpdump, which passes most arguments to the underlying original tcpdump. In addition it supports to specify a "mode": tcpdump-user -M headers: This restricts the captured packets, so that they contain only up to 42 octets, which usually means that only headers but no payload can be monitored.tcpdump-user -M freeports: This disallows the user to specify a filtering expression. Instead only UDP and TCP traffic on ports 8888 to 8893 is monitored. This is the port range that we suggest IBR users to use for any work in progress. These ports are also not filtered on the IBR firewall for inbound traffic. tcpdump-user -? shows a short usage summary. Notes - The IBR network is a switched ethernet, i.e., you have to run the captering either on the sending or the receiving host.
- The wrapper disallows the
-w file option. If you want to dump the output to a file, you can use something like tcpdump-user -w - > file. - If you want to analyze your captured data,
ethereal -r file can be helpful. [ Question to all fellows: Do you think there are any serious security risks in this concept? The only one I worry about at this point in time, is sensitive data in the first 42 octets of IP fragments. ] |
