Firewall signature authentication method and firewall-based anti-network topology discovery system

Abstract

The invention relates to a signature authentication method for a firewall and an anti-network topology discovery system based on a firewall, which belong to the field of computer network security technology. The invention aims to solve the problems of network layer data loss and disorder and high signature authentication overhead in the existing signature authentication method for firewalls. The method of the invention explains the implementation process of the firewall signature authentication scheme based on the message hash chain from two perspectives: the basic process of signature authentication and the hash chain construction and verification scheme. In this process, the three major problems faced by the firewall will be discussed respectively: the network layer data packet loss and disorder problem, the two-way authentication problem and the firewall hash chain signature authentication information organization problem. Based on the signature authentication method of the firewall, an anti-network topology discovery system is designed, which uses a trusted detection filtering module to design three trusted detection filtering schemes based on source IP address, token and hash chain signature authentication to improve the protection capability of the firewall in the anti-network topology discovery process.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer network security, and in particular relates to a signature authentication method for a firewall and an anti-network topology discovery system based on the firewall. Background Art

[0002] With the popularization and development of the internet, people's daily lives and working methods have undergone tremendous changes, and they can no longer do without the help of the internet. However, the emergence of the internet has also brought about a series of network security issues. Hackers and other network attackers often exploit vulnerabilities in existing software and network protocols to conduct illegal activities and obtain improper benefits. Distributed denial of service attacks (DDoS) are one of the main threats currently facing the Internet. Attackers control a large number of zombie hosts to send massive data packets to the target node, consuming the target node's resources and thus affecting its normal operation. According to data from the National Internet Emergency Center, my country suffered more than 152,000 DDoS attacks in 2020.

[0003] Research shows that network attacks are often accompanied by the detection and discovery of network topology structures. For example, in a distributed denial of service (DDoS) attack called a link flooding attack (LFA), attackers typically use network topology detection to obtain key nodes and links in the target network before launching an LFA attack. They then attack these key nodes and links one by one to effectively paralyze the target network.

[0004] Therefore, resisting network topology discovery and cyberattacks has become a crucial research topic in today's era. As the sole "gateway" for communication between internal and external networks, firewalls can inspect all network traffic entering and exiting the internal network, thereby protecting the internal network and preventing cyberattacks. Firewalls are one of the most commonly used technologies for network security protection. By deploying effective technical measures, firewalls can become a powerful tool for resisting network topology discovery, thereby ensuring internal network security and information security. Given that almost all current cyberattacks involve the detection and discovery of network topology, researching key firewall technologies that resist network topology discovery is crucial for improving internal network security.

[0005] Network topology discovery methods are categorized into internal collaborative topology detection and external end-to-end topology detection. Internal collaborative topology detection primarily relies on tools like Traceroute and requires the collaboration of internal network nodes. External end-to-end topology detection, on the other hand, relies on tools like tomography and does not require the collaboration of internal network nodes. Understanding these common network topology discovery methods and their current research status is essential for conducting research on countermeasures against network topology discovery.

[0006] Traceroute is a network exploration tool proposed by Jacobson V in 1989. It works by sending messages with increasing TTL values ​​to a target node. Passing nodes will return ICMP Time Exceeded messages, and the target node will return ICMP Port Unreachable messages, thereby inferring the target network's topology. By probing from multiple sources to multiple targets, Traceroute can reveal path and node information within the target network, thereby inferring the target network's topology. As one of the earliest network exploration tools, Traceroute is now widely used in network performance measurement, troubleshooting, and security auditing.

[0007] Tomography works by treating the network structure as a black box and inferring the target network's topology by measuring end-to-end path metrics, such as link loss rate and link delay, and calculating correlation metrics, such as delay variation and delay variance. Unlike traceroute, tomography does not require the cooperation of network nodes traversed or special probes of the target node. Compared to traceroute, tomography is more robust and scalable, making it particularly suitable for topology discovery in large-scale networks. As a result, tomography has become one of the most widely used network topology discovery tools.

[0008] To defend against malicious probing attacks, firewalls, a tool that audits all network traffic entering and leaving an intranet, have become one of the most commonly used technologies in network security. Firewalls can effectively monitor and block malicious probing traffic, thereby improving network security.

[0009] Regarding firewall technology, trusted probe packet filtering methods can utilize IP addresses, tokens, and hash chain elements as the basis for filtering probe packets. Experts have conducted extensive research on trusted probe filtering based on hash chains. In 1981, Lamport proposed a hash chain-based signature authentication mechanism. This mechanism uses a one-way hash function to construct a hash chain, implementing an identity authentication mechanism similar to a public key cryptosystem. Compared to digital signatures based on traditional public key algorithms, hash chain signature authentication is faster and effectively protects against eavesdropping and replay attacks. In a hash chain scheme, the signer must first initialize and generate a hash chain consisting of N hash blocks and store it locally, which adds additional space complexity. Furthermore, to account for the computational load and storage constraints of both the signer and the authenticator, the hash chain length should not be set too large during system initialization. To address the computational load and space complexity issues of this scheme, Jakobsson (2002) and Coppersmith et al. (2003) studied the optimal time-memory tradeoff for sequential hash chain traversal. Hash chain signature authentication methods also carry the risk of link loss due to packet loss. To solve this problem, Zhang et al. proposed a butterfly hash chain structure in 2005. This structure has certain advantages in payload and packet authentication probability, and is tolerant to packet loss. However, compared with other hash chain structures, this method requires multiple runs of the hash function, which is less efficient. Alshahrani and Traore (2019) and Varsha et al. (2021) respectively proposed their own lightweight solutions for mutual authentication of identities between communicating parties, solving the difficulty that traditional hash chains can only perform one-way authentication. Due to the limited length of the hash chain, if all hash blocks are used up, the signer needs to reinitialize the hash chain and register with the authenticator, which will result in additional time and network overhead. Summary of the Invention

[0010] The present invention aims to solve the problems of network layer data loss and disorder and high signature authentication overhead in existing signature authentication methods for firewalls, as well as the problems of low protection strength in the firewall-based anti-network topology discovery process and low judgment efficiency when monitoring traffic.

[0011] A firewall signature authentication method includes a trusted end signature process and a firewall authentication process;

[0012] The trusted end signature process is as follows:

[0013] The trusted end first configures the negotiated initial sequence number BASE_ID and seed information SEED, that is, the trusted end's sequence number ID1 = BASE_ID, m1 = SEED, and initializes the message count subscript i = 1; then, the sequence number ID is calculated by the hash algorithm.i The body message m of the probe packet i The hash value h(ID i ) and h(m i ), construct the hash chain block HC of this message through hash chain iteration i , and then send the Traceroute detection packet p i =(m i , HC i ) is sent to the intranet node, where (m i , HC i ) is the payload field of the detection packet; then, let i = i + 1 and update ID i With m i , and then use the updated ID i With m i Recalculate the corresponding hash value of the next probe packet to continue a new Traceroute probe;

[0014] The firewall authentication process is as follows:

[0015] The firewall first configures the negotiated initial sequence number BASE_ID, i.e., the firewall's sequence number ID'1 = BASE_ID, and HC'0 = NULL, where NULL represents a null character, and initializes the message count subscript i = 1.

[0016] Traceroute detection packet p is received on the firewall i =(m i , HC i ) and then extract m i , while iterating ID′ i , and according to m i with ID' i With HC' i-1 Construct hash chain block HC' i ; Then the received hash chain block HC i The hash chain block HC' calculated by the firewall itself i Compare; if the two are the same, the verification is passed, the detection packet is released, and the message count subscript i = i + 1 is set, and the update ID is calculated at the same time i ; Otherwise, block and discard the detection data packet;

[0017] During the firewall authentication process, if network layer data packets are lost or out of order, timeout retransmission and / or hash jump processing are performed. The specific process includes the following steps:

[0018] Assume that a trusted probe sends p to the protected intranet. i 、p i+1 、p i+2Three consecutive Traceroute probe packets; in this scenario, the following two scenarios may occur:

[0019] Scenario 1: p i The detection packet successfully reaches the firewall, and the trusted detection end receives the corresponding response packet r sent by the firewall i ; But p i+1 The detection packet is lost before reaching the firewall. Assume that the trusted detection end does not know that the detection packet has been lost and continues to send the third detection packet p i+2 ;

[0020] At this time, the firewall receives the detection packet p i+2 , due to the previous p i+1 Loss: The trusted end updates the hash chain block information, but the firewall fails to update in time, resulting in a mismatch between the hash chain blocks maintained by the trusted end and the firewall, causing the hash chain to be broken. Since the firewall cannot determine its correctness based on the hash chain, the detection packet is eventually discarded by the firewall and the response is rejected, resulting in the trusted end being unable to receive subsequent response packets.

[0021] To address this scenario, a timeout retransmission is implemented: When the trusted end sends a Traceroute probe packet, a timeout timer is immediately started. Only when the trusted end receives a response packet to the probe packet before the timer expires will the trusted end update the hash chain block and related information and send the next probe packet. If the timeout timer expires without receiving a response packet, the trusted probe will immediately resend the current probe packet, keeping the original hash chain block and other related information and TTL value unchanged.

[0022] Scenario 2: Detection Packet p i Successfully reached the firewall, but the response packet r i Lost during transmission;

[0023] For the above scenario, hash jumping is performed: when the firewall receives unexpected illegal Traceroute detection traffic, it will discard the packet and actively return an ICMP host unreachable message; if the trusted end receives the ICMP host unreachable message, it is considered that the response packet of the previous detection packet has been lost; the trusted end is asked to immediately abandon the current detection packet, update the hash block information, and skip the hash block information of this time to ensure that the hash chain block information of the trusted end and the firewall is synchronized. At the same time, it is necessary to ensure that the TTL value of the Traceroute detection packet remains unchanged, and then continue to send the next detection packet.

[0024] Furthermore, during the firewall authentication process, if the hash chain block HC i The hash chain block HC' calculated by the firewall itself iAt the same time as passing the verification, the response packet sent by the firewall to the trusted detection end is symmetrically encrypted before being sent. Only the corresponding trusted end with the symmetric key can decrypt and obtain the internal network topology information in the response packet.

[0025] Furthermore, the method further includes the step of organizing the firewall hash chain signature authentication information, and the specific process is as follows:

[0026] A trusted end information table, trust_list, is established to store signature authentication information for different trusted ends. The data structure is organized using a hash zipper method to improve the firewall's search and matching efficiency when filtering traceroute probe packets from different probes. The firewall distributes specific trusted identities (IDENTIFICATION) to different trusted ends and stores information about different trusted ends in different linked lists. The hash value h(IDENTIFICATION)%MAX_TRUST_NUM is calculated to determine which linked list, under the idx index, the trusted end information is placed in, and the corresponding information is inserted at the end of the linked list. MAX_TRUST_NUM represents the number of linked lists in trust_list.

[0027] Furthermore, update the ID i With m i The calculation formula is as follows:

[0028]

[0029]

[0030] Furthermore, the hash chain block HC of this message is constructed through hash chain iteration i The formula is as follows:

[0031]

[0032] Among them, || represents the splicing operation.

[0033] Furthermore, after receiving the Traceroute detection packet from the trusted end, the firewall iterates ID′ i The formula is as follows:

[0034]

[0035] Among them, ID′ i-1 This is the sequence number corresponding to the previous iteration of the firewall.

[0036] Furthermore, construct the hash chain block HC′ i The formula is as follows:

[0037]

[0038] Furthermore, the serial number ID is calculated using the SHA256 hash algorithm. i The body message m of the probe packet i The hash value h(ID i ) and h(m i ).

[0039] A firewall-based anti-network topology discovery system, the system includes a trusted detection filtering module, the trusted detection filtering module is used to perform trusted detection filtering based on source IP address, trusted detection filtering based on token, and trusted detection filtering based on hash chain signature authentication; the trusted detection filtering module includes a trusted detection filtering submodule based on source IP address, a trusted detection filtering submodule based on token, and a trusted detection filtering submodule based on hash chain signature authentication; wherein,

[0040] Source IP address-based trusted detection filtering submodule: allows the firewall to mark the corresponding source IP addresses as trusted addresses based on the requirements of the trusted detection party, thereby allowing traceroute detection packets received from these IP addresses to pass through;

[0041] Token-based trusted detection filter submodule: This module uses the cookie mechanism to allow the firewall to issue a token with an expiration date to the trusted end. During the validity period, the trusted end can obtain intranet topology information through traceroute detection packets carrying the token.

[0042] Trusted detection filtering submodule based on hash chain signature authentication: The firewall uses a signature authentication method of the firewall to verify whether the detection message is allowed to pass.

[0043] Furthermore, the system also includes a malicious detection and blocking module; the malicious detection and blocking module is used to detect and prevent malicious detection traffic.

[0044] Beneficial effects:

[0045] To prevent the discovery of intranet topology information through network topology, this paper proposes a firewall-based anti-network topology discovery method and system. This system includes a malicious probe detection and blocking module and a trusted probe filtering module. These modules prevent malicious probe traffic from entering without affecting the normal operation of trusted probes, thereby preventing attackers from discovering key nodes and paths within the intranet. The specific advantages of each module are as follows:

[0046] The malicious detection and blocking module in the present invention includes two submodules: firewall basic blacklist and whitelist configuration and firewall custom blacklist configuration. The firewall basic blacklist and whitelist configuration submodule can block common malicious detection traffic by configuring basic firewall rules, while allowing common service ports to ensure that the intranet host can work normally. The firewall custom blacklist configuration submodule allows users to customize blacklist rules based on seven aspects, including source address, destination address, source port, destination port, time range, protocol and behavior, thereby improving the flexibility and scalability of the firewall. Finally, this chapter also analyzes the limitations of the malicious detection and blocking module, pointing out the disadvantages of using only firewall blacklists to resist network topology discovery attacks, that is, simply refusing all data packets of a certain type to enter the intranet will affect the normal operation of the intranet nodes. Although large-scale flooding detection behavior can be prevented by limiting the number of data packets received per unit time, it also has the defect of not being able to cope with long-term slow detection attacks on multiple servers. Therefore, relying solely on a simple blacklist to block malicious detection cannot achieve ideal results.

[0047] The trusted detection filtering module proposes three trusted detection filtering schemes based on source IP address, token, and hash chain signature authentication. The trusted detection filtering submodule based on source IP address uses a simple and efficient mechanism to filter trusted detection packets based on the source IP address. However, this approach is less flexible and cannot meet the needs of the same trusted endpoint using different source IP addresses to perform traceroute detection of the intranet. If the trusted endpoint frequently changes its network environment, this can lead to inefficient firewall trusted configuration and management. The token-based trusted detection filtering submodule emulates the traditional cookie mechanism, enabling traceroute communication between the trusted endpoint and the firewall through tokens with expiration times. This scheme allows the same trusted endpoint to perform traceroute detection of the intranet based on different source IP addresses. However, this scheme offers relatively weak protection because any prober can obtain the pass token, thereby obtaining information about the intranet topology. This makes it ineffective against detection by individual malicious attackers and slow detection by multiple servers over extended periods of time. The trusted detection filter module based on hash chain signature authentication proposes a new firewall signature authentication scheme based on message hash chain. It not only effectively solves the problems of data loss and disorder at the network layer and the high overhead of signature authentication, but also uses the hash zipper method to organize the hash chain signature authentication information of different trusted detection parties on the firewall side, which can quickly match the signature authentication information of different trusted terminals, thereby improving the efficiency of signature authentication. By solving the three major problems of network layer data packet loss and disorder, two-way authentication, and signature authentication information organization, it successfully improves security and reliability, effectively improves the judgment efficiency when monitoring traffic, and at the same time, the present invention improves the overall protection of firewall-based anti-network topology discovery process. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 Diagram of the firewall architecture for anti-network topology discovery.

[0049] Figure 2 The following is the basic flow chart of firewall signature authentication based on message hash chain.

[0050] Figure 3 Construct a scheme graph for the hash chain.

[0051] Figure 4(a) is a diagram of the packet loss detection scenario in the firewall signature authentication scheme based on the message hash chain; Figure 4(b) is a diagram of the packet loss detection solution in the firewall signature authentication scheme based on the message hash chain; Figure 4(c) is a diagram of the response packet loss scenario in the firewall signature authentication scheme based on the message hash chain; Figure 4(d) is a diagram of the response packet loss solution in the firewall signature authentication scheme based on the message hash chain. DETAILED DESCRIPTION

[0052] The main purpose of this invention is to prevent malicious probe traffic from entering without affecting the normal operation of trusted probes, thereby preventing attackers from discovering key nodes and paths in the intranet. Currently, the mainstream tools for network topology detection are Traceroute and tomography. This invention focuses on how to prevent illegal Traceroute detection and provide reliable communication channels for legitimate probes, thereby comprehensively protecting the topological structure information of the internal network at multiple levels and ensuring the security of the internal network.

[0053] In this area, the key technologies for firewalls that resist network topology discovery face two major challenges. The first is how to identify and block malicious probe traffic; the second is how to allow trusted probes to function properly. To address these two issues, this present invention provides a firewall-based method and system for resisting network topology discovery. Specific implementation method one:

[0055] This embodiment is a firewall-based anti-network topology discovery system, such as Figure 1 As shown, it includes:

[0056] 1. Malicious detection and blocking module:

[0057] The Malicious Probe Detection and Blocking module is designed to detect and block malicious probing traffic, thereby preventing exposure of the internal network structure. This module includes the firewall basic blacklist and whitelist configuration submodule and the firewall custom blacklist configuration submodule.

[0058] The Firewall Basic Blacklist and Whitelist Configuration submodule utilizes the Linux IPtables framework to configure basic blacklist and whitelist rules, preventing common malicious network probing and scanning behaviors while allowing normal network traffic to ensure the normal operation of intranet hosts. The Firewall Custom Blacklist Configuration submodule allows users to customize blacklist rules according to their needs, achieving more flexible intranet security protection.

[0059] Firewall basic blacklist and whitelist configuration submodule:

[0060] Compared to other anti-topology discovery technologies, blacklisting and whitelisting are a simple and effective option. By designing and configuring appropriate rules, malicious detection traffic can be isolated from the intranet. A blacklist and whitelist is a set of rules that blocks malicious network traffic and allows safe network traffic.

[0061] The firewall basic black and white list configuration submodule in the present invention is realized by the IPtables framework, and basic firewall rules are configured and deployed. This submodule can identify and prevent various ICMP type scans (such as ping, timestamp-request, timestamp-reply and time-exceeded, etc.), as well as various TCP type scans (such as NMAP sniffing, Xmas Tree scanning, Null scanning and SYN / RST scanning, etc.) and flooding attacks (such as DoS attacks, Ping flooding attacks and TCP SYN flooding attacks, etc.). Specific firewall blacklist representative rules can be seen in Table 1. Whitelist is used to release commonly used service ports, such as 80, 443, 20, 21, 25, 110, 22 and 53, etc., to ensure that services such as HTTP, HTTPS, FTP, SMTP, POP3, SSH and DNS work normally, thereby ensuring the normal operation of intranet. Specific whitelist representative rules can be seen in Table 2.

[0062] Table 1 Firewall basic blacklist rules table

[0063]

[0064]

[0065] Table 2 Firewall basic whitelist rules

[0066]

[0067] Firewall custom blacklist configuration submodule:

[0068] Configuring IPtables firewall blacklist and whitelist rules one by one is inefficient, and it is difficult for ordinary users to customize and deploy personalized rules. Therefore, the present invention proposes a firewall custom blacklist configuration submodule, which allows users to generate and configure custom firewall blacklist rules with simple operations, improving the flexibility and scalability of the firewall.

[0069] The firewall custom blacklist submodule is implemented using the Linux kernel's Netfilter architecture, which contains five hooks: NF_INET_PRE_ROUTING, NF_INET_LOCAL_IN, NF_INET_FORWARD, NF_INET_LOCAL_OUT, and NF_INET_POST_ROUTING.

[0070] The NF_INET_PRE_ROUTING hook is triggered before the packet enters the router and is used to modify the destination IP address or port of the packet.

[0071] The NF_INET_LOCAL_IN hook is triggered after the data packet enters the local host and is used to filter or modify the received data packet;

[0072] The NF_INET_FORWARD hook is triggered when a packet is forwarded locally to another host and is used for policy routing on devices such as routers.

[0073] The NF_INET_LOCAL_OUT hook is triggered after a packet is sent from the local host and is used to filter or modify the sent packet;

[0074] The NF_INET_POST_ROUTING hook is triggered before the data packet is routed out of the local machine and is used for source address translation, etc.

[0075] Specific functions and information are shown in Table 3.

[0076] Table 3 Netfilter hook function information table

[0077]

[0078] The firewall's custom blacklist submodule allows users to customize blacklist rules based on seven aspects: source address, destination address, source port, destination port, time range, protocol, and behavior. For example, by simply setting (any, any, any, any, no, udp, reject), all traceroute attacks targeting large-port UDP packets on the intranet can be blocked. The firewall will inspect each data packet passing through the firewall at the NF_INET_POST_ROUTING hook of Netfilter. If the packet matches a rule in the blacklist, it will be discarded; if it does not match any blacklist rules, it will be allowed to pass. Users can add, delete, and modify rules one by one according to their needs, or import local rules in batches. They can also import existing firewall custom blacklist rules locally. This submodule can set up to 1,000 custom blacklist rules, providing users with a more flexible and customizable firewall rule configuration solution.

[0079] Analysis of the limitations of the malicious detection and blocking module:

[0080] In the malicious detection and blocking module, the firewall's basic blacklist functionality can effectively defend against network topology discovery attacks. For example, directly blocking all UDP packets from entering the intranet can effectively prevent malicious traceroute detection traffic using high-port UDP packets. However, this measure may affect the use of normal UDP network functions such as DNS, NTP, and SNMP on intranet nodes.

[0081] IPtables can address this issue by limiting the number of UDP packets received per unit time, preventing large-scale traceroute flooding. This allows legitimate UDP traffic to flow, allowing other UDP-based services on intranet nodes to function normally. However, this approach cannot effectively prevent probing by individual malicious attackers, nor can it prevent organized adversaries from using multiple servers for extended, slow probing. These attacks can still reveal information about the internal network's topology. Therefore, relying solely on a simple blacklist to block malicious probing is not ideal.

[0082] 2. Trusted Detection Filtering Module:

[0083] The trusted detection and filtering module is designed to address the shortcomings of the malicious detection and blocking module. The malicious detection and blocking module needs to use blacklist marking technology to prohibit any detection packet from passing through in order to effectively resist network topology discovery attacks. However, in some cases, partners and institutions need to use network detection packets to exchange information with the internal network, and this method is obviously not feasible. Therefore, we implemented a trusted detection filtering module based on the Netfilter architecture under the Linux kernel to ensure that relevant partners and institutions can obtain intranet topology information through trusted Traceroute detection. The present invention proposes three trusted detection filtering schemes: trusted detection filtering based on source IP address, trusted detection filtering based on tokens, and trusted detection filtering based on hash chain signature authentication, which are respectively implemented in the trusted detection filtering submodule based on source IP address, the trusted detection filtering submodule based on tokens, and the trusted detection filtering submodule based on hash chain signature authentication. Among them,

[0084] The trusted source IP address-based detection filtering submodule allows the firewall to mark the corresponding source IP addresses as trusted based on the needs of the trusted detection party, thereby allowing traceroute detection packets received from these IP addresses to pass through. This solution simplifies the firewall's filtering process, enabling the firewall to efficiently identify trusted detection parties and allow their detection packets to pass through.

[0085] Token-based trusted detection filtering submodule: Modeled after the traditional cookie mechanism, this module allows the firewall to issue a token with an expiration date to a trusted endpoint. During this time, the trusted endpoint can obtain intranet topology information through traceroute probe packets carrying the token.

[0086] Trusted detection filtering submodule based on hash chain signature authentication: The trusted end uses hash iteration to form a hash chain about the Traceroute message sequence. The firewall determines whether to allow the detection message to pass by verifying the hash chain, while ensuring the message's non-tampering, non-repudiation, reliability, and message integrity and synchronization.

[0087] The processing process of the trusted detection filter submodule based on the source IP address:

[0088] The trusted detection filtering submodule based on source IP addresses filters detection packets based on their source IP addresses. When a trusted detector needs to detect the internal network, it reports the IP address of the detection host to the firewall. The firewall can then mark the corresponding IP addresses as trusted based on the detector's needs, allowing detection packets from these IP addresses to pass through. This allows the firewall to efficiently identify trusted detectors and pass their detection packets, allowing the trusted end to receive the corresponding detection response packets and obtain information about the internal network's topology.

[0089] While the source IP address-based trusted detection and filtering submodule offers simple logic, efficient implementation, and the ability to filter trusted endpoints at the IP address level, it suffers from limited flexibility. If trusted endpoints frequently change network environments, it becomes necessary to constantly identify different trusted source IP addresses for the same trusted endpoint. This results in inefficient firewall trusted configuration, cumbersome management, and complex implementation. Maintaining and updating trusted source IP addresses also consumes significant manpower.

[0090] The token-based trusted detection filter module processes as follows:

[0091] In order to solve the problem of poor flexibility of the trusted detection and filtering scheme based on the source IP address, the present invention simulates the traditional cookie mechanism and proposes a token-based trusted detection and filtering scheme. When the trusted end needs to obtain internal network topology information, it will send a Traceroute detection request to the firewall. When the firewall receives the first detection request from the trusted end, it will release the detection packet and attach a token containing an expiration timestamp in the corresponding response packet (mainly to prevent attackers from obtaining unlimited access to the intranet after obtaining a trusted token. Adding a timestamp can make the token in the attacker's hand invalid after a period of time). Subsequently, the trusted end needs to carry the token in all subsequent Traceroute detection packets for the intranet before it can pass through the firewall to enter the intranet. If the token expires, the trusted end needs to obtain a new token again before it can continue to detect. This token-based trusted detection and filtering scheme can improve the efficiency of the firewall's trusted configuration and eliminate the dependence on specific IP addresses. It is suitable for situations where the trusted end needs to frequently change the network environment.

[0092] While the token-based trusted detection filtering submodule improves the configuration efficiency of the firewall's trusted list by eliminating IP address restrictions and allowing the same trusted endpoint to perform traceroute detection of the internal network using different source IP addresses, this method's protection capabilities are relatively weak. This is because it does not restrict any network node from performing traceroute detection of the internal network. Any network node that initiates a detection request to the firewall can obtain a pass token. Therefore, token-based trusted detection filtering cannot effectively prevent detection by individual malicious attackers, nor can it prevent organized adversaries from using multiple servers for long periods of slow detection. If an unauthorized attacker organizes a large number of hosts to sequentially detect internal network nodes over an extended period of time, they can still obtain information about the entire internal network's topology.

[0093] The processing process of the trusted detection filter module based on the hash chain is as follows:

[0094] Trusted detection and filtering solutions based on source IP addresses suffer from low configuration efficiency, as they prevent the same trusted endpoint from performing traceroute detection on the intranet based on different source IP addresses. Token-based trusted detection and filtering solutions, on the other hand, allow any prober to obtain intranet topology information, resulting in weaker protection and the potential for leakage of intranet topology information. Both of these issues impact the operation of trusted detection endpoints and the security of intranet topology information. Furthermore, as the sole channel for communication between the intranet and the intranet, the firewall must monitor all traffic entering and leaving the intranet. When processing large amounts of network traffic, identification time needs to be shortened and efficiency improved.

[0095] In order to solve the above problems, the present invention proposes a trusted detection and filtering scheme based on hash chain signature authentication. This scheme allows the same trusted end to perform traceroute detection on the intranet based on different source IP addresses, while limiting the trusted end to only those that have configured hash chain initialization information to be able to perform traceroute detection on the intranet, thereby improving the protection strength. In this scheme, the trusted end uses hash iteration to form a hash chain about the message sequence, and the firewall verifies the hash chain to ensure the non-tampering, non-repudiation, reliability of the message, as well as the integrity and synchronization of the message. This scheme based on hash chain technology for iterative processing not only meets the lightweight requirements for the firewall to handle large amounts of traffic, but also can resist IP spoofing, replay attacks and man-in-the-middle attacks, thereby improving the security of the firewall.

[0096] Existing hash chain solutions and their shortcomings: In 1981, Lamport proposed a signature authentication mechanism based on traditional one-way hash functions, similar to public-key cryptography. This protocol utilizes a series of one-way hash functions to form a hash chain to prevent eavesdropping and replay attacks. Compared to traditional public-key digital signatures, hash chain signature authentication is significantly faster. However, hash chain solutions still have many limitations and shortcomings.

[0097] First, it's important to note that the aforementioned hash chain scheme only supports one-way signature authentication, which limits its applicability in certain scenarios. To address this, some researchers have proposed lightweight, two-way authentication schemes based on hash chains. For example, Alshahrani, Traore, and Varsha et al. have each proposed solutions for mutual authentication between communicating parties.

[0098] Second, during the signature authentication process, hash chain schemes require the signer to initialize and generate a hash chain consisting of N hash blocks and store them locally, which adds additional space complexity. Furthermore, considering the computational load and storage limitations of both the signer and the authenticator, the hash chain length should not be set too large during system initialization. Coppersmith et al. and Jakobsson discussed the optimal time-memory tradeoff for sequential hash chain traversal during their research to address the computational load and space complexity issues of this scheme.

[0099] Third, due to the limited length of the hash chain, if all hash blocks are used up, the signer needs to reinitialize the hash chain and register with the authenticator, which incurs additional time and network overhead. To overcome this problem, academics have proposed a self-updating hash chain method that can generate and verify an unlimited number of hash blocks through a single registration, thus avoiding the overhead of repeated initialization.

[0100] Fourth, hash chain signature authentication methods carry the risk of chain breakage due to packet loss. To address this issue, Zhang et al. proposed a butterfly hash chain structure in 2005. This structure offers advantages in payload and packet authentication probability, and is tolerant to packet loss. However, compared to other hash chain structures, this method requires multiple runs of the hash function, making it less efficient.

[0101] Furthermore, most current hash chain research only considers specific data or keys as the basis for building hash chain structures, and does not consider network layer packets as the research object. Furthermore, existing methods also suffer from problems such as two-way authentication and packet loss.

[0102] As the sole channel for communication between internal and external networks, firewalls must monitor all traffic entering and leaving the intranet. When handling large volumes of network traffic, firewalls must be able to quickly and effectively identify and implement a lightweight trusted detection and filtering mechanism. Hash chain technology excels at this task. However, packets passing through the firewall are part of network layer communication data, so using hash chain technology for signature authentication presents the same challenges as previously mentioned hash chain solutions. Furthermore, existing hash chain signature authentication solutions are all one-to-one, making them incapable of handling multiple trusted detection endpoints in firewall scenarios. Therefore, efficiently organizing and matching signature authentication information from different trusted detection endpoints is a challenge that needs to be addressed.

[0103] This paper analyzes the issues with signature authentication schemes based on message hash chains in firewall scenarios and proposes a novel firewall signature authentication scheme based on message hash chains. This paper explains the implementation of this firewall signature authentication scheme from two perspectives: the basic signature authentication process and the hash chain construction and verification scheme. This process also explores three major issues facing firewalls: network layer packet loss and out-of-order processing, bidirectional authentication, and the organization of firewall hash chain signature authentication information.

[0104] More specifically, the specific process of the firewall signature authentication scheme based on the message hash chain of the trusted detection filter submodule based on the hash chain is as follows:

[0105] The basic process of the firewall signature authentication scheme based on the message hash chain is as follows: Figure 2 As shown in the figure, before formal communication between the trusted probe and the firewall, they must first negotiate the initial sequence number BASE_ID and seed information SEED. The initial sequence number BASE_ID serves as the initialization number ID1 of the sequence number mechanism to prevent man-in-the-middle attacks. The seed information SEED, as the body message m1 of the trusted probe's first probe packet, serves as a "stepping stone" for passing firewall authentication.

[0106] The basic process of the trusted end signature process is as follows: The trusted end first configures the negotiated initial sequence number BASE_ID and seed information SEED, that is, ID1 = BASE_ID, m1 = SEED, and initializes the message count subscript i = 1. Then, the sequence number ID is calculated using the SHA256 hash algorithm. i The body message m of the probe packet i The hash value h(ID i ) and h(m i ), and then construct the hash chain block HC of this message through hash chain iterative calculation i , and then send the Traceroute detection packet p i =(m i , HC i ) is sent to the intranet node, where (m i , HC i ) is the payload field of the detection packet. Finally, let i = i + 1, and use formula (1) and formula (2) to calculate the update ID i With m i , and then use the updated ID i With m i Recalculate the corresponding hash value of the next probe packet to continue a new Traceroute probe.

[0107] The basic process on the firewall authentication side is as follows: the firewall first configures the negotiated initial sequence number BASE_ID, that is, sets ID′1=BASE_ID, sets HC′0=NULL (null character), and initializes the message count subscript i=1.

[0108] The serial number of the trusted end is used as ID i Indicates that the firewall's serial number is ID' i Indicates that the firewall end and the trusted end are collectively referred to as the local end.

[0109] Traceroute detection packet p is received on the firewall i =(m i , HC i ) then, according to m i and the local ID' i With HC' i-1 Calculate the hash chain block HC' of the local end i Then the received hash chain block HC i The hash chain block HC' calculated by the firewall itself i If the two are the same, the verification is passed, the detection packet is released, and the message count subscript i = i + 1 is set, and the update ID is calculated at the same time i ; Otherwise, block and discard the detection packet.

[0110] The following details the hash chain construction process of the trusted detection end. Figure 3 As shown. The two communicating parties first negotiate the initial sequence number BASE_ID and seed information SEED, and set m1 = SEED, ID1 = BASE_ID. Then, use formula (1) and formula (2) to determine the sequence of the sequence number ID and the text message m of the detection packet to be sent, and respectively i and ID i Calculate its hash value.

[0111]

[0112]

[0113] Next, h(m i ) and h(ID i ) and the last hash chain block value HC of the original message hash chain i-1 Splice them together and use the SHA256 hash function again to calculate the new hash chain block HC i =h(h(m i )||h(ID i )||HC i-1 )). In this way, a continuous message hash chain is formed, and the iteration formula of the hash chain block is shown in formula (3).

[0114]

[0115] The verification formulas for the hash chain construction scheme of the trusted detection end are shown in formulas (4) and (5). After receiving the Traceroute detection packet from the trusted end, the firewall extracts m i , while iterating ID′ i , calculate the hash chain block HC′ of this end i .

[0116]

[0117]

[0118] Then, by comparing the HC sent by the trusted end in the detection packet i With HC' i , determine whether to release the detection packet.

[0119] Key issues facing firewall signature authentication schemes based on message hash chains include network layer packet loss and out-of-order processing, bidirectional authentication, and the organization of firewall hash chain signature authentication information. The following article will provide a detailed analysis of these three key issues and propose solutions.

[0120] A Aiming at the problem of packet loss and disorder at the network layer, the present invention proposes two solutions, namely timeout retransmission and hash jump. To better illustrate the above solutions, we first assume that a trusted probe sends p to the protected intranet. i 、p i+1 、p i+2 Three consecutive Traceroute probe packets. In this scenario, the following two scenarios may occur:

[0121] (1) Scenario 1: p i The detection packet successfully reaches the firewall, and the trusted detection end receives the corresponding response packet r sent by the firewall i But p i+1 The detection packet is lost before reaching the firewall, but the trusted detection end does not know that the detection packet has been lost and continues to send the third detection packet p i+2 , as shown in Figure 4(a).

[0122] At this time, the firewall receives the detection packet p i+2 But due to the previous p i+1The trusted end updated the hash chain block information, but the firewall failed to update in time, resulting in a mismatch between the hash chain blocks maintained by the trusted end and the firewall, causing the hash chain to break. Since the firewall cannot determine its correctness based on the hash chain, the detection packet is ultimately discarded by the firewall and the response is rejected, resulting in the trusted end being unable to receive subsequent response packets.

[0123] In response to this scenario, the present invention proposes a timeout retransmission mechanism. When the trusted detection end sends a data packet, a timeout timer is added, and the iterative update timing of the hash chain block information is modified. When the trusted end sends a Traceroute detection packet, a timeout timer is immediately started. Only when the trusted end receives a response packet to the detection packet before the timer times out, will the hash chain block and related information be updated and the next detection packet be sent. On the contrary, if the timeout timer expires and no response packet is received, the trusted detection end will immediately resend the current detection packet and keep the original hash chain block and other related information and TTL value unchanged. As shown in Figure 4(b), through the timeout retransmission mechanism, we can effectively solve the problem of detection packet loss in scenario one, avoid hash chain breakage, and thus prevent the trusted end from matching the firewall hash chain block.

[0124] Similarly, the timeout retransmission mechanism effectively addresses the potential out-of-order issues between traceroute probe packets and response packets. This is because the trusted end only updates the hash chain block information and sends the next probe packet after correctly receiving the response packet to the previous probe packet. This essentially avoids the packet out-of-order issues common in traditional networks, ensuring that the hash chain is correctly constructed and verified, and thus guaranteeing the accuracy and integrity of signature authentication.

[0125] (2) Scenario 2: Detection packet p i Successfully reached the firewall, but the response packet r i Lost during transmission. At this time, the trusted detection end with only a timeout retransmission mechanism cannot immediately perceive the loss of the response packet, and can only know that it has not received the corresponding response packet, thus falling into infinite retransmission of the detection packet p i As shown in Figure 4(c).

[0126] To address this scenario, we propose a hash hopping mechanism. When the firewall receives unexpected, illegal Traceroute probe traffic, it discards the packet and proactively returns an ICMP Host Unreachable message. If the trusted end receives an ICMP Host Unreachable message, it assumes that the response packet of the previous probe packet has been lost. In this case, the trusted end immediately discards the current probe packet and updates the hash block information, skipping the current hash block information to ensure that the hash chain block information between the trusted end and the firewall is synchronized. However, the TTL value of the Traceroute probe packet must remain unchanged before the next probe packet is sent, as shown in Figure 4(d). Through the hash hopping mechanism, we can effectively solve the problem of response packet loss.

[0127] B. Regarding the two-way authentication problem in the firewall scenario, the main contradiction is the need to prevent attackers from stealing internal network topology information, while the secondary contradiction is to prevent attackers from disrupting the Traceroute detection results of the trusted detection party. In order to solve the main contradiction, the present invention adopts a firewall signature authentication scheme based on a message hash chain. This scheme requires that the Traceroute detection packet sent by the trusted detection end to the firewall end needs to undergo iterative authentication of the hash chain block before it can be released, thereby avoiding the risk of attackers stealing internal network topology information. At the same time, in order to solve the secondary contradiction, the present invention adopts symmetric key signature authentication to simplify the processing flow and reduce the overhead of signature authentication. The response packet sent by the firewall to the trusted detection end is symmetrically encrypted before being sent. Only the corresponding trusted end with the symmetric key can decrypt and obtain the internal network topology information in the response packet, thereby ensuring the correctness and integrity of the response packet and avoiding the risk of attackers disrupting the Traceroute detection results of the trusted detection party.

[0128] C. In response to the problem of organizing the signature authentication information of the firewall hash chain, the present invention proposes a solution, namely, establishing a trusted end information table trust_list, which is used to store the signature authentication information of different trusted ends, and organizing the data structure through the hash zipper method to improve the search and matching efficiency when the firewall filters the Traceroute detection packets from different detectors. In order to store the information of different trusted ends in different linked lists, the firewall will distribute specific trusted identity identifiers IDENTIFICATION to different trusted ends. By calculating the hash value h(IDENTIFICATION)%MAX_TRUST_NUM, it can be determined in which idx-guided linked list the trusted end information should be placed, and the corresponding information can be inserted at the end of the linked list. Among them, MAX_TRUST_NUM represents the number of linked lists in trust_list, which can be adjusted according to the number of trusted ends to optimize the filtering and matching efficiency.

[0129] This paper analyzes the problems of signature authentication schemes based on message hash chains in firewall scenarios and proposes a new firewall signature authentication scheme based on message hash chains. Its main features and contributions are as follows:

[0130] (1) The present invention adopts two technologies, timeout retransmission and hash jump, to solve the common problems of loss and disorder of network layer data packets, avoid the problem of hash chain breakage, and thus ensure the correctness and integrity of signature authentication.

[0131] (2) In a firewall scenario, the primary conflict of two-way authentication is preventing attackers from stealing internal network topology information, while the secondary conflict is preventing attackers from disrupting the detection results of the trusted detection end. Therefore, we adopt a hash chain signature authentication scheme to resolve the primary conflict, and use symmetric key signature authentication to resolve the secondary conflict, thereby simplifying the processing flow and reducing the overhead of signature authentication.

[0132] (3) To address the problem that the firewall needs to deal with multiple trusted detection terminals, we use the hash zipper method on the firewall side to organize the hash chain signature authentication information of different trusted detection parties, so as to quickly match the signature authentication information of different trusted terminals, thereby improving the efficiency of signature authentication.

[0133] The above examples are merely illustrative of the calculation model and process of the present invention and are not intended to limit the embodiments of the present invention. Persons skilled in the art will readily appreciate that other variations or modifications based on the above description are possible. This list of embodiments is not exhaustive; however, any obvious variations or modifications derived from the technical solution of the present invention remain within the scope of protection of the present invention.

Claims

1. A signature authentication method for a firewall, characterized in that: Including the trusted end signature process and firewall authentication process; The trusted end signature process is as follows: The trusted end first configures the negotiated initial sequence number BASE_ID and seed information SEED, that is, the sequence number of the trusted end , and initialize the message count subscript i=1; then, calculate the sequence number through the hash algorithm The body message of the probe packet Hash value and , construct the hash chain block of this message through hash chain iteration , ,in Indicates the splicing operation; then the Traceroute detection packet Sent to the intranet node, where The payload field of the detection packet; Then, let i=i+1 and update and , and then use the updated and Recalculate the corresponding hash value of the next probe packet to continue a new Traceroute probe; The firewall authentication process is as follows: The firewall first configures the negotiated initial sequence number BASE_ID, which is the sequence number of the firewall. , and at the same time , Indicates a null character and initializes the message count subscript i=1; Traceroute detection packets are received on the firewall side Afterwards, by extracting , while iterating , and according to and and Constructing hash chain blocks ; Then the received hash chain block Hash chain blocks calculated by the firewall itself Compare; if the two are the same, the verification is passed, the detection packet is released, and the message count subscript i=i+1 is set, and the update is calculated at the same time ; Otherwise, block and discard the detection packet; During the firewall authentication process, if network layer data packets are lost or out of order, timeout retransmission and / or hash jump processing are performed. The specific process includes the following steps: Assume that a trusted probe sends a Three consecutive Traceroute probe packets; in this scenario, the following two situations may occur: Scenario 1: The detection packet successfully reaches the firewall, and the trusted detection end receives the corresponding response packet sent by the firewall ;but The detection packet is lost before reaching the firewall. Assume that the trusted detection end does not know that the detection packet has been lost and continues to send the third detection packet. ; At this time, the firewall receives the detection packet , due to the previous Loss: The trusted end updates the hash chain block information, but the firewall fails to update in time, resulting in a mismatch between the hash chain blocks maintained by the trusted end and the firewall, causing the hash chain to be broken. Since the firewall cannot determine its correctness based on the hash chain, the detection packet is eventually discarded by the firewall and the response is rejected, resulting in the trusted end being unable to receive subsequent response packets. To address this scenario, a timeout retransmission is implemented: When the trusted end sends a Traceroute probe packet, a timeout timer is immediately started. Only when the trusted end receives a response packet to the probe packet before the timer expires will the trusted end update the hash chain block and related information and send the next probe packet. If the timeout timer expires without receiving a response packet, the trusted probe will immediately resend the current probe packet, keeping the original hash chain block and TTL value unchanged. Scenario 2: Probe Packet Successfully reached the firewall, but the response packet Lost during transmission; For scenarios one and two, hash jumping is performed: when the firewall receives an unexpected illegal Traceroute probe packet, it will discard the packet and actively return an ICMP host unreachable message; if the trusted end receives an ICMP host unreachable message, it is considered that the response packet of the previous probe packet has been lost; the trusted end is asked to immediately abandon the current probe packet, update the hash block information, and skip the hash block information of this time to ensure that the hash chain block information of the trusted end and the firewall is synchronized. At the same time, it is necessary to ensure that the TTL value of the Traceroute probe packet remains unchanged, and then continue to send the next probe packet.

2. A firewall signature authentication method according to claim 1, characterized in that: During the firewall authentication process, if the hash chain block Hash chain blocks calculated by the firewall itself At the same time as passing the verification, the response packet sent by the firewall to the trusted detection end is symmetrically encrypted before being sent. Only the corresponding trusted end with the symmetric key can decrypt and obtain the internal network topology information in the response packet.

3. A signature authentication method for a firewall according to claim 2, characterized in that: The method further includes the step of organizing the firewall hash chain signature authentication information, the specific process of which is as follows: A trusted end information table, trust_list, is established to store signature authentication information for different trusted ends. The data structure is organized using a hash zipper method to improve the firewall's search and matching efficiency when filtering traceroute probe packets from different probes. The firewall distributes specific trusted identities (IDENTIFICATION) to different trusted ends and stores information for different trusted ends in different linked lists. The trusted end information is placed in the linked list guided by idx by calculating the hash value h(IDENTIFICATION)%MAX_TRUST_NUM, and the corresponding information is inserted at the end of the linked list. MAX_TRUST_NUM represents the number of linked lists in trust_list.

4. A signature authentication method for a firewall according to any one of claims 1 to 3, characterized in that: renew and The calculation formula is as follows: (1) (2)。 5. A signature authentication method for a firewall according to claim 4, characterized in that: After receiving the Traceroute detection packet from the trusted end, the firewall iterates The formula is as follows: (4) in, This is the sequence number corresponding to the previous iteration of the firewall.

6. A signature authentication method for a firewall according to claim 5, characterized in that: Constructing hash chain blocks The formula is as follows: (5)。 7. A signature authentication method for a firewall according to claim 6, characterized in that: During the trusted end signature process, the serial numbers are calculated using the SHA256 hash algorithm. The body message of the probe packet Hash value and .

8. Firewall-based anti-network topology discovery system, characterized by: The system includes a trusted detection and filtering module, which is used to perform trusted detection filtering based on source IP addresses, trusted detection filtering based on tokens, and trusted detection filtering based on hash chain signature authentication; The trusted detection and filtering module includes a trusted detection and filtering submodule based on source IP address, a trusted detection and filtering submodule based on token, and a trusted detection and filtering submodule based on hash chain signature authentication; wherein, Source IP address-based trusted detection filtering submodule: allows the firewall to mark the corresponding source IP addresses as trusted addresses based on the requirements of the trusted detection party, thereby allowing traceroute detection packets received from these IP addresses to pass through; Token-based trusted detection filter submodule: This module uses the cookie mechanism to allow the firewall to issue a token with an expiration date to the trusted end. During the validity period, the trusted end can obtain intranet topology information through traceroute detection packets carrying the token. Trusted detection filtering submodule based on hash chain signature authentication: The firewall uses a firewall signature authentication method described in any one of claims 1 to 7 to verify whether the detection message is allowed to pass.

9. The firewall-based anti-network topology discovery system according to claim 8, characterized in that: The system also includes a malicious detection and blocking module; the malicious detection and blocking module is used to detect and prevent malicious detection traffic.

Images