2023年7月23日发(作者：)

基于wireshark的协议分析ark远程抓包

2010-03-10 15:34

基于wireshark的协议分析ark远程抓包

远程抓包方案

主要参考文档：

/CaptureSetup

/CaptureSetup/Pipes

/articles/2007/01/24/how-to-monitor-packets-from-a-remote-interface/

使用Wireshark时，我们一般加载已经保存的数据文件或者实时抓取网卡上的数据包，进行数据分析。有时为了监控远程机器网络流量，我们需要远程抓包，并对抓取的包进行实时分析。这时候，我们需要在远程捕获网络流量，并在本地启动wireshark进行数据分析。为实现这个目的，这时候我们就面临一下几个问题：

1.远程主机上如何抓包：远程主机OS是windows还是linux

2.本地主机和远程主机通过什么连接：ssh、netcat，还是其他协议

3.远程主机数据如何传到本地：是传到named pipe(命名管道)还是stdout

根据wireshark wiki文档，我们知道目前有这三种解决方案：



/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)

这种方式不清楚怎么用

测试一：named pipe on local machine (本地named pipe测试)

利用管道，将libpcap数据文件作为输入，输出到tshark，开始分析

local machine ： 192.168.1.86

hank@gts ~ $mkfifo /tmp/pipe

hank@gts ~ $./tshark -i /tmp/pipe &

hank@gts ~ $cat /home/hank/net-data/ > /tmp/pipe &

测试二：SSH + pipe

利用ssh登录远程主机，发送抓包命令，并将捕获的数据包发送到本地的named pipe，本地tshark监听该named pipe，有数据即开始分析。

remote machine ： 192.168.1.82

local machine ： 192.168.1.86

开启一个终端，执行：

hank@gts ~ $mkfifo /tmp/pipe

hank@gts ~ $ssh root@192.168.1.82 "tcpdump -w - -i eth0" > /tmp/pipe

开启另一个终端，执行：

hank@gts ~ $ wireshark -k -i /tmp/pipe

在/CaptureSetup/Pipes中，执行ssh登录时，没有将输出重定向到pipe中去，于是我对该wiki做了修改，修改记录为：

CaptureSetup/Pipes (last edited 2009-05-14 08:02:36 by

hankchan)

测试三：netcat 这个测试见《How to monitor packets from a remote interface in real time》 ，该方式设计三台计算机，并且使用了netcat，本地接听某个端口，远程主机将数据发送到该端口。

remote machine ： 192.168.1.82

local machine ： 192.168.1.86

本地主机执行：

hank@gts ~/wireshark-dev/bin $ nc -l -p 3000

远程主机执行：

[root@localhost ~]# cat /dev/urandom | nc 192.168.1.86 3000

本地另开一个终端，执行：

gts bin # ./tshark -i eth0 -R ==3000

综上，SSH + pipe 作为远程抓包是十分理想的方案，前提是能ssh登陆远程主机，并且远程主机上有抓包工具。

附英文原文如下：

Step 5: Capture traffic using a remote machine

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.

Contents







Pipes

Named pipes

Remote Capture

3. Special feeding application

4. Stdin

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:

1. 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.

2. 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.

3. 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 > /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: # #

/projects/pywin32/ import win32pipe, win32file cf =

open(r'c:', 'rb') p = NamedPipe( r'.pipewireshark',

_ACCESS_OUTBOUND, _TYPE_MESSAGE |

_WAIT, 1, 65536, 65536, 300, None)

tNamedPipe(p, None) data = () ile(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 | 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?

2011年10月31日

15:30