Program for interception and decryption of data packets. Wireshark (network packet capture). Fake ARP Requests

Nowadays, public Wi-Fi networks have also become very popular. They are found in restaurants, gyms, shopping malls, in the subway, in hotels, in private hospitals and clinics, in apartments and condominiums - they can be found almost anywhere where quite a lot of people gather.

These networks have a feature - they are often open Wi-Fi networks that do not require a password to connect to. Are there any additional security rules for working with such networks?

Yes, when using open WiFi network it is important to understand that:

• all data is transmitted by radio waves, that is, unlike a wire that not everyone can access, radio waves can be intercepted by anyone who is within reach
• in open networks, data is not encrypted

With the first point, I think everything is clear: if someone with a computer and a Wi-Fi card is close enough, then he can capture and store all the traffic transmitted between the wireless Access Point and all its clients.

As for the second point, it is necessary to clarify about the encryption of the transmitted data. For example, if you open a site that uses the HTTPS protocol (that is, a secure protocol), such as a site, then the data transmitted to this site and from this site to you is encrypted. If you open a site running on the HTTP protocol, then all transmitted data: what pages you visited, what comments you left, what cookies your web browser received - this data is transmitted in unencrypted form. So, if you are connected to WiFi hotspot Access that requires a password, then the transmitted traffic is encrypted again. That is, even if you open a site using the HTTPS protocol, the transmitted traffic is encrypted twice (the first time when transferring from a web browser to a web server and vice versa, the second time when transferring from your device to the Access Point, and also in reverse direction). And if you open a site on the HTTP protocol, then the transmitted traffic is encrypted only once (only when transferring from your device to the Access Point and back).

But open access points do not encrypt traffic. It follows from this: if you use an open access point and open a site running on the HTTP protocol, then your data is transmitted in the clear and anyone near you can capture and save it. If you open a site on the HTTPS protocol, then this data is encrypted, however, you can still see which sites you opened (although you can’t see which pages and what you entered, for example, which comments you left).

So: you need to remember that open wireless network susceptible to information interception.

Interception of traffic in open Wi-Fi networks

For a successful attack, you need a Linux computer (for example, with Kali Linux or with BlackArch), as well as a Wi-Fi card from .

Let's start by looking at the names of the wireless interfaces:

As you can see, I have several wireless interfaces, I will use wlp0s20f0u2.

We transfer the wireless interface to monitor mode:

sudo ip link set INTERFACE down sudo iw INTERFACE set monitor control sudo ip link set INTERFACE up

In the previous commands, instead of INTERFACE you need to enter the name that the wireless interface has on your system. For example, for wlp0s20f0u2, the commands look like this:

sudo ip link set wlp0s20f0u2 down sudo iw wlp0s20f0u2 set monitor control sudo ip link set wlp0s20f0u2 up

Open the captured data file in Wireshark.

To highlight different data, we need Wireshark filters. Here I will show an example of using only some of the filters, it is recommended to explore the large collection of useful Wireshark filters.

To evaluate the quality of the capture, you can start with filters that display the results of the TCP protocol analysis.

For example:

tcp.analysis.duplicate_ack_num == 1

This filter outputs information about frames with the ACK flag that are duplicates. A large number of such frames may indicate communication problems between the Client and the Access Point.

Filter for displaying frames for which the previous segment is not captured:

Tcp.analysis.ack_lost_segment

This is normal at the beginning of data capture - because the information is not intercepted from the very beginning. But if this error occurs frequently in the future, then you are too far from the Access Point or Clients and you are not capturing some of the data they transmit.

To show frames that are retransmitted (retransmitted):

Tcp.analysis.retransmission

A large number of such frames may indicate that there is poor communication between the Client and the AP and they often have to send the same data repeatedly.

With a filter

You can see ARP traffic - with its help it is convenient to analyze how many devices in total this moment connected to local network what are their IP addresses and what MAC addresses. .

With a filter

you can see all sent DNS requests.

Thanks to these requests, you can find out which sites users have visited (even if these sites use HTTPS!), as well as which online services requests have been made.

For example, in the screenshot you can see the addresses of the online cinema Netflix, Facebook, and various Google services.

To filter HTTP traffic filter:

Here you can find a lot of interesting information. For example, you can see service requests and transmitted data, including API keys, device IDs, and more:

You can see visited URL address with all passed parameters:

Files downloaded and open on the Internet are visible:

You can save any transferred file. To do this, select the package that contains it with the mouse (1), then in the middle panel, which contains detailed information, scroll to the very bottom to find the data field and right-click on it to call the context menu (2), in context menu select Export Selected Packet Bytes(3) - Export bytes of the selected package:

Enter a file name, select a location, and save it.

Someone is updating Windows:

You can also see the cookies set by the user or the cookies transmitted by him:

With a filter

Http.cookie

you can see HTTP requests in which cookies were transmitted.

And with a filter

Http.set_cookie

you can see requests in which the server set cookies in the user's browser.

Neighbors download strange torrents:

Transferred method POST data also visible:

To search for any transferred images:

http.content_type contains "image"

To search for specific types of images:

http.content_type contains "gif" http.content_type contains "jpeg" http.content_type contains "png"

To search for files of a specific type:

http.content_type contains "text" http.content_type contains "xml" http.content_type contains "html" http.content_type contains "json" http.content_type contains "javascript" http.content_type contains "x-www-form-urlencode" http. content_type contains "compressed" http.content_type contains "application"

Searching Wireshark for requests to get files of a particular type. For example, to search for transferred ZIP archives:

Http.request.uri contains "zip"

Instead of http.request.uri filters can be used for greater accuracy http.request.uri.path or http.request.uri.query e.g. to search for download requests JPG files(links to pictures):

Http.request.uri.path contains "jpg"

A filter that only shows the data submitted by the POST method:

http.request.method == "POST"

A filter that only shows the data passed by the GET method:

http.request.method == "GET"

Search for requests to a specific site (host):

http.host==" "

Search for requests to a specific site by part of the name:

Http.host contains "here.partial.name"

Conclusion

Now the number of applications and sites that do not use encryption is rapidly decreasing. Therefore, the risk of such interception decreases every year. Nevertheless, it exists.

Even sites that use HTTPS can inadvertently give out data. For example:

It can be seen that the data from the user to booking.com is transmitted in unencrypted form, so this link can be intercepted.

The iPhone app is constantly downloading some (audio?) files without using a secure connection:

The popular (in some regions) qq.com either does not use encryption or uses its own algorithm:

The guaranteed protection against such interception is the use of a trusted VPN service. A reliable VPN service can be considered the one that you set up yourself, or the VPN of your corporate network.

Interceptor is a multifunctional network tool that allows you to get data from traffic (passwords, messages in instant messengers, correspondence, etc.) and implement various MiTM attacks.

Intercepter interface
Main functionality

• Interception of messenger messages.
• Interception of cookies and passwords.
• Interception of activity (pages, files, data).
• Ability to spoof file downloads by adding malicious files. Can be used in conjunction with other utilities.
• Replacing Https certificates with Http.

Recovery Mode– recovery of useful data from traffic, from protocols that transmit traffic in the clear. When the victim views files, pages, data, it is possible to partially or completely intercept them. Additionally, you can specify the size of the files so as not to download the program in small parts. This information can be used for analysis.

Password Mode– mode for working with cookies. Thus, it is possible to gain access to the visited files of the victim.

scan mode– the main mode for testing. Right-click Smart Scan to start scanning. After scanning, the window will display all network members, their operating system and other options.

Additionally, in this mode, you can scan ports. You need to use the Scan Ports feature. Of course, there are much more functional utilities for this, but the presence of this function is an important point.

If we are interested in a targeted attack on the network, then after scanning, we need to add the target IP to Nat using the (Add to Nat) command. In another window, it will be possible to carry out other attacks.

Nat mode. The main mode, which allows you to carry out a number of ARP attacks. This is the main window that allows targeted attacks.

DHCP mode. This is a mode that allows you to raise your DHCP server to implement DHCP attacks in the middle.

Some types of attacks that can be carried out
Website spoofing

To spoof the victim's site, you need to go to Target, after that you need to specify the site and its substitution. Thus, you can replace a lot of sites. It all depends on how good the fake is.

Website spoofing

Example for VK.com

Choosing a MiTM attack

​

Changing the Injection Rule
As a result, the victim opens a fake site when requested vk.com. And in the password mode, there should be the login and password of the victim:

To conduct a targeted attack, you must select a victim from the list and add it to the target. This can be done with the right mouse button.

Additions of MiTm attack
Now you can recover various data from traffic in Ressurection Mode.

Files and information of the victim through a MiTm attack
Traffic spoofing

Specifying settings
After that, the victim will change the request "trust" to "loser".

Additionally, you can kill cookies so that the victim logs out of all accounts and re-authorizes. This will intercept logins and passwords.

Destruction of cookies

How to see a potential sniferr on the network using Intercepter?
Using the Promisc Detection option, you can detect a device that is scanning on the local network. After scanning, the status column will be "Sniffer". This is the first way that allows you to define scanning on the local network.

Sniffer detection
SDR HackRF Device


​

HackRF is a complete $300 SDR device. Project author Michael Ossman is developing successful devices in this direction. Previously, the Ubertooth Bluetooth sniffer was developed and successfully implemented. HackRF is a successful project that has raised over 600k on Kickstarter. 500 such devices have already been implemented for beta testing.

HackRF operates in the frequency range from 30 MHz to 6 GHz. The sampling rate is 20 MHz, which allows you to intercept wifi signals and LTE networks.

How to protect yourself at the local level?
First, let's use the SoftPerfect WiFi Guard software. There is a portable version that takes no more than 4 MB. It allows you to scan your network and display which devices are displayed on it. It has settings that allow you to choose network card and the maximum number of scanned devices. Additionally, you can set the scan interval.


​

Conclusion
Thus, we have considered in practice how to use software to intercept data within the network. We considered several specific attacks that allow you to get login data, as well as other information. Additionally, we considered SoftPerfect WiFi Guard, which allows you to protect the local network from listening to traffic at a primitive level.

Original: network sniffing
Author: Paul Cobbaut
Publication date: March 12, 2015
Translation: A. Panin
Date of transfer: April 1, 2015

Chapter 23

A network administrator should be able to use a sniffer such as wireshark or tcpdump to diagnose network problems.

The student will also often have to resort to using a sniffer in order to understand the principles of the functioning of networks. This chapter describes the appropriate techniques for capturing network traffic.

23.1. wireshark app

23.1.1. Installing wireshark

IN this example here is the command to install the wireshark application on distributions using packages software with .deb extension (including Debian, Mint, Xubuntu and other distributions).

Root@debian8:~# Read package lists Done Build dependency tree Read status information Done... (output shortened)

On distributions that use .rpm software packages, such as CentOS, RHEL, and Fedora, the yum utility can be used to install the wireshark application.

# yum install wireshark Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile ... (output shortened)

23.1.2. Selecting a network interface

When you start the wireshark application for the first time, you will have to select a network interface. You will see a dialog that looks similar to the one shown in the illustration below.

It is likely that there will simply be no available network interfaces, because in some distributions network traffic can be intercepted exclusively by the root user. In this case, you will have to run the wireshark application as root using the sudo wireshark command.

Or you can follow the general guidelines and use the tcpdump utility or some other tool to capture the traffic and write the data to a file. Any captured data can be analyzed later using the wireshark application.

23.1.3. Traffic minimization

In the process of intercepting network traffic, thousands of packets can be generated in very short periods of time. Obviously, such a volume of data will make it difficult to analyze traffic. Try to get out of this situation by isolating your sniffer within the network. The preferred option is to intercept traffic passing through the network interface of an isolated virtual network that is under your full control.

If you are looking into tools to intercept network traffic at home, it will be a good idea to minimize traffic by shutting down all networking applications running on your computer, as well as disconnecting your computer from other computers and from devices such as smartphones and tablets.

Yet a more important tool for minimizing traffic are filters, which will be discussed in the next section.

23.1.4. Intercepting traffic generated by the ping utility

I ran a sniffer and captured all the packets transmitted over the network as a result of executing three ping commands (it does not make sense to run these commands as root):

Root@debian7:~# ping -c2 ns1.paul.local PING ns1.paul.local (10.104.33.30) 56(84) bytes of data. 64 bytes from 10.104.33.30: icmp_req=1 ttl=64 time=0.010 ms , 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.010/0.016/0.023/0.007 ms root@debian7:~# ping -c3 linux-training.be PING linux-training.be (188.93.155.87) 56(84) bytes of data. 64 bytes from antares.ginsys.net (188.93.155.87): icmp_req=1 ttl=56 time=15.6 ms from antares.ginsys.net (188.93.155.87): icmp_req=3 ttl=56 time=14.7 ms --- linux-training.be ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 14.756/16.110/17.881/1.309 ms root@debian7:~# ping -c1 centos7.paul.local PING centos7.paul.local (10.104.33.31) 56(84) bytes of data. 64 bytes from 10.104.33.31: icmp_req=1 ttl=64 time=0.590 ms --- centos7.paul.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max /mdev = 0.590/0.590/0.590/0.000ms

In total, more than 200 packets were captured from the network. Things will become much clearer if you enter the string icmp in the filter field and click the "Apply" button.

23.1.5. Intercepting traffic generated by the ping utility and the dns client

Working with the same data capture session, let's apply a different filter. We want to monitor both dns and icmp traffic, so we'll have to enter the names of the two mentioned protocols in the filter field.

To capture data related to the two protocols in question, the string "dns or icmp" must be entered in the filter field. If you enter the string "dns and icmp", no information about any packets will be displayed, since there are no packets related to both of the mentioned protocols.

Looking at the illustration above, you can see that packets 25 and 26 have source and destination IP addresses of 10.104.33.30. This is because the DNS client is running on the same computer as the DNS server.

A similar situation is observed in the case of packets 31 and 32, because using the ping utility, packets are sent working system on which the utility is running.

23.1.6. Specific IP address

In this case, packets related to the DNS protocol and containing a specific IP address are filtered. The string "ip.addr==10.104.33.30 and dns" is used as a filter. The and directive tells the application to display information about each package that matches two conditions.

Packet 93 contains a DNS query for the A record of the linux-training.be domain. Packet 98 contains the response from DNS servers. What do you think happened after packet 93 was sent and before packet 98 was received? Try to answer this question before reading the next section (when working with various systems it is always a good idea to try to predict upcoming events and check the correctness of your predictions).

23.1.7. Frame based filtering

The correct term to use for a captured packet is a frame (due to the fact that we are capturing packets at layer 2 of the OSI networking model). Thus, to display information about packets with specific numbers, you should use the frame.number directive in the filter field.

23.1.8. Examining the contents of packages

The middle pane of the sniffer window can be expanded. When you select a row within this panel, you can see the corresponding byte values ​​in the bottom panel field.

The illustration below shows the middle pane of the sniffer window with my laptop's address selected.

Note that the technique described above works great when capturing traffic on a single network interface. If you are capturing traffic, for example, using the tcpdump -i any command, you will encounter the "Linux cooked capture" packet capture method.

23.1.9. Other filter examples

You can combine two protocol declarations with an or ("OR") logical operator directive between them. The illustration below shows how to capture only ARP and BOOTP (or DHCP) packets.

And the following illustration shows how to intercept packets related to the DNS protocol and containing a specific IP address.

23.2. tcpdump utility

In the case of working with the system command line interface, packet capture can be performed using the tcpdump utility. Below are some examples of its use.

Using the tcpdump host $ip command will display information about all traffic related to a specific host (in this case, with the IP address 192.168.1.38).

Root@ubuntu910:~# tcpdump host 192.168.1.38 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

Ssh-only traffic (TCP port 22) can be captured using the tcpdump tcp port $port command. Output lines have been shortened to 76 characters for easier reading.

Root@deb503:~# tcpdump tcp port 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 14:22:20.716313 IP deb503. local.37973 > rhel53.local.ssh: P 666050963:66605 14:22:20.719936 local .ssh > deb503.local.37973: P 49:113(64) ack 14:22:20.721321 IP rhel53.local.ssh > deb503.local.37973: P 113:161(48) ack 14:22:20.721820 IP deb503 .local.37973 > rhel53.local.ssh: . ack 161 win 200 14:22:20.722492 IP rhel53.local.ssh > deb503.local.37973: P 161:225(64) ack 14:22:20.760602 IP deb503.local.37973 > rhel53.local.ssh: . ack 225 win 200 14:22:23.108106 IP deb503.local.54424 > ubuntu910.local.ssh: P 467252637:46 14:22:23.116804 IP ubuntu910.local.ssh > deb503.local.54424: P 1:8 1(80 ) ack 14:22:23.116844 IP deb503.local.54424 > ubuntu910.local.ssh: . ack 81 win 2 ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel

The same operation, but with the captured data written to a file, can be performed using the tcpdump -w $filename command.

Root@ubuntu910:~# tcpdump -w sshdump.tcpdump tcp port 22 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes ^C 17 packets captured 17 packets received by filter 0 packets dropped by kernel

Using the tcpdump -r $filename command, the contents of the file created in the previous example can be dumped.

Root@ubuntu910:~# tcpdump -r sshdump.tcpdump

Many other examples of the utility in question can be found in the man page tcpdump .

23.3. Practical task: interception of network traffic

23.4. Correct Practice Procedure: Intercepting Network Traffic

1. Install the wireshark application on your system (not running in a virtual machine).

On Debain/Ubuntu distributions: aptitude install wireshark

On Red Hat/Mandriva/Fedora distributions: yum install wireshark

2. Use the ping utility to generate traffic between your computer and some other computer.

Ping $ip_address

3. Start capturing network traffic.

(sudo) wireshark

Select network interface (probably eth0)

4. Using the filter, display information only about those packets that contain responses to requests from the ping utility.

Enter "icmp" (without the quotes) in the filter box and click the "Apply" button.

5. Now give the ping utility a domain name (such as www.linux-training.be) and try to capture the DNS query and response packets. What DNS server was used? Was TCP or UDP used to send the request and response?

First of all start the sniffer.

Enter "dns" in the filter field and click the "Apply" button.

Root@ubuntu910:~# ping www.linux-training.be PING www.linux-training.be (88.151.243.8) 56(84) bytes of data. 64 bytes from fosfor.openminds.be (88.151.243.8): icmp_seq=1 ttl=58 time=14.9 ms --- www.linux-training.be ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 14.984/15.539/16.095/0.569 ms

The wireshark application window should look similar.

Based on the information from the wireshark application window, it can be concluded that the DNS request was transmitted using a UDP packet, after which it is easy to answer the questions posed.

6. Find a closed website that has a password request form. Try to log in using username "paul" and password "hunter2" while the sniffer is running. Now try to find the entered username and password in the data captured using the sniffer.

Many users do not even realize that by filling in the login and password when registering or authorizing on a closed Internet resource and pressing ENTER, this data can easily be intercepted. Very often they are transmitted over the network in an unsecured form. Therefore, if the site on which you are trying to log in uses the HTTP protocol, then it is very easy to capture this traffic, analyze it using Wireshark, and then use special filters and programs to find and decrypt the password.

The best place to intercept passwords is the core of the network, where the traffic of all users goes to closed resources (for example, mail) or in front of the router to access the Internet when registering on external resources. We set up a mirror and we are ready to feel like a hacker.

Step 1. Install and run Wireshark to capture traffic

Sometimes for this it is enough to select only the interface through which we plan to capture traffic, and click the Start button. In our case, we capture wirelessly.

Traffic capture has begun.

Step 2. Filtering captured POST traffic

We open the browser and try to log in to any resource using the username and password. Upon completion of the authorization process and the opening of the site, we stop capturing traffic in Wireshark. Next, open the protocol analyzer and see a large number of packets. This is the stage where most IT professionals give up because they don't know what to do next. But we know and we are interested in specific packets that contain POST data that is generated on our local machine when filling out a form on the screen and sent to remote server when you click the "Login" or "Authorization" button in the browser.

Enter a special filter in the window to display captured packets: http.request.method == "POST"

And instead of a thousand packages, we see only one with the data we are looking for.

Step 3. Find the username and password

Quick click right button mouse and select from the menu Follow TCPSteam

After that, text will appear in a new window, which in the code restores the page content. Let's find the "password" and "user" fields, which correspond to the password and username. In some cases, both fields will be easy to read and not even encrypted, but if we are trying to capture traffic when accessing very well-known resources such as: Mail.ru, Facebook, Vkontakte, etc., then the password will be encoded:

HTTP/1.1 302 Found

Server: Apache/2.2.15 (CentOS)

X-Powered-By: PHP/5.3.3

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Set-Cookie:password= ; expires=Thu, 07-Nov-2024 23:52:21 GMT; path=/

Location: loggedin.php

Content Length: 0

Connection: close

Content-Type: text/html; charset=UTF-8

So in our case:

Username: networkguru

Password:

Step 4Determine the type of encoding to decrypt the password

We go, for example, to the site http://www.onlinehashcrack.com/hash-identification.php#res and enter our password in the identification window. I was given a list of encoding protocols in order of priority:

Step 5: Decrypt User Password

At this stage, we can use the hashcat utility:

~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

At the output, we received a decrypted password: simplepassword

Thus, with the help of Wireshark, we can not only solve problems in the operation of applications and services, but also try ourselves as a hacker by intercepting passwords that users enter in web forms. You can also find out passwords for mailboxes users using simple filters to display:

• The POP protocol and filter looks like this: pop.request.command == "USER" || pop.request.command == "PASS"
• The IMAP protocol and filter will be: imap.request contains "login"
• SMTP protocol and you will need to enter the following filter: smtp.req.command == "AUTH"

and more serious utilities for decrypting the encoding protocol.

Step 6. What if the traffic is encrypted and using HTTPS?

There are several options for answering this question.

Option 1. Connect to the disconnect between the user and the server and capture the traffic at the moment the connection is established (SSL Handshake). At the time of connection establishment, the session key can be intercepted.

Option 2: You can decrypt HTTPS traffic using a session key log file written by Firefox or Chrome. To do this, the browser must be configured to write these encryption keys to a log file (FireFox-based example) and you must receive this log file. Essentially, you need to steal the session key file with hard drive another user (which is illegal). Well, then capture the traffic and apply the received key to decrypt it.

Clarification. We're talking about the web browser of a person whose password is being stolen. If we mean decrypting our own HTTPS traffic and want to practice, then this strategy will work. If you're trying to decrypt other users' HTTPS traffic without access to their computers, it won't work - that's what encryption and privacy are for.

After receiving the keys according to option 1 or 2, you need to register them in WireShark:

1. Go to the menu Edit - Preferences - Protocols - SSL.
2. Set the flag "Reassemble SSL records spanning multiple TCP segments".
3. "RSA keys list" and click Edit.
4. Enter data in all fields and write the path in the file with the key

WireShark can decrypt packets that are encrypted using the RSA algorithm. If the DHE / ECDHE, FS, ECC algorithms are used, the sniffer is not a help to us.

Option 3. Get access to the web server that the user is using and get the key. But this is an even more difficult task. IN corporate networks for the purpose of debugging applications or content filtering, this option is implemented on a legal basis, but not for the purpose of intercepting user passwords.

BONUS

VIDEO: Wireshark Packet Sniffing Usernames, Passwords, and Web Pages

theory

Let's start with a little bit of terminology.

The word sniffer (literally from English it can be translated as "sniffer" or "sniffer") in the very general sense the essence of a kind of listening device embedded in the network to intercept the data transmitted over it. In a narrower sense, a sniffer is software that interacts with (often called "sitting down" came from is a registered trademark Network Associates, referring to the product "Sniffer(r) Network Analyzer", but later the word suffered the same fate as PC, xerox, kleenex - the sniffer becomes a household term denoting the entire class of similar products.

In some literature and documentation, as well as in electronic dictionaries like Lingvo, the term sniffer (network sniffer) is identified with such concepts as "network traffic analyzer", "packet analyzer", "protocol analyzer", "network analyzer". However, let me disagree a little with this approach.

Still, it would be more logical to say that sniffing is a set of measures to intercept traffic. Within the framework of a particular product, the following things can be implemented: packet capturing. At this stage, we get a kind of raw (machine readable) data dump, usually divided into pieces along frame (packet) boundaries. And what we are going to do with him is our problem. But usually, since we started the sniffer for some reason, we are interested in getting some result in a human readable format, for which packet decoding or protocol analysis is used;

Actually, this is the process of "raking" our dump. Here, for example, we had such raw material.

As you can see, this file consists of three columns: the offset of each line, the data in hexadecimal format, and its ASCII equivalent. This packet contains a 14-byte Ethernet header, a 20-byte IP header, a 20-byte TCP header, an HTTP header ending in two consecutive CRLF (0D 0A 0D 0A), and then the actual application layer data, in our case, the web traffic.

Sometimes such a representation is sufficient to obtain the necessary information, but it is still more convenient for the packet to be decoded and analyzed at all levels of the protocol stack. After all, is it really more pleasant to get such a picture?

In addition to the above, other "features" can be implemented, such as viewing running packets in real time, filtering according to a given scenario, various types of traffic statistics - the number of errors, intensity, and so on.

Types of sniffers and sniffing

Everything that will be described in this paragraph, of course, has some shade of conventionality, since no one has yet fully described the official "Theory of Sniffing". We'll have to come up with a classification "on the go";)

So, according to the "location" (if this term is applicable here), the sniffer can work:

On the router (gateway)

In this scenario, you can intercept traffic passing through the interfaces of this gateway. For example, from your local network to another network and vice versa. Accordingly, if we install a sniffer on an Internet provider's router, we can track the traffic of its users, and so on...

At the end node of the network

With regard to Ethernet, we will have two main possible options for wiretapping. Classical, unswitched Ethernet assumes that each network interface, in principle, "hears" all the traffic of its segment. However, in normal operation of the network card, after reading the first 48 bits of the frame header, the station compares its MAC address with the destination address specified in the frame. If the address is someone else's, the station "shamefully closes its ears", that is, it stops reading someone else's frame. Thus, in normal mode, you can intercept and analyze only your own traffic. To intercept the packets of all stations in the segment, you need to put your network card into a mode called promiscuous mode so that it "shamelessly" continues to read packets that are not intended for it. Almost all sniffer implementations allow the card to switch to promiscuous mode.

Note: the use of switched Ethernet creates a situation where even switching the card to promiscuous mode makes listening to traffic not intended for your station almost impossible. However, there is a technology for organizing such listening through the so-called ARP spoofing. The bottom line is this: the switch creates a so-called "broadcast domain", and a host with an installed sniffer can pretend to be, for example, a border router using ARP message forgery (sending constantly ARP messages, where network address router matches the MAC address of the listening station). Thus, the neighbors' traffic will forcibly turn in the direction of the "spy".

Otherwise, sniffers can differ from each other mainly in functionality, such as:

Supported physical interfaces and link layer protocols;

The quality of decoding and the number of "recognizable" protocols;

User interface and display convenience;

Additional features: statistics, real-time viewing, generating or modifying packages and more...

When choosing a sniffer (as well as any other software, by the way), it makes sense to be guided by the following considerations: from what exists under your OS, we choose either what exactly matches your tasks (it makes sense if you are planning either a one-time event, or the constant execution of the same operation) or the most fancy solution, in case you feel that the sniffer will be useful to you, but still don’t know in what situation :) But situations are different ...

Why do we need a sniffer?

Traditionally, the idea of ​​sniffing lived as if in two forms: legal and illegal use. Tellingly, the word "sniffer" is more often used in the illegal sphere, and "network analyzer" - in the legal one. Let's start with the legal application;)

Troubleshooting (detection of problems and network bottlenecks). In advanced mode, when the sniffer operates in a non-switched segment or on a gateway, we can get an almost complete picture of the events taking place in our network: traffic intensity by time, by workstations, by protocols, the number of errors different types. In addition, in both modes, we can "rake" more specific problems, when, say, a particular station fails to organize some interaction over the network, and this despite the fact that the network looks quite functional from the outside. A sniffer is especially useful in cases where network software is poorly documented or uses its own closed (undocumented), often suspicious technologies (protocols).

For example: ICQ, Europe Online. Suspicious technologies/software should be understood as situations where you suspect that a program contains a tab or other undocumented functionality. For example, there were rumors that the client part of the famous cDc Back Orifice is also a Trojan horse and sends some information to the owners - the authors of the software. Setting the BO Client "to listen" showed that the rumors were not true.

No less useful is a sniffer for debugging your own software. I will never forget the moment when the proxy server refused to establish a connection if the GET request ended with \n\n instead of the required \r\n\r\n. Only examining the packets sent by the "legitimate" browser and comparing them to the packets sent by my "upstart" script pointed me to an unfortunate error. Very, very often in my daily admin practice, I also have to deal with analysis at the TCP / UDP level.

Education. You can get half swooning by memorizing various protocol packet header formats and interaction methods (say, 3-way TCP handshake, DNS, traceroute plan application methods), but this knowledge is dead until you try to "touch it with your hands" - having written once program or ... looking into the sniffer! After reading the documentation for an unknown or poorly understood protocol, try to simulate interaction, intercept packets and analyze them - I assure you, everything will become extremely clear and moreover, this knowledge is more realistic and will be deposited in your head for a long time. In the case of closed technologies, a sniffer may be almost the only means for studying them.

Network traffic logging. There can be a lot of discussion about the legality and ethics of logging user traffic by an administrator for further review, but the fact remains that many organizations include this technology in their security policy. My personal opinion is that the master is the owner, that is, if the company provides its employees with equipment, connection to local and global networks, it has the right to demand the proper use of these resources. The second important reason for logging traffic is to detect unauthorized access attempts and other malicious activities - DoS attacks for example. Having such logs, the administrator can know with 100% accuracy what is happening in his network possessions.

Now let's talk about the illegal side of sniffing. Well, first of all, it's banal.

Eavesdropping. Having correctly installed a sniffer, you can spy on your neighbors and distant ones - enemies, friends, spouses;) You may be interested in such questions: why does a person use the network, what web resources does he visit, what data does he transmit, with whom and what does he communicate about? Forgive me the state security authorities, but the notorious SORM, the legitimacy of which in the form of total traffic logging is a big question, I still refer to this section, although it could also be in the last paragraph of "legal sniffing";)

More mercantile eavesdropping. However, a significant part of the "hacker" community does not exchange their talents for spying on unfaithful spouses and other everyday life. Most often, an attacker is interested in some material with which you can advance in the difficult task of breaking into other people's systems and networks. As you might have guessed, this is mainly about intercepting usernames and passwords passing over the network in unencrypted (plain text) form. In particular, this applies to passwords for telnet, POP, IMAP, NNTP, IRC, web applications that do not use encryption, SNMP v1 community-strings, etc.

Implementations

Now, having more or less dealt with the theoretical part, let's return to sinful earth - let's talk about specific implementations of sniffers for various platforms. In fact, there is a lot of such software, the difference in functionality and the price tag (especially in the last one) is colossal. The compiler of the "Sniffing (network wiretap, sniffer) FAQ" Robert Graham recommends trying the following products:

WinNT Server
Microsoft's WinNT Server comes with a built-in program called "Network Monitor". Go to the network control panel, select "Services", click "Add..." and select "Network Monitor Tools and Agent". After installation, the program will be available in start menu in the "Administrative Tools" section.

BlackICE is actually an Intrusion Detection System (IDS), but one of its functions is to write raw packet dumps in a form acceptable for decryption by protocol analyzers. One thing: the program only looks at traffic passing through local interfaces the host it is running on, i.e. is non-promiscuous. You can download the program on the website

This program, on the contrary, can only analyze packets recorded by a sniffer like BlackICE Pro.

Free protocol analyzer.

Naturally, this list is far from complete, you can climb any search engine or in the collection of software for download and find something suitable on the left side menu. Moreover, the review does not mention the most, in my opinion, the most outstanding product of this kind for Win32 - NetXRay, now renamed Sniffer Basic. We will talk about it a little later.

Snort
A sniffer based on libpcap with advanced filtering capabilities.

Again, the list is far from perfect, you can look for something else. Another thing is that in the *NIX community it's not particularly customary to "disperse" - there are time-tested, constantly improving leading products, and the majority prefers exactly them, without even trying to look for an alternative. The absolute leaders here are tcpdump and sniffit.

tcpdump & windump

(by Ghost//Necrosoft)

As mentioned above, TcpDump is the most commonly used sniffer under *nix systems. You can find it in any of the latest distributions of the operating system you are using. The best way to describe tcpdump is to simply list all of its command line options - that way you get a list of its features and a direct guide to action - "in one bottle".

WinDump is a port of TcpDump from *nix systems, performs the same functions and has the same syntax as TcpDump, but has a couple of additional command line options, which will be discussed below.

A small annotation for using TcpDump under various systems. On SunOS using nit or bpf devices: To run tcpdump, you must have read access to /dev/nit or /dev/bpf*. Under Solaris with dlpi, you should be able to access pseudo network adapters such as /dev/le. Under HP-UX with dlpi: you must be root or tcpdump must have uid set to root. Under IRIX with snoop and Linux: requirements similar to HP-UX. Under Ultrix and Digital UNIX: only superuser can access promiscuous-mode operations using pfconfig(8) you can get permission to run tcpdump Under BSD: you must have access to /dev/bpf* Under Win32: you must install the NDIS packet capture driver.

Now let's take a closer look at the command line options.

TcpDump [ -adeflnNOpqSvx ] [ -c count ] [ -F file ] [ -i interface ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ expression ]. Windump Specific Options [-D] [ -B size ].

-a allows you to convert network and broadcast addresses to names.

-c exit after processing count packets.

-d prints the contents of the package in human-readable form.

-dd outputs the contents of the package as a fragment of a C program.

-ddd displays the contents of the package in decimal form.

-e prints the link layer headers on each new line.

-f prints the addresses of remote and local hosts without conversion to names.

-F use file with description of filtering parameters (additional expressions in command line are ignored).

-i use interface interface for tracing. If not specified, tcpdump finds the lowest numbered active network interface (excluding loopback). In Windows interface - name network adapter or its number (can be found by running WinDump -D).

-l uses buffered output to stdout. A construct like "tcpdump -l | tee dat"" or "tcpdump -l > dat & tail -f dat"" can be useful.

-n Don't convert addresses (i.e. host address, port number, etc.) to names.

-N Don't print the domain name in the hostname. Those. if this flag is used, tcpdump will print "nic"" instead of "nic.ddn.mil"".

-O Do not run the package optimizer. This option is useful if you are handling packages yourself.

-p do not set the network interface to "promiscuous mode".

-q abbreviated output. Displays information in an abbreviated form.

-r reads packages from file (which are created with the -w option). If you want to use the console as input, then file is "-"".

-s prints a snaplen byte of each packet (in SunOS's NIT, the minimum number is 96). high levels, say, DNS and NFS packets.

-T force interpretation of packets by type type matching "expression" mask. The currently known types are rpc (Remote Procedure Call), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications control protocol), vat (Visual Audio Tool), and wb (distributed White Board).

-S prints the absolute TCP packet number.

-t does not print the time on each line.

-tt prints the unformatted time on each line.

-v verbose output. For example, packet lifetime and service type.

-vv verbose output. For example, displaying additional fields NFS reply packets.

-w writes raw packets to file, which you can later decrypt using the -r option. If you want to use the console as output, then file is "-"".

-x prints each package in hexadecimal (no header). Snaplen bytes will be sent to the output.

Additional WinDump Options:

-B sets the driver's buffer size to size in kilobytes. The default buffer size is 1 megabyte. If some packets are not displayed during operation, try increasing the buffer size. If you have a PPP connection or 10 Mbit Ethernet, then the buffer size can be halved or tripled.

-D lists the network devices that are present on your system. The list looks like: number is the number of the network device in the system, name is its name, followed by a description of the device. Later, you will be able to use this data in order to work with all available network interfaces of your system that are currently available. And you can select a device using the -I option - "WinDump -i name" or "WinDump -i number".

expression - in fact, an expression that sets the packet filtering criterion. If the expression field is absent, then all packets are displayed. Otherwise, only those packets that match the expression mask are displayed.

expression may consist of one or more primitives. Primitives often consist of the id (name or number) of the qualifier. There are three key types of qualifiers:

type is a qualifier that specifies the general policy. Possible types are host, net, and port. Those. "host foo", "net 128.3", "port 20". If type is not specified, the default is host.

dir is a qualifier indicating the direction in which packets are sent. The options are src, dst, src or dst, and src and dst. I.e. "src foo", "dst net 128.3", "src or dst port ftp-data". If dir is not specified, then src or dst is used by default. For "null" connections (that's ppp or slip) use the inbound and outbound specifier to indicate the desired direction.

proto - the qualifier allows you to filter packets by a specific protocol. Possible protocols are ether, fddi, ip, arp, rarp, decnet, lat, sca, moprc, mopdl, tcp, and udp. Those. "ether src foo", "arp net 128.3", "tcp port 21". If the qualifier is absent, then no packets are filtered. ("fddi" is actually an alias for "ether", because in most cases FDDI packets contain the Ethernet address of the sender and destination, and often contain the Ethernet types of the packets. FDDI headers also contain other fields that are not in the filter list .)

In addition to the above, some special primitives have no templates, these are: gateway, broadcast, less, greater, and arithmetic expressions. About this a little further.

Many compound filter expressions use the words and, or, and not to combine primitives. For example "host foo and not port ftp and not port ftp-data". Some qualifiers may be omitted to simplify entry. For example, "tcp dst port ftp or ftp-data or domain" is the same as "tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain".

The following expressions are allowed:

dst host host is true if the packet's IP destination field is host, which can be an address or a hostname.

src host host is true if the IP source field of the packet is host.

host host is true if the source or destination of the packet is host. The prefixes: ip, arp, or rarp can also be used as: ip host host which is equivalent to ether proto \ip and hosthost. If host is a name with multiple IP addresses, each address is checked for a match.

ether dst ehost True if the destination Ethernet address is ehost. Ehost - any of the names in /etc/ethers or a number (see ethers(3N).

ether src ehost is true if the source ethernet address is ehost.

ether host ehost is true if the destination or source Ethernet addresses are ehost.

gateway host is true if host is gateway. Those. The Ethernet address of the source or destination is host, but neither the source IP nor the destination IP is host. Host can be a name and can also be found in /etc/hosts and /etc/ethers. (Which is equivalent to ether host ehost and not host host, which can be used with any name or number for host/ehost.)

dst net net is true if the destination IP address is net. Net - any entry from /etc/networks or network address.

src net net is true if the sender's IP address is net.

net net True if the destination or source IP address is net.

net net mask mask True if the IP address matches the net c of the corresponding netmask. May be specified with src or dst.

net net/len is true if the IP is net and the subnet mask is len bitwise (CIDR format). May be specified with src or dst.

dst port port is true if the packet is ip/tcp or ip/udp and has a destination port of port. port can be a number or be present in /etc/services (see tcp(4P) and udp(4P)). If the name is used for two or more ports, then both port numbers and protocols are checked. If an invalid port number or name is used, then only port numbers are checked (i.e. dst port 513 outputs tcp/login and udp/who traffic, and port domain outputs tcp/domain and udp/domain).

src port port is true if the sender port is port.

port port is true if the source or destination port is port. Some expressions can be combined, for example: tcp src port port - only tcp packets with port -port.

less length is true if the packet length is less than or equal to length, which is the same as len<= length.

greater length is true if the packet length is greater than or equal to length, which is the same as len >= length.

ip proto protocol is true if the packet is an IP packet with protocol. Protocol can be numbered or one of the names icmp, igrp, udp, nd, or tcp.

ether broadcast is true if the packet is an Ethernet broadcast packet. The ether expression is optional.

ip broadcast is true if the packet is an IP broadcast packet.

ether multicast is true if the packet is an Ethernet multicast packet. The ether expression is optional. This is shorthand for "ether & 1!= 0".

ip multicast is true if the packet is an IP multicast packet.

ether proto protocol is true if the packet is of type Ethernet. Protocol can be a number or a name: ip, arp, or rarp.

decnet src host is true if the destination DECNET address is host, which can be an address like "10.123"", or a DECNET hostname. (DECNET hostname is only supported on Ultrix systems).

decnet dst host True if the destination DECNET address is host.

decnet host host True if the DECNET address of the destination or source is host.

proto[expr: size]

Proto is one of the following protocols ether, fddi, ip, arp, rarp, tcp, udp, or icmp, and indicates the protocol level for this operation. Byte offset for given level protocol is taken from expr. Size - optional, shows the number of bytes of interest at a given offset, it can be 1,2 or 4, the default is 1.

Examples of using tcpdump

List all incoming and outgoing packets from sundown: tcpdump host sundown

Issuing traffic between helios and one of two hot or ace: tcpdump host helios and \(hot or ace \)

List all prakets between ace and other hosts, excluding helios: tcpdump ip host ace and not helios

Dumping traffic between the local machine and the Berkeley machine: tcpdump net ucb-ether

Dumping ftp traffic through the snup gateway: tcpdump "gateway snup and (port ftp or ftp-data)"

Issuing traffic that does not belong to machines on the local network (if your machine is a gateway to another network, tcpdump will not be able to emit traffic on your local network). tcpdump ip and not net localnet

Issuance of old and stop packets (SYN and FIN packets) that do not belong to the local network. tcpdump "tcp & 3!= 0 and not src and dst net localnet"

Dumping IP packets longer than 576 bytes transmitted through snup gateway: tcpdump "gateway snup and ip > 576"

Issuing IP broadcast or multicast packets that are not sent via Ethernet broadcast or multicast: tcpdump "ether & 1 = 0 and ip >= 224"

Dump all ICMP packets that are not echo request/response (i.e., not ping packets): tcpdump "icmp!= 8 and icmp!= 0"

NetXRay

By Alice D. Saemon

The one I love...

Long long time ago... NetXRay was the first sniffer that came to my attention. Then, in 1997, this English program made a splash in the circles of windows-oriented networkers. Years have passed, but the old version of NetXRay (3.0.1) is still in service, in daily work on my workstation. To date, the product has been renamed to Sniffer Basic, some new features have been added, but, from a larger point of view, the main functionality has remained unchanged since 3.0.1. This is the first reason why NetXRay 3.0.1 will be described in the paper. The second reason ... (looking around at the anti-piracy police) is that the product is very expensive (1643 pounds, which is sterling), and the trial restrictions are very serious. So, let's get started.

The package consists of a set of different functions and can really be called a network analyzer rather than a sniffer. All features (modules) are grouped in the "Tools" menu, and various settings are also located there. Let's start with them. You can select the adapter for which the current test is being carried out (probe). The adapter must support the NDIS 3.0/3.1 standard.

Attention, bug! If you "set" NetXRay on the "wrong" adapter in its opinion or capture packets that it cannot decode at the link-network level (for example, exploit traffic that sends crookedly fragmented packets) - at the decoding stage (protocol analysis), the program freezes tightly .

Simultaneously, you can test on several interfaces, for which multiple program incarnations (probes) are created. In a new probe, you can copy all the settings of any of the existing ones.

In the options, you can configure the following things: appearance desktop, standard port numbers for various protocols (3 options - very useful in cases where network applications work on non-standard ports), response to the occurrence of an event, threshold values ​​for various kinds statistics, etc.

Well, now let's get down to the functional modules of the package.

capture (packet capture)

The heart of NetXRay, in fact, is that in the popular understanding there is a sniffer. Therefore, let me describe it in as much detail as possible.

When this module is activated, a small window appears in front of us with " dashboard" and a couple of buttons. All actions that we can perform in this window are duplicated in the Capture menu. And we can do this: start capturing packets, stop, stop + view the contents of the buffer and simply view the contents of the buffer, provided that the capture was stopped, where we can also fine-tune the filters:

The address of the sender and recipient. To facilitate this task, there is The address book and some set of preset addresses, for example "Any".

By templates. If you need to catch packages that contain some specific data anywhere in the package, you can write a fancy pattern. Moreover, which is especially nice, you can design templates in any representation convenient for you: binary, hexadecimal, ASCII and EBCDIC.

According to protocols known to the program. This:

Network: AppleTalk, AppleTalk ARP, APOLLO, DECNET, IP, IP ARP, IPX, LAT, NetBEUI, OSI, SNA, VINES, VINES Loopback, VINES Echo, XNS

Higher in the IP stack: transport, service and routing - ICMP, IGMP, GGP, EGP, IGP, ISO-TP4, HELLO, IP-VINES, IGRP, OSPF, TCP, UDP; application layer - FTP, REXEC, RLOGIN, RSH, PRINTER, SMTP, TELNET, DNS(TCP), GOPHER, HTTP, POP, SUNRPC(TCP), NNTP, NETBIOS, X-WINDOW, DNS(UDP), BOOTP, TFTP, SUNRPC(UDP), SNMP, SNMPTRAP, BIFF, WHO, SYSLOG, RIP, GDP, NFS.

Higher in the IPX stack: NCP, SAP, NRIP, NBIOS, DIAGNOSTIC, SERIALIZATION, NMPI, NLSP, NSNMP, NSNMPTRAP, SPX.

As you can see, not so little, I would say - even redundant for real life.

Attention! The protocol filter has a slightly strange interface: it is assumed that if all checkboxes within the boundaries of one level are unchecked, all protocol packets of this level and everything above (lower when looking at the user interface ;) are captured. Thus, if you have not set a single "bird" - absolutely everything is caught. Naturally, unknown application layer protocols are also caught in this case, but not decoded into a human-readable form, which is natural, since they are unknown :))

In addition, you can adjust the buffer size or specify the file where to drop the packet capture result.

Filter settings can be written to a so-called profile, given a name, and subsequently selected from the list.

After working out the capture of the required number of packets, when viewing is activated, we fall out into the so-called "results window", which by default has the names XRay1, XRay2 and so on according to the number of current buffers. You can see such a window on the screenshot: above - a list of packages with a brief "annotation", in the middle - decoded data (well, I could decode;) and below - a raw package. It is curious that when you click on the field of interest in the decoded section, the corresponding place in the raw packet is highlighted - you can check the quality of the protocol analyzer;)

The user interface of the "results window" has along with the advantages (the ability to apply any of the filters discussed above to the displayed buffer, the ability to send any packet or buffer to the network with one mouse click or copy a number of packets to a separate buffer, a very beautiful display of decoded data, even with some nesting for fields of little interest to the average user) as well as obvious disadvantages (you cannot delete a couple of packages from the buffer, there is no clipboard-operability, that is, the results cannot, for example, be copied and saved in text format).

In addition to accumulating packets in a buffer or file for subsequent decoding, there is also the possibility of viewing traffic in real time.

True a) visually it looks terrible b) this option is enabled in such an illogical place that even such an old NetXRay user like me forgets where this "bird" is. The bird is installed in the menu Tools | Options... General tab, Realtime Display checkbox, and not in the Capture settings, where it would be logical to look for it;-/

In addition, the "results window" contains bookmarks for statistical data on the capture session, but we will not dwell on them.

packet generator

This is really a wonderful thing: you can "sketch" from scratch and send absolutely any packet to the network. The interface consists of the main window and the so-called package designer, divided into two sections - Configure and Decode.

In the first one, we have a portrait of a standard dump (see the theoretical part of the article), filled with zeros. We begin to enter hexadecimal numbers there - in the decoding section, which looks exactly like the decrypted packet in the "results window" of Capture, an analysis of our packet appears.

But in this case, we can not only look at the decoded packet, but also make changes by clicking on the desired field with the mouse. However, changing the values ​​in any case is carried out only in hexadecimal form, and the input fields are striking in their inconvenience: (There are several options for generating and sending packets: send the current packet, send the current buffer, write a packet from scratch, or send an edited packet from what you have collected .

Note on the interface: if the "send current packet" option is called from the "results window" of Capture, the packet is sent immediately without calling the packet constructor, however, it remains in the current "send buffer" and can be corrected there later.

If "send the current packet" is called from the Packet Generator window, the packet constructor is automatically called. Be careful!

In the package constructor in the Decode section, the program will give you some hints, in particular, calculate a new checksum when modifying the package (she would still make the appropriate changes herself, lazy creation;). However, AI differs from the human mind in that it does not know how to think properly. So when, for example, you change the recipient's IP address, consider whether you should change its MAC address at the same time?;)

Packets can be sent in different modes: one click - one packet, a specified number of packets, or in a loop. This way you can generate traffic. In general, you can find a lot of applications for the packet generator, it's up to your imagination and ingenuity.

all sorts of things

In addition to the above, the program contains a lot of other useful and not very (as anyone;) bells and whistles. Briefly about them:

Dashboard. Network load statistics, more precisely of the part of it that you can see. Number of packets, bytes, errors of all types, utilization calculation. I've always been confused by this feature, because I've never seen error messages in my life - well, it can't be that there aren't any!;)

host table. Catches various information about the hosts visible to the sniffer and their activities (without full capture and analysis of packets)

matrix. Almost the same as the Host Table, but presented in a slightly different format.

history. Draws graphs and diagrams on the behavior of the network in a certain period of time.

protocol distribution. As the name suggests, it keeps statistics on the use of various protocols.

statistics. Statistics on utilization and size of personnel.

Alarm log. A log of events defined by you.

Well, that's all in a nutshell. (wow, "it turned out briefly % -()) Download and test for health - for your own joy and to spite your enemies :)

Conclusion

Well, the tale of sniffers is over for today. Who listened (read to the end) - well done, I hope you got answers to most of your questions. For the sake of fairness, I note: not ALL issues were considered within the framework of this article. At least two big topics were left out: the internal structure of sniffers, including methods and approaches to writing such software, as well as ways to counter sniffering.

As for the first, here's what I think: the topic is interesting, requiring separate material, but it will be intended mainly for programmers. Let's figure something out about this. As for the second question, the answer to it is by and large the same: encryption, encryption and again encryption, which is obvious. There are, of course, methods for recognizing the presence of a sniffer on the network and even resisting it, but they are quite private and not painfully effective.