Deep-level intranet topology structure inference method and system based on flow

Abstract

The invention discloses a flow-based deep intranet topology structure inference method and system, and belongs to the technical field of network topology construction. The method comprises the following steps: acquiring NTP (Network Time Protocol) traffic characteristics and TCP (Transmission Control Protocol) traffic characteristics of traffic; inferring the Windows equipment scale and the Linux equipment scale of each level of intranet according to the NTP traffic characteristics; performing hierarchical feature clustering on the TCP traffic based on the TCP traffic features and the Windows device scale and the Linux device scale of each level of intranet to obtain a TCP data packet array classified according to host devices; and performing host device relationship inference based on the TCP data packet array classified according to the host devices so as to construct a deep intranet topology structure. According to the invention, the network level of the deep local area network can be accurately deduced.

Description

Technical Field

[0001] The present invention belongs to the technical field of network topology construction, and in particular relates to a method and system for inferring deep-level intranet topology structure based on traffic. Background Art

[0002] Nowadays, with the rapid development of new information technologies such as computers, big data, cloud computing, the Internet of Things, and 5G, network equipment has been upgraded, scaled up, and structured more complex, and the requirements for network management have become higher, especially the company's information security, network management real-time, and the effectiveness of defense measures.

[0003] With the rapid development of the Internet, the Internet of Things is no longer just a concept, but a reality. Various Internet of Things devices have penetrated into all aspects of life, such as smart cameras, smart phones, smart homes, etc. While the Internet brings convenience to people, it also brings some hidden problems. The first is the security issue. The network security issues caused by the full popularization and application of the Internet have gradually become prominent, bringing huge threats to information security to enterprises. In particular, the concealment and upgrading of attack methods. Today's attackers can use various high-tech means to hide their positions, resulting in many security measures being ineffective. The second is the management problem. The large scale and complex structure of the intranet are already an irreversible trend. With the increasing number of devices in the intranet and the continuous expansion of the subnet structure, the management of the entire network has become more difficult. When there is a fault in the network, if the fault cannot be located in time, the loss will often be immeasurable. Another is the defense problem. Only by understanding the topology of the entire network can we quickly discover hosts and devices of unknown origin when they appear, and predict possible network attack paths and attack targets in advance, and advance the network's security line. If the network's defense mechanism and strategy are not perfect, it may lead to unpredictable disasters.

[0004] In terms of the Internet, most companies face various problems in network operations and data management. Some problems come from internal mistakes, such as insufficient network security awareness or lack of reliable security precautions; other problems may come from external threats. However, network attacks often do not occur suddenly. In the "KillChain" model, Martin Company divides this into 7 stages: target reconnaissance, initial attack, escalation of privileges, internal reconnaissance, lateral movement, persistent residence, and goal achievement. The attacker will first conduct reconnaissance on the selected target, first understand the network and resource conditions of the target attack object by various means externally, and then break through the defense line through watering hole attacks, spear phishing attacks, vulnerability penetration and other means to enter the target system, and then further penetrate the attack by detecting the internal network environment, escalating privileges through vulnerabilities, and implanting persistent backdoors, and finally launch an attack to achieve its goal.

[0005] To sum up, a comprehensive and accurate network topology structure can effectively help complete tasks such as network fault location, asset inventory, and security protection design. However, important enterprises and institutions represented by schools, scientific research, and military industry have the characteristics of many types of network equipment, cumbersome zoning and domain management, and complex security policy configuration, making intranet topology mapping an important basic support for solving the above problems.

[0006] The acquisition of the intranet topology is of great significance, but the commonly used detection technology cannot detect the entire intranet, mainly because the intranet contains a large number of routers with NAT services turned on. NAT, or Network Address Translation, is a common network technology that is often used in home or corporate networks. It allows private IP addresses to be used in the local area network and public IP addresses to be used on the Internet, so that hosts in the local area network can access the Internet. NAT services are usually provided by network devices such as routers. It maps the IP addresses and port numbers of hosts in the local area network to public IP addresses and port numbers, and forwards data packets between the Internet and the local area network. This technology can effectively reduce the use of IP addresses, improve network security, and simplify network management. However, it is precisely because NAT converts data packets that it affects the flow-based topology inference function.

[0007] Currently, due to the existence of NAT, there are many insurmountable difficulties in the process of inferring network topology. For example, the existence of gateway devices such as network address translation will affect the accuracy of inferring the target network topology by capturing traffic from outside the target network. The existence of these devices makes it difficult to determine the number of host devices in the internal network, difficult to judge the relationship, and difficult to obtain the topology of the deep internal network. In recent years, methods based on TCP / IP protocol field changes or traffic clustering have gradually been applied to topology inference, but they are more focused on the detection of NAT devices and the determination of host scale, or it is difficult to effectively integrate related features, which will lead to large deviations in the inference of network topology, such as the following two methods:

[0008] The "Identification of Hosts behind a NAT Device Utilizing Multiple Fields of IP and TCP" published in 2016 [H.Park, S.-h.Shin, B.-h.Roh and C.Lee, "Identification of hosts behind a NAT device utilizing multiple fields of IPand TCP," 2016 International Conference on Information and Communication Technology Convergence (ICTC), Jeju, Korea (South), 2016, pp.484-486, doi: 10.1109 / ICTC.2016.7763518.] uses multiple IP and TCP field features to identify hosts in a NAT network. The method first performs a TCP SYN scan on the target network, and then analyzes the returned SYN-ACK packet to determine the IP address of the NAT device in the target network. Then, the method uses the changes in the values ​​of different fields to identify the host behind the NAT, including the ID and length fields of the IP header and the sequence number and window size fields of the TCP header. However, the technical solution relies on passively observing network traffic, so it cannot directly control test conditions or actively trigger traffic, which is not applicable to some scenarios. On the other hand, it requires analysis of multiple IP and TCP fields, and the algorithm is complex and may cause performance problems. In addition, in some cases, NAT devices may modify fields in the traffic, causing the algorithm to fail.

[0009] "Exploring NAT Detection and Host Identification Using Machine Learning" [Khatouni, Ali Safari et al. "Exploring NAT Detection and Host Identification Using Machine Learning." 2019 15th International Conference on Network and Service Management (CNSM) (2019): 1-8.] published in 2019 proposed a NAT detection and host identification method based on machine learning. The method includes dataset preparation, feature extraction, classifier construction, and model evaluation. First, data packets are collected from the network and each packet is marked whether it passes through the NAT device. Then, feature information of each data packet is extracted, including address, port, and protocol. Next, a classifier is constructed using this feature information, such as using a random forest algorithm. Finally, the performance of the classifier is evaluated, such as using indicators such as accuracy, recall, and F1 score. However, this technical solution still has the following defects:

[0010] 1. Requires large data sets and computing resources: Due to the use of machine learning algorithms, large data sets are required for training and testing, and corresponding computing resources are required to process these data. This may limit the application of the method, especially when computing resources are limited.

[0011] 2. Limited scalability: Since it uses a machine learning-based approach, it may need to be retrained and tested when processing new network data. This means that the approach may not scale well when the network size increases or the network topology changes.

[0012] 3. May not be applicable to some NAT devices: This method uses some common features in network data packets for classification and identification, which may not be applicable to certain types of NAT devices, resulting in the inability to accurately identify and classify hosts.

[0013] Therefore, a technical solution is currently needed to accurately infer the network hierarchy of a deep local area network. Summary of the invention

[0014] In order to solve the difficulty of deep-level LAN detection caused by NAT technology, the present invention proposes a flow-based deep-level intranet topology inference method and system, which can accurately infer the network level of the deep-level LAN.

[0015] To achieve the above objectives, the technical solution of the present invention includes the following contents.

[0016] A method for inferring a deep intranet topology structure based on traffic flow, the method comprising:

[0017] Obtain NTP traffic characteristics and TCP traffic characteristics of traffic;

[0018] Infer the scale of Windows and Linux devices in each layer of the intranet based on NTP traffic characteristics;

[0019] Based on the TCP traffic characteristics and the scale of Windows devices and Linux devices in each layer of the intranet, the TCP traffic is hierarchically clustered to obtain an array of TCP data packets classified by host devices.

[0020] Based on the TCP data packet array classified by host device, host device relationship inference is performed to build a deep intranet topology structure.

[0021] Furthermore, the TCP traffic characteristics of the traffic are obtained, including:

[0022] Parse the TCP traffic packet and extract fields in the TCP handshake packet, wherein the fields in the TCP handshake packet include: capture_time field, seq_num field, ack_num field, SYN field, ACK field and ttl field;

[0023] Based on the fields in the TCP handshake packet, each handshake process is integrated to obtain TCP traffic characteristics.

[0024] Further, the NTP traffic characteristics include: the time when the NAT router captures the NTP data packet, the mode of the NTP data packet, the lifetime value of the NTP data packet and the destination IP of the NTP data packet;

[0025] The inference of the scale of Windows devices and Linux devices in each level of the intranet based on the NTP traffic characteristics includes:

[0026] The NTP packets are classified by layer using the lifetime value of the NTP packets to obtain the total scale of devices in each layer of the intranet.

[0027] The devices in each level of the intranet are distinguished based on the destination IP of the NTP data packet, and the scale of Windows devices and Linux devices in the intranet at this level are obtained by combining the total scale of devices in the intranet at this level.

[0028] Further, the TCP traffic characteristics include: the time when the NAT router captures the TCP data packet, the delay time of the TCP data packet and the survival time value of the TCP data packet;

[0029] The method performs hierarchical feature clustering on TCP traffic based on TCP traffic characteristics and the scale of Windows devices and Linux devices in each layer of the intranet to obtain an array of TCP data packets classified by host devices, including:

[0030] According to the lifetime value of TCP packets, TCP packets are classified by layer;

[0031] Taking the delay time of the TCP data packet as the characteristic value and the total size of Windows devices and Linux devices in each level of the intranet as the number of clusters, the TCP data packets at each level are clustered respectively, and based on the clustering results, an array of TCP data packets classified by host device is generated.

[0032] Furthermore, host device relationship inference is performed based on the TCP data packet array classified by host device to construct a deep intranet topology structure, including:

[0033] Based on the delay array of the host device, construct an associated delay array between two host devices; wherein the delay array of the host device is an array of TCP data packets classified by the host device;

[0034] Calculating correlation coefficients between host devices according to the association delay array;

[0035] The similarity of the delay arrays is calculated, and combined with the correlation coefficients between the host devices, a deep intranet topology structure is constructed.

[0036] Furthermore, based on the correlation between the host devices, a deep intranet topology structure is constructed by calculating the similarity of the associated delay arrays, including:

[0037] Calculate the similarity of the delay arrays of the two host devices;

[0038] When the similarity of the delay arrays is greater than a set threshold and the survival time values ​​of the TCP data packets are the same, two host devices with the largest correlation coefficient between the host devices are selected for merging, the average of the delay arrays of the two host devices is used as the delay array of the merged node, and after globally updating the associated delay arrays, the similarity of the delay arrays of the two host devices is calculated again;

[0039] When the similarity of the associated delay arrays is greater than a set threshold and the survival time values ​​of the TCP data packets are different, constructing a hierarchical structure of two corresponding host device nodes based on the survival time values ​​of the TCP data packets, and re-executing the calculation of the similarity of the delay arrays of the two host devices;

[0040] When the similarity of the delay arrays corresponding to a host device or a merged node is less than the set threshold, the host device is connected to a NAT router or a NAT router is used to replace the merged node, and the average value of the delay array of the host device or the delay array involved in the merged node is used as the delay array of the NAT router, and the survival time value of the TCP data packet of the NAT router is set to the survival time value of the TCP data packet of the previous level;

[0041] When only one node remains after the merger, the node is connected to the NAT router representing the source node.

[0042] A traffic-based deep intranet topology inference system, the system comprising:

[0043] A feature extraction module is used to obtain NTP traffic features and TCP traffic features of traffic;

[0044] The scale analysis module is used to infer the scale of Windows devices and Linux devices in each layer of the intranet based on the NTP traffic characteristics;

[0045] A feature clustering module is used to perform hierarchical feature clustering on TCP traffic based on TCP traffic features and the scale of Windows devices and Linux devices in each layer of the intranet, and obtain an array of TCP data packets classified by host devices;

[0046] The structure inference module is used to infer the relationship between host devices based on the TCP data packet array classified by host devices to build a deep intranet topology structure.

[0047] An electronic device comprises: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the method for inferring deep intranet topology structure based on traffic described in any one of the above items is implemented.

[0048] A computer-readable storage medium, characterized in that computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are executed by a processor, any of the above-mentioned methods for inferring deep intranet topology structure based on traffic is implemented.

[0049] Compared with the prior art, the present invention can deduce the topology of the deep-level intranet by analyzing the traffic data, using NTP traffic packets to infer the scale of devices in the network and using TCP traffic packets to infer the relationship between devices without prior knowledge. In view of the fact that there is little research on the topology of NAT devices in the intranet, the topology inference method proposed by the present invention is based on the traffic inference method in the public network, which has at least the following technical advantages:

[0050] (1) Device scale inference algorithm: Based on the destination IP address and period of the NTP request data packet sent by the same device when making a time synchronization request, all NTP traffic packets are classified by host and the scale of the host device is inferred.

[0051] (2) Device traffic clustering algorithm: The “half of the difference in capture time between the second and third handshake packets in the TCP three-way handshake data packet” is taken as the “one-way delay between the NAT device and the device in the intranet”, and the TCP handshake flow is clustered by host based on the one-way delay.

[0052] (3) Device relationship inference algorithm: First, half of the round-trip delay from the NAT device to the intranet device is used as the one-way delay from the detection device to the detected device calculated by the "adjacent" group measurement method. Secondly, based on the fact that the network status at similar times is approximately the same, an array of associated delays between two devices is constructed based on the delays of all devices at similar times. Finally, the correlation coefficient and cosine similarity of the associated delay array are used as correlation indicators to construct a correlation matrix. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 It is a deep intranet topology inference framework based on traffic.

[0054] Figure 2 It is a schematic diagram of the deep intranet topology inference method.

[0055] Figure 3 It is the periodic characteristic of the Linux device NTP request.

[0056] Figure 4 It is the periodic characteristic of NTP requests of Windows devices.

[0057] Figure 5 It is a schematic diagram of the construction of the delay array associated between devices.

[0058] Figure 6 It is the TCP three-way handshake process.

[0059] Figure 7 It is the measurement model of the "adjacent" grouping measurement method.

[0060] Fig. 8AIt is the original network topology.

[0061] Figure 8B is the inferred network topology. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention is further described in detail below through specific implementations and in conjunction with the accompanying drawings.

[0063] Figure 1 It is the main flow chart of the technical solution of the present invention. Figure 1 As shown in FIG. 1 , the topology structure inference method proposed in the present invention includes four steps: data acquisition and preprocessing, device scale inference, device flow clustering, and device relationship inference. Figure 2 shown.

[0064] Step 1: Capture traffic from the NAT router egress, parse the NTP traffic and TCP traffic, extract key feature values ​​and save them as structured data.

[0065] In step 1, we first need to monitor and capture the traffic at the NAT router exit, and then capture the traffic at the router exit and parse it by protocol classification (NTP, TCP). Next, we extract the corresponding structure and perform relevant calculations to obtain its key eigenvalues. These eigenvalues ​​can be used to describe the structured data of the corresponding network device status for subsequent device scale inference and device traffic clustering.

[0066] First, the traffic is very large. Second, not all traffic can be used for topology inference, so only traffic packets containing key features are parsed. The following describes the parsing and feature value extraction of traffic packets in detail:

[0067] (1) NTP traffic package

[0068] Since almost all devices have time synchronization requirements, they will generate NTP traffic packets. After further investigation, it was found that the time intervals for sending NTP request packets by devices with Linux and Windows operating systems have certain regular characteristics, and NTP traffic packets can be analyzed to infer the scale of devices.

[0069] The present invention uses the destination IP address and periodic characteristics of the NTP request packet to infer the number of devices contained in the deep intranet, so the following characteristic data in the NTP traffic packet is selected to form a four-tuple structure (capture_time, mode, ttl, dest_ip). Among them, capture_time is the time when the NAT router captures the data packet. Since the actual time when the target device sends the request cannot be obtained, but when the network state is stable, the delay from the target device to the NAT router is stable, it can be approximately considered that the time interval captured by the NAT router is equal to the time interval when the target device sends the request. mode is the mode of the NTP request packet, and when mode=3, it indicates the client mode. The present invention only analyzes the time interval when the target device sends a request to the NTP server, so it only needs to parse the NTP traffic packet when mode=3. ttl is the survival time value, and the default initial TTL value of Linux devices and Windows devices is constant. Linux devices are generally 64, while Windows devices are generally 64 or 128 due to reasons such as the operating system. dest_ip is used to record the IP address of the NTP server, and the NTP server requested by the Windows device is constant. Since capture_time, mode, ttl, and dest_ip do not change after NAT translation, they can be used as device features to infer device size.

[0070] (2) TCP traffic packet

[0071] Because almost all devices in the network have the need to establish connection requests with other devices in the network or servers that can provide Internet services, a TCP three-way handshake packet will be generated in this process to prepare for data transmission. After analysis, the time difference between the second handshake and the third handshake in the TCP handshake packet can be used as the round-trip delay from the host device to the NAT router, which can be used as an important indicator of device relevance in the subsequent device relationship inference stage.

[0072] The present invention infers the relationship between nodes based on TCP traffic packets. When parsing TCP traffic packets, the following fields in the TCP handshake packet are extracted (capture_time, seq_num, ack_num, SYN, ACK and ttl). After integrating each handshake process, a triple structure consisting of three feature data (capture_time, delay_time, ttl) is constructed.

[0073] Step 2: NTP traffic is layered according to TTL, and then the NTP traffic packets of each layer are classified by host device based on the characteristics of the NTP server and time cycle when the device makes a time synchronization request, so as to infer the scale of the host device.

[0074] In step 2, since the key component of the deep intranet is the host device, the inferred core is the host device, the inferred scale is the scale of the host device, the inferred relationship is the relationship between the host devices, and the traffic is clustered according to the host device. This makes the number of clusters consistent with the number of hosts, and the attribution of traffic clusters is consistent with the host devices in the topology.

[0075] For Linux devices, the traffic cycle characteristics of their NTP request packets are as follows: Figure 3 As shown in the figure, the default time synchronization tool for modern Linux distributions (such as Ubuntu, Debian, Arch Linux, OpenSUSE, etc.) is systemd-timesyncd. Using the "timectl" command and according to the "timesync-status", you can see that the default time interval between two consecutive NTP requests sent by the same device is 32 seconds at the minimum and 2048 seconds at the maximum. Therefore, if the time interval between two request data meets the above rules, it can be inferred that they come from the same Linux device.

[0076] For Windows devices, the time points at which they send different NTP request packets are usually periodic, and the NTP server requested by Windows devices is fixed by default. If the computer is running Windows XP Home Edition or is not a domain-joined computer, it is configured by default to obtain the time from time.windows.com. Figure 4 As shown, time.windows.com represents the server domain name of the Windows device NTP request. The time interval of the Windows device NTP request can be obtained by the current synchronization time and the next synchronization time: 2023 / 5 / 1 8:02-2023 / 4 / 30 22:56≈9 hours (next synchronization time minus current synchronization time). Using this feature, the NTP packets of Windows devices can be quickly identified and classified by host. Therefore, by collecting and analyzing the NTP request data packets of all Windows devices in the intranet, the scale of Windows devices can also be inferred.

[0077] The present invention will infer the scale of deep-level intranet devices based on this data structure, and the steps are roughly as follows:

[0078] 1. Use TTL to classify NTP traffic by layer: NTP traffic packets with the same TTL value are grouped into one category, indicating that the traffic belongs to devices on the same layer;

[0079] 2. Use the destination IP to further classify the traffic in each category according to the operating system type (Windows and Linux): NTP traffic packets with destination IP 52.231.114.183 (time.windows) or 20.189.79.72 (time.nist.gov) are grouped into one category, indicating the host device traffic of the Windows system; the others are grouped into one category, indicating the host device traffic of the Linux system;

[0080] 3. Group and cluster the traffic of each operating system at each layer: first, the scale of Windows devices. The number of NTP request packets at the capture time is inferred as the scale of Windows devices. Secondly, the scale of Linux devices. The traffic packets whose capture time difference between each pair of data packets is a power of 2 are grouped into one category, and the number of clusters is the scale of Linux devices.

[0081] Step 3: Calculate the one-way delay between the device and the NAT router to which each group of TCP flows belongs through the TCP three-way handshake packet, and cluster the TCP flows by host based on the one-way delay. The clustering algorithm is k-means, and the number of clusters is the number of device scales inferred in the previous stage. After clustering is completed, a delay array consisting of one-way delays at different times classified by host devices will be obtained.

[0082] The TCP three-way handshake process is as follows Figure 6 The TCP three-way handshake process usually includes the following three steps, each of which uses SYN, SEQ, ACK and other flags and sequence numbers:

[0083] (1) The client sends a SYN packet:

[0084] SYN: Synchronization flag, used to initialize the connection.

[0085] SEQ=x: The client randomly generates an initial sequence number x, indicating that this is the client's sending sequence number.

[0086] The client sends a SYN packet to the server, indicating that it wishes to establish a connection and informing the server of the client's initial sequence number.

[0087] (2) The server replies with a SYN-ACK packet:

[0088] SYN: The server also sends the SYN flag to indicate that it agrees to establish a connection.

[0089] SEQ=y: The server generates an initial sequence number y, indicating that this is the server's sending sequence number.

[0090] ACK=x+1: The server confirms receipt of the client's SYN packet and adds 1 to the client's sequence number x in the ACK field, indicating that the client's next data packet sequence number is expected to be x+1.

[0091] The server agrees to establish a connection by sending a SYN-ACK packet and confirms to the client that it has received the client's SYN request.

[0092] (3) The client sends an ACK packet:

[0093] ACK: Acknowledgement flag.

[0094] SEQ=x+1: The client's sequence number continues to increase, indicating the client's next sending sequence number.

[0095] ACK=y+1: The client confirms receipt of the server's SYN packet and adds 1 to the server's sequence number y in the ACK field, indicating that the next data packet sequence number expected from the server is y+1.

[0096] The client confirms the server's SYN packet by sending an ACK packet. At this point, the three-way handshake is completed and the TCP connection is established.

[0097] In this process, SYN indicates a synchronization request for initializing a connection, SEQ indicates the current sequence number of the sender, ACK indicates confirmation of the received sequence number, and ACK=x+1 means that the sender expects the sequence number of the next packet sent by the other party to be x+1.

[0098] In step 3, since the link delays of different links are very different, the link delay of the same device is kept within a certain range without the influence of the network state, so the present invention keeps the link delay of the same device within a certain range to cluster the TCP handshake traffic packets. According to the previous analysis, half of the capture time difference of the last two handshake processes in the TCP three-way handshake data packet can be considered to be approximately equal to the one-way delay from the host device to the NAT router under ideal conditions.

[0099] First, all TCP traffic lists are layered according to TTL, and then the traffic in each layer is clustered according to the host device. The present invention uses the k-means clustering algorithm to perform clustering with delay_time as the characteristic value, and the number of clusters is the device scale inferred in the previous step. After clustering, the inference result of the TCP handshake data packet attribution can be obtained and saved as the label field (label). At the same time, the feature structured data is saved as a four-tuple structure (capture_time, delay_time, ttl and label), where the label field is used as the device identifier in the next stage. After this stage is completed, the data packet array of each TCP handshake of different devices will be obtained, and the delay array classified by device will be further obtained, which will be used for device relationship inference in the next stage.

[0100] Step 4: Based on the assumption that traffic packets with similar time are approximately the same as those experiencing the same network state, an array of associated delays between two devices is constructed, and the correlation coefficient and cosine similarity of the associated array are calculated, which are used as important indicators of the correlation between the two host devices to construct a correlation matrix. Each time, the two devices with the greatest correlation are selected for merging, and the correlation matrix is ​​updated until only one device is left.

[0101] In step four, almost all devices need to send data packets related to establishing communication requests, namely TCP handshake traffic packets. In the past, when inferring the scale of public network equipment, delay covariance is often used as an important indicator of the correlation between two devices. The topological structure of the present invention is similar to that of the public network, so this idea is used here to infer the node relationship, thereby completing the inference of the network topology of the entire deep intranet. In the previous stage, the four-tuple (capture_time, delay_time, ttl and label) of TCP data packets clustered by host can be obtained, and the TCP data packets are divided into arrays classified by host according to label.

[0102] Next, the device nodes will be merged according to the correlation between the two devices. The specific process is as follows:

[0103] (1) In the initialization phase, the NAT router and the target node are first added to the source node set and the target node set respectively, and an empty edge set is initialized.

[0104] (2) In the correlation matrix construction phase, we first need to determine the characteristic array between the two devices, that is, the delay array captured at similar times. The construction of the correlation delay array draws on the basic idea of ​​the "adjacent" group measurement method, such as Figure 5As shown in the figure, based on the delay pairs of all capture times of the two devices within a certain time range, the associated delay array between the two devices is constructed. The horizontal axis represents the time axis of the data packet captured at the NAT router, and the lines at both ends of the horizontal axis represent the one-way delay of device A and device B reaching the NAT device at the corresponding time. The length represents the size of the delay, marked as TX. Figure 5 It can be seen that the two devices have 6 groups of related one-way delays, so the associated delay arrays between the two devices are: A (T2 T3 T5T6T8 T9) and B (T11 T12 T14 T15 T17 T19).

[0105] Secondly, the correlation coefficients and cosine similarities between all devices are calculated based on the associated delay arrays of each pair of devices to construct a correlation matrix. Figure 7 The shared-link and non-shared-link model of the "adjacent" group measurement method is presented, where represents the shared link between node i and node j, and They represent the links from detection node S to node i and from detection node S to node j respectively. Since different links are independent of each other, through the reasoning proof of data formula and the actual verification of past experiments, we can get the relationship as shown in formula (1):

[0106]

[0107] Therefore, in the "adjacent" group measurement method, the more links two nodes share, the greater the delay covariance between them, which means that the correlation between them is higher. This is mainly because when the network load is medium, the background traffic will cause sufficient changes to the queuing delay of the probe packet, and the delay covariance of the shared link is large. In the device relationship inference algorithm proposed in this paper, based on this core idea, the correlation between any two devices in the deep intranet is calculated, and the topological structure between them is further inferred.

[0108] (3) In the most similar device selection stage, when the cosine similarity exceeds the correlation threshold, a group of devices with the largest correlation coefficient are selected for merging.

[0109] (4) During the correlation matrix update phase, after the devices are merged, the correlation matrix must also be updated accordingly.

[0110] (5) Finally, if there is only one node left in the target node set, connect that node to the source node and terminate the inference algorithm, otherwise return to the most similar device selection stage and repeat the process. Fig. 8A is the original network topology, Figure 8B This is the network topology inferred by the present invention.

[0111] By building a simulation topology in EVE-NG and conducting multiple experiments, it can be found that the present invention can accurately infer the network hierarchy, and the average accuracy of inferring the device scale is 80%, and the network hierarchy can be correctly inferred every time. In addition, the present invention also performs well in terms of link integrity, link accuracy, and link recall, which are 0.87, 0.84, and 0.73, respectively. Compared with other methods, the present invention focuses on using NTP and TCP traffic packets for inference, first obtaining a reliable device scale number, and then inferring the device relationship, so it can show better performance and higher accuracy.

[0112] In summary, the present invention creatively proposes a deep-level intranet topology structure inference scheme based on traffic, and innovatively "migrates and applies" the topology structure inference scheme in the public network to a new research object, so that the impact of NAT service can be ignored; and complex problems are split up, first inferring the device scale, clustering the traffic based on the node scale, and then calculating the correlation between two nodes to infer the node relationship, thereby achieving the purpose of effectively inferring the topology structure.

[0113] The inference method proposed by the present invention is based on the traffic at the exit of the NAT router. NAT will map the IP address and port number of the host in the local area network to the public IP address and port number. In view of this situation, the present invention selects the attributes that remain unchanged before and after NAT conversion as features to infer the topological structure, and also combines the characteristics of sending NTP request packets during time synchronization to infer the device scale, and combines the difference in the three-way handshake to calculate the correlation coefficient to infer the node relationship, which can avoid the influence of NAT as much as possible, thereby improving the accuracy of the inference result.

[0114] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the present disclosure. The present disclosure is intended to cover any variations, uses or adaptations of the present disclosure, which follow the general principles of the present disclosure and include common knowledge or customary technical means in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the present disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from the scope thereof.

Claims

1. A method for inferring deep intranet topology based on traffic, characterized in that: The method comprises: Obtain NTP traffic characteristics and TCP traffic characteristics of traffic; Infer the scale of Windows and Linux devices in each layer of the intranet based on NTP traffic characteristics; Based on the TCP traffic characteristics and the scale of Windows devices and Linux devices in each layer of the intranet, the TCP traffic is hierarchically clustered to obtain an array of TCP data packets classified by host devices. Based on the TCP data packet array classified by host device, host device relationship inference is performed to build a deep intranet topology structure.

2. The method according to claim 1, characterized in that Obtain TCP traffic characteristics of traffic, including: Parse the TCP traffic packet and extract fields in the TCP handshake packet, wherein the fields in the TCP handshake packet include: capture_time field, seq_num field, ack_num field, SYN field, ACK field and ttl field; Based on the fields in the TCP handshake packet, each handshake process is integrated to obtain TCP traffic characteristics.

3. The method according to claim 1, characterized in that The NTP traffic characteristics include: the time when the NAT router captures the NTP data packet, the mode of the NTP data packet, the lifetime value of the NTP data packet and the destination IP of the NTP data packet; The inference of the scale of Windows devices and Linux devices in each level of the intranet based on the NTP traffic characteristics includes: The NTP packets are classified by layer using the lifetime value of the NTP packets to obtain the total scale of devices in each layer of the intranet. The devices in each level of the intranet are distinguished based on the destination IP of the NTP data packet, and the scale of Windows devices and Linux devices in the intranet at this level are obtained by combining the total scale of devices in the intranet at this level.

4. The method according to claim 1, characterized in that: The TCP traffic characteristics include: the time when the NAT router captures the TCP data packet, the delay time of the TCP data packet and the survival time value of the TCP data packet; The method performs hierarchical feature clustering on TCP traffic based on TCP traffic characteristics and the scale of Windows devices and Linux devices in each layer of the intranet to obtain an array of TCP data packets classified by host devices, including: According to the lifetime value of TCP packets, TCP packets are classified by layer; Taking the delay time of the TCP data packet as the characteristic value and the total size of Windows devices and Linux devices in each level of the intranet as the number of clusters, the TCP data packets at each level are clustered respectively, and based on the clustering results, an array of TCP data packets classified by host device is generated.

5. The method according to claim 4, characterized in that Based on the array of TCP data packets classified by host devices, host device relationship inference is performed to build a deep intranet topology structure, including: Based on the delay array of the host device, construct an associated delay array between two host devices; wherein the delay array of the host device is an array of TCP data packets classified by the host device; Calculating correlation coefficients between host devices according to the association delay array; The similarity of the delay arrays is calculated, and combined with the correlation coefficients between the host devices, a deep intranet topology structure is constructed.

6. The method according to claim 5, characterized in that Based on the correlation between the host devices, a deep intranet topology structure is constructed by calculating the similarity of the associated delay arrays, including: Calculate the similarity of the delay arrays of the two host devices; When the similarity of the delay arrays is greater than a set threshold and the survival time values ​​of the TCP data packets are the same, two host devices with the largest correlation coefficient between the host devices are selected for merging, the average of the delay arrays of the two host devices is used as the delay array of the merged node, and after globally updating the associated delay arrays, the similarity of the delay arrays of the two host devices is calculated again; When the similarity of the associated delay arrays is greater than a set threshold and the survival time values ​​of the TCP data packets are different, constructing a hierarchical structure of two corresponding host device nodes based on the survival time values ​​of the TCP data packets, and re-executing the calculation of the similarity of the delay arrays of the two host devices; When the similarity of the delay arrays corresponding to a host device or a merged node is less than the set threshold, the host device is connected to a NAT router or a NAT router is used to replace the merged node, and the average value of the delay array of the host device or the delay array involved in the merged node is used as the delay array of the NAT router, and the survival time value of the TCP data packet of the NAT router is set to the survival time value of the TCP data packet of the previous level; When only one node remains after the merger, the node is connected to the NAT router representing the source node.

7. A deep intranet topology inference system based on traffic, characterized in that: The system comprises: A feature extraction module is used to obtain NTP traffic features and TCP traffic features of traffic; The scale analysis module is used to infer the scale of Windows devices and Linux devices in each layer of the intranet based on the NTP traffic characteristics; A feature clustering module is used to perform hierarchical feature clustering on TCP traffic based on TCP traffic features and the scale of Windows devices and Linux devices in each layer of the intranet, and obtain an array of TCP data packets classified by host devices; The structure inference module is used to infer the relationship between host devices based on the TCP data packet array classified by host devices to build a deep intranet topology structure.

8. An electronic device, characterized in that: The electronic device includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the traffic-based deep-level intranet topology structure inference method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by the processor, the method for inferring deep intranet topology structure based on traffic as described in any one of claims 1-6 is implemented.

Images