Vehicle-mounted Ethernet SOME / IP abnormal flow detection system and method, and medium

Abstract

The invention discloses a vehicle-mounted Ethernet SOME / IP abnormal flow detection system and method, and a medium, and belongs to the field of information security, and the system comprises a central gateway which manages the overall process of an abnormal detection rule; the rule base is used for receiving and storing an anomaly detection rule issued by the central gateway; the domain controller compares and matches the communication data according to the anomaly detection rule set in the rule base, discovers unmatched abnormal behaviors, and gives an alarm to the central gateway; the method comprises the following steps: a central gateway generates a global anomaly detection rule through a rule generation algorithm and stores the global anomaly detection rule in a rule base; then capturing and analyzing a service discovery stage message, dynamically updating a global anomaly detection rule according to message information and a rule generation algorithm, and storing the global anomaly detection rule in rule libraries of different domain controllers according to correlation; and finally, the domain controller executes anomaly detection based on the updated anomaly detection rule. The medium is used for storing the method; the method is high in dynamic adaptability, efficient in rule management, high in detection accuracy and high in robustness.

Description

Technical Field

[0001] The present invention belongs to the technical field of information security, and particularly relates to an in-vehicle Ethernet SOME / IP abnormal traffic detection system and method, and a medium. Background Art

[0002] With the rapid development of the automotive industry, the number of electronic control units (ECUs) in modern cars has increased sharply, and the internal network structure of vehicles has become increasingly complex. In recent years, the automotive industry has been developing rapidly towards intelligence and networking, and intelligent technologies related to automobiles have become a research hotspot. The application of technologies such as in-vehicle infotainment (IVI) and advanced driving assistance system (ADAS) has greatly enriched people's driving experience. However, traditional automotive general bus standards such as CAN (Controller Area Network) are difficult to meet the development needs of intelligent vehicles due to bandwidth issues. Against this background, in-vehicle Ethernet has emerged. The SOME / IP (Scalable service-Oriented MiddlewarE over IP) protocol in in-vehicle Ethernet can well meet the efficient and reliable communication needs between different ECUs. As a service-oriented middleware protocol, it has been widely used in in-vehicle networks. By providing dynamic service discovery, data serialization, and a flexible transmission mechanism, it has greatly improved the data interaction efficiency between various systems inside the vehicle. However, the SOME / IP protocol specification does not define security mechanisms, such as authentication or encryption schemes. With the increase in the complexity of communication networks and data traffic, abnormal situations may occur in communication data, such as packet loss, latency, and network attacks, posing a severe challenge to the safety and reliability of automobiles. In an automotive communication system, once abnormal data appears due to an attack, it may lead to function failure, system crash, or even safety accidents.

[0003] Due to the service-oriented characteristics of SOME / IP, its network traffic is highly dynamic and unpredictable compared to traditional automotive protocols (such as the CAN bus protocol). Therefore, a more suitable and efficient anomaly detection method is urgently needed. Currently, the detection of SOME / IP abnormal traffic mainly relies on machine learning models to train normal communication patterns to identify attacks, but there are still the following problems: (1) It is difficult to establish a stable normal behavior baseline. The highly dynamic communication mode of the SOME / IP protocol makes it difficult for the detection system to accurately model, affecting the detection accuracy. (2) The detection model lacks flexibility. Static models are difficult to adapt to the dynamic changes of in-vehicle services, reducing the applicability and generalization ability. (3) Single-point deployment has security risks. Once the detection node fails or is attacked, there is no distributed detection mechanism to support it, affecting the system's robustness.

[0004] Ding et al. published "Suricata-based SOME / IP intrusion detection system design and implementation" (Suricata-based SOME / IP intrusion detection system design and implementation[C] / / Fourth International Conference on Mechanical, Electronics, and Electrical and Automation Control (METMS2024). SPIE, 2024, 13163: 1867-1873). This study proposed a Suricata-based SOME / IP protocol anomaly detection system. However, due to the lack of consideration of the dynamic nature of SOME / IP services and the extensibility of detection rules, it has the disadvantages of being difficult to adapt to dynamic registration, subscription, and service instance changes and being difficult to meet robustness and extensibility. Summary of the Invention

[0005] To overcome the above-mentioned disadvantages of the prior art, the object of the present invention is to provide an in-vehicle Ethernet SOME / IP abnormal traffic detection system, method and medium. By utilizing the two-stage communication characteristics of SOME / IP and adopting a Domain Controller architecture, the central gateway captures and parses SOME / IP-SD messages to obtain the service status of different Domain Controllers in real time. Subsequently, based on the Suricata rule format, the central gateway dynamically changes the detection rules according to the service status and distributes them to the corresponding Domain Controllers. Each Domain Controller, as a distributed detection node, uses the corresponding rules to perform abnormal detection on SOME / IP communication messages according to the received rule status to identify abnormal behaviors. The present invention not only realizes the dynamic expansion of abnormal detection, but also improves the accuracy of abnormal detection through the automatic generation and automatic update of abnormal detection rules. At the same time, the distributed abnormal detection of Domain Controllers improves the robustness and effectively enhances the security protection ability of the in-vehicle network.

[0006] To achieve the above object, the technical solution adopted by the present invention is:

[0007] An in-vehicle Ethernet SOME / IP abnormal traffic detection system, comprising: a central gateway (CGW), a rule library and a Domain Controller;

[0008] The central gateway (CGW): As the core control node of the in-vehicle network, it is responsible for managing the overall process of abnormal detection rules. Its specific tasks include: capturing and parsing SOME / IP protocol service discovery phase (SOME / IP-SD) messages in real time to extract key information; based on the parsing results, dynamically generating abnormal detection rules that conform to the Suricata rule format, and adjusting the rule status in real time according to network behaviors to ensure its accuracy and applicability; finally, distributing the generated detection rules and status lists to the rule libraries corresponding to each Domain Controller.

[0009] The rule library: As the storage node in the system, it is responsible for receiving and storing the abnormal detection rules issued by the central gateway (CGW).

[0010] The Domain Controller: As the execution node in the system, it compares and matches the communication data according to the abnormal detection rule set in the corresponding rule library. Once an abnormal behavior that does not match the abnormal detection rule is found, it alarms the central gateway (CGW) in a timely manner.

[0011] A method for detecting abnormal traffic of in-vehicle Ethernet SOME / IP, comprising the following steps:

[0012] Step 1: The Central Gateway (CGW) generates global anomaly detection rules through a rule generation algorithm and stores them in the rule libraries of different domain controllers according to their content relevance;

[0013] Step 2: The Central Gateway (CGW) captures and parses the Service Discovery Phase (SOME / IP-SD) messages;

[0014] Step 3: The Central Gateway (CGW) dynamically updates the global anomaly detection rules generated in Step 1 according to the Service Discovery Phase (SOME / IP-SD) message information parsed in Step 2 by using the rule generation algorithm, and distributes them to the corresponding rule libraries of the domain controllers;

[0015] Step 4: The Domain Controller performs anomaly detection based on the updated anomaly detection rules in Step 3.

[0016] The anomaly detection rules described in Step 1 include SOME / IP service location detection rules, SOME / IP message header detection rules, and / or request-response type detection rules. Among them, the service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, that is, there is a correlation.

[0017] The SOME / IP service location detection is based on the communication matrix of the vehicle SOME / IP protocol to generate the detection of the service location anomaly of the SOME / IP message for matching the source IP, source port, destination IP, destination port of the SOME / IP protocol and preliminarily screening the SOME / IP traffic. The rule generation steps are as follows:

[0018] Step 1.1: Initialize the address storage table addr_table, store the source IP, source port, destination IP, and destination port of the legal SOME / IP protocol, and initialize the traversal variable entry;

[0019] Step 1.2: Based on the source IP, source port, destination IP, and destination port stored in Step 1.1 for matching, traverse the address storage table addr_table to check whether the source IP, source port, destination IP, and destination port of the SOME / IP message match the data stored in the address storage table addr_table. If the match is successful, return "match successful"; otherwise, continue traversing;

[0020] Step 1.3: If no match is found after the traversal in Step 1.2 ends, return "address anomaly".

[0021] After the detection of the SOME / IP service location passes, the SOME / IP message header is detected. The steps for generating the SOME / IP message header detection rules are as follows:

[0022] Step 1.4: Extract the key fields of the SOME / IP message, including the message ID, protocol version, interface version, service ID, message length, and message type. At the same time, set the expected ranges for the most recent message ID and message length;

[0023] Step 1.5: Based on the key fields in Step 1.4, check whether the message ID belongs to a replay attack, whether the protocol version and interface version match, whether the service ID matches, and whether the message length exceeds the set range. If all detections pass, return the type of the message;

[0024] Step 1.6: Based on the detection results in Step 1.5, return the detected replay attack, protocol or interface version error, illegal service ID, or message length anomaly.

[0025] After the SOME / IP message header detection passes, the message type is returned. When the message type is the request-response type, the request and response detection is entered. The steps for generating the request-response type detection rules are as follows:

[0026] Step 1.7: Extract the key fields of the SOME / IP message, including the source IP, destination IP, source port, destination port, request ID, message ID, message type, and timestamp. Establish a request list (requestList) to record and manage the request messages to be matched;

[0027] Step 1.8: Store the request message in the request list (requestList) established in Step 1.7, and traverse the request list (requestList) to match the response message. If the response times out, it is determined as a "timed-out response message"; if the source IP, destination IP, port, request ID, and message ID of the request message and the response message match, it is determined as "no anomaly";

[0028] Step 1.9: Based on the determination results in Step 1.8, return the corresponding anomaly results.

[0029] In Step 2, the central gateway (CGW) captures and parses the service discovery phase (SOME / IP-SD) messages of the SOME / IP protocol in real time, extracts the key information, including the service status, communication target, and service type. According to the parsing results, it is judged whether there is a new service or a service status change in the current network, and the service status table is updated. The specific steps are as follows:

[0030] Step 2.1: Initialize the service status list (service_status_table) to store and manage the status information of SOME / IP services, parse the received Service Discovery (SOME / IP-SD) messages, and extract relevant fields, including service ID, instance ID, event group ID, IP address, port, protocol, and Time-To-Live (TTL).

[0031] Step 2.2: Update the service status based on the message type parsed in Step 2.1:

[0032] If the message type is "Find", it means the client is looking for a service, and the status is not updated;

[0033] If the message type is "Offer", check if the service is a new service. If so, add it to the service status list (service_status_table); otherwise, update the Time-To-Live (TTL) value to maintain the service status;

[0034] If the message type is "Subscribe", it means the client subscribes to a service, and the status is not updated;

[0035] If the message type is "Stop", check the Time-To-Live (TTL) value. If the Time-To-Live (TTL) is 0, mark the service as stopped;

[0036] Step 2.3: Output the updated service status list (service_status_table) based on the update result in Step 2.2.

[0037] The specific steps of Step 3 are as follows:

[0038] When the Central Gateway (CGW) determines that the Service Discovery (SOME / IP-SD) message information is a new service according to the service status list, the Central Gateway (CGW) dynamically generates anomaly detection rules based on the Suricata rule format and rule generation algorithm;

[0039] When the Central Gateway (CGW) determines that the Service Discovery (SOME / IP-SD) message information is an existing service and the service status has changed according to the service status list, the Central Gateway (CGW) updates the status of the existing rules;

[0040] Subsequently, the Central Gateway (CGW) distributes the dynamically generated detection rules and the latest status of the rules to the corresponding Domain Controller according to content relevance, so as to achieve distributed anomaly detection. Among them, the service identifier of the anomaly detection rule is associated with the service identifier managed by the Domain Controller, that is, there is relevance.

[0041] The specific steps of step 4 are as follows: The Domain Controller captures SOME / IP communication data in the domain in real time, performs anomaly detection on the captured SOME / IP packets based on the anomaly detection rule set in the latest rule library. If it is determined to be abnormal, the Domain Controller reports the abnormal information to the Central Gateway (CGW) and generates an alarm log.

[0042] The anomaly detection process is as follows:

[0043] Step 4.1, the Domain Controller first monitors the network traffic to determine whether it is a SOME / IP protocol packet. If the detected traffic is a SOME / IP protocol packet, it enters step 4.2 for processing; if it does not conform to the SOME / IP protocol specification, the traffic is directly discarded.

[0044] Step 4.2, after confirming in step 4.1 that the traffic is a SOME / IP protocol packet, further check the IP address and port number in the packet, and match the anomaly detection rules in the rule library. If the IP address or port number does not match, the DomainController discards it and writes it into the alarm log; if the IP address and port number match successfully, the DomainController performs a detailed check on the key fields of the message header of the SOME / IP packet. The key fields include message ID, protocol version, interface version, service ID, and message length. If there is a mismatch in the message header fields, the DomainController writes the abnormal information into the warning log; if the message header fields match successfully, the DomainController classifies the packet according to the message type field of the SOME / IP packet. The SOME / IP protocol supports multiple message types, including Request message and Response message. The Domain Controller determines the specific type of the packet according to the message type in the message header. If the packet type does not match the message type, the Domain Controller writes the abnormal information into the warning log.

[0045] Step 4.3, make a judgment according to the message type in step 4.2:

[0046] If the packet is a Request message, the Domain Controller checks the legitimacy of the request. When the service ID, method ID, and instance ID fields do not match the anomaly detection rules, the Domain Controller writes the abnormal information into the warning log.

[0047] If the message is a response message, the Domain Controller verifies whether the response status code, the returned data field, and the anomaly detection rule match. If they do not match, the Domain Controller writes the anomaly information to the warning log.

[0048] A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements an in-vehicle Ethernet SOME / IP anomaly traffic detection method.

[0049] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0050] 1. The present invention utilizes the SOME / IP-SD message parsing mechanism to achieve real-time monitoring of the service status, and dynamically adjusts the anomaly detection rules according to the changes in the service status, thereby improving the adaptability and real-time performance of the detection system.

[0051] 2. The present invention centrally manages the detection rules through the Central Gateway (CGW) and distributes the corresponding rules to each Domain Controller, effectively reducing the complexity of rule configuration and improving the flexibility and scalability of rule management.

[0052] 3. The present invention automatically generates and updates the anomaly detection rules according to the actual operation of the SOME / IP service, avoiding the problem of decreased detection accuracy caused by fixed rules in the traditional static detection model.

[0053] 4. Adopting a distributed detection architecture, each Domain Controller independently performs anomaly detection. Even if a certain node fails, other nodes can still continue to detect, ensuring the security and robustness of the entire in-vehicle network.

[0054] In summary, the present invention has the advantages of strong dynamic adaptability, efficient rule management, high detection accuracy, and high robustness. The present invention proposes a dynamic rule matching anomaly detection scheme based on the in-vehicle Ethernet SOME / IP protocol. This scheme utilizes the two-stage communication characteristics of SOME / IP. Under the domain controller architecture, the central gateway (CGW) captures and parses the messages in the service discovery phase (SOME / IP-SD), and obtains the status of different SOME / IP services in real time. At the same time, combined with the Suricata anomaly detection rule format, SOME / IP anomaly detection rules for each domain controller are dynamically generated according to the SOME / IP service status. The central gateway (CGW) serves as the central controller, responsible for rule generation and distribution. Different domain controllers serve as detection nodes, storing the anomaly detection rules of the corresponding services. Finally, through the two-stage linkage mechanism of the SOME / IP protocol, the automatic generation and automatic status update of SOME / IP anomaly detection rules are realized, thereby improving the dynamic scalability and accuracy of the detection model. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 FIG. is the architecture diagram of the in-vehicle Ethernet SOME / IP abnormal traffic detection system of the present invention.

[0056] Figure 2 FIG. is the flowchart of rule generation of the central gateway (CGW) in steps 1-3 of the abnormal traffic detection method of the present invention.

[0057] Figure 3 FIG. is a screenshot of an example of generating an anomaly detection rule in an embodiment of the present invention.

[0058] Figure 4 FIG. is the anomaly detection flowchart of the domain controller of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0059] The present invention will be described in detail below with reference to the accompanying drawings.

[0060] See Figure 1 , an in-vehicle Ethernet SOME / IP abnormal traffic detection system, comprising: a central gateway (CGW), a rule library, and a domain controller;

[0061] The Central Gateway (CGW): As the core control node of the in-vehicle network, it is responsible for managing the overall process of anomaly detection rules. Its specific tasks include: capturing and parsing SOME / IP protocol service discovery phase (SOME / IP-SD) messages in real time, and extracting key information; based on the parsing results, dynamically generating anomaly detection rules that conform to the Suricata rule format, and adjusting the rule status in real time according to network behavior to ensure its accuracy and applicability; finally, distributing the generated detection rules and status lists to the rule libraries corresponding to each domain controller.

[0062] The rule library: As the storage node in the system, it is responsible for receiving and storing the anomaly detection rules issued by the Central Gateway (CGW).

[0063] The Domain Controller: As the execution node in the system, it compares and matches the communication data according to the set of anomaly detection rules in the corresponding rule library. Once an abnormal behavior that does not match the anomaly detection rules is found, it alerts the Central Gateway (CGW) in a timely manner.

[0064] See Figure 2 , a method for detecting SOME / IP abnormal traffic in in-vehicle Ethernet, includes the following steps:

[0065] Step 1: The Central Gateway (CGW) generates global anomaly detection rules through a rule generation algorithm, and stores them in the rule libraries of different domain controllers according to their content relevance, including SOME / IP service location detection rules, SOME / IP message header detection rules, and / or request-response type detection rules. Among them, the service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, that is, there is relevance.

[0066] The SOME / IP service location detection rule defines the communication relationship between the in-vehicle SOME / IP network server and the client for the communication matrix of the vehicle SOME / IP protocol. Based on the communication matrix, first generate an anomaly detection for detecting the service location of SOME / IP messages, which is used to match the quadruple (source IP, source port, destination IP, destination port) of the SOME / IP protocol, and preliminarily screen SOME / IP traffic. The specific rule generation steps are as follows:

[0067] Step 1.1: Initialize the address storage table addr_table to store legal SOME / IP communication quadruples, and initialize the traversal variable entry.

[0068] Step 1.2: Based on the source IP, source port, destination IP, and destination port stored in Step 1.1, perform matching. Traverse the address storage table addr_table to check whether the source IP, source port, destination IP, and destination port of the SOME / IP message match the data stored in the address storage table addr_table. If the match is successful, return "Match successful"; otherwise, continue traversing.

[0069] Step 1.3: If no matching item is found after the traversal in Step 1.2, return "Address exception".

[0070] Its detection algorithm is as follows:

[0071]

[0072] In this algorithm, when the source IP, destination IP, source port, and destination port of the message match those in the address storage table, perform SOME / IP message header detection. If the match fails, output "Address exception".

[0073] The steps for generating the SOME / IP message header detection rules are as follows:

[0074] Step 1.4: Extract the key fields of the SOME / IP message, including message ID, protocol version, interface version, service ID, message length, and message type. At the same time, set the expected range (maximum and minimum values) for the most recent message ID and message length.

[0075] Step 1.5: Based on the key fields in Step 1.4, check whether the message ID belongs to a replay attack, whether the protocol version and interface version match, whether the service ID matches, and whether the message length exceeds the set range. If all detections pass, return the type of this message.

[0076] Step 1.6: Based on the detection results in Step 1.5, return the detected replay attack, protocol or interface version error, illegal service ID, or message length exception.

[0077] Its detection algorithm is as follows:

[0078]

[0079]

[0080] This algorithm is used to detect key fields of SOME / IP message headers item by item, including message ID, protocol version, interface version, service ID, message length, and message type. First, replay attacks are prevented by comparing the message IDs, and then it is checked whether the protocol version, interface version, and service ID meet the expectations. Finally, it is detected whether the message length is within the valid range. If all the checks pass, the message type is returned, and subsequent request-response type detection will be performed based on this return type;

[0081] When the message type is the request-response type, it enters the request and response detection. The rules for generating the request-response type detection are as follows:

[0082] Step 1.7: Extract the key fields of the SOME / IP message, including source IP, destination IP, source port, destination port, request ID, message ID, message type, and timestamp, and establish a request list (requestList) to record and manage the request messages to be matched;

[0083] Step 1.8: Store the request message into the request list (requestList) established in Step 1.7, and traverse the request list (requestList) to match the response message. If the response times out, it is determined as a "timeout response message"; if the source IP, destination IP, port, request ID, and message ID of the request message and the response message match, it is determined as "no exception";

[0084] Step 1.9: Based on the determination result of Step 1.8, return the corresponding exception result.

[0085] Its detection algorithm is as follows:

[0086]

[0087]

[0088] This algorithm aims to process request and response messages in the SOME / IP protocol. For request messages, the algorithm stores the key information into the request storage table (requestList). For response messages, the algorithm traverses the request storage table to verify whether there is a timeout response message or whether a request message matching the response message can be found. If a matching request is found, the algorithm returns no exception; otherwise, the algorithm will return that an orphaned response message is detected or a timeout response message is detected.

[0089] According to the exception detection algorithm of the present invention, the generated exception detection rules follow the Suricata format and are distributedly deployed for different domain servers to improve the detection accuracy and speed. Such as Figure 3This is an example of an anomaly detection rule specifically designed to monitor SOME / IP packets passing through a specific port (port 30491). A length threshold is set in the rule, and when the length of the detected SOME / IP message exceeds this threshold, an alarm will be triggered. The purpose of this rule is to detect messages with excessive lengths, which may be caused by network attacks or other types of abnormal traffic.

[0090] Step 2: The Central Gateway (CGW) captures and parses Service Discovery Phase (SOME / IP-SD) messages;

[0091] After generating and deploying the vehicle global rules based on the SOME / IP-based communication matrix and the defined rule generation algorithm, the Central Gateway (CGW), as the core control node of the in-vehicle network, captures Service Discovery Phase (SOME / IP-SD) messages of the SOME / IP protocol in real time. And it parses the captured SOME / IP-SD messages to extract key information, including service status, communication target, service type. According to the parsing results, it determines whether there are new services or service status changes in the current network, and updates the service status table. The specific steps are as follows:

[0092] Step 2.1: Initialize the service status list (service_status_table) to store and manage the status information of SOME / IP services, parse the received Service Discovery Phase (SOME / IP-SD) messages, and extract relevant fields, including service ID, instance ID, event group ID, IP address, port, protocol, and Time-To-Live (TTL);

[0093] Step 2.2: Update the service status based on the message type parsed in Step 2.1:

[0094] If the message type is "Find", it means the client is looking for a service, and the status is not updated;

[0095] If the message type is "Offer", check whether the service is a new service. If so, add it to the service status list (service_status_table); otherwise, update the Time-To-Live (TTL) value to maintain the service status;

[0096] If the message type is "Subscribe", it means the client subscribes to a service, and the status is not updated;

[0097] If the message type is "Stop", check the Time-To-Live (TTL) value. If the Time-To-Live (TTL) is 0, mark the service as stopped;

[0098] Step 2.3: Based on the update result of Step 2.2, output the updated service status list (service_status_table).

[0099] The algorithm for updating the service status is described as follows:

[0100]

[0101]

[0102] This algorithm captures and parses SOME / IP-SD messages to update the service status table in real time. It determines the status changes of services based on the message types (Find, Offer, Subscribe, Stop): for Offer messages, it determines whether a service is newly added or enabled; for Stop messages, it determines whether a service is disabled; Find and Subscribe messages do not require status updates. Ultimately, it ensures that the service status table always reflects the latest network service status.

[0103] Step 3: The Central Gateway (CGW) dynamically updates the global anomaly detection rules generated in Step 1 according to the service discovery phase (SOME / IP-SD) message information parsed in Step 2 using a rule generation algorithm, and distributes them to the corresponding rule library of the domain controller;

[0104] When the Central Gateway (CGW) determines that the service discovery phase (SOME / IP-SD) message information is for a newly added service based on the service status list, the Central Gateway (CGW) dynamically generates anomaly detection rules according to the Suricata rule format and the rule generation algorithm;

[0105] During the rule generation process, the Central Gateway (CGW) combines the two-phase communication characteristics of the SOME / IP protocol - the service discovery phase and the service communication phase - to ensure that the generated rules are both accurate and applicable;

[0106] When the Central Gateway (CGW) determines that the service discovery phase (SOME / IP-SD) message information is for an existing service and the service status has changed based on the service status list, the Central Gateway (CGW) updates the status of the existing rules;

[0107] Subsequently, the Central Gateway (CGW) distributes the dynamically generated detection rules and the latest status of the rules to the corresponding domain controller (Domain Controller) according to content relevance, thereby achieving distributed anomaly detection. Among them, the service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, that is, they are relevant.

[0108] Step 4: The Domain Controller performs anomaly detection based on the updated anomaly detection rules in Step 3;

[0109] As a distributed detection node, the Domain Controller captures SOME / IP communication data within the domain in real time. Based on the latest anomaly detection rule set in the Domain Controller, it performs rule matching on the captured SOME / IP packets to identify abnormal behaviors. If an anomaly is detected, the Domain Controller reports the anomaly information to the Central Gateway (CGW) and generates an alarm log. See Figure 4 , and the detailed anomaly detection process is as follows:

[0110] Step 4.1, the Domain Controller first monitors the network traffic to determine whether it is a SOME / IP protocol packet. If the detected traffic is a SOME / IP protocol packet, it proceeds to Step 4.2 for processing; if it does not conform to the SOME / IP protocol specification, the traffic is directly discarded to avoid interference to the system caused by invalid data;

[0111] Step 4.2, after confirming in Step 4.1 that the traffic is a SOME / IP protocol packet, it further checks the IP address and port number in the packet and matches the anomaly detection rules in the rule library. If the IP address or port number does not match, the Domain Controller discards it and writes it into the alarm log; if the IP address and port number match successfully, the Domain Controller performs a detailed check on the key fields of the message header of the SOME / IP packet. The key fields include message ID, protocol version, interface version, service ID, and message length. If there is a mismatch in the message header fields, the Domain Controller writes the anomaly information into the warning log; if the message header fields match successfully, the Domain Controller classifies the packet according to the message type field of the SOME / IP packet. The SOME / IP protocol supports multiple message types, including Request messages and Response messages. The Domain Controller determines the specific type of the packet based on the message type in the message header. If the packet type does not match the message type, the Domain Controller writes the anomaly information into the warning log;

[0112] Step 4.3, make a judgment based on the message type in Step 4.2:

[0113] If the message is a request message, the Domain Controller checks the legality of the request. When the service ID, method ID, and instance ID fields do not match the anomaly detection rules, the Domain Controller writes the anomaly information to the warning log;

[0114] If the message is a response message, the Domain Controller verifies whether the response status code and the returned data field match the anomaly detection rules. If they do not match, the Domain Controller writes the anomaly information to the warning log.

[0115] The present invention also discloses a computer-readable storage medium storing a computer program, which when executed by a processor implements the method for detecting abnormal traffic of in-vehicle Ethernet SOME / IP.

[0116] Simulation experiment

[0117] The following part verifies the effectiveness, robustness, and efficiency of the present invention through simulation experiments. The experimental environment is shown in Table 1, and the dataset uses the dataset generated by Some / IP Generator. Some / IP Generator is a Python-based tool for generating Some / IP data packets. The generator effectively simulates the Some / IP data packet traffic duration between different ECUs in the same local area network by using Python's native multi-process components and multiple communication queues. The dataset contains normal network traffic samples and various abnormal network traffic samples. Through these datasets, the performance of the present invention in actual applications can be tested. Multiple attack scenarios are set up in the experiment to simulate different attack types such as Fakesource attack, FakeClientID attack, DeleteRequest attack, DeleteResponse attack, and WrongInterface attack, verifying the effectiveness of the present invention.

[0118] Table 1 Experimental environment

[0119] Operating System Windows 11 CPU AMD Ryzen 5 5600H Memory 2*16G Graphics Card (Video Memory) GTX 3050 Ti (12G) Emulation Environment Python 3.8

[0120] (1) Experimental setup

[0121] Table 2 Dataset setup

[0122] Dataset Type Sample Size Normal 1000 Fake Source 100 Fake Client ID 100 Delete Request 100 Delete Response 100 Wrong Interface 100

[0123] To construct a SOME / IP simulation dataset, this embodiment considers a vehicular network consisting of 8 servers, 8 clients, and an attacker. The number of service exchanges is limited to 3. Each client subscribing to a service and method can generate 500 data packets for a SOME / IP network session. In addition, to verify the effectiveness of the solution, this embodiment considers five types of attacks against the SOME / IP protocol, as shown in Table 2.

[0124] (2) Effectiveness evaluation

[0125] Table 3 Effects of detecting different attacks

[0126] Attack Type Fake Source Fake Client ID Delete Request Delete Response Wrong Interface Detection Effect √ √ √ √ √

[0127] According to the experimental results shown in Table 3, it can be seen that the present invention can effectively identify multiple attack types. Among the five set attack types, the present invention can accurately detect abnormal behaviors and give alarms in a timely manner.

[0128] Table 4 Effects of detecting attacks in different service states

[0129] Service Status Attack False Positive Enabled √ × Disabled √ × New √ ×

[0130] Based on the data analysis results in Table 4, in multiple service states, the present invention demonstrates effective detection capabilities for corresponding attack behaviors and reduces and avoids misjudgments of normal data. Whether the service is in an active, deactivated, or newly added state, the present invention can accurately identify attack behaviors. The results further confirm that when the service state of the SOME / IP protocol changes dynamically, the present invention can achieve dynamic matching of rules, ensuring the accuracy and reliability of attack detection. This ability is crucial for enhancing the security protection of the SOME / IP protocol in vehicular networks.

[0131] (3) Efficiency evaluation

[0132] Table 5 Size of the rule set and time required for detection

[0133] Rule Storage Space Detection Time 0.6 KB / Entry 0.318 ms

[0134] Table 5 shows that the average size of the anomaly detection rules in the anomaly traffic detection method designed by the present invention is only 0.6 KB, and the average time for detecting 1000 SOME / IP messages is 0.318 ms. It can be seen that its distributed low resource occupancy and high detection speed enable it to well adapt to the requirements of real-time performance and limited resources in the vehicle networking environment, providing an efficient and feasible solution for the security protection of the SOME / IP protocol in vehicular networks.

Claims

1. A vehicle-mounted Ethernet SOME / IP abnormal traffic detection system, characterized in that: include: Central Gateway (CGW), Rule Base and Domain Controller; The central gateway (CGW): as the core control node of the vehicle network, is responsible for managing the overall process of anomaly detection rules. Its specific tasks include: real-time capture and analysis of SOME / IP protocol service discovery phase (SOME / IP-SD) messages to extract key information; Based on the analysis results, anomaly detection rules that conform to the Suricata rule format are dynamically generated, and the rule status is adjusted in real time according to network behavior to ensure its accuracy and applicability; finally, the generated detection rules and status list are distributed to the rule base corresponding to each domain controller; The rule base: as a storage node in the system, responsible for receiving and storing anomaly detection rules issued by the central gateway (CGW); The domain controller (Domain Controller): as an execution node in the system, compares and matches the communication data according to the anomaly detection rule set in the corresponding rule base, and once an abnormal behavior that does not match the anomaly detection rule is found, it will promptly alert the central gateway (CGW).

2. A method for detecting abnormal traffic of SOME / IP in vehicle Ethernet based on the system of claim 1, characterized in that: The following steps are involved: Step 1: The central gateway (CGW) generates global anomaly detection rules through a rule generation algorithm and stores them in the rule bases of different domain controllers according to their content relevance; Step 2: The central gateway (CGW) captures and parses the service discovery phase (SOME / IP-SD) message; Step 3: The central gateway (CGW) dynamically updates the global anomaly detection rules generated in step 1 using the rule generation algorithm based on the service discovery phase (SOME / IP-SD) message information parsed in step 2, and sends it to the rule base of the corresponding domain controller; Step 4: The domain controller performs anomaly detection based on the anomaly detection rules updated in step 3.

3. The method according to claim 2, characterized in that: The anomaly detection rules in step 1 include SOME / IP service location detection rules, SOME / IP message header detection rules and / or request response type detection rules, wherein the service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, that is, there is correlation.

4. The method according to claim 3, characterized in that: The SOME / IP service location detection is based on the communication matrix of the vehicle SOME / IP protocol, generates a service location anomaly detection for detecting SOME / IP messages, and is used to match the source IP, source port, destination IP, destination port of the SOME / IP protocol and preliminarily screen the SOME / IP traffic. The rule generation steps are as follows: Step 1.1: Initialize the address storage table addr_table to store the source IP, source port, destination IP, destination port of the legal SOME / IP protocol, and initialize the traversal variable entry; Step 1.2: Based on the source IP, source port, destination IP, and destination port stored in step 1.1, the address storage table addr_table is traversed to check whether the source IP, source port, destination IP, and destination port of the SOME / IP message match the data stored in the address storage table addr_table. If the match is successful, "match successful" is returned, otherwise the traversal continues; Step 1.3: If no match is found after the traversal in step 1.2, an "address exception" is returned.

5. The method according to claim 3, characterized in that: After the SOME / IP service location detection is passed, the SOME / IP message header is detected. The steps of generating the SOME / IP message header detection rule are as follows: Step 1.4: Extract key fields of the SOME / IP message, including message ID, protocol version, interface version, service ID, message length, and message type. At the same time, set the expected range of the most recent message ID and message length. Step 1.5: Based on the key fields in step 1.4, check whether the message ID belongs to a replay attack, whether the protocol version and interface version match, whether the service ID matches, and whether the message length exceeds the set range. If all tests pass, return the type of the message; Step 1.6: Based on the detection results of step 1.5, the detected replay attack, protocol or interface version error, illegal service ID or abnormal message length is returned.

6. The method according to claim 3, characterized in that: After the SOME / IP message header detection passes, the message type is returned. When the message type is a request response type, the request and response detection is entered. The request response type detection rule generation steps are as follows: Step 1.7: Extract key fields of the SOME / IP message, including source IP, destination IP, source port, destination port, request ID, message ID, message type and timestamp, and create a request list (requestList) for recording and managing request messages to be matched; Step 1.8: Store the request message into the request list (requestList) established in step 1.7, and traverse the request list (requestList) to match the response message. If the response times out, it is judged as "timeout response message"; if the source IP, destination IP, port, request ID and message ID of the request message and the response message all match, it is judged as "no abnormality"; Step 1.9: Based on the determination result of step 1.8, the corresponding abnormal result is returned.

7. The method according to claim 3, characterized in that: The central gateway (CGW) described in step 2 captures and parses the service discovery phase (SOME / IP-SD) message of the SOME / IP protocol in real time, extracts key information, and the key information includes service status, communication target, and service type. According to the parsing result, it is determined whether there is a new service or service status change in the current network, and the service status table is updated. The specific steps are as follows: Step 2.1: Initialize the service status table (service_status_table) to store and manage the status information of SOME / IP services, parse the received service discovery phase (SOME / IP-SD) message, and extract relevant fields, including service ID, instance ID, event group ID, IP address, port, protocol and time to live (TTL); Step 2.2: Update the service status based on the message type parsed in step 2.1: If the message type is "Find", it means that the client is looking for a service and does not update the status; If the message type is "Offer", check whether the service is a new service. If so, add it to the service status list (service_status_table). Otherwise, update the time to live (TTL) value to maintain the service status. If the message type is "Subscribe", it means that the client subscribes to the service and does not update the status; If the message type is "Stop", the TTL value is checked. If the TTL is 0, the service is marked as stopped. Step 2.3: Based on the update result of step 2.2, output the updated service status list (service_status_table).

8. The method according to claim 2, characterized in that: The specific steps of step 3 are as follows: When the central gateway (CGW) determines that the message information in the service discovery phase (SOME / IP-SD) is a new service according to the service status list, the central gateway (CGW) dynamically generates anomaly detection rules based on the Suricata rule format and rule generation algorithm; The central gateway (CGW) determines that the message information in the service discovery phase (SOME / IP-SD) is an existing service based on the service status list, and when the service status changes, the central gateway (CGW) updates the status of the existing rules; Subsequently, the central gateway (CGW) sends the dynamically generated detection rules and the latest status of the rules to the corresponding domain controller (Domain Controller) according to the content relevance, thereby realizing distributed anomaly detection, wherein the service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, that is, there is relevance.

9. The method according to claim 2, characterized in that: The specific steps of step 4 are as follows: the domain controller (DomainController) captures the SOME / IP communication data in the domain in real time, and performs anomaly detection on the captured SOME / IP messages based on the anomaly detection rule set in the latest rule base. If it is determined to be abnormal, the domain controller (DomainController) reports the abnormal information to the central gateway (CGW) and generates an alarm log; The anomaly detection process is as follows: Step 4.1, the domain controller first monitors the network traffic to determine whether it is a SOME / IP protocol message. If the detected traffic is a SOME / IP protocol message, it proceeds to step 4.2 for processing; if it does not comply with the SOME / IP protocol specification, it directly discards the traffic; Step 4.2, after confirming that the traffic is a SOME / IP protocol message in step 4.1, further check the IP address and port number in the message, match the anomaly detection rules in the rule base, if the IP address or port number does not match, the domain controller (DomainController) discards it and writes it into the alarm log; if the IP address and port number match successfully, the domain controller (DomainController) performs a detailed check on the key fields of the message header of the SOME / IP message, the key fields include message ID, protocol version, interface version, service ID, message length, if the message header field does not match, the domain controller (DomainController) writes the abnormal information into the warning log; if the message header field matches successfully, the domain controller (DomainController) classifies the message according to the message type field of the SOME / IP message. The SOME / IP protocol supports multiple message types, including request messages (Request) and response messages (Response). The domain controller (DomainController) determines the specific type of the message according to the message type of the message header. If the message type does not match the message type, the domain controller (DomainController) writes the abnormal information into the warning log; Step 4.3, judge according to the message type in step 4.2: If the message is a request message, the domain controller checks the legitimacy of the request. When the service ID, method ID, and instance ID fields do not match the anomaly detection rules, the domain controller writes the anomaly information to the warning log. If the message is a response message, the domain controller verifies whether the response status code, the returned data field and the anomaly detection rule match. If not, the domain controller writes the anomaly information into the warning log.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 2 to 9 are implemented.

Images