Remote packet capture protocol v 0 experimental что это
Rpcapd is a daemon (Unix) or service (Win32) that allows the capture and filter part of libpcap to be run on a remote system.
Rpcapd can run in two modes: passive mode (default) and active mode.
In passive mode, the client (e.g., a network sniffer) connects to rpcapd . The client then sends the appropriate commands to rpcapd to start the capture.
In active mode, rpcapd tries to establish a connection toward the client (e.g., a network sniffer). The client then sends the appropriate commands to rpcapd to start the capture.
Active mode is useful in case rpcapd is run behind a firewall and cannot receive connections from the external world. In this case, rpcapd can be configured to establish the connection to a given host, which has to be configured in order to wait for that connection. After establishing the connection, the protocol continues its job in almost the same way in both active and passive mode.
Installing the Remote Capture Daemon in UNIX
The WinPcap source archive can be compiled in UNIX as well. Currently, remote capture has been tested on Linux and BSD. What you have to do is:
- download the WinPcap sources
- unpack the sources
- we suggest to use the unzip -a command in order to convert DOS files to UNIX ones
- ./configure
- Warning: in case the previous step reports an error, please regenerate the configure file using automake (version 2.50 or higher required)
- make
The remote capture capabilities are turned on by default on Linux and FreeBSD. In case you do not want remote capture capabilities in libpcap, you can type
at the " configure " step. All the possible flags are listed when typing ./configure --help .
What you obtained right now, is:
- a library file ( libpcap.a ), which can be linked to other applications (like tcpdump ) in order to enable the remote capture for them.
- an executable ( rpcapd ) that is the remote daemon
Warning: in order to run the rpcapd daemon, the program must either
- run as root (or)
- run as user, but it must be owned by root and must be SUID root ( chmod u+s rpcapd )
Known bugs
FreeBSD: the first time you call the pcap_stat() , the function takes several seconds to return. Therefore, programs like Analyzer seem to hang up for 20-30 seconds at the beginning of the capture (if this is done with BSD as a remote probe). We're investigating to solve this issue.
Installing rpcapd on Win32
The remote daemon is installed automatically when installing WinPcap. The installation process places the rpcapd executable file into the WinPcap folder. This file can be executed either from the command line, or as a service. For instance, the installation process updates the list of available services list and it creates a new item (Remote Packet Capture Protocol v.0 (experimental)). To avoid security problems, the service is inactive and it has to be started manually (control panel - administrative tools - services - start).
The service has a set of "standard" parameters, i.e. it is launched with the -d flag (in order to make it run as a service) and the -f rpcapd.ini flag.
Remote Capture
WinPcap comes with Remote Capture capabilities. This is an highly experimental feature that allows to interact to a remote machine and capture packets that are being transmitted on the remote network.
This requires a remote daemon (called rpcapd ) which performs the capture and sends data back and a local client that sends the appropriate commands and receives the captured data.
WinPcap extends the standard WinPcap code in such a way that all WinPcap-based tools can expoit remote capture capabilities. For instance, the capabillity to interact with a remote daemon are added to the client software without any explicit modification to it. Vice versa, the remote daemon must be explicitely installed (and configured) on the remote machine.
SEE ALSO
This document was created by man2html, using the manual pages from "The Tcpdump Group" git repositories.
Time: 10:43:38 GMT, October 05, 2021 [Valid HTML 4.01] [Valid CSS]Remote Capture Running Modes
The Remote Capture Protocol (RPCAP) can work in two modes:
- Passive Mode (default): the client (e.g. a network sniffer) connects to the remote daemon, it sends them the appropriate commands, and it starts the capture.
- Active Mode: the remote daemon try to establish a connection toward the client (e.g. the network sniffer); then, the client sends the appropriate commands to the daemon and it starts the capture. This name is due to the fact thet the daemon becomes active instead of waiting for new connections.
The Active Mode is useful in case the remote daemon is behind a firewall and it cannot receive connections from the external world. In this case, the daemon can be configured to establish the connection to a given host, which will have been configured in order to wait for that connection. After establishing the connection, the protocol continues its job in almost the same way in both Active and Passive Mode.
Remote Capture
WinPcap comes with Remote Capture capabilities. This is an highly experimental feature that allows to interact to a remote machine and capture packets that are being transmitted on the remote network.
This requires a remote daemon (called rpcapd ) which performs the capture and sends data back and a local client that sends the appropriate commands and receives the captured data.
WinPcap extends the standard WinPcap code in such a way that all WinPcap-based tools can expoit remote capture capabilities. For instance, the capabillity to interact with a remote daemon are added to the client software without any explicit modification to it. Vice versa, the remote daemon must be explicitely installed (and configured) on the remote machine.
Installing the Remote Capture Daemon in UNIX
The WinPcap source archive can be compiled in UNIX as well. Currently, remote capture has been tested on Linux and BSD. What you have to do is:
- download the WinPcap sources
- unpack the sources
- we suggest to use the unzip -a command in order to convert DOS files to UNIX ones
- ./configure
- Warning: in case the previous step reports an error, please regenerate the configure file using automake (version 2.50 or higher required)
- make
The remote capture capabilities are turned on by default on Linux and FreeBSD. In case you do not want remote capture capabilities in libpcap, you can type
at the " configure " step. All the possible flags are listed when typing ./configure --help .
What you obtained right now, is:
- a library file ( libpcap.a ), which can be linked to other applications (like tcpdump ) in order to enable the remote capture for them.
- an executable ( rpcapd ) that is the remote daemon
Warning: in order to run the rpcapd daemon, the program must either
- run as root (or)
- run as user, but it must be owned by root and must be SUID root ( chmod u+s rpcapd )
Known bugs
FreeBSD: the first time you call the pcap_stat() , the function takes several seconds to return. Therefore, programs like Analyzer seem to hang up for 20-30 seconds at the beginning of the capture (if this is done with BSD as a remote probe). We're investigating to solve this issue.
Installing rpcapd on Unix-like systems
Configuration file
The user can create a configuration file in the same directory as the executable, and put the configuration commands in there. In order for rpcapd to execute the commands, it needs to be restarted on Win32, i.e. the configuration file is parsed only at the beginning. The UNIX version of rpcapd will reread the configuration file upon receiving a HUP signal. In that case, all the existing connections remain in place, while the new connections will be created according to the new parameters.
In case a user does not want to create the configuration file manually, they can launch rpcapd with the desired flags plus -s filename . Rpcapd will parse all the parameters and save them into the specified configuration file.
Remote Capture Running Modes
The Remote Capture Protocol (RPCAP) can work in two modes:
- Passive Mode (default): the client (e.g. a network sniffer) connects to the remote daemon, it sends them the appropriate commands, and it starts the capture.
- Active Mode: the remote daemon try to establish a connection toward the client (e.g. the network sniffer); then, the client sends the appropriate commands to the daemon and it starts the capture. This name is due to the fact thet the daemon becomes active instead of waiting for new connections.
The Active Mode is useful in case the remote daemon is behind a firewall and it cannot receive connections from the external world. In this case, the daemon can be configured to establish the connection to a given host, which will have been configured in order to wait for that connection. After establishing the connection, the protocol continues its job in almost the same way in both Active and Passive Mode.
Starting a capture on a remote machine
If you are using a tool that is already aware of the remote capture (like Analyzer), everything is simple. The capture wizard will help you to locate the appropriate interface on the remote machine.
If your preferred tool is not aware of the remote capture, you can still use the remote capture. In this case you have to read the next Section.
Be carefully: the capture server ( rpcapd ) must be up and running on the remote machine.
New string specifiers for interface selection
If your preferred tool is not aware of the remote capture, the only thing you must do is to insert, as interface specifier, the indication of the remote machine you want to contact. The following forms are allowed:
Adapter String Description It opens a local file. It opens a remote adapter; the host is specified by means of the literal name, without port number (i.e. it uses the RPCAP default port). It is the same as before, but it uses a different port number. It opens a remote adapter, but the host is specified by means of an IPv4 numeric address, without port number (i.e. it uses the RPCAP default port). It is the same as before, but it uses a different port number. It is the same as before, but the numeric address is specified within square brackets (like IPv6 addresses). It opens a remote adapter, but the host is specified by means of an IPv6 numeric address, without port number (i.e. it uses the RPCAP default port). In case of IPv6 addresses you MUST use the square brackets. It is the same as before, but it uses a different port number. It opens a local adapter, without using the RPCAP protocol. It opens a local adapter; it is kept for compability, but it is strongly discouraged. It opens the first local adapter; it is kept for compability, but it is strongly discouraged. The following formats are not allowed:
Adapter String Description It cannot be used to open the first local adapter. It cannot be used to open the first remote adapter. Sending Packets
Note that the original libpcap library at the moment doesn't provide any way to send packets, therefore all the functions shown here are WinPcap extensions and will not work under Unix.
Sending a single packet with pcap_sendpacket()
The simplest way to send a packet is shown in the following code snippet. After opening an adapter, pcap_sendpacket() is called to send a hand-crafted packet. pcap_sendpacket() takes as arguments a buffer containing the data to send, the length of the buffer and the adapter that will send it. Notice that the buffer is sent to the net as is, without any manipulation. This means that the application has to create the correct protocol headers in order to send something meaningful.
Send queues
While pcap_sendpacket() offers a simple and immediate way to send a single packet, send queues provides an advanced, powerful and optimized mechanism to send a collection of packets. A send queue is a container for a variable number of packets that will be sent to the network. It has a size, that represents the maximum amount of bytes it can store.
A send queue is created calling the pcap_sendqueue_alloc() function, specifying the size of the new send queue.
Once the send queue is created, pcap_sendqueue_queue() can be used to add a packet to the send queue. This function takes a pcap_pkthdr with the timestamp and the length and a buffer with the data of the packet. These parameters are the same as those received by pcap_next_ex() and pcap_handler(), therefore queuing a packet that was just captured or read from a file is a matter of passing these parameters to pcap_sendqueue_queue().
To transmit a send queue, WinPcap provides the pcap_sendqueue_transmit() function. Note the third parameter: if nonzero, the send will be synchronized, i.e. the relative timestamps of the packets will be respected. This operation requires a remarkable amount of CPU, because the synchronization takes place in the kernel driver using "busy wait" loops. Although this operation is quite CPU intensive, it often results in very high precision packet transmissions (often around few microseconds or less).
Note that transmitting a send queue with pcap_sendqueue_transmit() is much more efficient than performing a series of pcap_sendpacket(), because the send queue is buffered at kernel level drastically decreasing the number of context switches.
When a queue is no longer needed, it can be deleted with pcap_sendqueue_destroy() that frees all the buffers associated with the send queue.
The next program shows how to use send queues. It opens a capture file with pcap_open_offline(), then it moves the packets from the file to a properly allocated send queue. At his point it transmits the queue, synchronizing it if requested by the user.
Note that the link-layer of the dumpfile is compared with the one of the interface that will send the packets using pcap_datalink(), and a warning is printed if they are different -- it is important that the capture-file link-layer be the same as the adapter's link layer for otherwise the tranmission is pointless.
documentation. Copyright (c) 2002-2005 Politecnico di Torino. Copyright (c) 2005-2007 CACE Technologies. All rights reserved.
Starting rpcapd on Unix-like systems
rpcapd needs sufficient privileges to perform packet capture, e.g. run as root or be owned by root and have suid set. Most operating systems provide more elegant solutions when run as user than the above solutions, all of them different.Configuring the Remote Daemon (rpcapd)
The Remote Daemon is a standard Win32 executable running either in console mode or as a service. The executable can be found in the WinPcap folder and it has the following syntax:
The daemon can be compiled and it is actually working on Linux as well.
Here there is a brief description of the allowed commands:
Switch Description It sets the address the daemon has to bind to (either numeric or literal). Default: it binds to all local IPv4 and IPv6 addresses. It sets the port the daemon has to bind to. Default: it binds to port 2002. It binds only to IPv4 addresses. Default: both IPv4 and IPv6 waiting sockets are used. It specifies a file that keeps the list of the hosts which are allowed to connect to this daemon (if more than one, the file keeps them one per line). We suggest to use literal names (instead of numeric ones) in order to avoid problems with different address families (IPv4 and IPv6). It permits NULL authentication (usually used with '-l', that guarantees that only the allowed hosts can connect to the daemon). Default: the username/password authentication mechanism is required. It forces the daemon to run in active mode and to connect to 'host' on port 'port'. This does not exclude that the daemon is still able to accept passive connections. It forces the daemon to run in active mode only (default: the daemon always accepts active connections, even if the '-a' switch is specified). Forces the daemon to run in background, i.e. as a daemon (UNIX only) or as a service (Win32 only). Warning (Win32): this switch is provided automatically when WinPcap installs this daemon into the Win32 services (control panel - administrative tools - services). It saves the current configuration to file. It loads the current configuration from file; all the switches specified from the command line are ignored and the file settings are used instead. It prints an help screen. Installing the remote daemon
The remote daemon is installed automatically when installing WinPcap. The installation process places the rpcapd file into the WinPcap folder. This file can be executed either from the command line, or as a service. For instance, the installation process updates the list of available services list and it creates a new item (Remote Packet Capture Protocol v.0 (experimental) ). To avoid security problems, the service is inactive and it has to be started manually (control panel - administrative tools - services - start).
The service has a set of "standard" parameters, i.e. it it launched with the " -d " flag (in orde to make it running as a service) and the " -f rpcapd.ini " flag. The user can create a file called rpcapd.ini in the same folder of the executable, and put the configuration commands in there. In order for the service to execute the commands, you have to stop and restart it again (i.e. the initialization file is parsed only at the beginning). Viceversa, the UNIX version of rpcapd is able to read the configuration file when sending a kill -HUP signal to it. In that case, all the existing connections remain in place, while the new connections will be created according to the new parameters.
In case the user does not want to create the configuration file manually, it can launch rpcapd with the requested parameters plus the " -s filename " one. The daemon will parse all the parameters and save them into the specified configuration file.
Starting the remote daemon as a standard executable
The rpcapd executable can be launched directly, i.e. it can run in the foreground as well (not as a daemon/service). The procedure is quite simple: you have to invoke the executable from the command line with all the requested parameters but the " -d " flag. The capture server will start in the foreground.
Starting a capture on a remote machine
If you are using a tool that is already aware of the remote capture (like Analyzer), everything is simple. The capture wizard will help you to locate the appropriate interface on the remote machine.
If your preferred tool is not aware of the remote capture, you can still use the remote capture. In this case you have to read the next Section.
Be carefully: the capture server ( rpcapd ) must be up and running on the remote machine.
New string specifiers for interface selection
If your preferred tool is not aware of the remote capture, the only thing you must do is to insert, as interface specifier, the indication of the remote machine you want to contact. The following forms are allowed:
Adapter String Description It opens a local file. It opens a remote adapter; the host is specified by means of the literal name, without port number (i.e. it uses the RPCAP default port). It is the same as before, but it uses a different port number. It opens a remote adapter, but the host is specified by means of an IPv4 numeric address, without port number (i.e. it uses the RPCAP default port). It is the same as before, but it uses a different port number. It is the same as before, but the numeric address is specified within square brackets (like IPv6 addresses). It opens a remote adapter, but the host is specified by means of an IPv6 numeric address, without port number (i.e. it uses the RPCAP default port). In case of IPv6 addresses you MUST use the square brackets. It is the same as before, but it uses a different port number. It opens a local adapter, without using the RPCAP protocol. It opens a local adapter; it is kept for compability, but it is strongly discouraged. It opens the first local adapter; it is kept for compability, but it is strongly discouraged. The following formats are not allowed:
Adapter String Description It cannot be used to open the first local adapter. It cannot be used to open the first remote adapter. OPTIONS
-b address Bind to the IP address specified by address (either numeric or literal). By default, rpcapd binds to all local IPv4 and IPv6 addresses. -p port Bind to the port specified by port . By default, rpcapd binds to port 2002. -4 Listen only on IPv4 addresses. By default, rpcapd listens on both IPv4 and IPv6 addresses. -l host_list Only allow hosts specified in the host_list argument to connect to this server. host_list is a list of host names or IP addresses, separated by commas. We suggest that you use host names rather than literal IP addresses in order to avoid problems with different address families. -n Permit NULL authentication (usually used with -l ). -a host , port Run in active mode, connecting to host host on port port . In case port is omitted, the default port (2003) is used. -v Run in active mode only; by default, if -a is specified, rpcapd it accepts passive connections as well. -d Run in daemon mode (UNIX only) or as a service (Win32 only). Warning (Win32): this flag is specified automatically when the service is started from the control panel. -i Run in inetd mode (UNIX only). -D Log debugging messages. -s config_file Save the current configuration to config_file in the format specified by rpcapd-config (5). -f config_file Load the current configuration from config_file in the format specified by rpcapd-config (5) and ignore all flags specified on the command line. -h Print this help screen.If rpcapd was compiled with SSL support, the following options are also available: -S Require that SSL be used on connections. -C With SSL enabled, XXX - I'm not sure how *fetching* the list of compression mechanisms does anything to compression. -S ssl_keyfile With SSL enabled, use ssl_keyfile as the SSL key file. -X ssl_certfile With SSL enabled, use ssl_certfile as the SSL certificate file.
Starting rpcapd on Win32
The rpcapd executable can be launched directly, i.e. it can run in the foreground as well (not as a daemon/service). The procedure is quite simple: you have to invoke the executable from the command line with all the requested parameters except for the -d flag. The capture server will start in the foreground.
Configuring the Remote Daemon (rpcapd)
The Remote Daemon is a standard Win32 executable running either in console mode or as a service. The executable can be found in the WinPcap folder and it has the following syntax:
The daemon can be compiled and it is actually working on Linux as well.
Here there is a brief description of the allowed commands:
Switch Description It sets the address the daemon has to bind to (either numeric or literal). Default: it binds to all local IPv4 and IPv6 addresses. It sets the port the daemon has to bind to. Default: it binds to port 2002. It binds only to IPv4 addresses. Default: both IPv4 and IPv6 waiting sockets are used. It specifies a file that keeps the list of the hosts which are allowed to connect to this daemon (if more than one, the file keeps them one per line). We suggest to use literal names (instead of numeric ones) in order to avoid problems with different address families (IPv4 and IPv6). It permits NULL authentication (usually used with '-l', that guarantees that only the allowed hosts can connect to the daemon). Default: the username/password authentication mechanism is required. It forces the daemon to run in active mode and to connect to 'host' on port 'port'. This does not exclude that the daemon is still able to accept passive connections. It forces the daemon to run in active mode only (default: the daemon always accepts active connections, even if the '-a' switch is specified). Forces the daemon to run in background, i.e. as a daemon (UNIX only) or as a service (Win32 only). Warning (Win32): this switch is provided automatically when WinPcap installs this daemon into the Win32 services (control panel - administrative tools - services). It saves the current configuration to file. It loads the current configuration from file; all the switches specified from the command line are ignored and the file settings are used instead. It prints an help screen. Installing the remote daemon
The remote daemon is installed automatically when installing WinPcap. The installation process places the rpcapd file into the WinPcap folder. This file can be executed either from the command line, or as a service. For instance, the installation process updates the list of available services list and it creates a new item (Remote Packet Capture Protocol v.0 (experimental) ). To avoid security problems, the service is inactive and it has to be started manually (control panel - administrative tools - services - start).
The service has a set of "standard" parameters, i.e. it it launched with the " -d " flag (in orde to make it running as a service) and the " -f rpcapd.ini " flag. The user can create a file called rpcapd.ini in the same folder of the executable, and put the configuration commands in there. In order for the service to execute the commands, you have to stop and restart it again (i.e. the initialization file is parsed only at the beginning). Viceversa, the UNIX version of rpcapd is able to read the configuration file when sending a kill -HUP signal to it. In that case, all the existing connections remain in place, while the new connections will be created according to the new parameters.
In case the user does not want to create the configuration file manually, it can launch rpcapd with the requested parameters plus the " -s filename " one. The daemon will parse all the parameters and save them into the specified configuration file.
Starting the remote daemon as a standard executable
The rpcapd executable can be launched directly, i.e. it can run in the foreground as well (not as a daemon/service). The procedure is quite simple: you have to invoke the executable from the command line with all the requested parameters but the " -d " flag. The capture server will start in the foreground.
Читайте также: