远程抓包方案
http://blog.notreally.org/articles/2007/01/24/how-to-monitor-packets-from-a-remote-interface/
-
/Pipes - using a UNIX pipe and use a different tool to capture from
下文主要讨论这种方式
-
/WinPcapRemote - using [WinPcap]'s remote capturing feature (rpcapd) - currently not supported
在windows下安装winpcap后，winpcap安装目录下就有rpcapd这个命令行工具，但wireshark目前不支持读取rpcapd的输出，可以用其他工具读取rpcapd的输出。这种方式只限于windows操作系统。
-
RMON - use SNMP's RMON to capture - currently not supported ("Remote Packet Capture Using RMON" explains why it doesn't work well)
这种方式不清楚怎么用
hank@gts ~ $mkfifo /tmp/pipe
hank@gts ~ $ssh root@192.168.1.82 "tcpdump -w - -i eth0" > /tmp/pipe
hank@gts ~/wireshark-dev/bin $ ./tshark -i /tmp/pipe
Make sure you've finished step 4 successfully!
In this step: Don't use your local machine to capture traffic as in the previous steps but use a remote machine to do so.
Remote Capturing is currently very limited:
-
/Pipes - using a UNIX pipe and use a different tool to capture from
-
/WinPcapRemote - using [WinPcap]'s remote capturing feature (rpcapd) - currently not supported
-
RMON - use SNMP's RMON to capture - currently not supported ("Remote Packet Capture Using RMON" explains why it doesn't work well)
Of course, you can use Wireshark installed on a remote machine in combination with a remote control software (e.g. VNC, Windows Remote Desktop, ...).
XXX - explain special capture filter strings relevant to remote capturing!
Pipes
The following will explain capturing using pipes a bit.
Before pipes, Wireshark could read the captured packets to display either from a file (which had been previously created) or for a network interface (in real time). Since pipes are supported, Wireshark can also read packets from another application, and shows them in real time. This is useful if you want to watch a network in real time, and Wireshark cannot capture from that network, e.g. because it is not an Ethernet network, or it is not on the local machine.
There are three main limitations that you should be aware of:
- It is not currently known whether this works on Windows. If you want to use this on Windows, give it a try and report your results to the development list (and/or update this page). If you want to help testing, you should be able to compile Wireshark from sources.
-
This only works with the de facto standard libpcap format version 2.4, as described in Development/LibpcapFileFormat. Some other formats may work in theory, but this has not been tested.
- Capturing from a pipe is inconvenient, because you have to set up the pipe and put a file header into the pipe before you can start the capture. A few patches have been mailed to the development list that could solve this, so if you find the approach inconvenient, try the patches.
XXX - mention to configure live update of the Wireshark window
Named pipes
A named pipe looks like a file, but it is really just a buffer for interprocess communication. One process can send data to it, and another process can read it. There are two main ways to create a named pipe: with mkfifo or using special syntax of the bash shell.
Way 1: mkfifo
If you have a capture file in the right format (from Wireshark or tcpdump), you can do the following:
> mkfifo /tmp/pipe > wireshark -k -i /tmp/pipe & > cat capture.cap > /tmp/pipe &
This should start a capture from the named pipe /tmp/pipe. After you start the last command, a list of packets from the file should start appearing on the screen.
An example of remote capture using pipes can be found in Jesús Roncero's blog.
Way 2: bash
You can do exactly the same with special bash syntax:
> wireshark -k -i
Way 3: python
The following small python script shows how to use python on Windows:
# Win32 Wireshark named pipes example # Requires Python for Windows and the Python for Windows Extensions: # http://www.python.org # http://sourceforge.net/projects/pywin32/ import win32pipe, win32file cf = open(r'c:pipetest.pcap', 'rb') p = win32pipe.CreateNamedPipe( r'.pipewireshark', win32pipe.PIPE_ACCESS_OUTBOUND, win32pipe.PIPE_TYPE_MESSAGE | win32pipe.PIPE_WAIT, 1, 65536, 65536, 300, None) win32pipe.ConnectNamedPipe(p, None) data = cf.read() win32file.WriteFile(p, data)
Named pipes conclusion
In all of the above cases you cannot use the buttons in Wireshark to (re)start the capture, because the feeding process has no way of knowing that a new capture should be started. Also the feeding process may not be killed after Wireshark terminates. I think it is killed if you stop the capture before closing Wireshark, but I am not quite sure why.
There was a short discussion that the feeding process could detect that the pipe is not connected, and then restart the capture once it is connected again. So maybe this is possible, if you write the feeding process accordingly. There are also two patches that support reading from a TCP network connect (which has a define connection sequence), and from spawned child processes. Both patches should solve this specific problem.
Of course these examples are not really useful, because you could just read the file directly. In a real scenario, the feeding process would be either a remote capture process, or a special application.
Remote Capture
In bash syntax, remote capture is possible with the following command:
> wireshark -k -i
The main problem is that you have to exclude the traffic generated by the ssh session from capturing. Several patches are available to do this, but excluding port 22 is probably the easiest solution for now.
The second problem is that ssh cannot ask for a password on stdin. You should either set up ssh-agent, so that you don't need a password, or you should configure x-askpass to open a window for the password.
This can be worked around by combining SSH with a FIFO.
>mkfifo /tmp/pipe >ssh user@remote-host "tshark -w - not port 22"
In another terminal run the following:
>wireshark -k -i /tmp/pipe
As soon as Wireshark starts "listening" on the pipe, SSH will prompt for the password and allow you to continue. Wireshark can also be switched out for dumpcap and tcpdump can be used in place of tshark with slight variations on the above commands.
Special feeding application
Sometimes you want to display traffic from a network that is not accessible to the usual capture tools like tshark, tcpdump and snoop. You may have your own application to capture the traffic, and Wireshark can read the capture files, but how do you interface it with Wireshark to show traces in real time?
Pipes are the answer. As long as you use the de facto standard libpcap format, you should be able to write the capture to a named pipe, and view the packets in real time with Wireshark reading from this pipe.
Stdin
As described in the man page, you can use the minus sign for the interface name to capture from stdin. Stdin is a file descriptor that is predefined for every process, and it is usually connected to an anonymous pipe by the shell calling the process. So reading from stdin, you should be able to rewrite the command above to
> cat capture.cap | wireshark -k -i -
While the documentation says that Wireshark should be able to capture from stdin (which is an anonymous pipe), it is not clear whether it always works. Some people have reported success, but for me it only works with tshark, not with wireshark. Maybe this is related to the following bug?
Please note: this feature won't work with all versions of libiconv, as it will interpret the - sign as the start of a new parameter, see: bug #265
XXX - is this possible for both command line and interactive usage?
posted on 2012-12-24 10:46 michael.xh73 阅读(1088) 评论(0) 编辑 收藏 举报
