How to check a port using wireshark. Wireshark: a classic for analyzing network packets. Other filter examples
Original: Network sniffing
Author: Paul Cobbaut
Published date: March 12, 2015
Translation: A. Panin
Transfer date: April 1, 2015
Chapter 23. Intercepting network traffic
The network administrator must 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 network functioning. This chapter describes appropriate techniques for intercepting network traffic.
23.1. wireshark app
23.1.1. Installing wireshark
This example provides a command to install the wireshark application on distributions that use software packages with the .deb extension (including Debian, Mint, Xubuntu and other distributions).
Root@debian8:~# Read package lists Done Build dependency tree Read status information Done... (output shortened)
Distributions that use .rpm software packages, such as CentOS, RHEL, and Fedora, can use the yum utility 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 launch the wireshark application for the first time, you will have to select the network interface. You will see a dialog that looks similar to 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 recommendations and use the tcpdump utility or some other tool to intercept the traffic and write the data to a file. Any intercepted data can be analyzed later using the wireshark application.
23.1.3. Traffic minimization
During the process of intercepting network traffic, thousands of packets can be generated over very short periods of time. Obviously, such a volume of data will complicate traffic analysis. 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're looking into tools to intercept network traffic at home, it may be helpful to shut down any network applications running on your computer and disconnect your computer from other computers and devices such as smartphones and tablets to minimize traffic.
However, a more important tool for minimizing traffic is filters, which will be discussed in the next section.
23.1.4. Intercepting traffic generated by the ping utility
I ran the sniffer and captured all the packets sent over the network as a result of three ping commands (it makes no 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 64 bytes from 10.104.33.30: icmp_req=2 ttl=64 time=0.023 ms --- ns1.paul.local ping statistics --- 2 packets transmitted , 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 64 bytes from antares.ginsys.net (188.93.155.87): icmp_req=2 ttl=56 time=17.8 ms 64 bytes 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.000 ms
In total, more than 200 packets were captured from the network. Everything will become much more obvious if you enter the icmp string 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, we can apply a different filter. We want to monitor traffic related to both the dns protocol and the icmp protocol, so we will 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 line "dns and icmp", no information about any packets will be displayed, since there are no packets related to both mentioned protocols.
Looking at the above illustration, you will notice that packets 25 and 26 have source and destination IP addresses of 10.104.33.30. This is because the DNS client runs on the same computer as the DNS server.
A similar situation is observed in the case of packets 31 and 32, because the ping utility is used to send packets to the working system on which this 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 print information about each packet that matches two conditions.
Packet 93 contains a DNS query aimed at obtaining the type A record of the linux-training.be domain. Packet 98 contains the response from the DNS server. 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 different systems, it is always useful to try to predict upcoming events and check the correctness of your predictions).
23.1.7. Frame-based filtering
The correct term used to refer to an intercepted packet is frame (due to the fact that we do packet interception at Layer 2 of the OSI network model). Thus, to display information about packets with specific numbers, you should use the frame.number directive in the filter field.
23.1.8. Investigation of package contents
The middle panel of the sniffer window can be expanded. When you select a line within this panel, you can see the corresponding byte values in the field of the lower panel.
The illustration below shows the middle panel of the sniffer window with the selected address of my laptop.
Note that the technique described above works great when intercepting traffic transmitted through a single network interface. If you capture 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 the two protocol descriptions by using the logical or operator directive placed between them. The illustration below shows how to capture only packets related to the ARP and BOOTP (or DHCP) protocols.
And the following illustration shows a method for intercepting packets related to the DNS protocol and containing a specific IP address.
23.2. tcpdump utility
If working with the system command line interface, packet interception can be carried out 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, 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
Interception of traffic related exclusively to the ssh protocol (TCP protocol, port 22) can be carried out using the tcpdump tcp port $port command. The length of output lines has been trimmed 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 IP rhel53.local.ssh > deb503.local.37973: P 1:49(48) ack 48 14:22:20.720922 IP rhel53.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:81 (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 writing the captured data 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
The tcpdump -r $filename command can print the contents of the file created in the previous example.
Root@ubuntu910:~# tcpdump -r sshdump.tcpdump
Many other examples of how to use this utility can be found in the tcpdump man page.
23.3. Practical task: intercepting network traffic
23.4. The correct procedure for completing a practical task: 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 intercepting network traffic.
(sudo)wireshark
Select the 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 quotes) in the filter field and click the "Apply" button.
5. Now pass the ping utility a domain name (such as www.linux-training.be) and try to capture DNS request and response packets. What DNS server was used? Was TCP or UDP used to transmit the request and response?
First of all, launch 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 64 bytes from fosfor.openminds.be (88.151.243.8): icmp_seq=2 ttl=58 time=16.0 ms ^C --- 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, we can conclude that the DNS request was transmitted using a UDP packet, after which it is easy to answer the questions posed.
6. Find a private website that has a password request form. Try to log in using the username "paul" and password "hunter2" while the sniffer is running. Now try to find the entered username and password in the data captured by the sniffer.
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 sections 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, answer 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, so that, 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,
search for vulnerabilities, Wi-Fi injection, automatic execution of 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 in the most simple way
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 (yup, this is where they will file) and, what’s even more interesting -
dynamically change parameters in packets (for example, IP or MAC address).
This lesson describes network hacking technologies based on intercepting network packets. Hackers use such technologies to listen to network traffic in order to steal valuable information, to organize data interception for the purpose of a man-in-the-middle attack, to intercept TCP connections, allowing, say, data spoofing, and to perform other equally interesting actions. Unfortunately, most of these attacks in practice are implemented only for Unix networks, for which hackers can use both special utilities and Unix system tools. Windows networks, apparently, have been ignored by hackers, and we are forced to limit our description of data interception tools to sniffer programs designed for trivial listening of network packets. However, one should not neglect at least a theoretical description of such attacks, especially for anti-hackers, since knowledge of the hacking technologies used will help prevent many troubles.
Network sniffing
To sniff Ethernet networks, network cards set to listening mode are usually used. Listening to an Ethernet network requires connecting a computer running a sniffer program to a network segment, after which all network traffic sent and received by computers on that network segment becomes available to the hacker. It is even easier to intercept traffic from radio networks that use wireless network intermediaries - in this case, you do not even need to look for a place to connect to the cable. Or an attacker can connect to the telephone line connecting the computer to the Internet server, finding a convenient place for this (telephone lines are usually laid in basements and other rarely visited places without any protection).
To demonstrate sniffing technology, we will use a very popular sniffer program SpyNet, which can be found on many Web sites. Official website of the program SpyNet located at http://members.xoom.com/layrentiu2/, where you can download a demo version of the program.
Program SpyNet consists of two components - CaptureNet And PipeNet. Program CaptureNet allows you to intercept packets transmitted over the Ethernet network at the network level, i.e. in the form of Ethernet frames. Program PipeNet allows you to assemble Ethernet frames into application layer packets, restoring, for example, email messages, HTTP messages (exchange of information with a Web server) and perform other functions.
Unfortunately, in the demo version SpyNet possibilities PipeNet are limited to the HTTP package build demo, so we won't be able to demonstrate how it works SpyNet in full. However, we will demonstrate the capabilities of network sniffing SpyNet using our experimental network as an example, transferring a text file from the host Sword-2000 to host Alex-Z using regular Windows Explorer. Simultaneously on the computer A1ex-1 we will launch the program CaptureNet, which will intercept transmitted packets and allow the contents of the transmitted file to be read in Ethernet frames. In Fig. 1 shows the text of the secret message in the file secret.txt; we will try to find this text in the captured Ethernet frames.
Rice. 1. Text of the secret message in the Notepad window
To capture Ethernet frames, follow these steps:
On the computer Alex-Z run the program CaptureNet. In the displayed working window of the program, select the menu command Capture * Start(Capture * Start) and start the process of capturing network frames.
Using Windows Explorer, copy the security.txt file from your computer Sword-2000 on A1ex-3.
After transferring the secret.txt file, select the menu command Capture * Stop(Capture * Stop) and stop the capture process.
The captured Ethernet frames will be displayed on the right side of the program's working window CaptureNet(Figure 2), with each row in the top list representing an Ethernet frame, and below the list the contents of the selected frame.
Rice. 2. Ethernet frame contains secret message text
Having looked through the list of intercepted frames, we can easily find the one that contains the text we transmitted This is a very big secret (This is a very big secret).
We emphasize that this is the simplest example, when all intercepted network traffic was recorded. Program CaptureNet allows you to intercept packets sent over certain protocols and to certain host ports, select messages with specific content and accumulate the intercepted data in a file. The technique for performing such actions is simple, and can be mastered using the program’s help system SpyNet.
In addition to primitive network eavesdropping, hackers have access to more sophisticated means of data interception. Below is a brief overview of such methods, albeit from a theoretical aspect. The reason is that for Windows networks, the practical implementation of data interception attacks is extremely limited, and the set of reliable utilities for interception attacks is quite poor.
Methods for intercepting network traffic
Network listening using network analyzer programs like the one above CaptureNet, is the first, simplest way to intercept data. Except SpyNet For network sniffing, many tools are used, initially developed for the purposes of analyzing network activity, diagnosing networks, selecting traffic according to specified criteria, and other network administration tasks. An example of such a program is tcpdump (http://www.tcpdump.org), which allows you to record network traffic in a special log for later analysis.
To protect against network eavesdropping, special programs are used, for example, AntiSniff (http://www.securitysoftwaretech.com/antisniff), which are capable of identifying computers on the network that are listening to network traffic. To solve their problems, antisniffer programs use a special sign of the presence of listening devices on the network - the network card of the sniffer computer must be in a special listening mode. While in listening mode, network computers react in a special way to IP datagrams sent to the host being tested. For example, listening hosts typically process all incoming traffic, not just datagrams sent to the host's address. There are other signs indicating suspicious host behavior that the program can recognize AntiSniff.
Undoubtedly, eavesdropping is very useful from the point of view of an attacker, since it allows one to obtain a lot of useful information - passwords transmitted over the network, addresses of network computers, confidential data, letters, etc. However, simple eavesdropping does not allow a hacker to interfere with network communication between two hosts in order to modify and corrupt data. To solve such a problem, more complex technology is required.
False ARP requests
To intercept and take over the process of network interaction between two hosts A and B, an attacker can replace the IP addresses of interacting hosts with his own IP address by sending falsified ARP (Address Resolution Protocol) messages to hosts A and B. You can get acquainted with the ARP protocol in Appendix D, which describes the procedure for resolving (converting) the host's IP address to the machine address (MAC address) hardcoded into the host's network card. Let's see how a hacker can use ARP to intercept network communications between hosts A and B.
To intercept network traffic between hosts A and B, the hacker imposes his IP address on these hosts, so that A and B use this falsified IP address when exchanging messages. To impose his IP address, the hacker performs the following operations.
The attacker determines the MAC addresses of hosts A and B, for example, using the command nbtstat from the package W2RK.
The attacker sends messages to the identified MAC addresses of hosts A and B, which are falsified ARP responses to requests for resolving the hosts' IP addresses to the MAC addresses of computers. Host A is informed that the IP address of host B corresponds to the MAC address of the attacker’s computer; host B is informed that the IP address of host A also corresponds to the MAC address of the attacker’s computer.
Hosts A and B store the received MAC addresses in their ARP caches and then use them to send messages to each other. Since IP addresses A and B correspond to the MAC address of the attacker’s computer, hosts A and B, unsuspectingly, communicate through an intermediary who can do anything with their messages.
To protect against such attacks, network administrators must maintain a database with a table of correspondence between the MAC addresses and IP addresses of their network computers. Further, using special software, for example, the utility arpwatch (ftp://ftp.ee.lbl.gov/arpwatch-2.lab.tar.gz) you can periodically survey the network and identify inconsistencies.
On UNIX networks, this type of spoofed ARP request attack can be implemented using system utilities for monitoring and managing network traffic, for example, arpredirect. Unfortunately, such reliable utilities do not seem to be implemented on Windows 2000/XP networks. For example, on the NTsecurity website ( http://www.ntsecurity.nu) you can download the utility GrabitAII, presented as a means to redirect traffic between network hosts. However, a basic check of the functionality of the utility GrabitAII shows that complete success in implementing its functions is still far away.
False routing
To intercept network traffic, an attacker can spoof the real IP address of a network router with their own IP address, doing this, for example, using falsified ICMP Redirect messages. Host A must, according to RFC-1122, perceive the received Redirect message as a response to a datagram sent to another host, for example, B. Host A determines its actions on the Redirect message based on the contents of the received Redirect message, and if datagram redirection is specified in Redirect from A to B along a new route, this is exactly what host A will do.
To perform false routing, the attacker must know some details about the organization of the local network in which host A is located, in particular, the IP address of the router through which traffic is sent from host A to B. Knowing this, the attacker will generate an IP datagram in which IP -the sender address is defined as the IP address of the router, and the recipient is host A. Also included in the datagram is an ICMP Redirect message with the address field of the new router set to the IP address of the attacker's computer. Having received such a message, host A will send all messages to the IP address of the attacker's computer.
To protect against such an attack, you should disable (for example, using a firewall) the processing of ICMP Redirect messages on host A, and the command can reveal the IP address of the attacker’s computer tracert(on Unix this is the tracerout command). These utilities are capable of finding an additional route that has appeared on the local network that was not provided for during installation, unless, of course, the network administrator is vigilant.
The above examples of interceptions (to which the capabilities of attackers are far from limited) convince us of the need to protect data transmitted over the network if the data contains confidential information. The only method of protection against interceptions of network traffic is the use of programs that implement cryptographic algorithms and encryption protocols and prevent the disclosure and substitution of secret information. To solve such problems, cryptography provides tools for encrypting, signing and verifying the authenticity of messages transmitted over secure protocols
The practical implementation of all the cryptographic methods for protecting information exchange described in Chapter 4 is provided by VPN (Virtual Private Network) networks. A brief overview of cryptographic security principles and techniques can be found in Appendix E, and a detailed description of the cryptographic security features provided by the application is provided in Appendix E. PGP Desktop Security (http://www.pgp.com).
TCP connection interception
The most sophisticated network traffic interception attack should be considered TCP connection capture (TCP hijacking), when a hacker interrupts the current communication session with the host by generating and sending TCP packets to the attacked host. Next, using the TCP protocol's ability to restore an interrupted TCP connection, the hacker intercepts the interrupted communication session and continues it instead of the disconnected client.
Several effective utilities have been created to perform TCP connection hijacking attacks, but all of them are implemented for the Unix platform, and on Web sites these utilities are presented only in source code form. Thus, as convinced practitioners of the noble cause of hacking, attacks using the TCP connection interception method are not of much use to us. (Those who like to understand other people's program code can refer to the site http://www.cri.cz/~kra/index.html, where you can download the source code of the well-known TCP connection interception utility Hunt from Pavel Krauz).
Despite the lack of practical tools, we cannot ignore such an interesting topic as intercepting TCP connections, and we will dwell on some aspects of such attacks. Some information about the structure of a TCP packet and the procedure for establishing TCP connections is given in Appendix D of this book, but here we will focus on the question - what exactly allows hackers to carry out TCP connection interception attacks? Let us consider this topic in more detail, relying mainly on the discussion in and.
The TCP protocol (Transmission Control Protocol) is one of the basic OSI transport layer protocols that allows you to establish logical connections over a virtual communication channel. Over this channel, packets are transmitted and received with their sequence recorded, the flow of packets is controlled, retransmission of distorted packets is organized, and at the end of the session the communication channel is broken. The TCP protocol is the only core protocol in the TCP/IP family that has an advanced message identification and connection system.
To identify a TCP packet, there are two 32-bit identifiers in the TCP header, which also act as packet counters, called sequence number and acknowledgment number. We will also be interested in one more field of the TCP packet, called control bits. This 6-bit field includes the following control bits (in order from left to right):
URG - urgency flag;
ACK - confirmation flag;
PSH - carry flag;
RST - connection re-establishment flag;
SYN - synchronization flag;
FIN - connection termination flag.
Let's look at the procedure for creating a TCP connection.
1. If host A needs to create a TCP connection with host B, then host A sends host B the following message:
A -> B: SYN, ISSa
This means that the message sent by host A has the SYN flag (Synchronize sequence number) set, and the sequence number field is set to the initial 32-bit value ISSa (Initial Sequence Number).
2. In response to the request received from host A, host B responds with a message in which the SYN bit is set and the ACK bit is set. In the sequence number field, host B sets its initial counter value - ISSb; the acknowledgment number field will then contain the ISSa value received in the first packet from host A, increased by one. So host B responds with this message:
B -> A: SYN, ACK, ISSb, ACK(ISSa+1)
3. Finally, host A sends a message to host B in which: the bit is set ASK; the sequence number field contains the value ISSa + 1; The confirmation number field contains the value ISSb + 1. After this TCP connection between hosts A And IN is considered established:
A -> B: ACK, ISSa+1, ACK(ISSb+1)
4. Now the host A can send data packets to the host IN over the newly created virtual TCP channel:
A -> B: ACK, ISSa+1, ACK(ISSb+1); DATA
Here DATA stands for data.
From the algorithm for creating a TCP connection discussed above, it can be seen that the only identifiers of TCP subscribers and a TCP connection are two 32-bit parameters of the sequence number and acknowledgment number - ISSa And ISSb. Therefore, if a hacker manages to find out the current field values ISSa And ISSb, then nothing will prevent it from generating a falsified TCP packet. This means that a hacker only needs to select the current parameter values ISSa And ISSb TCP packet for a given TCP connection, send the packet from any Internet host on behalf of the client of this TCP connection, and this packet will be accepted as valid!
The danger of such TCP packet spoofing is also important because the high-level FTP and TELNET protocols are implemented based on the TCP protocol, and the identification of FTP and TELNET packet clients is entirely based on the TCP protocol.
In addition, since the FTP and TELNET protocols do not check the IP addresses of message senders, after receiving a falsified packet, the FTP or TELNET servers will send a response message to the IP address of the hacker host specified in the false packet. After this, the hacker host will start working with the FTP or TELNET server from its IP address, but with the rights of a legally connected user, who, in turn, will lose contact with the server due to mismatch of counters.
Thus, to carry out the attack described above, a necessary and sufficient condition is knowledge of the two current 32-bit parameters ISSa And ISSb, identifying the TCP connection. Let's consider possible ways to obtain them. In the case when the hacker host is connected to the attacked network segment, the task of obtaining the values ISSa And ISSb is trivial and can be solved by analyzing network traffic. Therefore, it must be clearly understood that the TCP protocol allows, in principle, to protect a connection only if it is impossible for an attacker to intercept messages transmitted over this connection, that is, only if the hacker host is connected to a network segment different from the subscriber segment of the TCP connection.
Therefore, intersegment attacks are of greatest interest to a hacker, when the attacker and his target are in different network segments. In this case, the task of obtaining values ISSa And ISSb is not trivial. To solve this problem, only two methods have now been invented.
Mathematical prediction of the initial value of TCP connection parameters by extrapolation of previous values ISSa And ISSb.
Exploiting vulnerabilities in identifying TCP connection subscribers on Unix rsh servers.
The first problem is solved through in-depth studies of the implementation of the TCP protocol in various operating systems and is now of purely theoretical significance. The second problem is solved by using Unix system vulnerabilities to identify trusted hosts. (Trusted by this host A called network host IN whose user can connect to the host A without authentication using host r-service A). By manipulating the parameters of TCP packets, a hacker can try to impersonate a trusted host and intercept a TCP connection with the attacked host.
All this is very interesting, but the practical results of this kind of research are not yet visible. Therefore, we advise everyone who wants to delve deeper into this topic to turn to the book, from where the information presented above was mainly taken.
Conclusion
Intercepting network data is the most effective method of network hacking, allowing a hacker to obtain almost all the information circulating on the network. The greatest practical development has been achieved by sniffing tools, i.e. listening to networks; However, we cannot ignore methods of intercepting network data, performed by interfering with the normal functioning of the network in order to redirect traffic to a hacker host, especially methods of intercepting TCP connections. However, in practice, the last mentioned methods have not yet received sufficient development and need to be improved.
An anti-hacker should know that the only salvation from data interception is its encryption, i.e. cryptographic protection methods. When sending a message over the network, you should assume in advance that the network's cable system is absolutely vulnerable, and any hacker connected to the network will be able to catch all transmitted secret messages from it. There are two technologies for solving this problem - creating a VPN network and encrypting the messages themselves. All these tasks are very easy to solve using a software package PGP Desktop Security(its description can be found, for example, in).
Sometimes when using the Internet, situations arise in which traffic leaks or unexpected consumption of system resources occurs. To quickly analyze and detect the source of the problem, special network tools are used. One of them, WireShark, will be discussed in the article.
general information
Before using WireShark, you need to familiarize yourself with its scope, functionality and capabilities. In short: the program allows you to capture packets in real time in wired and wireless network connections. Used in Ethernet, IEEE 802.11, PPP and similar protocols. You can also use VoIP call traffic interception.
The program is distributed under the GNU GPL license, which means it is free and open source. You can run it on many Linux distributions, MacOS, and there is also a version for the Windows operating system.
How to use WireShark?
Firstly, you should first install it on the system. Since one of the most commonly used Linux distributions is Ubuntu, all examples will be shown in it.
To install, just type the command in the console:
sudo apt-get install wireshark
After this, the program will appear in the main menu. You can launch it from there. But it is better to do this from the terminal, since she needs superuser rights. This can be done like this:
Appearance
The program has a convenient graphical interface. The user will see a friendly window divided into 3 parts. The first is directly related to capture, the second relates to opening files and samples, and the third is help and support.
The Capture block contains a list of network interfaces available for capture. When you select, for example, eth0 and click the Start button, the interception process will start.
The window with intercepted data is also logically divided into several parts. At the top there is a control panel with various elements. Following this is a list of packages. It is presented in the form of a table. Here you can see the sequence number of the package, the time it was intercepted, the sending and receiving address. You can also remove data about the protocols used, length and other useful information.
Below the list is a window with the contents of the technical data of the selected package. And even lower there is a display in hexadecimal form.
Each view can be expanded into a larger window for easier reading of the data.
Applying filters
While the program is running, dozens or even hundreds of packets will always pass in front of the user. Weeding them out manually is quite difficult and time-consuming. Therefore, the official WireShark instructions recommend using filters.
There is a special field for them in the program window - Filter. To configure the filter more precisely, there is an Expression button.
But for most cases, a standard set of filters will suffice:
- ip.dst — packet destination ip address;
- ip.src — sender address;
- ip.addr - just any ip;
- ip.proto - protocol.
Using filters in WireShark - instructions
To try how the program works with filters, you need to enter a certain command. For example, such a set - ip.dst == 172.217.23.131 - will show all flying packets to the Google website. To view all traffic - both incoming and outgoing - you can combine two formulas - ip.dst == 172.217.23.131 || ip.src == 172.217.23.131. Thus, it turned out to use two conditions in one line at once.
You can use other conditions, for example ip.ttl< 10. Данная команда выведет все пакеты с длительностью жизни меньше 10. Чтобы выбрать данные по их размеру, можно применить такой подход — http.content_length > 5000.
Additional features
For convenience, WireShark has a way to quickly select packet parameters as the field to be analyzed. For example, in a field with technical data, you can right-click on the desired object and select Apply as Column. What does it mean to transfer it to the field area as a column.
Similarly, you can select any parameter as a filter. To do this, there is an Apply as Filter item in the context menu.
Separate session
You can use WireShark as a monitor between two network nodes, for example, a user and a server. To do this, select the package you are interested in, call up the context menu and click Follow TCP Stream. A new window will display the entire log of the exchange between the two nodes.
Diagnostics
WireShark has a separate tool for analyzing network problems. It's called Expert Tools. You can find it in the lower left corner, in the form of a round icon. Clicking on it will open a new window with several tabs - Errors, Warnings and others. With their help, you can analyze in which nodes failures occur, packets do not arrive, and detect other problems with the network.
Voice traffic
As already mentioned, WireShark can also intercept voice traffic. An entire Telephony menu is dedicated to this. This can be used to find problems in VoIP and fix them quickly.
The VoIP Calls item in the Telephony menu will allow you to view completed calls and listen to them.
Export objects
This is probably the most interesting functionality of the program. It allows you to use WireShark as an interceptor of files transmitted over the network. To do this, you need to stop the interception process and export HTTP objects to the File menu. The window that opens will display a list of all files transferred during the session, which can be saved to a convenient location.
Finally
Unfortunately, it will be difficult to find the current version of WireShark in Russian on the Internet. The most accessible and frequently used one is in English.
The same is true with detailed instructions for WireShark in Russian. The official one from the developer is presented in English. There are many short, short WireShark tutorials online for beginners.
However, for those who have been working in the IT field for a long time, understanding the program will not present any particular difficulties. And great opportunities and rich functionality will brighten up all the difficulties in learning.
It is worth noting that in some countries, using a sniffer like WireShark may be illegal.
General scheme
The sequence of steps that a program using the pcap library (from PacketCAPture) must perform to complete its task is as follows:
- Define the network interface that will be listened to. (On Linux this could be eth0, on BSD xl1).
- Initialize pcap. In this case, the library is informed on which interface we will listen to the data. It is possible to listen to several interfaces simultaneously (in different sessions).
- If it is necessary to create a filter (for example, we are only interested in TCP packets arriving on port 23), “compile” this filter and apply it to a particular session.
- Go to the packet receiving cycle. After this, every time another packet arrives and it passes through the specified filter, a function is called that needs to be defined in advance. This function can perform any action we want. It can parse the package and give it to the user, it can save it to disk, or it can do nothing at all.
- When finished, you must close all open sessions.
Let's consider the listed steps in detail.
Interface Definition
To determine the interface on which to listen, you can use two methods.
The first is that the interface name is specified by the user. Consider the following program:
#include
The user specifies the interface by passing its name as the first argument to our program. Naturally, the user-specified interface must exist.
The second way is to find out the interface name from the library itself:
#include
In this case, pcap gives us the name of the interface it owns. The errbuf line will contain a description of the error if one occurs when executing the pcap_lookupdev() call.
Opening an interface for packet interception
To create a traffic interception session, you need to call the pcap_open_live() function. The prototype of this function (from the pcap man page) looks like this:
Pcap_t *pcap_open_live (char *device, int snaplen, int promisc, int to_ms, char *ebuf)
The first argument is the device name that we defined in the previous step. snaplen is an integer that specifies the maximum number of bytes of a network frame that will be captured by the library. If promisc is set to true, the interface goes into the so-called promiscuous mode (packets addressed to other stations on the network are intercepted). to_ms - timeout in milliseconds (if the value is set to zero, reading will occur until the first error, if set to minus one - infinitely). Finally, errbuf is the line where we will receive the error message. The function returns the session handle (descriptor).
To demonstrate, let's look at a piece of code:
#include
Here an interface is opened, the name of which is indicated in the line somedev , indicating how many bytes of the packet to capture (the BUFSIZ value is defined in pcap.h). The network interface switches to promiscuous mode. The data will be read until an error occurs. In case of an error, you can display its text description on the screen using the errbuf pointer.
A note about intercepting traffic in promiscuous and non-promiscuous modes: the two methods are very different. In the case of traffic interception in non-promiscuous mode, the node receives only the traffic that is directed to or related to it. Only traffic to, from and routed through the host will be intercepted by our program. In promiscuous mode, the network interface accepts all packets coming through the cable. In a non-switched environment, this could be all network traffic. Its clear advantage is that it provides a larger number of packets to intercept, which may (or may not) be useful depending on what you are intercepting the network stream for.
However, traffic interception in promiscuous mode can be detected; another node can determine with high accuracy whether we are using promiscuous mode. Additionally, it only works in non-switched environments (such as hubs or switches that are flooded with arp packets). Thirdly, if the network is heavily loaded, our program will use a large amount of system resources.
Traffic filtering
Often a packet interceptor is needed to intercept not all, but only certain packets. For example, there are times when we want to intercept traffic on port 23 (telnet) in search of passwords. Or perhaps we want to intercept a file being sent over port 21 (FTP). Perhaps we want to intercept only DNS traffic (UDP port 53). In any case, it is very rarely necessary to intercept all data. The pcap_compile() and pcap_setfilter() functions are used to filter traffic.
Once we have called pcap_open_live() and have a functioning traffic capture session, we can apply our filter. Naturally, you can implement the filter manually by parsing the ETH/IP/TCP headers after receiving the packet, but using the internal pcap filter is more efficient and also simpler.
Before you can apply a filter, you need to “compile” it. The filter expression is stored in an ordinary string (character array). The syntax of such expressions is described in detail in the tcpdump man page (man tcpdump).
The pcap_compile() function is used to compile the filter. Its prototype looks like this:
Int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask)
The first argument is the handle (descriptor) of our session (pcap_t *handle in the previous example). The next argument is a pointer to the area in memory where we will store the compiled version of our filter. Next comes the filter expression itself in the form of a regular string. The next parameter determines whether our expression needs to be optimized or not (as usual, 0 means no, 1 means yes). The last parameter is the netmask to which our filter is applied. The function returns -1 in case of error, all other values indicate successful completion.
Once the expression is compiled, it must be applied, which is done using the pcap_setfilter() function. Its prototype is this:
Int pcap_setfilter(pcap_t *p, struct bpf_program *fp)
The first argument is the handle (descriptor) of our packet interception session, the second is a pointer to the compiled version of the expression for the filter (usually the second argument of the pcap_compile() function).
The following example demonstrates the use of a filter:
#include
This program prepares an interceptor for packets going to or from port 23, in promiscuous mode, on the eth0 interface. The example contains the pcap_lookupnet() function, which returns the network address and netmask for the device whose name is passed to it as a parameter. Its use is necessary because in order to apply a filter, we must know the address and network mask.
Packet interception
There are two packet interception techniques. You can intercept and process one packet at a time, or you can work with a group of packets by setting a special loop that will run until pcap intercepts a specified number of packets. To work in the first mode, the pcap_next() function is used. pcap_next() prototype:
U_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h)
The first argument is the handle of our session, the second is a pointer to a structure in which information about the packet will be stored, such as the time when it was intercepted, the length of the packet and the length of its individual part (for example, if the packet is fragmented). pcap_next() returns a u_char pointer to the memory location where the packet described by this structure is stored.
Demonstration of using pcap_next() to capture a single packet:
#include
This program intercepts packets on the device that pcap_lookupdev() returns, putting it in pormiscuous mode. It detects a packet that comes through port 23 (telnet) and displays its size in bytes. Calling pcap_close() closes an open capture session.
The alternative method, although more difficult to understand, is likely to be more useful. There are very few (if any) packet captures that use pcap_next() . In the vast majority of cases they use pcap_loop() or pcap_dispatch() (which in turn uses pcap_loop()). In order to understand the use of these two functions, you need to understand the idea of callback functions.
Callback functions are a frequently used programming technique. The principle is quite simple. Let's say you have a program that waits for some event. For the purpose of, for example, processing a keystroke. Every time a key is pressed, I want to call a function that will handle that event. The function I'm using is a callback function. Every time the user presses a key, my program will call a callback function. Callback functions are used in pcap, but instead of calling them when the user presses a key, pcap calls them when it receives another packet. pcap_loop() and pcap_dispatch() are functions that use the callback function mechanism in almost the same way. Both call a callback function every time pcap intercepts a packet that passes through the filter (unless, of course, the filter is compiled and applied to the session, otherwise all intercepted packets are passed to the callback function)
Function prototype pcap_loop():
Int pcap_loop (pcap_t *p, int cnt, pcap_handler callback, u_char *user);
The first argument is our session handle. The next integer tells pcap_loop() how many total packets to capture (a negative value means packets should be captured until an error occurs). The third argument is the name of the callback function (only the name, without parentheses). The last argument is used in some applications, but usually it is simply set to NULL. pcap_dispatch() is almost identical, the only difference is how the functions handle the timeout, the value of which is set when pcap_open_live() is called. pcap_loop() simply ignores timeouts, unlike pcap_dispatch() . Details are in man pcap.
Before we give an example of how to use pcap_loop(), we need to look at the format of our callback function. We can't arbitrarily define a callback function prototype because pcap_loop() won't know what to do with it. The prototype of our callback function should be like this:
Void got_packet (u_char *args, const struct pcap_pkthdr *header, const u_char *packet);
Let's take a closer look at it. First, the function returns an empty value (void). This makes sense since pcap_loop() cannot know what to do with the return value. The first argument is the same as the last argument to pcap_loop(). Whatever value is used as the last argument to pcap_loop() is passed as the first argument to the callback function whenever it is called from pcap_loop() . The second argument is the pcap header, which contains information about when the packet was captured, its size, etc. The pcap_pkthdr structure is defined in pcap.h as follows:
Struct pcap_pkthdr ( struct timeval ts; // timestamp bpf_u_int32 caplen; // length of the captured part of the packet bpf_u_int32 len; // total length of the packet );
The last argument of the callback function is the most interesting. This is a pointer to a buffer, which actually contains the entire packet captured using pcap_loop().
How to use the packet variable? The packet contains many attributes, so as you can imagine, it is not actually a string, but some set of structures (for example, a TCP/IP packet will contain an ethernet, ip, tcp header and the data itself). The packet parameter, which is of type u_char , is actually a serialized version of these structures. In order to obtain useful data from these structures, we must carry out some transformations.
First of all, we must have structures defined in the program that we will use. We will use the following structures (we could actually take them directly from the header files, but the field names of structures vary from platform to platform, so these are used for demonstration purposes):
Struct sniff_ethernet ( u_char ether_dhost; u_char ether_shost; u_short ether_type; /* IP? ARP? RARP? etc */ ); // IP header struct sniff_ip ( #if BYTE_ORDER == LITTLE_ENDIAN u_int ip_hl:4, ip_v:4; #endif #if BYTE_ORDER == BIG_ENDIAN u_int ip_v:4, /* version */ ip_hl:4; /* header length */ #endif /* not _IP_VHL */ u_char ip_tos; u_short ip_id; #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; */ struct in_addr ip_src,ip_dst; and dest address */ ); struct sniff_tcp ( u_short th_sport; u_short th_dport; tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ #if BYTE_ORDER == LITTLE_ENDIAN u_int th_x2:4, /* (unused) */ th_off:4; / * data offset */ #endif #if BYTE_ORDER == BIG_ENDIAN u_int th_off:4, /* data offset */ th_x2:4; /* (unused) */ #endif u_char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 #define TH_ECE 0x40 #define TH_CWR 0x80 #define TH_FLAGS \ (TH_FIN|TH_SYN|TH_RST|\ TH_ACK|TH_URG|TH_ECE|TH_CWR) _short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ );
If structure descriptions from standard header files are used, then sometimes in order for a program that uses a TCP header description to compile without errors, it is necessary to define the _BSD_SOURCE symbol before including the header files. An alternative way is to define the structures that describe the TCP header manually.
pcap naturally uses exactly the same structures when capturing packets. Then it simply creates a u_char string (buffer) and copies the data from the structures into it. How to parse a string back into structures? This is easily done using pointers and type conversions.
First, let's declare the variables we need to parse the u_char package into separate headers:
Const struct sniff_ethernet *ethernet; const struct sniff_ip *ip; const struct sniff_tcp *tcp; const char *payload; int size_ethernet = sizeof(struct sniff_ethernet); int size_ip = sizeof(struct sniff_ip); int size_tcp = sizeof(struct sniff_tcp);
Now we do the type conversion:
Ethernet = (struct sniff_ethernet*)(packet); ip = (struct sniff_ip*)(packet + size_ethernet); tcp = (struct sniff_tcp*)(packet + size_ethernet + size_ip); payload = (u_char *)(packet + size_ethernet + size_ip + size_tcp);
After this we can access the fields of all structures in the usual way, for example:
If (tcp->th_flags & TH_URG) ( ... ); ... printf("TTL = %d\n", ip->ip_ttl);
Shutdown
When you are finished, you need to close the session. This is done using the pcap_close() function.
