Vehicle-mounted Ethernet SOME / IP abnormal traffic detection system, method, and media

Abstract

This invention discloses an in-vehicle Ethernet SOME / IP abnormal traffic detection system, method, and medium, belonging to the field of information security. The system includes: a central gateway, managing the overall process of abnormal detection rules; a rule base, receiving and storing abnormal detection rules issued by the central gateway; and domain controllers, comparing and matching communication data based on the abnormal detection rule set in the rule base, detecting mismatched abnormal behavior, and alerting the central gateway. The method includes: the central gateway first generating global abnormal detection rules using a rule generation algorithm and storing them in the rule base; then capturing and parsing service discovery phase messages, dynamically updating the global abnormal detection rules based on message information and the rule generation algorithm, and storing them in the rule bases of different domain controllers according to their correlation; finally, the domain controllers performing abnormal detection based on the updated abnormal detection rules; and a medium for storing the method. This invention features strong dynamic adaptability, efficient rule management, high detection accuracy, and high robustness.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, specifically relating to an in-vehicle Ethernet SOME / IP abnormal traffic detection system, method, and medium. Background Technology

[0002] The rapid development of the automotive industry has led to a dramatic increase in the number of Electronic Control Units (ECUs) in modern vehicles, resulting in increasingly complex internal vehicle network structures. In recent years, the automotive industry has rapidly moved towards intelligent and connected vehicles, making automotive-related intelligent technologies a research hotspot. Applications such as In-Vehicle Infotainment (IVI) and Advanced Driving Assistance Systems (ADAS) have greatly enriched the driving experience. However, traditional automotive bus standards such as CAN (Controller Area Network) struggle to meet the bandwidth demands of intelligent vehicle development. Against this backdrop, automotive Ethernet has emerged as a leading solution. The SOME / IP (Scalable Service-Oriented Middleware over IP) protocol in automotive Ethernet effectively meets 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 flexible transmission mechanisms, it significantly improves the efficiency of data interaction between various systems within the vehicle. However, the SOME / IP protocol specification does not define security mechanisms, such as authentication or encryption schemes. With the increasing complexity of communication networks and the growth of data traffic, anomalies may occur in communication data, such as packet loss, delays, and network attacks, posing a serious challenge to the safety and reliability of automobiles. In automotive communication systems, once an attack occurs and abnormal data is generated, it can lead to functional failures, system crashes, or even safety incidents.

[0003] Because SOME / IP has service-oriented characteristics, its network traffic is more dynamic and unpredictable than traditional automotive protocols (such as CAN bus protocols), thus requiring more suitable and efficient anomaly detection methods. Currently, SOME / IP anomaly traffic detection mainly relies on machine learning models to train normal communication patterns to identify attacks, but the following problems still exist: (1) It is difficult to establish a stable baseline of normal behavior. The highly dynamic communication patterns of the SOME / IP protocol make 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 applicability and generalization ability. (3) Single-point deployment poses security risks. Once the detection node fails or is attacked, the lack of a distributed detection mechanism affects the robustness of the system.

[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), which proposed a Suricata-based SOME / IP protocol anomaly detection system. However, because this method does not consider 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 it is difficult to meet robustness and scalability requirements. Summary of the Invention

[0005] To overcome the shortcomings of the prior art, the present invention aims to provide an in-vehicle Ethernet SOME / IP abnormal traffic detection system, method, and medium. Utilizing the two-phase communication characteristics of SOME / IP, and employing a domain controller architecture, the central gateway captures and parses SOME / IP-SD packets to obtain the service status of different domain controllers in real time. Subsequently, the central gateway dynamically modifies the detection rules based on the service status according to the Suricata rule format and distributes them to the corresponding domain controllers. Each domain controller, acting as a distributed detection node, performs anomaly detection on SOME / IP communication packets according to the received rule status, identifying abnormal behavior. This invention not only achieves dynamic expansion of anomaly detection but also improves the accuracy of anomaly detection through automatic generation and status updating of anomaly detection rules. Furthermore, the distributed anomaly detection by domain controllers enhances robustness, effectively strengthening the security protection capabilities of the in-vehicle network.

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

[0007] An in-vehicle Ethernet SOME / IP abnormal traffic detection system includes: a central gateway (CGW), a rule base, and a domain controller;

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

[0009] The rule base, as a storage node in the system, is responsible for receiving and storing anomaly detection rules issued by the central gateway (CGW).

[0010] The Domain Controller, as the execution node in the system, compares and matches communication data according to the anomaly detection rule set in its corresponding rule base. Once an abnormal behavior that does not match the anomaly detection rule is detected, it promptly alerts the Central Gateway (CGW).

[0011] A method for detecting abnormal traffic on a vehicle-mounted Ethernet SOME / IP network includes 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 bases 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 using the rule generation algorithm based on the service discovery phase (SOME / IP-SD) message information parsed in Step 2, and distributes them to the rule base corresponding to the domain controller.

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

[0016] The anomaly detection rules mentioned in step 1 include SOME / IP service location detection rules, SOME / IP message header detection rules, and / or request / response type detection rules. The service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, i.e., they are related.

[0017] The SOME / IP service location detection is based on the vehicle's SOME / IP protocol communication matrix. It generates service location anomaly detection for SOME / IP packets, which is used to match the source IP, source port, destination IP, and destination port of the SOME / IP protocol and to initially filter SOME / IP traffic. The rule generation steps are as follows:

[0018] Step 1.1: Initialize the address storage table addr_table to store the source IP, source port, destination IP, and destination port of valid SOME / IP protocols, 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, perform a match by traversing the address storage table addr_table and checking whether the source IP, source port, destination IP, and destination port of the SOME / IP packet 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, return "Address error".

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

[0022] 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 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 checks pass, return the message type.

[0024] Step 1.6: Based on the detection results of Step 1.5, return the detected replay attacks, protocol or interface version errors, illegal service IDs, or abnormal message lengths.

[0025] After the SOME / IP message header detection passes, the message type is returned. If the message type is a request-response type, the request and response detection is initiated. 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 source IP, destination IP, source port, destination port, request ID, message ID, message type and timestamp, and build 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) created in Step 1.7, and iterate through 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 response message all match, it is determined as "no anomaly".

[0028] Step 1.9: Based on the judgment result of Step 1.8, return the corresponding abnormal result.

[0029] In step 2, the Central Gateway (CGW) captures and parses SOME / IP-SD service discovery messages in real time to extract key information, including service status, communication target, and service type. Based on the parsing results, it determines whether there are any new services or changes in service status in the current network and updates the service status table. The specific steps are as follows:

[0030] 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) 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 that the client is searching for the service and is not updating the status;

[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 that the client subscribes to the service and does not update the status;

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

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

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

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

[0039] The Central Gateway (CGW) determines whether the service discovery phase (SOME / IP-SD) message information is an existing service based on the service status list. When the service status changes, the Central Gateway (CGW) updates the status of the existing rules.

[0040] Subsequently, the Central Gateway (CGW) distributes the dynamically generated detection rules and their latest status to the corresponding Domain Controllers according to content relevance, thereby achieving distributed anomaly detection. The service identifier of the anomaly detection rule is associated with the service identifier managed by the Domain Controller, which means that they are related.

[0041] The specific steps of step 4 are as follows: The Domain Controller captures SOME / IP communication data within its domain in real time. Based on the latest anomaly detection rule set in the rule base, it performs anomaly detection on the captured SOME / IP packets. If an anomaly is determined, the Domain Controller reports the anomaly 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 if 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; otherwise, the traffic is discarded.

[0044] Step 4.2: After confirming in Step 4.1 that the traffic is a SOME / IP protocol message, further check the IP address and port number in the message and match them with the anomaly detection rules in the rule base. If the IP address or port number does not match, the Domain Controller discards it and writes it to 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 SOME / IP message header. The key fields include message ID, protocol version, interface version, service ID, and message length. If a message header field mismatch occurs, the Domain Controller writes the exception information to the warning log. If the message header field matches successfully, the Domain Controller 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 and response messages. The Domain Controller determines the specific type of the message based on the message type in the message header. If the message type does not match the message type, the Domain Controller writes the exception information to the warning log.

[0045] Step 4.3, determine the message type based on step 4.2:

[0046] If the message is a request message, the Domain Controller checks the validity of the request. If the Service ID, Method ID, or Instance ID fields do not match the exception detection rules, the Domain Controller writes the exception information to the warning log.

[0047] If the message is a response message, the domain controller verifies whether the response status code, returned data fields, and exception detection rules match. If they do not match, the domain controller writes the exception information to the warning log.

[0048] A computer-readable storage medium storing a computer program that, when executed by a processor, implements a method for detecting abnormal traffic on an in-vehicle Ethernet SOME / IP network.

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

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

[0051] 2. This invention manages detection rules uniformly through a central gateway (CGW) and distributes corresponding rules to each domain controller. This invention effectively reduces the complexity of rule configuration and improves the flexibility and scalability of rule management.

[0052] 3. This invention automatically generates and updates anomaly detection rules based on the actual operation of the SOME / IP service, avoiding the problem of decreased detection accuracy caused by fixed rules in traditional static detection models.

[0053] 4. A distributed detection architecture is adopted, with each domain controller independently performing anomaly detection. Even if a node fails, other nodes can continue to detect, ensuring the security and robustness of the entire vehicle network.

[0054] In summary, this invention offers advantages such as strong dynamic adaptability, efficient rule management, high detection accuracy, and high robustness. This invention proposes a dynamic rule-matching anomaly detection scheme based on the vehicular Ethernet SOME / IP protocol. This scheme utilizes the two-phase communication characteristics of SOME / IP. Under a domain controller architecture, the central gateway (CGW) captures and parses service discovery phase (SOME / IP-SD) messages to obtain the real-time status of different SOME / IP services. Simultaneously, combined with the Suricata anomaly detection rule format, it dynamically generates SOME / IP anomaly detection rules for each domain controller based on the SOME / IP service status. The central gateway (CGW), acting as the central controller, is responsible for rule generation and distribution. Different domain controllers act as detection nodes, storing the corresponding service anomaly detection rules. Finally, through the two-phase linkage mechanism of the SOME / IP protocol, the automatic generation and status update of SOME / IP anomaly detection rules are achieved, thereby improving the dynamic scalability and accuracy of the detection model. Attached Figure Description

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

[0056] Figure 2 This is a flowchart of the rule generation process for steps 1 to 3 of the abnormal traffic detection method of the present invention, which is the central gateway (CGW).

[0057] Figure 3 Screenshot showing an example of anomaly detection rules generated in an embodiment of the present invention.

[0058] Figure 4 This is a flowchart of the anomaly detection process for the Domain Controller of this invention. Detailed Implementation

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

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

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

[0062] The rule base, as a storage node in the system, is responsible for receiving and storing anomaly detection rules issued by the central gateway (CGW).

[0063] The Domain Controller, as the execution node in the system, compares and matches communication data according to the anomaly detection rule set in its corresponding rule base. Once an abnormal behavior that does not match the anomaly detection rule is detected, it promptly alerts the Central Gateway (CGW).

[0064] See Figure 2 A method for detecting abnormal traffic on a vehicle-mounted Ethernet SOME / IP network 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 bases of different domain controllers according to their content relevance. These rules include SOME / IP service location detection rules, SOME / IP message header detection rules, and / or request / response type detection rules. The service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, which means that the rules are related.

[0066] The SOME / IP service location detection rules define the communication relationship between the in-vehicle SOME / IP network server and client based on the vehicle's SOME / IP protocol communication matrix. Based on the communication matrix, service location anomaly detection for SOME / IP packets is first generated. This is used to match the SOME / IP protocol's four-tuple (source IP, source port, destination IP, destination port) and to initially filter SOME / IP traffic. The specific rule generation steps are as follows:

[0067] Step 1.1: Initialize the address storage table addr_table to store valid 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 a match by traversing the address storage table addr_table and checking whether the source IP, source port, destination IP, and destination port of the SOME / IP packet 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 match is found after the traversal in Step 1.2, return "Address error".

[0070] The detection algorithm is as follows:

[0071]

[0072] In this algorithm, if the source IP, destination IP, source port, and destination port of a message match the address storage table, then the SOME / IP message header is checked; if the match fails, an address error is output.

[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 checks pass, return the message type.

[0076] Step 1.6: Based on the detection results of Step 1.5, return the detected replay attacks, protocol or interface version errors, illegal service IDs, or abnormal message lengths.

[0077] The detection algorithm is as follows:

[0078]

[0079]

[0080] This algorithm is used to inspect key fields in the SOME / IP message header item by item, including message ID, protocol version, interface version, service ID, message length, and message type. First, it prevents replay attacks by comparing message IDs. Then, it checks whether the protocol version, interface version, and service ID meet expectations. Finally, it checks whether the message length is within a valid range. If all checks pass, it returns the message type, which will be used for subsequent request / response type detection.

[0081] When the message type is a request-response type, the request and response detection process begins. The steps for generating the request-response type detection rules 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 build a request list (requestList) to record and manage the request messages to be matched;

[0083] Step 1.8: Store the request message in the request list (requestList) created in Step 1.7, and iterate through 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 response message all match, it is determined as "no anomaly".

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

[0085] The detection algorithm is as follows:

[0086]

[0087]

[0088] This algorithm is designed to process request and response messages in the SOME / IP protocol. For request messages, the algorithm stores key information in a request store table (requestList). For response messages, the algorithm iterates through the request store table to verify whether a timed-out response message exists or whether a matching request message can be found. If a matching request is found, the algorithm returns no exception; otherwise, the algorithm returns an error message indicating that an orphaned response message or a timed-out response message was detected.

[0089] According to the anomaly detection algorithm of the present invention, the generated anomaly detection rules follow the Suricata format and are distributed across different domain servers to improve the accuracy and speed of detection. Figure 3This is an example of an anomaly detection rule specifically designed to monitor SOME / IP packets passing through a specific port (port 30491). The rule sets a length threshold; when a detected SOME / IP message exceeds this threshold, an alert is triggered. The purpose of this rule is to detect excessively long messages, which may be caused by network attacks or other types of abnormal traffic.

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

[0091] After generating and deploying vehicle-wide rules based on the SOME / IP communication matrix and defined rule generation algorithm, the Central Gateway (CGW), as the core control node of the vehicular network, captures SOME / IP service discovery phase (SOME / IP-SD) packets in real time. It then parses the captured SOME / IP-SD packets to extract key information, including service status, communication target, and service type. Based on the parsing results, it determines whether there are any new services or changes in service status in the current network and updates the service status table accordingly. The specific steps are as follows:

[0092] 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) 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 that the client is searching for the service and is not updating the status;

[0095] 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.

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

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

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

[0099] The service status update process algorithm is described as follows:

[0100]

[0101]

[0102] This algorithm updates the service status table in real time by capturing and parsing SOME / IP-SD packets. It determines service status changes based on packet type (Find, Offer, Subscribe, Stop): for Offer packets, it determines whether the service has been added or enabled; for Stop packets, it determines whether the service has been disabled; Find and Subscribe packets do not require status updates. Ultimately, this 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 using the rule generation algorithm based on the service discovery phase (SOME / IP-SD) message information parsed in Step 2, and distributes them to the rule base corresponding to the domain controller.

[0104] When the Central Gateway (CGW) determines that the service discovery phase (SOME / IP-SD) message information is a new service based on the service status list, the Central Gateway (CGW) dynamically generates anomaly detection rules according to the Suricata rule format and 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] The Central Gateway (CGW) determines whether the service discovery phase (SOME / IP-SD) message information is an existing service based on the service status list. When the service status changes, the Central Gateway (CGW) updates the status of the existing rules.

[0107] Subsequently, the Central Gateway (CGW) distributes the dynamically generated detection rules and their latest status to the corresponding Domain Controllers according to content relevance, thereby achieving distributed anomaly detection. The service identifier of the anomaly detection rule is associated with the service identifier managed by the Domain Controller, which means that they are related.

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

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

[0110] Step 4.1: The Domain Controller first monitors the network traffic to determine if 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; otherwise, the traffic is discarded to avoid invalid data interfering with the system.

[0111] Step 4.2: After confirming in Step 4.1 that the traffic is a SOME / IP protocol message, further check the IP address and port number in the message and match them with the anomaly detection rules in the rule base. If the IP address or port number does not match, the Domain Controller discards it and writes it to 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 SOME / IP message header. The key fields include message ID, protocol version, interface version, service ID, and message length. If a message header field mismatch occurs, the Domain Controller writes the exception information to the warning log. If the message header field matches successfully, the Domain Controller 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 and response messages. The Domain Controller determines the specific type of the message based on the message type in the message header. If the message type does not match the message type, the Domain Controller writes the exception information to the warning log.

[0112] Step 4.3, determine the message type based on step 4.2:

[0113] If the message is a request message, the Domain Controller checks the validity of the request. If the Service ID, Method ID, or Instance ID fields do not match the exception detection rules, the Domain Controller writes the exception information to the warning log.

[0114] If the message is a response message, the domain controller verifies whether the response status code, returned data fields, and exception detection rules match. If they do not match, the domain controller writes the exception information to the warning log.

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

[0116] Simulation Experiment

[0117] The following section verifies the effectiveness, robustness, and efficiency of this invention through simulation experiments. The experimental environment is shown in Table 1. The dataset used is generated by Some / IP Generator. Some / IP Generator is a Python-based tool for generating Some / IP packets. This generator utilizes Python's native multi-process components and multiple communication queues to effectively simulate the duration of Some / IP packet traffic between different ECUs within the same local area network. The dataset includes normal network traffic samples and various abnormal network traffic samples. These datasets allow for testing the performance of this invention in practical applications. Multiple attack scenarios were set up in the experiment, simulating different attack types such as Fakesource attacks, FakeClientID attacks, DeleteRequest attacks, DeleteResponse attacks, and WrongInterface attacks, thus verifying the effectiveness of this invention.

[0118] Table 1 Experimental Environment

[0119] operating system Windows 11 CPU AMDRyzen 55600H Memory 2*16G Graphics card (video memory) GTX3050Ti (12G) Simulation environment Python 3.8.

[0120] (1) Experimental setup

[0121] Table 2 Dataset Settings

[0122] Dataset types Sample size Normal 1000 Fakesource 100 FakeClientID 100 DeleteRequest 100 DeleteResponse 100 WrongInterface 100

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

[0124] (2) Effectiveness assessment

[0125] Table 3 shows the effectiveness of detecting different attacks.

[0126] Attack type Fakesource FakeClientID DeleteRequest DeleteResponse WrongInterface Detection effect √ √ √ √ √

[0127] As shown in Table 3, the experimental results demonstrate that this invention can effectively identify multiple attack types. Among the five specified attack types, this invention accurately detected abnormal behavior and issued timely alerts.

[0128] Table 4. Attack detection effectiveness under different service states

[0129] Service Status attack misjudgment Enable √ × Deactivate √ × New √ ×

[0130] Based on the data analysis results in Table 4, this invention demonstrated effective detection capabilities against corresponding attack behaviors under various service states, while reducing and avoiding misjudgments of normal data. Whether the service is active, deactivated, or newly added, this invention can accurately identify attack behaviors. The results further confirm that when the SOME / IP protocol service state dynamically changes, this invention can achieve dynamic rule matching, ensuring the accuracy and reliability of attack detection. This capability is crucial for enhancing the security protection of the SOME / IP protocol in in-vehicle networks.

[0131] (3) Efficiency assessment

[0132] Table 5. Rule set size and detection time

[0133] Rule storage space Detection time 0.6KB / piece 0.318ms

[0134] Table 5 shows the average size of the anomaly detection rules in the anomaly traffic detection method designed in this invention, which is only 0.6KB, and the average time to detect 1000 SOME / IP packets is 0.318ms. This demonstrates its distributed, low-resource-consumption, and high-detection-speed characteristics, making it well-suited to the real-time and resource-constrained requirements of the vehicle network environment, providing an efficient and feasible solution for the security protection of the SOME / IP protocol in in-vehicle 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 vehicular network, is responsible for managing the overall process of anomaly detection rules. Its specific tasks include: capturing and parsing SOME / IP-SD packets during the SOME / IP protocol service discovery phase in real time, and extracting key information; dynamically generating anomaly detection rules that conform to the Suricata rule format based on the parsing results, and adjusting the rule status in real time according to network behavior to ensure its accuracy and applicability; and finally, distributing the generated detection rules and status lists to the rule bases of each domain controller. The rule base, as a storage node in the system, is responsible for receiving and storing anomaly detection rules issued by the central gateway (CGW). The Domain Controller acts as an execution node in the system. It compares and matches communication data according to the anomaly detection rule set in its corresponding rule base. Once an abnormal behavior that does not match the anomaly detection rule is detected, it promptly alerts the Central Gateway (CGW). The method for implementing the system includes the following steps: 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 based on their content relevance. The anomaly detection rules include SOME / IP service location detection rules, SOME / IP message header detection rules, and / or request / response type detection rules. The service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, i.e., they are related. Step 2: The central gateway (CGW) captures and parses SOME / IP-SD packets during the service discovery phase; Step 3: Based on the SOME / IP-SD message information obtained during the service discovery phase in Step 2, the Central Gateway (CGW) dynamically updates the global anomaly detection rules generated in Step 1 using a rule generation algorithm, and distributes them to the rule base of the corresponding domain controller. The specific steps are as follows: When the Central Gateway (CGW) determines that the SOME / IP-SD message information during the service discovery phase is a newly added service based on the service status list, the CGW dynamically generates anomaly detection rules according to the Suricata rule format and rule generation algorithm. When the central gateway CGW determines that the SOME / IP-SD message information during the service discovery phase is an existing service based on the service status list, and the service status changes, the central gateway CGW updates the status of the existing rules. Subsequently, the central gateway (CGW) distributes the dynamically generated detection rules and the latest status of the rules to the corresponding domain controllers according to content relevance, thereby realizing distributed anomaly detection. The service identifier of the anomaly detection rule is associated with the service identifier managed by the domain controller, which means that they are related. Step 4: The Domain Controller performs anomaly detection based on the anomaly detection rules updated in Step 3.

2. The implementation method of the vehicle-mounted Ethernet SOME / IP abnormal traffic detection system according to claim 1, characterized in that, The SOME / IP service location detection is based on the vehicle's SOME / IP protocol communication matrix. It generates service location anomaly detection for SOME / IP packets, which is used to match the source IP, source port, destination IP, and destination port of the SOME / IP protocol and to initially filter 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, and destination port of valid SOME / IP protocols, 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, perform a match by traversing the address storage table addr_table and checking whether the source IP, source port, destination IP, and destination port of the SOME / IP packet match the data stored in the address storage table addr_table. If the match is successful, return "match successful"; otherwise, continue traversing. Step 1.3: If no match is found after the traversal in Step 1.2, return "Address error".

3. The method according to claim 2, characterized in that, After the SOME / IP service location detection passes, the SOME / IP message header is inspected. The steps for generating the SOME / IP message header inspection rules are as follows: 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 for 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 checks pass, return the message type. Step 1.6: Based on the detection results of Step 1.5, return the detected replay attacks, protocol or interface version errors, illegal service IDs, or abnormal message lengths.

4. The method according to claim 2, characterized in that, After the SOME / IP message header detection passes, the message type is returned. If the message type is a request-response type, the request and response detection is initiated. The steps for generating the request-response type detection rules are as follows: 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 create a request list (requestList) to record and manage the request messages to be matched; Step 1.8: Store the request message in the request list created in Step 1.7, and iterate through the request list 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 response message all match, it is determined as "no exception". Step 1.9: Based on the judgment result of Step 1.8, return the corresponding abnormal result.

5. The method according to claim 2, characterized in that, In step 2, the central gateway (CGW) captures and parses SOME / IP-SD packets during the service discovery phase of the SOME / IP protocol in real time, extracting key information, including service status, communication target, and service type. Based on the parsing results, it determines whether there are any new services or changes in service status in the current network and updates the service status table. The specific steps are as follows: Step 2.1: Initialize the service status list service_status_table, which is used to store and manage the status information of SOME / IP services. Parse the received SOME / IP-SD messages during the service discovery phase 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 searching for the service and is not updating the status; 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. 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", check the Time-to-Live (TTL) value. If the TTL is 0, mark the service as stopped. Step 2.3: Based on the update results of Step 2.2, output the updated service status list service_status_table.

6. The method according to claim 2, characterized in that, The specific steps of step 4 are as follows: The Domain Controller captures SOME / IP communication data within its domain in real time, performs anomaly detection on the captured SOME / IP packets based on the latest anomaly detection rule set in the rule base, and if an anomaly is determined, the Domain Controller reports the anomaly 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 if 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; otherwise, the traffic is discarded. Step 4.2: After confirming in Step 4.1 that the traffic is a SOME / IP protocol message, further check the IP address and port number in the message and match them with the anomaly detection rules in the rule base. If the IP address or port number does not match, the Domain Controller discards it and writes it to 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 SOME / IP message header, including message ID, protocol version, interface version, service ID, and message length. If a message header field mismatch occurs, the Domain Controller writes the exception information to the warning log. If the message header field matches successfully, the Domain Controller 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 and response messages. The Domain Controller determines the specific type of the message based on the message type in the message header. If the message type does not match the message type, the Domain Controller writes the exception information to the warning log. Step 4.3, determine the message type based on step 4.2: If the message is a request message, the Domain Controller checks the validity of the request. If the Service ID, Method ID, or Instance ID fields do not match the exception detection rules, the Domain Controller writes the exception information to the warning log. If the message is a response message, the Domain Controller verifies whether the response status code, returned data fields, and exception detection rules match. If they do not match, the Domain Controller writes the exception information to the warning log.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 2 to 6.

Images