Wireshark (network packet interceptor). Sniffer for Windows Intercepter-NG (instructions for use)
Each member of the ][ team has their own preferences regarding software and utilities for
pen test. After consulting, we found out that the choice varies so much that it is possible
create a real gentleman's set of proven programs. That's it
decided. In order not to make a hodgepodge, we divided the entire list into topics - and in
This time we’ll touch on utilities for sniffing and manipulating packets. Use it on
health.
Wireshark
Netcat
If we talk about data interception, then Network Miner will be taken off the air
(or from a pre-prepared dump in PCAP format) files, certificates,
images and other media, as well as passwords and other information for authorization.
A useful feature is to search for those pieces of data that contain keywords
(for example, user login).
Scapy
Website:
www.secdev.org/projects/scapy
A must-have for any hacker, it is a powerful tool for
interactive packet manipulation. Receive and decode packets of the most
different protocols, respond to the request, inject the modified and
a package created by yourself - everything is easy! With its help you can perform a whole
a number of classic tasks such as scanning, tracorute, attacks and detection
network infrastructure. In one bottle we get a replacement for such popular utilities,
like: hping, nmap, arpspoof, arp-sk, arping, tcpdump, tetheral, p0f, etc. At that
it's about time Scapy allows you to perform any task, even the most specific
a task that can never be done by another developer already created
means. Instead of writing a whole mountain of lines in C to, for example,
generating the wrong packet and fuzzing some daemon is enough
throw in a couple of lines of code using Scapy! The program does not have
graphical interface, and interactivity is achieved through the interpreter
Python. Once you get the hang of it, it won’t cost you anything to create incorrect
packets, inject the necessary 802.11 frames, combine different approaches in attacks
(say, ARP cache poisoning and VLAN hopping), etc. The developers themselves insist
to ensure that Scapy's capabilities are used in other projects. Connecting it
as a module, it’s easy to create a utility for various types of local area research,
searching for vulnerabilities, Wi-Fi injection, automatic execution specific
tasks, etc.
packeth
Website:
Platform: *nix, there is a port for Windows
An interesting development that allows, on the one hand, to generate any
ethernet packet, and, on the other hand, send sequences of packets with the purpose
bandwidth checks. Unlike other similar tools, packeth
has a graphical interface, allowing you to create packages as simply as possible
form. Further more. The creation and sending are especially elaborated
sequences of packets. You can set delays between sending,
send packets at maximum speed to test throughput
section of the network (yep, this is where they’ll be filing) and, what’s even more interesting -
dynamically change parameters in packets (for example, IP or MAC address).
In this article we will look at creating a simple sniffer for Windows OS.
Anyone interested, welcome to cat.
Introduction
Target: write a program that will capture network traffic(Ethernet, WiFi), transmitted over IP protocol.Facilities:Visual Studio 2005 or higher.
The approach described here does not belong to the author personally and is successfully used in many commercial, as well as completely free programs (hello, GPL).
This work is intended primarily for beginners in network programming, who, however, have at least basic knowledge in the field of sockets in general, and Windows sockets in particular. Here I will often write well-known things, because the subject area is specific, if I miss something, my head will be a mess.
I hope you find it interesting.
Theory (reading is not required, but recommended)
At the moment, the vast majority of modern information networks are based on the foundation of the TCP/IP protocol stack. TCP/IP protocol stack (Transmission Control Protocol/Internet Protocol) is a collective name for network protocols different layers used in networks. In this article, we will be mainly interested in the IP protocol - a routed network protocol used for the non-guaranteed delivery of data divided into so-called packets (a more correct term is a datagram) from one network node to another.Of particular interest to us are IP packets designed to transmit information. This is a fairly high level of the OSI network data model, when you can isolate yourself from the device and data transmission medium, operating only with a logical representation.
It is completely logical that sooner or later tools for intercepting, monitoring, recording and analyzing network traffic should have appeared. Such tools are usually called traffic analyzers, packet analyzers or sniffers (from English to sniff - sniff). This is a network traffic analyzer, a program or hardware-software device designed to intercept and subsequently analyze, or only analyze, network traffic intended for other nodes.
Practice (substantive conversation)
At the moment, quite a lot of software has been created to listen to traffic. The most famous of them: Wireshark. Naturally, the goal is not to reap his laurels - we are interested in the task of intercepting traffic by simply “listening” to a network interface. It is important to understand that we are not going to hack and intercept stranger traffic. We just need to view and analyze the traffic that passes through our host.Why this may be needed:
- View the current traffic flow through the network connection (incoming/outgoing/total).
- Redirect traffic for subsequent analysis to another host.
- Theoretically, you can try to use it to hack a WiFi network (we're not going to do that, are we?).
How so? Very simple.
The key step in turning a simple network application into a network analyzer is to switch the network interface to promiscuous mode, which will allow it to receive packets addressed to other interfaces on the network. This mode is forced network card accept all frames, regardless of who they are addressed to on the network.
Starting with Windows 2000 (NT 5.0), it became very easy to create a program to listen to a network segment, because its network driver allows you to set the socket to receive all packets.
Enabling Promiscuous Mode
long flag = 1; SOCKET socket; #define SIO_RCVALL 0x98000001 ioctlsocket(socket, SIO_RCVALL, &RS_Flag);Our program operates on IP packets and uses Windows library Sockets version 2.2 and raw sockets. In order to gain direct access to an IP packet, the socket must be created as follows:
Creating a raw socket
s = socket(AF_INET, SOCK_RAW, IPPROTO_IP);Here instead of a constant SOCK_STREAM(TCP protocol) or SOCK_DGRAM(UDP protocol), we use the value SOCK_RAW. Generally speaking, working with raw sockets is interesting not only from the point of view of traffic capture. In fact, we get full control for the formation of the package. Or rather, we form it manually, which allows, for example, to send a specific ICMP packet...
Go ahead. It is known that an IP packet consists of a header, service information and, in fact, data. I advise you to look here to refresh your knowledge. Let's describe the IP header in the form of a structure (thanks to the excellent article on RSDN):
Description of the IP packet structure
typedef struct _IPHeader ( unsigned char ver_len; // header version and length unsigned char tos; // service type unsigned short length; // length of the entire packet unsigned short id; // Id unsigned short flgs_offset; // flags and offset unsigned char ttl ; // lifetime unsigned char protocol; // protocol unsigned short xsum; // checksum unsigned long src; // sender IP address unsigned long dest; // destination IP address unsigned short *params; // parameters (up to 320 bits) unsigned char *data; // data (up to 65535 octets) )IPHeader;The main function of the listening algorithm will look like this:
Single packet capture function
IPHeader* RS_Sniff() ( IPHeader *hdr; int count = 0; count = recv(RS_SSocket, (char*)&RS_Buffer, sizeof(RS_Buffer), 0); if (count >= sizeof(IPHeader)) ( hdr = (LPIPHeader )malloc(MAX_PACKET_SIZE); memcpy(hdr, RS_Buffer, MAX_PACKET_SIZE); RS_UpdateNetStat(count, hdr); return hdr; ) else return 0; )Everything is simple here: we receive a piece of data using the standard socket function recv, and then copy them into a structure like IPHeader.
And finally, we start an endless packet capture loop:
Let's capture all packets that reach our network interface
while (true) ( IPHeader* hdr = RS_Sniff(); // processing the IP packet if (hdr) ( // print the header in the console) )A bit offtopic
Here and below, the author made the RS_ (from Raw Sockets) prefix for some important functions and variables. I did the project 3-4 years ago, and I had a crazy idea to write a full-fledged library for working with raw sockets. As often happens, after obtaining some significant (for the author) results, the enthusiasm faded, and the matter did not go further than a training example.In principle, you can go further and describe the headers of all subsequent protocols located above. To do this, you need to analyze the field protocol in the structure IPHeader. Look at the example code (yes, there should be a switch, damn it!), where the header is colored depending on what protocol the packet has encapsulated in IP:
/* * Highlighting a package with color */ void ColorPacket(const IPHeader *h, const u_long haddr, const u_long whost = 0) ( if (h->xsum) SetConsoleTextColor(0x17); // if the package is not empty else SetConsoleTextColor(0x07) ; // empty package if (haddr == h->src) ( SetConsoleTextColor(BACKGROUND_BLUE | /*BACKGROUND_INTENSITY |*/ FOREGROUND_RED | FOREGROUND_INTENSITY); // "native" package for return ) else if (haddr == h->dest ) ( SetConsoleTextColor(BACKGROUND_BLUE | /*BACKGROUND_INTENSITY |*/ FOREGROUND_GREEN | FOREGROUND_INTENSITY); // "native" receive packet ) if (h->protocol == PROT_ICMP || h->protocol == PROT_IGMP) ( SetConsoleTextColor(0x70) ; // ICMP packet ) else if(h->protocol == PROT_IP || h->protocol == 115) ( SetConsoleTextColor(0x4F); // IP-in-IP packet, L2TP ) else if(h- >protocol == 53 || h->protocol == 56) ( SetConsoleTextColor(0x4C); // TLS, IP with Encryption ) if(whost == h->dest || whost == h->src) ( SetConsoleTextColor (0x0A); ) )
However, this is significantly beyond the scope of this article. For our training example, it will be enough to look at the IP addresses of the hosts from which and to which traffic is coming, and calculate its amount per unit of time (the finished program is in the archive at the end of the article).
In order to display IP header data, you must implement a function to convert the header (but not the data) of the datagram to a string. As an example of implementation, we can offer the following option:
Converting an IP header to a string
inline char* iph2str(IPHeader *iph) ( const int BUF_SIZE = 1024; char *r = (char*)malloc(BUF_SIZE); memset((void*)r, 0, BUF_SIZE); sprintf(r, "ver=% d hlen=%d tos=%d len=%d id=%d flags=0x%X offset=%d ttl=%dms prot=%d crc=0x%X src=%s dest=%s", BYTE_H (iph->ver_len), BYTE_L(iph->ver_len)*4, iph->tos, ntohs(iph->length), ntohs(iph->id), IP_FLAGS(ntohs(iph->flgs_offset)), IP_OFFSET (ntohs(iph->flgs_offset)), iph->ttl, iph->protocol, ntohs(iph->xsum), nethost2str(iph->src), nethost2str(iph->dest)); return r; )Based on the basic information given above, we get this small program (the creepy name ss, short for simple sniffer), which implements local listening IP traffic. Its interface is shown below in the figure.
Source and binary code I provide it as is, as it was several years ago. Now I'm scared to look at it, and yet, it's quite readable (of course, you can't be so self-confident). Even Visual Studio Express 2005 will be sufficient for compilation.
What we ended up with:
- The sniffer operates in user mode, but requires administrator privileges.
- Packets are not filtered and are displayed as is (you can add custom filters - I suggest looking at this topic in detail in the next article if you are interested).
- WiFi traffic is also captured (it all depends on specific model chip, it may not work for you, like it did for me several years ago), although there is AirPcap, which can do this wonderfully, but costs money.
- The entire datagram stream is logged to a file (see the archive attached at the end of the article).
- The program operates as a server on port 2000. You can connect to the host using the telnet utility and monitor traffic flows. The number of connections is limited to twenty (the code is not mine, I found it on the Internet and used it for experiments; I didn’t delete it - it’s a pity)
Many users do not realize that by filling out a 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 you are trying to log into 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 all user traffic 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 launch Wireshark to capture traffic
Sometimes, to do 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 are capturing over a wireless network.
Traffic capture has begun.
Step 2. Filtering captured POST traffic
We open the browser and try to log in to some resource using a username and password. Once the authorization process is complete and the site is opened, we stop capturing traffic in Wireshark. Next, open the protocol analyzer and see a large number of packages. This is where most IT professionals give up because they don't know what to do next. But we know and are interested in specific packages that contain POST data, which are generated on our local machine when filling out a form on the screen and sent to a remote server when we click the “Login” or “Authorization” button in the browser.
We enter a special filter in the window to display captured packets: http.request.method == “POST"
And we see, instead of thousands of packages, only one with the data we are looking for.
Step 3. Find the user's login and password
Quickly right-click and select the item from the menu Follow TCP Steam
After this, text will appear in a new window that restores the contents of the page in code. Let's find the fields “password” and “user”, which correspond to the password and username. In some cases, both fields will be easily readable 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 encrypted:
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
Thus, in our case:
Username: networkguru
Password:
Step 4. Determine the encoding type to decrypt the password
For example, go to the website 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. Decrypting the 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, intercepting passwords that users enter in web forms. You can also find out passwords for user mailboxes 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"
- The protocol is SMTP 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 uses HTTPS?
There are several options to answer this question.
Option 1. Connect when the connection between the user and the server is broken and capture traffic at the moment the connection is established (SSL Handshake). When a connection is established, the session key can be intercepted.
Option 2: You can decrypt HTTPS traffic using the session key log file recorded 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 should receive that log file. Essentially, you need to steal the session key file from another user's hard drive (which is illegal). Well, then capture the traffic and use the resulting key to decrypt it.
Clarification. We're talking about the web browser of a person whose password they're trying to steal. If we mean deciphering our own HTTPS traffic and if we want to practice, then this strategy will work. If you are trying to decrypt the HTTPS traffic of other users without access to their computers, this will not work - that is both encryption and privacy.
After receiving the keys according to option 1 or 2, you need to register them in WireShark:
- Go to the menu Edit - Preferences - Protocols - SSL.
- Set the flag “Reassemble SSL records spanning multiple TCP segments”.
- “RSA keys list” and click Edit.
- Enter the 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 will not help us.
Option 3. Gain access to the web server that the user is using and obtain 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
Original: Capturing Packets in Your C Program, with libpcap
Author: Pankaj Tanwar
Date of publication: February 1, 2011
Translation: A. Panin
Translation date: October 11, 2012
This article provides an overview of the main functions of the libpcap library and shows an example of creating a packet capture program.
All data movement in networks occurs in the form of packets, which are the unit of data for networks. To understand what data is in a packet, you need to understand the hierarchy of network protocols within the network model. If you are not familiar with network model ISO OSI (Open Systems Interconnection - basic reference model Open Systems Interaction), I strongly recommend studying the relevant documentation. A good source of information is the Wikipedia article.
The term "packet" is first introduced at the network level. The main protocols at this level are: IP (Internet Protocol), ICMP (Internet Control Message Protocol), IGMP (Internet Group Management Protocol) and IPsec (a set of protocols for ensuring the protection of data transmitted via IP protocol). Transport layer protocols include TCP (Transmission Control Protocol), which is focused on creating a persistent connection; UDP (User Datagram Protocol), which does not require a permanent connection; SCTP (Stream Control Transmission Protocol) combines the properties of the two protocols above. The application layer contains many commonly used protocols such as: HTTP, FTP, IMAP, SMTP and many others.
Packet capture refers to the collection of data transmitted over a network. Any time the network card receives an Ethernet frame, it checks the destination MAC address of the packet to see if it matches its own. If the addresses match, an interrupt request is generated. This interrupt is subsequently handled by the network card driver; it copies the data from the network card buffer to a buffer in the kernel address space, then checks the type field in the packet header and passes the packet to the required protocol handler depending on the contents of the field. Data traverses the handler stack network layers and reach application level, which is processed using a custom application.
When we capture packets, the driver sends a copy of the received packet to the packet filter as well. To capture packets we will use the open source library source code libpcap.
libpcap basics
The libpcap library is a platform-independent open source library (the Windows version is called winpcap). Well-known sniffers tcpdump and Wireshark use this library to work.
To develop our program, we need a network interface on which packets will be captured. We can assign this device ourselves or use the function provided by libpcap: char *pcap_lookupdev(char *errbuf).
This function returns a pointer to a string containing the name of the first network interface suitable for packet capture; if an error occurs, NULL is returned (this is also true for other libpcap functions). The errbuf argument is intended to be a user buffer in which an error message will be placed if an error occurs - this is very convenient when debugging programs. The size of this buffer must be at least PCAP_ERRBUF_SIZE (currently 256) bytes.
Working with the device
Next we open the selected network device using the function pcap_t *pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, char *errbuf). It returns the device identifier, represented as a variable of type pcap_t, which can be used in other libpcap functions. The first argument is the network interface we want to work with, the second is maximum size buffer for capturing data in bytes.
Installation minimum value The second parameter is useful when you only need to capture packet headers. The size of an Ethernet frame is 1518 bytes. The value 65535 will be enough to capture any packet from any network. The promisc argument specifies whether the device will operate in promiscuous mode or not. (In promiscuous mode, the network card will generate interrupts for all data it receives, not just those that match the MAC address. Read more in Wikipedia).
The to_ms argument tells the kernel how many milliseconds to wait before copying information from kernel space to user space. Passing a value of 0 will cause the data read operation to wait until enough packets have been collected. To reduce the number of data copy operations from kernel space to user space, we will set this value depending on the intensity of network traffic.
Data Capture
Now we need to start capturing packets. Let's use the function u_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h). Here *p is a pointer returned by pcap_open_live() ; the next argument is a pointer to type variable struct pcap_pkthdr, which returns the first packet received.
Function int pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user) used to assemble packages and process them. It returns the number of packets specified by the cnt argument. The callback function is used to process received packets (we will need to define this function). To pass additional information to this function, we will use the *user parameter, which is a pointer to a variable of type u_char (we will need to do our own type casting depending on the required type of data passed to the function).
The callback function prototype looks like this: void callback_function(u_char *arg, const struct pcap_pkthdr* pkthdr, const u_char* packet). The first argument is the *user argument passed to pcap_loop() ; the next argument is a pointer to a structure containing information about the received packet. The fields of the struct pcap_pkthdr structure are presented below (taken from the pcap.h file): struct pcap_pkthdr ( struct timeval ts; /* time stamp */ bpf_u_int32 caplen; /* length of portion present */ bpf_u_int32 len ; /* size of this packet (length of this packet (off wire)) */ )
An alternative to pcap_loop() is the function pcap_dispatch(pcap_t *p, int cnt, pcap_handler callback, u_char *user). The only difference is that this function returns the result after the time specified when calling pcap_open_live() has elapsed.
Traffic filtering
Until this time, we received all packets coming to the network interface. Now let's use the pcap function, which allows you to filter traffic coming to a given port. We can also use this function to work only with packets for a given protocol, such as ARP or FTP. First, we need to create a filter using this function: int pcap_compile(pcap_t *p, struct bpf_program *fp, const char *str, int optimize, bpf_u_int32 mask);
The first argument is similar in all library functions and was discussed earlier; the second argument is a pointer to the compiled version of the filter. The next one is the expression for the filter. This expression can be a protocol name such as ARP, IP, TCP, UDP, etc. You can find many example expressions in the pcap-filter and tcpdump manuals, which should be installed on your system.
The next argument sets the optimization state (0 - do not optimize, 1 - optimize). Next comes the network mask with which the filter works. The function returns -1 in case of error (if an error is detected in the expression).
After compiling, let's apply the filter using the function int pcap_setfilter(pcap_t *p, struct bpf_program *fp). The second argument of the function is a compiled version of the expression for filtering traffic.
Receiving IPv4 information
Int pcap_lookupnet(const char *device, bpf_u_int32 *netp, bpf_u_int32 *maskp, char *errbuf)
Using this function, you can obtain the IPv4 network address and network mask assigned to this network interface. The network address will be written at *netp , and the network mask at *mask .
A small packet capture program
Now let's write a program that will help us understand how pcap works. Let's call the file with the source code sniff.c. This is a program from the manuals section of tcpdump.org, authored by Martin Casado. First, let's include the necessary header files. #include
Next, we introduce a callback function to process received packets. This function will simply print the current number of packets received. We'll write another callback function later. This same function is so obvious that it requires no explanation. void my_callback(u_char *args, const struct pcap_pkthdr* pkthdr, const u_char* packet) ( static int count = 1; fprintf(stdout, "%3d, ", count); fflush(stdout); count++; )
Now let's look at the main() function. Here we use the functions that we analyzed earlier: int main(int argc,char **argv) ( int i; char *dev; char errbuf; pcap_t* descr; const u_char *packet; struct pcap_pkthdr hdr; struct ether_header *eptr; / * net/ethernet.h */ struct bpf_program fp; /*composed filtering expression */ bpf_u_int32 maskp; /*subnet mask */ bpf_u_int32 netp; /* ip */ if(argc != 2)( fprintf(stdout, "Usage: %s \"expression\"\n" ,argv); return 0; ) /* Get the device name */ dev = pcap_lookupdev(errbuf); if(dev == NULL) ( fprintf(stderr, "%s \n", errbuf); exit(1); ) /* Obtaining the network address and netmask for the device */ pcap_lookupnet(dev, &netp, &maskp, errbuf); /* opening the device in promiscuous mode */ descr = pcap_open_live( dev, BUFSIZ, 1,-1, errbuf); if(descr == NULL) ( printf("pcap_open_live(): %s\n", errbuf); exit(1); ) /* now the filter expression is created */ if(pcap_compile(descr, &fp, argv, 0, netp) == -1) ( fprintf(stderr, "Error calling pcap_compile\n"); exit(1); ) /* applying a filter */ if(pcap_setfilter(descr, &fp) == -1) ( fprintf(stderr, "Error setting filter\n"); exit(1); ) /* callback function used in a loop */ pcap_loop(descr, -1, my_callback, NULL); return 0; )
Compile the program using the commands below and run as root (required to enable promiscuous mode): $ gcc -lpcap sniff.c -o sniffer # ./sniffer ip
Figure 1 shows an example output of the program.
Figure 1: Program output
Since the filter expression is set to ip , your screen will soon be filled with IP packets being received. You can replace ip with another expression, for example, tcp, arp, etc. - look at the tcpdump man page for examples.
Another implementation of a callback function that prints the contents of packets received based on a given filter expression (it's already in sniff.c): void another_callback(u_char *arg, const struct pcap_pkthdr* pkthdr, const u_char* packet) ( int i=0; static int count=0; printf("Packet Count: %d\n", ++count); /* Number of packets */ printf("Recieved Packet Size: %d\n", pkthdr->len); /* Header length */ printf("Payload:\n"); /* And now the data */ for(i=0;i
You can change the pcap_loop() function call line in the main() function where the my_callback() function is called to use the new variant of the function. Compile the modified program and run it with the same expression as argument. The output shown in Figure 2 contains data from IP packets. 
Figure 2: Output showing the contents of the packets.
I think we can stop here. Test the program yourself, experiment with pcap and you will understand how powerful the component is at the heart of the best (and our favorite) tcpdump and Wireshark sniffers.
Analyzers network packets, or sniffers, were originally developed as a means of solving network problems. They are able to intercept, interpret and store packets transmitted over the network for subsequent analysis. On the one hand, this allows system administrators and service engineers technical support Observe how data is transferred over the network, diagnose and fix problems that arise. In this sense, packet sniffers are a powerful tool for diagnosing network problems. On the other hand, like many other powerful tools that were originally intended for administration, over time, sniffers began to be used for completely different purposes. Indeed, a sniffer in the hands of an attacker is a rather dangerous tool and can be used to obtain passwords and other confidential information. However, you should not think that sniffers are some kind of magical tool through which any hacker can easily view confidential information transmitted over the network. And before we prove that the danger posed by sniffers is not as great as is often presented, let us consider in more detail the principles of their functioning.
Operating principles of packet sniffers
Further in this article we will consider only software sniffers designed for Ethernet networks. Sniffer is a program that works at the NIC (Network Interface Card) level (link layer) and in a hidden way intercepts all traffic. Since sniffers work on link level OSI model, they don't have to play by protocol rules anymore high level. Sniffers bypass the filtering mechanisms (addresses, ports, etc.) that Ethernet drivers and the TCP/IP stack use to interpret data. Packet sniffers capture from the wire everything that comes through it. Sniffers can store frames in binary format and later decrypt them to reveal higher-level information hidden inside (Figure 1).
In order for the sniffer to capture all packets passing through the network adapter, the network adapter driver must support promiscuous mode. It is in this mode of operation of the network adapter that the sniffer is able to intercept all packets. This mode of operation of the network adapter is automatically activated when the sniffer is launched or is set manually by the corresponding sniffer settings.
All intercepted traffic is passed to a packet decoder, which identifies and splits packets into the appropriate hierarchy levels. Depending on the capabilities of a particular sniffer, the provided packet information can subsequently be further analyzed and filtered.
Limitations of using sniffers
Sniffers posed the greatest danger in those days when information was transmitted over the network in clear text (without encryption), and local networks were built on the basis of concentrators (hubs). However, those days are gone forever, and nowadays using sniffers to gain access to confidential information is by no means an easy task.
The fact is that when building local networks based on hubs, there is a certain common data transmission medium (network cable) and all network nodes exchange packets, competing for access to this medium (Fig. 2), and a packet sent by one network node is transmitted to all ports of the hub and this packet is listened to by all other nodes on the network, but only the node to which it is addressed receives it. Moreover, if a packet sniffer is installed on one of the network nodes, then it can intercept all network packets related to a given network segment (the network formed by the hub).
Switches are more intelligent devices than broadcast hubs and isolate network traffic. The switch knows the addresses of the devices connected to each port and transmits packets only between the necessary ports. This allows you to offload other ports without having to forward every packet to them, as a hub does. Thus, a packet sent by a certain network node is transmitted only to the switch port to which the packet recipient is connected, and all other network nodes are not able to detect this packet (Fig. 3).
Therefore, if the network is built on the basis of a switch, then a sniffer installed on one of the network computers is capable of intercepting only those packets exchanged this computer with other network nodes. As a result, in order to be able to intercept packets that the computer or server of interest to the attacker exchanges with other network nodes, it is necessary to install a sniffer on this particular computer (server), which is actually not so simple. However, you should keep in mind that some packet sniffers are launched from command line and may not have a graphical interface. Such sniffers, in principle, can be installed and launched remotely and unnoticed by the user.
Additionally, you should also keep in mind that while switches isolate network traffic, all managed switches have port forwarding or port mirroring functionality. That is, the switch port can be configured in such a way that all packets arriving on other switch ports are duplicated on it. If in this case a computer with a packet sniffer is connected to such a port, then it can intercept all packets exchanged between computers on a given network segment. However, as a rule, the ability to configure the switch is available only to the network administrator. This, of course, does not mean that he cannot be an attacker, but there are many other ways for a network administrator to control all users local network, and it is unlikely that he will monitor you in such a sophisticated way.
Another reason why sniffers are no longer as dangerous as they once were is that most sensitive data is now transmitted encrypted. Open, unencrypted services are rapidly disappearing from the Internet. For example, when visiting websites, it is increasingly used SSL protocol(Secure Sockets Layer); SFTP (Secure FTP) is used instead of open FTP, and virtual private networks (VPNs) are increasingly used for other services that do not use encryption by default.
So, those concerned about the potential for malicious use of packet sniffers should keep the following in mind. First, to pose a serious threat to your network, sniffers must be located within the network itself. Secondly, today's encryption standards make it extremely difficult to intercept sensitive information. Therefore, at present, packet sniffers are gradually losing their relevance as hacker tools, but at the same time they remain an effective and powerful tool for diagnosing networks. Moreover, sniffers can be successfully used not only for diagnosing and localizing network problems, but also for auditing network security. In particular, the use of packet analyzers allows you to detect unauthorized traffic, detect and identify unauthorized software, identify unused protocols to remove them from the network, generate traffic for penetration testing (penetration test) in order to check the security system, work with intrusion detection systems ( Intrusion Detection System (IDS).
Overview of software packet sniffers
All software sniffers can be divided into two categories: sniffers that support launch from the command line, and sniffers that have a graphical interface. However, we note that there are sniffers that combine both of these capabilities. In addition, sniffers differ from each other in the protocols they support, the depth of analysis of intercepted packets, the ability to configure filters, and the possibility of compatibility with other programs.
Typically, the window of any sniffer with a graphical interface consists of three areas. The first of them displays the summary data of intercepted packets. Typically, this area displays a minimum of fields, namely: packet interception time; IP addresses of the packet sender and recipient; MAC addresses of the sender and recipient of the packet, source and destination port addresses; protocol type (network, transport or application layer); some summary information about the intercepted data. The second area displays statistical information about the individual selected package, and finally the third area displays the package in hexadecimal or ASCII character form.
Almost all packet sniffers allow you to analyze decoded packets (which is why packet sniffers are also called packet analyzers, or protocol analyzers). The sniffer distributes intercepted packets across layers and protocols. Some packet sniffers are capable of recognizing the protocol and displaying the captured information. This type of information is usually displayed in the second area of the sniffer window. For example, any sniffer can recognize the TCP protocol, and advanced sniffers can determine which application generated this traffic. Most protocol analyzers recognize over 500 different protocols and can describe and decode them by name. How more information able to decode and display the sniffer on the screen, the less you have to decode manually.
One problem that packet sniffers may encounter is the inability to correctly identify a protocol using a port other than the default port. For example, to improve security, some well-known applications may be configured to use ports other than the default ports. So, instead of the traditional port 80 reserved for the web server, this server You can forcefully reconfigure it to port 8088 or any other. Some packet analyzers in this situation are not able to correctly determine the protocol and display only information about the lower-level protocol (TCP or UDP).
There are software sniffers that come with software analytical modules as plugins or built-in modules that allow you to create reports with useful analytical information about intercepted traffic.
Another characteristic feature of most packet analyzer software is the ability to configure filters before and after traffic is captured. Filters select certain packets from the general traffic according to a given criterion, which allows you to get rid of unnecessary information when analyzing traffic.