A network protocol security testing system

Abstract

The application discloses a network protocol security test system, which comprises software components and hardware components. The software components are responsible for protocol flow editing, test data generation and detection, test result analysis and saving, and the hardware components provide a channel for protocol data transmission. The software components comprise a protocol analysis module, a protocol editing module, a test sequence generation module, a protocol simulation module, a result display module and a hardware control interface module. The hardware components comprise a data bus module, a traffic generation module, a traffic detection module and a network interface module. The test system uses conversion conditions to describe the operation mechanism of the protocol, supports multiple simulation test modes, improves the efficiency of test analysis, and is suitable for testing different types of protocols. The protocol formal analysis supports standard protocols and user customized protocols. Different test sequences and test sets are constructed by changing the condition parameters, which improves the pertinence and comprehensiveness of the test.

Description

Technical Field

[0001] This invention relates to the field of network security testing, and in particular to a network protocol security testing system. Background Technology

[0002] A network protocol is a set of rules that both parties communicating on a network must adhere to. It's a collection of communication rules between all devices connected to a network (computers, switches, routers, firewalls, etc.), defining the format that information transmitted during communication must use and the meaning of these formats. Therefore, a network protocol ultimately manifests as the format of data packets transmitted over the network. Common network protocols include IP (Internet Protocol), TCP (Transmission Control Protocol), and UDP (User Datagram Protocol).

[0003] In recent years, with the continuous development of computer network technology, various new network protocols have emerged. Network protocols may contain vulnerabilities in protocol model building, protocol structure design, protocol implementation, and verification. These vulnerabilities can be exploited by attackers, causing the protocol entity to deviate from the requirements of the specification during operation, or allowing attackers to access the network or device where the protocol entity resides without authorization and commit damage. The goal of network protocol security testing is to test whether the protocol can resist various known or unknown network attacks, thereby judging the security performance of the protocol. Therefore, discovering potential protocol security vulnerabilities through testing and identifying existing vulnerabilities in network protocols early on helps reduce network security risks and effectively reduce the costs of subsequent protection and maintenance.

[0004] To address the above issues, the existing solutions mainly include:

[0005] (1) White-box testing by developers is used to check for potential problems in the protocol. Due to the complexity of network protocols, white-box testing often cannot balance test quality and efficiency.

[0006] (2) Black-box testing is conducted by testers. Testers create test cases according to the protocol specifications and finally determine whether there are any problems based on the test results. Testing has a certain degree of blindness and it is difficult to construct comprehensive test cases.

[0007] (3) Designing a dedicated test system for a specific protocol requires professional personnel to analyze and process the test results, making it difficult to achieve batch and automated testing and affecting the efficiency of testing.

[0008] (4) General-purpose testing systems only support testing of common standard protocols and are incompatible with non-standard protocols. Regarding protocol editing, there is a lack of flexible methods for handling non-standard protocols. In terms of protocol simulation, it is impossible to create test procedures or generate test data for non-standard protocols on existing platforms. Summary of the Invention

[0009] To address the aforementioned technical problems, this invention provides a network protocol security testing system, aiming to improve the comprehensiveness of analysis and testing, increase testing efficiency, enable the reuse of testing processes, and enhance the degree of automation in testing.

[0010] To achieve the above objectives, the technical solution of the present invention is as follows:

[0011] A network protocol security testing system includes software components and hardware components. The software components are responsible for editing the protocol flow, generating and detecting test data, and analyzing and saving test results. The hardware components provide channels for transmitting and receiving protocol data. The software components and hardware components are connected and communicate through a data bus module. The software components control the operation of the hardware components to realize the testing functions.

[0012] The software components include a protocol analysis module, a protocol editing module, a test sequence generation module, a protocol simulation module, a result display module, and a hardware control interface module;

[0013] The protocol analysis module performs formal analysis on the protocol and protocol entities, representing the protocol's attributes and transformation mechanisms as a set of several nodes and the transition behaviors between nodes;

[0014] The protocol editing module uses the analysis results from the protocol analysis module to model the protocol's operating mechanism. By constructing a directed protocol graph, it graphically displays the state transition path of the protocol during operation.

[0015] The test sequence generation module analyzes the test scenario set composed of the protocol directed graph, extracts the state transition condition parameters of each edge, and uses a depth-first traversal algorithm to traverse the protocol directed graph to generate a test case set.

[0016] The protocol simulation module tests the input test sequences and outputs the test results for each test sequence;

[0017] The results display module records and summarizes the test process information to form test report data, which users can analyze and find problems.

[0018] The hardware control interface module establishes a data transmission channel between the software components and the hardware components;

[0019] The hardware components include a data bus module, a traffic generation module, a traffic detection module, and a network interface module.

[0020] In the above scheme, the protocol editing module constructs a directed graph of the protocol through nodes and transition conditions to provide a visual description of the protocol; nodes are used to describe all states of the protocol operation, and directed edges are used to describe the transition conditions that cause the states to occur.

[0021] In the above scheme, the protocol editing module uses a visual, drag-and-drop description method to build a directed protocol graph. Specific steps include:

[0022] (1) Add network protocol entities to participate in the test, and configure the protocol entity attributes, i.e., the config parameters;

[0023] (2) Set the prerequisites for starting the test, including test port status availability detection, link status detection, and path detection information;

[0024] (3) Add the corresponding nodes and edit the node attributes according to the description of the protocol specification;

[0025] (4) According to the protocol specification, use directed edges to connect the corresponding nodes and edit the attributes of the directed edges, i.e., the link parameters.

[0026] In the above scheme, the protocol simulation module includes a data capture submodule, a data storage submodule, a data detection submodule, a network protocol attack construction submodule, a data generation submodule, and a data sending submodule;

[0027] The data capture submodule employs a timed query mechanism to call the hardware control interface to obtain test data from the network and then filters the test data.

[0028] The data storage submodule receives data from the data capture submodule, stores the data in a data list, and adds a timestamp, marking the data as received data; test data is stored in a test queue for subsequent analysis.

[0029] The data detection submodule extracts protocol data from the data capture submodule using a timed query method, and detects the format and content of the data according to the test sequence. It processes the data queue stored in the data storage submodule, extracts the data, and matches it according to the exchange attribute of the current test stage. If the match is successful, the test will proceed to the next stage. If the match is unsuccessful, it continues to extract data from the data queue and detect it until a special case occurs and the detection stops.

[0030] The network protocol attack construction submodule, combining the encapsulation and inheritance features of object-oriented programming, encapsulates the parameters of each attack faced by the protocol into a unique attack object, with the attack target and attack operation parameters as members of the object. The resulting description is: attack =<enable,basic_attr,target,act> The testing system combines the protocol generated by the protocol analysis module and the attack generated by the network protocol attack construction submodule, using them together as input to the data generation submodule to create test cases that meet different testing scenarios. During the protocol simulation process, the testing system configures the attack to execute different attack tests.

[0031] The data generation submodule: Based on the exchange attribute and combined with the output of the network protocol attack construction submodule, it creates test data. This test data contains the address information of the protocol entities participating in the test and can be transmitted normally over the network.

[0032] The data sending submodule calls the hardware control interface to transmit the test data created by the data generation submodule to the hardware component, thereby sending protocol data to the protocol entity under test.

[0033] In the above scheme, the protocol simulation module uses a timed polling mechanism to detect anomalies caused by security testing. During the execution of the test case, the test system sends timed polling data packets to probe the protocol entity's protocol operation status, thereby promptly detecting anomalies caused by sending test data. Specifically, after the protocol status reaches a certain node, the timed polling data packet detection function belonging to that node is started according to the set parameters. If the protocol entity does not reply within a specified time, or if the response content of the timed polling data packet does not meet the requirements of the built-in security attributes, it indicates that the protocol of the device under test has an anomaly, a prompt is given, and the response data and current status information are saved for analysis of the cause.

[0034] In the above scheme, when the protocol simulation module performs simulation testing, the test system can execute different test processes according to the configuration of the mode parameter in the protocol entity attribute config.

[0035] When mode = client / server, the test system and the protocol entity under test interact according to the content specified in the test sequence. The roles played by both parties are determined by the type parameter in exchange, and it is determined whether the test system should perform a request operation or a response operation.

[0036] When mode=observer, for each test sequence, the test system extracts the received data from the data queue, compares it with the exchange parameter of the test node, and if the data is valid, it saves the data to the data queue and marks it as received data; then it continues to extract the received data from the data queue and compare it with the next node, until all nodes have been compared.

[0037] In a further technical solution, when the test system executes a request operation, it creates test data based on the stream parameter in the exchange, saves the data to the data queue, marks the data as data to be sent, and finally calls the data sending submodule to send the data out.

[0038] When the test system performs a response operation, it extracts the received data from the data queue and analyzes and matches it one by one according to the stream parameter in the exchange. If a match is found, the data is saved to the data queue and marked as received data. After the data matching judgment, a timeout judgment is performed. If a timeout occurs, the processing of the test queue is stopped. If no timeout occurs, the system continues to match the next received data until a valid data is found or a timeout occurs.

[0039] In the above scheme, the software component obtains the test data sent by the protocol entity participating in the test through the traffic detection module, records the time of receiving each test data, converts and stores the data, and provides it for use by the subsequent test module; one or more test case data generated by the software component are injected into the network where the protocol entity under test is located through the traffic generation module.

[0040] In the above scheme, the flow generation module includes a sending state machine and a sending circuit, wherein the sending circuit includes a flow control circuit, a sending RAM and a packet encapsulation circuit;

[0041] The sending state machine includes a start state and a stop state. It is the core of the traffic generation module and controls the entire traffic transmission process. The traffic control circuit stores the transmission control parameters, including the data transmission mode and transmission speed. The sending RAM stores test data created by the software components, which is read by the packetization circuit. The packetization circuit packages the data into a data format that can be transmitted over the network for use by the network interface module. The traffic detection module acquires the network protocol data packets sent by the target protocol entity, processes the data according to filtering conditions, and saves the data that meets the conditions for use by the software components.

[0042] In the above scheme, the traffic detection module includes a receiving state machine, a filtering storage circuit, a DDR interface circuit, and DDR memory;

[0043] The receiving state machine is the core of the traffic detection module, controlling the execution of the traffic detection module;

[0044] The filtering and storage circuit compares the data according to the filtering parameters and saves the data that meets the requirements to the DDR memory; the filtering parameters include source IP address, destination IP address, protocol number, source port, and destination port;

[0045] Network test data enters the hardware component through the network interface module. This data is first cached in DDR memory. The hardware component performs read and write operations on the DDR memory through the filtering storage circuit and the DDR interface circuit.

[0046] The network protocol security testing system provided by the present invention, through the above technical solution, has the following beneficial effects:

[0047] (1) This invention uses a directed graph to describe the state transition mechanism of the protocol and dynamically displays the operation process of the protocol; it models the operation mechanism of the protocol and graphically displays the state transition path of the protocol during operation; when problems are found, the protocol state and various transition conditions can be improved by dragging and other visual methods, thereby quickly improving the protocol function.

[0048] (2) The created protocol directed graph forms a test scenario set, where each directed path represents a unique test scenario. By analyzing the test scenario set, the state transition condition parameters of each edge are extracted, and a depth-first traversal algorithm is used to traverse the protocol directed graph to generate a test case set. It can select to execute some or all test sequences as needed, and can also adjust the execution order of test cases to execute tests that meet specific scenarios.

[0049] (3) Perform formal analysis on the protocol, summarizing the protocol attributes and transition actions into a set of nodes and transition behaviors between nodes. Use a depth-first traversal algorithm to traverse the directed graph of the protocol to generate a set of test cases. Then, process the set of test cases to obtain a set of test sequences to ensure the comprehensiveness of the test.

[0050] (4) Combining the encapsulation and inheritance features of object-oriented programming, the parameters of each attack faced by the protocol are encapsulated into a unique attack object, with the attack target, attack operation, and other related parameters as members of the object. By changing the test parameters, various different test scenarios can be constructed, and it is also convenient to add new attack test types, further improving the comprehensiveness of the test.

[0051] (5) During protocol simulation, an initiator and responder are assigned for each state occurrence, dividing the test system's operating mode into client / server mode and observer mode. This allows for flexible changes in testing methods, enabling the execution of tests for specific states and objects, thus improving the relevance of the tests.

[0052] (6) It can export the designed protocol data format to the storage medium and import the data format of the previous design, which is convenient for design reuse; each protocol message exists in the form of an independent file, and a built-in protocol message set can be built, which is convenient for the expansion and updating of the protocol message set. It can store the test sequence in the form of a file to the hardware for the next test. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0054] Figure 1 This is a schematic diagram of a network protocol security testing system disclosed in an embodiment of the present invention.

[0055] Figure 2 This is a schematic diagram of the protocol simulation module structure;

[0056] Figure 3 This is a schematic diagram of the protocol simulation test process;

[0057] Figure 4 This is a schematic diagram of the client / server mode simulation test process;

[0058] Figure 5 This is a schematic diagram of the simulation test process for the monitoring mode. Detailed Implementation

[0059] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0060] This invention addresses the lack of a unified testing system in the field of traditional network protocol security testing. By integrating the characteristics of protocol conformance testing and protocol security testing, it proposes a network protocol security testing system. The system uses a graphical approach to display the protocol's operational mechanism and a formal approach to describe the actions of protocol entities and the security issues faced by the protocol. Without applying various attack actions, it can detect potential vulnerabilities in the protocol based on protocol conformance testing theory. If various attack actions are applied, by treating these attack actions as normal inputs to the protocol, it simulates various attack behaviors during protocol operation, thereby testing the protocol's security.

[0061] like Figure 1As shown, the test system includes software components and hardware components. The software components are responsible for editing the protocol flow, generating and detecting test data, and analyzing and saving test results. The hardware components provide channels for transmitting and receiving protocol data. The software components and hardware components communicate through a data bus module. The software components control the operation of the hardware components to realize the test functions.

[0062] I. Software Components

[0063] The software components include a protocol analysis module, a protocol editing module, a test sequence generation module, a protocol simulation module, a result display module, and a hardware control interface module.

[0064] 1. Protocol Analysis Module

[0065] The protocol analysis module performs formal analysis on the protocol and protocol entities, representing the protocol's attributes and transformation mechanisms as a set of nodes and the transition behaviors between nodes, as described below:

[0066] (1) Node

[0067] node(i) =<num,name,describe> Let represent the i-th state of the protocol, 1≤i≤n, where n represents the number of protocol states. Here, num represents the node's index, 1≤num≤n; name is a string representing the node's name; and describe is a string providing a brief description of the node.

[0068] (2) Directed edge

[0069] `link(i,j) = {node(i), node(j), action}` represents the connection from node(i) to node(j), describing the conditions required for a transition from state i to state j. Here, 1 ≤ i ≤ n, 1 ≤ j ≤ n, i ! = j, and n represents the number of protocol states.

[0070] `action = {exchange_1, exchange_2, ..., exchange_m}` is the set of interactions between protocol entities. `exchange_m` represents the m-th interaction required to transition from state i to state j. At any given time, only one interaction action is executed.

[0071] exchange=<role,type,stream> , represents an interaction between protocol entities, where:

[0072] `role` is an enumeration type representing the protocol entity that performs the current interaction. It has two possible values: `tester` (the test system) and `DUT` (the object under test).

[0073] `type` is an enumeration type that indicates whether the interaction is initiated or responded to by the `role`. It has two possible values: `sponsor` (initiator) and `respondent` (responder).

[0074] stream=<layer_1,layer_2,layer_3,……,layer_m> This describes the structure of the protocol data, indicating that during interaction, the protocol data sent by one protocol entity to another consists of m layers of data. The protocol data is stored in a hierarchical manner, with each layer using a dynamic array to store the content of the next layer, facilitating the addition and deletion of data.

[0075] layer=<field_1,field_2,field_3,……,field_m> This describes the structure of protocol data at a certain layer, indicating that the layer consists of m fields.

[0076] field=<name,length,defaultvalue> This represents the basic structure of a field in the protocol. Here, `name` is a string representing the field's name; `length` is an integer representing the field's length; and `defaultvalue` is a dynamic array describing the default value stored in the field.

[0077] For standard network protocols and private user protocols, the test system can describe them using the above method and store them in an XML template for later retrieval and analysis.

[0078] (3) By traversing the directed graph, the test system obtains the protocol operation flow consisting of nodes and directed edges. These operation flows can be described as: protocol = {link(1,2), link(2,3), ...}.

[0079] (4) Set the properties of the protocol entity. This property can be described as: config=<tester_name,DUT_name,tester_addr,DUT_addr,mode> `tester_name` is a string describing the name of the test system as the protocol entity. `DUT_name` is a string describing the name of the object under test as the protocol entity. `mode` is an enumeration type representing the working mode of the test system, with two possible values: client / server and observer.

[0080] 2. Protocol Editing Module

[0081] Based on the results of the formal analysis, the protocol editing module assigns test roles (DUT and tester) to the protocol entities participating in the test. When editing the protocol, the initiator and responder responsible for each state change are specified according to the protocol specification. The initiator and responder correspond to the DUT or Tester mentioned above.

[0082] The protocol editing module uses the analysis results from the protocol analysis module to model the protocol's operational mechanism and graphically display the state transition paths during operation. By analyzing the directed graph of the protocol, users can identify existing vulnerabilities and make targeted improvements to the protocol. The protocol editing module defines two elements to construct the directed graph of the protocol for visual description: nodes and transition conditions.

[0083] Nodes are used to describe all states of the protocol's operation, mapping each state during the protocol's operation to a node in a directed graph. At any given time, a protocol entity can only be in one of these states.

[0084] Directed edges are used to describe the transition conditions that cause a state change. To achieve a state change, two nodes may need to interact multiple times, which is achieved by sending and receiving protocol data conforming to the protocol specification. Therefore, the transition condition includes one or more protocol data. Each protocol data consists of multiple protocol messages. The length and data of each field in the protocol message can be edited according to the protocol specification, filling the message with specific content. The protocol editing module can export the designed protocol data format to storage media and import previously designed data formats, facilitating design reuse. Each protocol message exists as an independent file, and a built-in protocol message set can be built, facilitating the expansion and updating of the protocol message set. Each protocol header can be stored in visual description formats such as XML and JSON, making it easy to understand the protocol format and content. These files can be encrypted and stored; the encryption and decryption process is entirely controlled by the software, and the user cannot know the specific definition of the message, protecting sensitive information in the protocol messages.

[0085] According to the protocol specification, the transformation conditions that can be edited by editing directed edges include:

[0086] (1) Packet sending rules, including timed packet sending (sending data packets at certain time intervals, the time interval for sending packets needs to be set in milliseconds) and data replay (sending certain protocol data that meet the filtering conditions multiple times, the filtering conditions include protocol type, field value, etc., the number of replays and the replay time interval in milliseconds need to be set); by using data replay rules, data replay tests and DDoS attack tests can be performed.

[0087] (2) Packet receiving rules, including timeout retransmission (if no response is received within a specified time, the previous protocol data will be retransmitted, and the specified time is in seconds) and delay waiting (if no response is received within a specified time, the delay will be in seconds).

[0088] (3) Periodic polling mechanism: periodically send detection protocol data to detect the status of the peer protocol entity.

[0089] Based on the analysis results from the protocol analysis module, the protocol editing module uses a visual, drag-and-drop method to create a directed protocol graph. Specific steps include:

[0090] (1) Add network protocol entities to participate in the test, and configure the protocol entity attributes, i.e., the config parameters;

[0091] (2) Set the prerequisites for starting the test, including information such as test port status availability detection, link status detection, and path detection;

[0092] (3) Add the corresponding nodes and edit the node attributes according to the description of the protocol specification;

[0093] (4) According to the protocol specification, use directed edges to connect the corresponding nodes and edit the attributes of the directed edges, i.e., the link parameters.

[0094] 3. Test sequence generation module

[0095] To increase test coverage, it is necessary to test all states of the protocol in order to effectively discover security vulnerabilities in the protocol under different states.

[0096] The protocol editing module creates a directed graph that forms a set of test scenarios, where each directed path represents a unique test scenario. The test sequence generation module analyzes the set of test scenarios, extracts the state transition condition parameters for each edge, and uses a depth-first traversal algorithm to traverse the directed graph to generate a set of test cases.

[0097] The test case collection contains a large number of different test cases, each describing a different test scenario. The test case collection includes test case templates and test case instances. Test case templates are created based on the protocol format in the protocol editing module.

[0098] Test case instances are obtained by modifying the initial test case data according to configured change rules. First, following the protocol message format description and the set change rules, field values ​​are created for the fields to be tested. Then, each field value is processed individually to obtain all test cases corresponding to the initial test cases. These field values ​​are categorized as normal and abnormal. The change rules include incrementing, decrementing, random, time-based changes, and data within a specified range. Each time a change rule is implemented, a specific value is assigned to each field to be tested, thus forming a unique test case.

[0099] The final set of test cases constitutes the test sequence. It allows for the selection and execution of some or all test sequences as needed, and the execution order of the test cases can be adjusted to execute tests that meet specific scenarios. The test sequence can be stored in hardware as a file for later use in subsequent tests.

[0100] 4. Protocol Simulation Module

[0101] The protocol simulation module consists of a data capture submodule, a data storage submodule, a data detection submodule, a network protocol attack construction submodule, a data generation submodule, and a data transmission submodule, such as... Figure 2 As shown. The protocol simulation module takes one or more test sequences as input and outputs the test results for each test sequence.

[0102] The data capture submodule employs a timed query mechanism to call the hardware control interface to obtain test data from the network and then filters the test data. Filtering criteria include protocol entity attributes (network address), protocol matching (filtering out data related to the protocol under test), and defined regular expressions.

[0103] The data storage submodule receives data from the data capture submodule, stores the data in a data list, and adds a timestamp, marking the data as received. Test data is stored in a test queue for later analysis. Test case data is stored using a first-in, first-out (FIFO) approach to facilitate problem analysis and localization when anomalies are discovered.

[0104] The data inspection submodule extracts protocol data from the data capture submodule using a timed query method. The acquired protocol data includes all test data from the first node to the end of the test. Based on the test sequence, it inspects the format and content of the data. It processes the data queue stored in the data storage submodule, extracts data, and matches it against the exchange attribute of the current test phase. If a match is successful, the test proceeds to the next phase. If a match fails, it continues to extract and inspect data from the data queue until a special condition occurs (timeout, user-initiated stoppage, etc.).

[0105] The network protocol attack construction submodule combines the encapsulation and inheritance features of object-oriented programming to encapsulate the parameters of each attack faced by the protocol into a unique attack object. The attack target, attack operations, and other related parameters are treated as members of the object, resulting in the description: attack =<enable,basic_attr,target,act> The testing system combines the protocol generated by the protocol analysis module and the attack generated by the network protocol attack construction submodule, using both as input to the test case generation module to create test cases that meet different testing scenarios. During protocol simulation, the testing system configures the attack to execute different attack tests. The parameters of the attack are as follows:

[0106] (1) enable: Whether the network protocol attack construction submodule is enabled. enable is a boolean value. If true is selected, the test case data will be modified according to the module configuration parameters; otherwise, the test case data will not be changed.

[0107] (2) basic_attr represents the basic attributes of the attack target, described as: basic_attr =<no,name,decribe> Where no represents the sequence number of the target, no≥1; name is a string representing the name of the target; decribe is a string representing descriptive information about the target.

[0108] (3) target =<protocol,content> This describes the relevant information about the target of the attack. The protocol and content parameters are combined to determine the final attack target. That is, if the protocol and the content specified by the content are both satisfied, then it can be confirmed as the final attack target.

[0109] (3.1) protocol =<name,describe> This indicates the specific protocol targeted by the attack. `name` is a string representing the protocol's name, which is unique within the system; `describe` is a string providing a descriptive description of the protocol.

[0110] (3.2)content=<deststream|destfields> The attack describes the data of the attacked protocol entity, and tests are conducted from both the perspective of the overall protocol data and the perspective of individual fields within the protocol data. In each test, one approach is selected to construct the attack test data.

[0111] deststream=<offset,streamdata> This represents a data segment. `offset` is a 16-bit integer representing the offset from the beginning of the protocol data header. `streamdata` is an array storing single-byte data, representing the data prepared for the attack.

[0112] destfields=<sn’,destfield_1,destfield_2,……,destfield_n> , represents the set of fields that are being attacked.

[0113] in:

[0114] sn' =<sn_1,sn_2,……,sn_n> , is a set of sn indices, recording the sn of all selected destfields. sn' is a string, with each sn indice separated by a punctuation mark ",".

[0115] destfield=<sn,targetdata> This represents the data designed for the sn-th field of the protocol. sn represents the field number, targetdata represents the new data to be set, and 0 <= sn <= the total number of fields.

[0116] (4)act =<handle,effect> This indicates the operations performed during the attack test and their potential impact.

[0117] (4.1) The handle describes the operation performed by the attack. These operations include: protocol data replay, protocol data tampering, protocol session reordering, etc. The data source for the handle operation is the content in the target, and the object of the operation is the protocol in the target.

[0118] (4.2) effect represents the state of the protocol entity after an attack is performed. effect is an enumeration value that describes the impact of an attack on the attacked protocol entity. The values ​​of effect include normal protocol interaction, protocol interaction timeout, protocol interaction interruption, and protocol interaction restart.

[0119] Data generation submodule: Based on the exchange property and combined with the network protocol attack construction submodule output, it creates test data. This data contains the address information of the protocol entities participating in the test and can be transmitted normally over the network.

[0120] Data transmission submodule: Calls the hardware control interface to transmit the test data created by the data generation submodule to the hardware component, thereby sending protocol data to the protocol entity under test.

[0121] The protocol simulation module detects whether the protocol operation conforms to the expected specifications and whether there are other security issues through the interaction of protocol entities. During each interaction, test data is first generated based on the conversion conditions, and then the test data is processed using an attack model to form a security test case for that test instance. Anomaly alarms and abnormal message detection are implemented during the test. The protocol simulation module completes the security test by executing a large number of test sequences.

[0122] After initiating the protocol simulation test, the system first checks the prerequisites for starting the test. The test can only officially begin if these prerequisites are met; otherwise, an alarm will be issued and logged in the background log. These prerequisites include testing port availability, link status, and path detection. Next, the validity of the test sequence will be checked. When checking data in the link, if invalid parameters are found, a prompt will be given, the directed edge representing the relevant conversion condition will be highlighted on the graphical interface, and the test will stop.

[0123] Protocol simulation test process as follows Figure 3 As shown, the protocol simulation test module performs tests sequentially according to the test sequence. It constructs test data based on the test cases in the test sequence, sends data to the protocol entity under test, or responds to test data from the protocol entity under test. Before each test, the user can select one or more test sequences. During the execution of each test sequence, when receiving test data, the test data is extracted, parsed, and its summary information is extracted. This summary information is then saved as a summary of the test data to the data queue. When sending test data, the data generation submodule creates the test data, and the data sending submodule sends the test data, saving the test data and its summary information to the data queue. The data summary information includes the network address, the protocol type used, the timestamp of reception, and the timestamp of transmission.

[0124] During protocol simulation testing, the test system uses the data sending submodule to send test data to the protocol entity under test based on the `exchange` parameter, or extracts received protocol data from the data storage submodule, and compares it with the parameters in the conversion conditions. If data violating the `exchange` attribute is found, the test stops or continues to wait for data according to the conversion conditions. If the comparison results of requests and responses during the test indicate that the current interaction meets the requirements of the `exchange` attribute, execution continues until an error occurs or the test ends.

[0125] The protocol simulation module uses a timed polling mechanism to detect anomalies caused by security testing. During test case execution, the test system sends timed polling data packets to probe the protocol entity's operational status, thereby promptly detecting anomalies caused by sending test data. Specifically, after the protocol status reaches a certain node, the timed polling data packet detection function for that node is activated according to set parameters. If the protocol entity does not respond within a specified time, or if the response content of the timed polling data packet does not meet the requirements of the built-in security attributes, it indicates that the protocol of the device under test has an anomaly, a prompt is given, and the response data and current status information are saved for analysis of the cause.

[0126] During protocol simulation testing, if an anomaly is detected, the test is stopped, and the node and directed edge where the anomaly occurred are marked on the directed graph. The test system not only saves all recently sent and received data packets, but also saves the attributes of each node and the transition conditions between nodes, and classifies all data and attributes according to the order of testing.

[0127] Anomalies discovered during testing may be caused by a single piece of test data or a combination of multiple pieces of test data. To accurately pinpoint the cause, the testing system saves all recently sent and received test data, as well as the test parameters for each test, including security attribute parameters and attack model parameters. Through comprehensive backtracking analysis of these parameters and data, the message and attack model parameters that generated the anomaly are identified.

[0128] Depending on the `mode` parameter configuration in the protocol entity attribute `config`, the test system can execute different test procedures during protocol simulation. When `mode = client / server`, the simulation test procedure is as follows: Figure 4 As shown. In this mode, the test system and the protocol entity under test interact according to the content specified in the test sequence. The type parameter in the exchange determines the roles played by both parties and determines whether the test system should perform a request manipulation or a response operation.

[0129] When the test system executes a request operation, it creates test data based on the stream parameter in the exchange, saves the data to the data queue, marks the data as data to be sent, and finally calls the data sending submodule to send the data out.

[0130] When the test system executes a response operation, it retrieves the received data from the data queue and analyzes and matches it one by one according to the stream parameter in the exchange. If a match is found, the data is saved to the data queue and marked as received data. After the data matching judgment, a timeout check is performed. If a timeout occurs, processing of the test queue stops. If no timeout occurs, matching the next received data continues until valid data is found or a timeout occurs.

[0131] When mode = observer, the simulation test process is as follows: Figure 5 As shown. In this mode, for each test sequence, the test system retrieves the received data from the data queue, compares it with the exchange parameter of the test node, and if the data is valid, saves the data to the data queue and marks it as received data. Then, it continues to retrieve received data from the data queue and compare it with the next node, until all nodes have been compared.

[0132] To test specific states of a protocol individually, testing can be divided into single-state testing and multi-state testing. In single-state security testing, transition rules are used to quickly bring the protocol to a certain state through normal interaction, and then various security tests are performed in that state. This mode can be applied to localized testing, progressively detecting security vulnerabilities in each protocol state. In multi-state security testing, the test system simultaneously initiates attack models from multiple transition conditions to examine the protocol's operational state. Multi-state security testing can be applied to systemic testing of the protocol's resistance to attacks during operation.

[0133] To locate the anomaly, the devices involved in the test are first restored to their initial state through normal message interaction based on the parameters in the conversion conditions. Then, a single-state mode is used to locate the anomaly step by step. If no anomaly is found, the attack model that occurs when the anomaly occurs is applied one by one and tested in sequence. This process is repeated until the attack model that causes the anomaly is identified.

[0134] To eliminate interference from previous tests, the test equipment is restored to its initial state before each test. Specific interactive data is then sent according to the parameters in the transition conditions to restore the protocol entity to its initial state. A periodic polling mechanism is used to monitor the restoration progress, and the results are reflected in the directed graph.

[0135] The testing system has four test ports, which can test four protocol entities simultaneously.

[0136] 5. Result Display Module

[0137] The results display module shows test process information for users to analyze and find problems. It records and summarizes test process information to form test report data. Test process information includes the test execution process, data exchanged between the two parties, configuration attributes, key attributes of test cases, protocol attack settings, etc., providing possible causes, and finally generating a security test report containing all test information.

[0138] The main information displayed includes:

[0139] ●Protocol entity information config=<tester_name,DUT_name,tester_addr,DUT_addr,mode> ;

[0140] ● Protocol interaction information link(i,j) and the exchange and attack information of this link;

[0141] ● The total number of test cases currently being executed;

[0142] ● The number of test cases that were successfully tested in the currently executing test cases;

[0143] ● The number of test cases that failed in the currently executing test cases;

[0144] ● Summary information of all currently executed test cases, including state transition order, protocol entity address, and protocol type;

[0145] ● When a test case is selected, detailed decoding information and raw hexadecimal data for that test case will be displayed.

[0146] 6. Hardware control interface module

[0147] The hardware control interface module establishes a data transmission channel between the software and hardware. It includes a driver submodule and an interface control submodule. The driver submodule is a data interface designed according to the hardware characteristics. It transmits the data from the interface control submodule to the hardware, thereby controlling the hardware's operation. The interface control submodule calls the driver submodule to read data from and transmit data to the hardware. The protocol simulation module sends data to the hardware or reads data from the hardware by calling the hardware control interface module.

[0148] II. Hardware Components

[0149] The hardware component consists of multiple modules, including a data bus module, a traffic generation module, a traffic detection module, and a network interface module. The software component obtains test data sent by the protocol entities participating in the test through the traffic detection module, records the reception time of each test data, transforms and stores the data, and provides it for use by subsequent test modules; the software component generates one or more test case data, which are then injected into the network where the protocol entity under test resides through the traffic generation module.

[0150] 1. Data bus module, designed using VHDL language, uses FPGA to simulate the communication mechanism of standard CPCI bus to transmit data between hardware and software components.

[0151] 2. Flow generation module, including a sending state machine and a sending circuit, wherein the sending circuit includes a flow control circuit, a sending RAM and a packet encapsulation circuit.

[0152] The sending state machine, including start and stop states, is the core of the traffic generation module, controlling the entire traffic transmission process. The traffic control circuit stores transmission control parameters, including the data transmission mode and speed. The sending RAM stores test data created by software components, which the packetization circuit can read from. The packetization circuit packages the data into a data format suitable for network transmission, for use by the network interface module. The traffic detection module acquires network protocol data packets sent by the target protocol entity, processes the data according to filtering conditions, and saves data that meets the criteria for use by the software components.

[0153] 3. Flow detection module, including receiving state machine, filtering and storage circuit, DDR interface circuit and DDR memory.

[0154] The receiver state machine is the core of the traffic detection module, controlling its execution.

[0155] The filtering and storage circuit compares the data according to the filtering parameters and saves the data that meets the requirements to DDR memory. The filtering parameters include source IP address, destination IP address, protocol number, source port, and destination port.

[0156] Network test data enters the hardware components via the network interface module, where it is first cached in DDR memory. The hardware components then perform read and write operations on the DDR memory through filtering storage circuitry and DDR interface circuitry.

[0157] 4. Network interface module, including two sets of gigabit network transceivers and SFP ports. The network interface module is the external interface of the test system, connecting the test system with the protocol entity under test, realizing the reception of protocol data and the transmission of test case data packets; the network interface module connects to external transceiver devices, which can be wired network devices or wireless network devices.

[0158] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A network protocol security testing system, characterized by, The software component is responsible for protocol flow editing, test data generation and detection, test result analysis and saving, and the hardware component provides a channel for protocol data transmission and reception; the software component and the hardware component are connected through a data bus module for communication, and the software component controls the operation of the hardware component to realize the test function; The software component includes a protocol analysis module, a protocol editing module, a test sequence generation module, a protocol simulation module, a result display module, and a hardware control interface module; The protocol analysis module performs formal analysis on protocols and protocol entities, and represents the attributes and conversion mechanism of the protocol as a collection of nodes and transition behaviors between the nodes; The protocol editing module uses the analysis results of the protocol analysis module to model the operation mechanism of the protocol, and displays the state transition path of the protocol during operation through the construction of a protocol directed graph; The test sequence generation module analyzes the test scenario set composed of the protocol directed graph, extracts the state transition condition parameters of each edge, uses a depth-first traversal algorithm to traverse the protocol directed graph, and generates a test case set, and finally the test case set constitutes a test sequence; The protocol simulation module tests the input test sequence and outputs the test result of each test sequence; The result display module records and summarizes the test process information to form test report data for user analysis and problem finding; The hardware control interface module establishes a data transmission channel between the software component and the hardware component; The hardware component includes a data bus module, a traffic generation module, a traffic detection module, and a network interface module; The protocol simulation module includes a data capture submodule, a data storage submodule, a data detection submodule, a network protocol attack construction submodule, a data generation submodule, and a data sending submodule; The data capture submodule uses a timing query mechanism to call the hardware control interface to obtain test data from the network and filters the test data; The data storage submodule receives data from the data capture submodule, stores the data in a data list, and adds a timestamp, and the data is marked as received data; The test data is stored in a test queue for subsequent analysis; The data detection submodule extracts protocol data from the data capture submodule in a timing query manner, detects the format and content of the data according to the content of the test sequence, processes the data queue stored in the data storage submodule, extracts the data, and matches the data according to the exchange attribute of the current test stage; if the matching is successful, it indicates that the test will enter the next stage; if the matching is unsuccessful, the data is continuously extracted from the data queue and detected until the special situation of timeout or user stopping detection occurs. The network protocol attack building submodule: combining the encapsulation and inheritance features of the object-oriented idea, encapsulating the parameters of each attack faced by the protocol into a unique attack object, taking the attack target and attack operation parameters as the members of the object, and obtaining the description result as: attack=<enable, basic_attr, target, act>; the test system combines the protocol generated by the protocol analysis module and the attack generated by the network protocol attack building submodule, and takes them as the inputs of the data generation submodule, so as to create test cases meeting different test scenarios; In the protocol simulation process, the test system configures the attack to perform different attack tests; The data generation submodule: creating test data according to the exchange attribute and in combination with the output of the network protocol attack building submodule, wherein the test data contains the address information of the protocol entities participating in the test and can be normally transmitted on the network; The data sending submodule: calling the hardware control interface, transmitting the test data created by the data generation submodule to the hardware component, and thus sending protocol data to the protocol entity to be tested.

2. The network protocol security testing system of claim 1, wherein, The protocol editing module constructs a protocol directed graph through nodes and conversion conditions, and visually describes the protocol; the nodes are used to describe all states of the protocol running, and the directed edges are used to describe the conversion conditions causing the states to occur.

3. The network protocol security testing system of claim 1, wherein, The protocol editing module uses a visual and drag-and-drop description method to establish a protocol directed graph, and the specific steps include: (1) adding the network protocol entities participating in the test, and configuring the protocol entity attribute, i.e., the config parameter, of the protocol entity; (2) setting the prerequisites for starting the test, including the test port state availability detection, the link state detection, and the pass information; (3) adding the corresponding nodes according to the description of the protocol specification, and editing the node attribute; (4) connecting the corresponding nodes using the directed edges according to the description of the protocol specification, and editing the attribute, i.e., the link parameter, of the directed edge.

4. The network protocol security testing system of claim 1, wherein, The protocol simulation module uses a timing polling mechanism to detect the abnormality caused by the security test; during the execution of the test case, the test system sends a timing polling data packet for detecting the protocol running state of the protocol entity, so as to timely find the abnormality caused by sending the test data; Specifically, after the protocol state reaches a certain node, the timing polling data packet detection function belonging to the node is started according to the set parameter; if the protocol entity does not reply within the specified time, or the response content of the timing polling data packet does not meet the requirements of the built-in security attribute, it is indicated that the protocol of the device to be tested is abnormal, a prompt is given, and the response data and the current state information are saved for analyzing the cause.

5. The network protocol security testing system of claim 1, wherein, The protocol simulation module can perform different test processes during the protocol simulation according to the configuration of the mode parameter in the protocol entity attribute config. When mode=client / server, the test system and the tested protocol entity interact according to the content specified by the test sequence, and the type parameter in the exchange determines the roles played by the two parties and judges whether the test system should perform a request operation or a response operation currently; When mode=observer, for each test sequence, the test system extracts the received data from the data queue, compares the data with the exchange parameter of the test node, and if the data is valid data, saves the data to the data queue and marks the data as received data; then continues to extract the received data from the data queue and compares the next node until all nodes are compared.

6. The network protocol security testing system of claim 5, wherein, When the test system performs a request operation, the test data is created according to the stream parameter in the exchange, the data is saved to the data queue, and the data is marked as sent data, and finally the data sending submodule is called to send the data out; When the test system performs a response operation, the received data is extracted from the data queue, and the stream parameter in the exchange is analyzed one by one according to the stream parameter; if the data is matched, the data is saved to the data queue, and the data is marked as received data; after the data matching judgment, the timeout judgment is performed, if the timeout, stop processing the data queue; if not, continue to match the next received data until the valid data is found or the timeout.

7. The network protocol security testing system of claim 1, wherein, The software component obtains the test data sent by the protocol entity participating in the test through the traffic detection module, records the time of receiving each test data, converts and stores the data, and provides the data for subsequent test modules; one or more test case data generated by the software component is injected into the network where the tested protocol entity is located through the traffic generation module.

8. The network protocol security testing system of claim 1, wherein, The traffic generation module includes a sending state machine and a sending circuit, wherein the sending circuit includes a traffic control circuit, a sending RAM and a packet circuit; The state of the sending state machine includes a start state and a stop state, which is the core of the traffic generation module and controls the whole traffic sending process; The traffic control circuit saves the sending control parameters, including the sending mode and the sending speed of the data; The sending RAM stores the test data created by the software component for the packet circuit to read out various test data; The packet circuit packs the data into a data format that can be transmitted on the network for the network interface module to use; the traffic detection module obtains the network protocol data packet sent by the target protocol entity, processes the data according to the filtering condition, saves the data meeting the condition, and provides the data for the software component to use.

9. The network protocol security testing system of claim 1, wherein, The traffic detection module includes a receiving state machine, a filtering storage circuit, a DDR interface circuit and a DDR memory; The receiving state machine is the core of the traffic detection module and controls the execution of the traffic detection module; The filtering storage circuit compares the data according to the filtering parameters and saves the data meeting the requirements to the DDR memory; The filtering parameters include source IP address, destination IP address, protocol number, source port and destination port; The network test data enter the hardware component through the network interface module, and the data are first buffered into the DDR memory; the hardware component realizes the read-write operation of the DDR memory through the filtering storage circuit and the DDR interface circuit.

Images