Pcap

Setting the device

This is terribly simple. There are two techniques
for setting the device that we wish to sniff on.

The first is that we can
simply have the user tell us. Consider the following program:

	#include <stdio.h>
	#include <pcap.h>

	int main(int argc, char *argv[])
	{
		 char *dev = argv;

		 printf("Device: %s\n", dev);
		 return(0);
	}

The user specifies the device by passing the name of it as the first argument to
the program. Now the string «dev» holds the name of the interface that we
will sniff on in a format that pcap can understand (assuming, of course, the
user gave us a real interface).

The other technique is
equally simple. Look at this program:

	#include <stdio.h>
	#include <pcap.h>

	int main(int argc, char *argv[])
	{
		char *dev, errbuf;

		dev = pcap_lookupdev(errbuf);
		if (dev == NULL) {
			fprintf(stderr, "Couldn't find default device: %s\n", errbuf);
			return(2);
		}
		printf("Device: %s\n", dev);
		return(0);
	}

In this case, pcap just sets the device on its own. «But wait, Tim,» you
say. «What is the deal with the errbuf string?» Most of the pcap
commands allow us to pass them a string as an argument. The purpose of
this string? In the event that the command fails, it will populate the
string with a description of the error. In this case, if pcap_lookupdev()
fails, it will store an error message in errbuf. Nifty, isn’t it?
And that’s how we set our device.

PCAP Functions Used

Below I will cover all of the LibPCAP specific functions used in the 80211sniff.c code.

pcap_open_live()

This function opens the device for capturing packets. We use it as, which has 5 arguments. This function is for creating a handle which we creatively just name . will be NULL if an error has occurred while trying to listen on the device. The error will be stored in memory and pointed to by the the string pointer. This is why we check for an error and print it if so like so,

  • dev — The wireless device.
  • BUFSIZ — size of buffer or snap length of the handle.
  • — Boolean — promiscous mode or not.
  • 3000 — timeout for reading data in milliseconds.
  • erbuf — a place to store any error that arises from trying to run the function.

pcap_datalink()

This function returns an integer when passed the handle, whic is it’s only argument. In our code, we use it as What is printed is the link-layer header type for the packet received. In our case, 127 is the link-layer header type, which refers to the 802.11 IEEE RadioTap header: . Uncomment the call to to verify before compiling the code.

pcap_compile()/pcap_setfilter()

The function is used for creating a Berkley Filter Program, BFP, TCPDump filter. We use simple strings with specific syntax to filter out only the packet types that we want. In our case, we want a 802.11 Beacon packet. These packets are 802.11 management frames with a subtype value of 8, which in little endian format is represented as the byte: . The string that we use to get the beacon is and is defined to the pointer as . Using BPF is much more efficient that simply checking the values of the packet for type and subtype and should be used. For more information on TCPDump filters, check out the references section below. The arguments to are as follows,

  • handle — the opened handle to the PCAP session created by .
  • bpf program — a dereferenced pointer to a struct of the type bpf_program as we created with .
  • filter — our string object, that contains the BPF filter syntax as described above.
  • — Boolean for optimization
  • netp — an object of type which is the netmask of the device. In our case, we don’t have a netmask since our device is in RFMON mode.
    This sub routine will return a -1 if it fails, thus we have a test as which will exit the application by calling if true.

pcap_open_dead()/pcap_dump_open()/pcap_dump()/pcap_close()

These functions are for writing our captured packet to a file. The first, opens a faux handle to a session for writing. This does not open a file on disk, but a fake capture session. We pass to this function two arguments,

  • DLT_IEEE802_11_RADIO — data link-type constant as defined by as
  • BUFSIZ — snap length constant as defined by as .

The second, opens the actual file on disk to write the packet to that is «captured» by the faux handle created by . In our code we call it with 2 arguments,

  • fileHandle — the handle open to open the PCAP session.
  • outputFileName — the string of bytes that defines our file name on disk, in our case . This can be offloaded to an argument in , but please remember to add it to the subroutine.

The third subroutine, , writes the packet ot the file that is opened by . It takes three arguments,

  • *(u_char ) outputFile — the object.
  • header — the object that we defined at the interface to and is passed by .
  • packet — the passed to the function and is also passed by the function.

Finally, our last function is the fucntion which simply closes the file descriptor argument, . Without closing the file descriptor we could have corrupted data left in the file after our capture session.

Below is a simple output taken from my VMWare station with Weakerthan Linux 7 and an ALFA 802.11 USB WiFi adapter.

Getting Started

Writing applications with PcapPlusPlus is very easy and intuitive. Here is a simple application that shows how to read a packet from a PCAP file and parse it:

#include "IPv4Layer.h"
#include "Packet.h"
#include "PcapFileDevice.h"

int main(int argc, char* argv[])
{
    // open a pcap file for reading
    pcpp::PcapFileReaderDevice reader("1_packet.pcap");
    if (!reader.open())
    {
        printf("Error opening the pcap file\n");
        return 1;
    }

    // read the first (and only) packet from the file
    pcpp::RawPacket rawPacket;
    if (!reader.getNextPacket(rawPacket))
    {
        printf("Couldn't read the first packet in the file\n");
        return 1;
    }

    // parse the raw packet into a parsed packet
    pcpp::Packet parsedPacket(&rawPacket);

    // verify the packet is IPv4
    if (parsedPacket.isPacketOfType(pcpp::IPv4))
    {
        // extract source and dest IPs
        pcpp::IPv4Address srcIP = parsedPacket.getLayerOfType<pcpp::IPv4Layer>()->getSrcIpAddress();
        pcpp::IPv4Address destIP = parsedPacket.getLayerOfType<pcpp::IPv4Layer>()->getDstIpAddress();

        // print source and dest IPs
        printf("Source IP is '%s'; Dest IP is '%s'\n", srcIP.toString().c_str(), destIP.toString().c_str());
    }

    // close the file
    reader.close();

    return ;
}

Opening the device for sniffing

The task of creating a sniffing session is really quite
simple. For this, we use pcap_open_live(). The prototype of this
function (from the pcap man page) is as follows:

	pcap_t *pcap_open_live(char *device, int snaplen, int promisc, int to_ms,
	    char *ebuf)

The first argument is the device that we specified in the previous
section. snaplen is an integer which defines the maximum number of
bytes to be captured by pcap. promisc, when set to true, brings the
interface into promiscuous mode (however, even if it is set to false, it
is possible under specific cases for the interface to be in promiscuous
mode, anyway). to_ms is the read time out in milliseconds (a value of 0
means no time out; on at least some platforms, this means that you may
wait until a sufficient number of packets arrive before seeing any
packets, so you should use a non-zero timeout). Lastly, ebuf is a
string we can store any error messages within (as we did above with
errbuf). The function returns our session handler.

To demonstrate, consider this code snippet:

	 #include <pcap.h>
	 ...
	 pcap_t *handle;

	 handle = pcap_open_live(dev, BUFSIZ, 1, 1000, errbuf);
	 if (handle == NULL) {
		 fprintf(stderr, "Couldn't open device %s: %s\n", dev, errbuf);
		 return(2);
	 }

This code fragment opens the device stored in the strong «dev», tells it to
read however many bytes are specified in BUFSIZ (which is defined in pcap.h).
We are telling it to put the device into promiscuous mode, to sniff until an
error occurs, and if there is an error, store it in the string errbuf; it
uses that string to print an error message.

A note about promiscuous vs. non-promiscuous sniffing: The two
techniques are very different in style. In standard, non-promiscuous
sniffing, a host is sniffing only traffic that is directly related to
it. Only traffic to, from, or routed through the host will be picked up
by the sniffer. Promiscuous mode, on the other hand, sniffs all traffic
on the wire. In a non-switched environment, this could be all network
traffic. The obvious advantage to this is that it provides more packets
for sniffing, which may or may not be helpful depending on the reason
you are sniffing the network. However, there are regressions.
Promiscuous mode sniffing is detectable; a host can test with strong
reliability to determine if another host is doing promiscuous sniffing.
Second, it only works in a non-switched environment (such as a hub, or a
switch that is being ARP flooded). Third, on high traffic networks, the
host can become quite taxed for system resources.

Not all devices provide the same type of link-layer headers in the
packets you read. Ethernet devices, and some non-Ethernet devices,
might provide Ethernet headers, but other device types, such as loopback
devices in BSD and OS X, PPP interfaces, and Wi-Fi interfaces when
capturing in monitor mode, don’t.

You need to determine the type of link-layer headers the device
provides, and use that type when processing the packet contents. The
pcap_datalink() routine returns a value indicating the type of
link-layer headers; see the list of link-layer
header type values. The values it returns are the DLT_
values in that list.

If your program doesn’t support the link-layer header type provided
by the device, it has to give up; this would be done with code such as

	if (pcap_datalink(handle) != DLT_EN10MB) {
		fprintf(stderr, "Device %s doesn't provide Ethernet headers - not supported\n", dev);
		return(2);
	}

which fails if the device doesn’t supply Ethernet headers. This
would be appropriate for the code below, as it assumes Ethernet headers.

Internal

Some command line tools are shipped together with Wireshark. These tools are useful to work with capture files.

  • capinfos is a program that reads a saved capture file and returns any or all of several statistics about that file

  • dumpcap a small program whose only purpose is to capture network traffic, while retaining advanced features like capturing to multiple files (since version 0.99.0). Dumpcap is the engine under the Wireshark/tshark hood. For long-term capturing, this is the tool you want.

  • editcap edit and/or translate the format of capture files

  • mergecap merges multiple capture files into one

  • randpkt random packet generator

  • rawshark dump and analyze raw libpcap data

  • reordercap reorder input file by timestamp into output file

  • text2pcap generates a capture file from an ASCII hexdump of packets

  • tshark is the command-line equivalent of Wireshark, similar in many respects to tcpdump/WinDump but with many more features. Learn it, use it, love it.

Wrappers

  • dumpcapui — A GUI front-end for dumpcap.exe that helps you in setting up dumpcap.exe captures and allows storing and retrieving of those settings at a later time. (Windows)

  • Net::Sharktools — Use Wireshark’s packet dissection engine from Perl (blog entries: ).

  • Packet Dump Decode (pdd) is a simple and convenient GUI wrapper around the Wireshark tools to convert packet hexdumps into well formatted xml (viz. text2pcap and tshark). Using pdd, you just need to copy-paste the hexdump into pdd and hit the «Decode» button (GPL, Linux/Win32)

  • Packet Hexdump Decoder (phd) is a web-based utility that uses Wireshark tools to decode packet hexdumps online.

  • Sharktools — Use Wireshark’s packet dissection engine from Matlab and Python (announcement).

  • Webshark.io — Web interface using sharkd as backend. Git repo

  • Termshark — Terminal user interface for tshark. Written in Go, supports Linux/macOS/FreeBSD/Windows. Git repo

Getting Started: The format of a pcap application

The first thing to understand is the
general layout of a pcap sniffer. The flow of code is as follows:

  1. We begin by determining which interface we want to sniff
    on. In Linux this may be something like eth0, in BSD it may be xl1, etc.
    We can either define this device in a string, or we can ask pcap to
    provide us with the name of an interface that will do the job.
  2. Initialize pcap. This is where we actually tell pcap
    what device we are sniffing on. We can, if we want to, sniff on multiple
    devices. How do we differentiate between them? Using file handles.
    Just like opening a file for reading or writing, we must name our sniffing
    «session» so we can tell it apart from other such sessions.
  3. In the event that we only want to sniff specific traffic (e.g.:
    only TCP/IP packets, only packets going to port 23, etc) we must create a rule
    set, «compile» it, and apply it. This is a three phase process, all of
    which is closely related. The rule set is kept in a string, and is
    converted into a format that pcap can read (hence compiling it.) The
    compilation is actually just done by calling a function within our program; it
    does not involve the use of an external application. Then we tell pcap
    to apply it to whichever session we wish for it to filter.
  4. Finally, we tell pcap to enter it’s primary execution loop.
    In this state, pcap waits until it has received however many packets we want
    it to. Every time it gets a new packet in, it calls another function
    that we have already defined. The function that it calls can do anything
    we want; it can dissect the packet and print it to the user, it can save it in
    a file, or it can do nothing at all.
  5. After our sniffing needs are satisfied, we close our
    session and are complete.

This is actually a very
simple process. Five steps total, one of which is optional (step 3,
in case you were wondering.) Let’s take a look at each of the steps and how
to implement them.

Malware Traffic

Captured malware traffic from honeypots, sandboxes or real world intrusions.

Contagio Malware Dump: Collection of PCAP files categorized as APT, Crime or Metasplothttp://contagiodump.blogspot.com/2013/04/collection-of-pcap-files-from-malware.html
(the PCAP archive is hosted on DropBox and MediaFire)

WARNING: The password protected zip files contain real malware

Also see Contagio’s PCAP files per case:

  • Trojan.Tbot http://contagiodump.blogspot.com/2012/12/dec-2012-skynet-tor-botnet-trojantbot.html
  • ZeroAccess Trojan http://contagiodump.blogspot.com/2012/10/blackhole-2-exploit-kit-files-partial.html
  • CVE-2012-4681 http://contagiodump.blogspot.com/2012/09/cve-2012-4681-samples-original-apt-and.html
  • Trojan Taidoor http://contagiodump.blogspot.com/2011/11/nov-3-cve-2011-0611-1104statmentpdf.html
  • Poison Ivy CnC http://contagiodump.blogspot.com/2011/07/message-targeting-experts-on-japan.html

Malware analysis blog that shares malware as well as PCAP fileshttp://malware-traffic-analysis.net/

Filtering traffic

Often times our sniffer may only be interested in specific
traffic. For instance, there may be times when all we want is to sniff on
port 23 (telnet) in search of passwords. Or perhaps we want to highjack a
file being sent over port 21 (FTP). Maybe we only want DNS traffic (port
53 UDP). Whatever the case, rarely do we just want to blindly sniff all
network traffic. Enter pcap_compile() and pcap_setfilter().

The process is quite simple. After we have already called
pcap_open_live() and have a working sniffing session, we can apply our
filter. Why not just use our own if/else if statements? Two reasons.
First, pcap’s filter is far more efficient, because it does it directly
with the BPF filter; we eliminate numerous steps by having the BPF
driver do it directly. Second, this is a lot easier 🙂

Before applying our filter, we must «compile» it. The
filter expression is kept in a regular string (char array). The syntax
is documented quite well in the man page for tcpdump; I leave you to
read it on your own. However, we will use simple test expressions, so
perhaps you are sharp enough to figure it out from my
examples.

To compile the program we call pcap_compile(). The
prototype defines it as:

	int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, 
	    bpf_u_int32 netmask)

The first argument is our session handle (pcap_t *handle in our
previous example). Following that is a reference to the place we will
store the compiled version of our filter. Then comes the expression
itself, in regular string format. Next is an integer that decides if
the expression should be «optimized» or not (0 is false, 1 is
true. Standard stuff.) Finally, we must specify the network mask of the
network the filter applies to. The function returns -1 on failure; all
other values imply success.

After the expression has been compiled, it is time to apply
it. Enter pcap_setfilter(). Following our format of explaining pcap,
we shall look at the pcap_setfilter() prototype:

	int pcap_setfilter(pcap_t *p, struct bpf_program *fp)

This is very straightforward. The first argument is our session handler,
the second is a reference to the compiled version of the expression (presumably
the same variable as the second argument to pcap_compile()).

Perhaps another code sample would help to better understand:

	 #include <pcap.h>
	 ...
	 pcap_t *handle;		/* Session handle */
	 char dev[] = "rl0";		/* Device to sniff on */
	 char errbuf;	/* Error string */
	 struct bpf_program fp;		/* The compiled filter expression */
	 char filter_exp[] = "port 23";	/* The filter expression */
	 bpf_u_int32 mask;		/* The netmask of our sniffing device */
	 bpf_u_int32 net;		/* The IP of our sniffing device */

	 if (pcap_lookupnet(dev, &net, &mask, errbuf) == -1) {
		 fprintf(stderr, "Can't get netmask for device %s\n", dev);
		 net = 0;
		 mask = 0;
	 }
	 handle = pcap_open_live(dev, BUFSIZ, 1, 1000, errbuf);
	 if (handle == NULL) {
		 fprintf(stderr, "Couldn't open device %s: %s\n", dev, errbuf);
		 return(2);
	 }
	 if (pcap_compile(handle, &fp, filter_exp, 0, net) == -1) {
		 fprintf(stderr, "Couldn't parse filter %s: %s\n", filter_exp, pcap_geterr(handle));
		 return(2);
	 }
	 if (pcap_setfilter(handle, &fp) == -1) {
		 fprintf(stderr, "Couldn't install filter %s: %s\n", filter_exp, pcap_geterr(handle));
		 return(2);
	 }

This program preps the sniffer to sniff all traffic coming from or going to port
23, in promiscuous mode, on the device rl0.

You may notice that the previous example contains a function that we
have not yet discussed. pcap_lookupnet() is a function that, given the
name of a device, returns one of its IPv4 network numbers and
corresponding network mask (the network number is the IPv4 address ANDed
with the network mask, so it contains only the network part of the
address). This was essential because we needed to know the network mask
in order to apply the filter. This function is described in the
Miscellaneous section at the end of the document.

It has been my experience that this filter does not work across all
operating systems. In my test environment, I found that OpenBSD 2.9
with a default kernel does support this type of filter, but FreeBSD 4.3
with a default kernel does not. Your mileage may vary.

Wrapping Up

At this point you should be able to write a
sniffer using pcap. You have learned the basic concepts behind opening a
pcap session, learning general attributes about it, sniffing packets, applying
filters, and using callbacks. Now it’s time to get out there and sniff those
wires!

This document is Copyright 2002 Tim Carstens.
All rights reserved. Redistribution and use, with or without modification,
are permitted provided that the following conditions are met:

  1. Redistribution must retain the above copyright notice and this list of
    conditions.
  2. The name of Tim Carstens may not be used to endorse or
    promote products derived from this document without specific prior written
    permission.

Cyber Defence Exercises (CDX)


This category includes network traffic from exercises and competitions, such as Cyber Defense Exercises (CDX) and red-team/blue-team competitions.

MACCDC — Pcaps from National CyberWatch Mid-Atlantic Collegiate Cyber Defense Competitionhttps://www.netresec.com/?page=MACCDC

ISTS — Pcaps from the Information Security Talent Searchhttps://www.netresec.com/?page=ISTS

WRCCDC — Pcaps from the Western Regional Collegiate Cyber Defense Competition (over 1TB of PCAPs)https://archive.wrccdc.org/pcaps/

Malware Traffic

Captured malware traffic from honeypots, sandboxes or real world intrusions.

Contagio Malware Dump: Collection of PCAP files categorized as APT, Crime or Metasplothttp://contagiodump.blogspot.com/2013/04/collection-of-pcap-files-from-malware.html
(the PCAP archive is hosted on DropBox and MediaFire)

WARNING: The password protected zip files contain real malware

Also see Contagio’s PCAP files per case:

  • Trojan.Tbot http://contagiodump.blogspot.com/2012/12/dec-2012-skynet-tor-botnet-trojantbot.html
  • ZeroAccess Trojan http://contagiodump.blogspot.com/2012/10/blackhole-2-exploit-kit-files-partial.html
  • CVE-2012-4681 http://contagiodump.blogspot.com/2012/09/cve-2012-4681-samples-original-apt-and.html
  • Trojan Taidoor http://contagiodump.blogspot.com/2011/11/nov-3-cve-2011-0611-1104statmentpdf.html
  • Poison Ivy CnC http://contagiodump.blogspot.com/2011/07/message-targeting-experts-on-japan.html

Malware analysis blog that shares malware as well as PCAP fileshttp://malware-traffic-analysis.net/

Network Forensics

Network forensics training, challenges and contests.

  • Slides/Cases (PDF)
  • SecurityOnion VM (5.8 GB)VirtualBox VM with PCAP files. VM login credentials are: user/password
  • Capture files (4.4 GB)

ENISA’s Network Forensics training

  • Document for teachers (PDF)
  • Document for students (PDF)
  • Virtual Machine (OVA)

SCADA/ICS Network Captures

4SICS ICS Lab PCAP files — 360 MB of PCAP files from the ICS village at 4SICShttps://www.netresec.com/?page=PCAP4SICS

Типы файлов PCAP

Ассоциация основного файла PCAP

.PCAP

Формат файла: .pcap
Тип файла: Packet Capture Data

PCAP представляет собой файл данных, созданный Wireshark, бесплатной программы, используемой для анализа сети. Файл PCAP используется для перехвата пакетов и анализа сетевых данных характеристик. Файл PCAP могут быть проанализированы с помощью программного обеспечения, которое включает в себя Libpcap или WinPCap библиотеки.

Создатель: The Wireshark Team
Категория файла: Файлы данных
Ключ реестра: HKEY_CLASSES_ROOT\.pcap

Программные обеспечения, открывающие Packet Capture Data:

Wireshark, разработчик — The Wireshark Team

Совместимый с:

Windows
Mac
Linux

Network Miner, разработчик — Netresec

Совместимый с:

Windows
Linux

WinDump, разработчик — RiverBed

Совместимый с:

Windows

Malformed pcapng Files

  • http.bigendian.ntar — same as http.littleendian but buggy! mixture of big and little endian byte swapping, beginning with a bad SHB major version value

  • test007.ntar (SHB, IDB, 1 * SPB) — there are two problems with this file: (1) the SPB Block Length is 139, which is not a multiple of 4, and (2) the SPB Packet Data contains more than the SHB’s snaplen length allows (SHB’s snaplen is 96, but the SPB contains 123 bytes of data).

  • test010.ntar (SHB, IDB, 1 * SPB) — same problem as test007.ntar above.

Included below is the C source code to a very simplistic program to read and dump header information about a pcapng (a.k.a. ntar) file. This program has been successfully compiled using gcc and used on several different types of systems including Linux, cygwin and Solaris 9.

ntartest.c

To compile this program use the command:

# gcc -o ntartest ntartest.c

To use the program provide a pcapng file as the first argument to the program:

# ntartest http.littleendian.pcapng

NTAR

The Network Trace Archival and Retrieval library is able to read and write pcapng files. Caveats: i) frozen since 2007, ii) no plugins for EPB, ISB, and NRB blocks. Mailing list archives.

  • Upstream has a more recent version of the library that includes support for EPB blocks. Unfortunately this version is not available for download on the website.
  • (2012-07) NTAR library anonymous subversion repository (ml announcement)

Wireshark

As of Wireshark 1.2.0, pcapng files can be read and written, and live captures can be done in pcapng format as well as pcap format. There were a number of bugs in 1.2.0’s support that were fixed in 1.2.1.

The current limitations for pcapng format are:

  • Only a single section
  • Only blocks SHB, IDB, PB, EPB, SPB (others will be ignored)
  • Lots of Options not implemented
  • Writing files is mostly untested
  • When merging files, mergecap doesn’t retain each IDB’s snaplen
  • mergecap won’t merge pcapng files with different encapsulations and intermixed timestamps

tshark 1.6 should be able to read and write NRB blocks (command line options: -W n and -H hosts_file).

dumpcap 1.4/1.6/1.7 uses the libpcap_write_.*_block functions from pcapio.c to write the pcapng blocks. It currently writes SHB, IDB, EPB and ISB blocks.

  • dumpcap -i eth0 -n -w file.pcapng
  • dumpcap -i eth0 -w file.pcapng

    Capture file will have the following blocks: SHB, IDB, EPB, EPB, …, ISB.

  • dumpcap -i eth0 -i eth1 -i eth2 -w file.pcapng
    • Capture file will have the following pcapng blocks: SHB, IDB, IDB, IDB, EPB, EPB, …, ISB, ISB, ISB.
    • You can also supply a different capture filter for each interface: dumpcap -i eth0 -f udp -i eth1 -i eth2 -f tcp -w file.pcapng
    • TODO: the «-i any» behavior needs to be specified (see )

  • dumpcap -i eth0 -i eth1 -i eth2 -w file.pcapng

    Capture file will have the following pcapng blocks: SHB, IDB, ISB, IDB, ISB, IDB, ISB, EPB, EPB, …, ISB, ISB, ISB.

  • dumpcap -i eth0 -i eth1 -i eth2 -w file.pcapng

    • Stopped writing ISB blocks immediately after IDB blocks
    • Capture file will have the following pcapng blocks: SHB, IDB, IDB, IDB, EPB, EPB, …, ISB, ISB, ISB.
  • — Pcapng is now the default file format.

Некоторые программы, использующие libpcap/WinPcap

  • tcpdump, Инструмент для захвата, сохранения пакетов и для дальнейшего их анализа.
  • Wireshark (также Ethereal), Удобная программа с развитым графическим интерфейсом для захвата и анализа сетевых данных.
  • Snort, Система обнаружения сетевых атак.
  • Nmap, a port-scan fingerprinting
  • the Bro IDS Мониторинг сети.
  • URL Snooper, определяет URLs аудио и видео файлов так, что их можно записать.
  • Kismet, для 802.11 беспроводных локальных сетей.
  • AppRadar, Система обнаружения вторжения в базу данных.
  • L0phtCrack программа проверки паролей.
  • AutoScan Network, программа обнаружения сетевых атак.
  • pTraffer Система сбора, индексирования и поиска информации с оповещением о появлении ключевых слов
  • HiDownload, менеджер закачек со встроенным сниффером
  • SSl Strip программа для совершения хакерских действий через интернет
  • SING, спуффер
  • Darkstat, мониторинг трафика
  • Proteus, пакет программ для автоматизированного проектирования (САПР) электронных схем
  • Router Scan, программа для проверки безопасности сетей Wi-Fi, для работы с протоколом WPS

Today and the Future

It is widely accepted that the libpcap file format serves its purpose but lacks some useful features. There’s a next generation pcap file format documented at the pcapng specification Git repository. The new format supplies many of the capabilities listed in «Drawbacks» above.

Wireshark currently has the ability to read and write pcapng files, and does so by default, although doesn’t support all of the capabilities of the files. Libpcap 1.1.0 and later have a limited ability to read them as well, although libpcap doesn’t yet supporting writing them.

More details about the integrating of the pcapng file format into Wireshark at: Development/PcapNg

Описание

В текстовом виде PCAP-фильтр выглядит как выражение, состоящее из одного или нескольких примитивов. Примитивы в выражении определяют возможность приема фильтром входящего пакета. Каждый примитив определяет конкретный элемент пакета протокола стандартной структуры и его значение, сравниваемое фильтром со значением соответствующего элемента входящего пакета. Если значение примитива совпадает со значением элемента пакета, фильтр отмечает его как «логическую истину» (true) и переходит к сравнению следующего примитива. При совпадении всех значений выражения со значениями проверенных элементов пакета фильтр принимает решение о приеме данного пакета, в противном случае входящий пакет игнорируется.

Каждый примитив обычно состоит из одного или нескольких квалификаторов и следующего за ними идентификатора (имя или число). Всего имеется три типа квалификаторов:

  • «type» – определяет тип имени или номера идентификатора. Возможные значения: «host» (хост), «net» (сеть), «port» (порт) или «portrange» (диапазон портов). Если квалификатор отсутствует, по умолчанию принимается «host».
  • «dir» – определяет возможное направление приема и передачи данных объектом, указанным в качестве идентификатора: к нему и/или от него. Допускается указание следующих значений: «src» (отправитель), «dst» (получатель), «src and dst» (отправитель и получатель), «src or dst» (отправитель или получатель). Если квалификатор не указан, по умолчанию принимается «src  or  dst».
  • «proto» – определяет тип протокола, используемого объектом, указанным в качестве идентификатора. Возможные значения: «ether», «fddi», «ip», «arp», «rarp», «decnet», «lat», «sca», «moprc», «mopdl», «tcp» и «udp». При отсутствии квалификатора значение по умолчанию выбирается по максимальному соответствию указанному идентификатору.

Стоит отметить, что существуют некоторые специальные примитивы, которые не соответствуют шаблону: «broadcast», «less», «greater», а также арифметические выражения. Подробное описание приведено ниже.

Более сложные выражения фильтра создаются с использованием слов «and»,  «or» и «not» для объединения примитивов. Примитивы можно группировать с помощью скобок и логических операций:

  • отрицание («!» или «not»);
  • сложение («&&» или «and»);
  • дизъюнкция («||» или «or»).

Отрицание имеет самый высокий приоритет. Сложение и дизъюнкция имеют одинаковый приоритет в выражении и читаются слева направо. 

Аббревиатуры «ip», «arp», «rarp», «atalk», «aarp», «iso», «stp», «ipx», «netbeui» являются сокращениями для «ether proto p», где «p» один из указанных протоколов. «tcp», «udp», «icmp» являются сокращениями для «ip proto p», где «p» — один из указанных выше протоколов. «clnp», «esis», «isis» являются сокращениями для «iso proto  p», где «p» — один из указанных выше протоколов.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector