Equipment information identification method based on deep packet inspection

Abstract

The invention provides an equipment information identification method based on deep packet inspection, and the method comprises the steps: S1, carrying out the deep packet inspection, identification and filtering of an input network data packet based on a preset trusted application rule base through a network intrusion detection engine, and obtaining trusted application traffic; s2, filtering user agent information based on a primary filtering rule in the trusted application traffic, and outputting candidate traffic; s3, for the candidate traffic, performing accurate extraction of equipment information from the whole HTTP protocol message to obtain structured equipment information; and S4, associating the structured equipment information with the corresponding network quintuple information, and outputting a value log file. According to the scheme, double screening is performed through combination of trusted application filtering and UA primary filtering, interference of forged UA and non-standard applications is eliminated from the source, and the accuracy of equipment detection is improved.

Description

Technical Field

[0001] This invention belongs to the field of network identification technology, and specifically relates to a device information identification method based on deep packet inspection. Background Technology

[0002] In today's network environment, accurately identifying the operating system and model of terminal devices is crucial for network security, business auditing, and user behavior analysis. Currently, the most common device identification technology is parsing the User-Agent (UA) field in the HTTP request header. This technology relies on device information actively reported by the client, and its basic assumption is that the UA string is authentic and reliable.

[0003] However, this premise no longer holds true in practical applications. Because the User Agent (UA) string can be completely controlled by the client, it is extremely easy to forge or tamper with, resulting in a fundamental flaw in existing technology: the reliability of device information detection is extremely low. Specifically, modern browser developer tools provide convenient device emulation functions, allowing a desktop browser UA to be disguised as the UA of any mobile device with a single click; furthermore, users can also actively forge UAs using plugins or malicious applications.

[0004] Existing technologies rely entirely on a single and untrusted User Agent (UA) field, resulting in device information detection results with almost zero credibility in practical applications. They cannot effectively distinguish between genuine device information and maliciously forged information, thus making subsequent business logic (such as security risk control and precision operation) that depends on this detection result built on an unreliable foundation, thereby affecting its accuracy. Summary of the Invention

[0005] The purpose of the embodiments in this specification is to provide a device information identification method based on deep packet inspection.

[0006] To solve the above-mentioned technical problems, the embodiments of this application are implemented in the following ways: In a first aspect, this application provides a device information identification method based on deep packet inspection, the method comprising: S1. Through the network intrusion detection engine, based on the pre-built trusted application rule base, deep packet inspection is performed on the input network data packets to identify and filter trusted application traffic. S2. In the trusted application traffic, the user agent information is filtered based on the primary filtering rules to output candidate traffic; S3. For the candidate traffic, accurately extract device information from the entire HTTP protocol message to obtain structured device information; S4. Associate the structured device information with the corresponding network quintuple information and output the value log file.

[0007] In one embodiment, the rules for building the trusted application rule base satisfy all of the following conditions: The company size corresponding to the application meets the preset conditions; When there are multiple company domains corresponding to an application, select the domain that has been tested a preset number of times; For a known model of test equipment, conduct multiple tests on the target application within different time ranges; In an internal network environment with a preset number of users, a blind test of the target application is conducted for a preset duration.

[0008] In one embodiment, S1 uses a network intrusion detection engine, based on a pre-built trusted application rule base, to perform deep packet inspection on the input network packets, identify and filter trusted application traffic, including: S11. Capture the input network data packets, parse the network data packets, and extract the application layer payload of the HTTP traffic; S12. Locate and extract the Host field value from the HTTP request header from the application layer payload; S13. Match the Host field value with the trusted application rule base to obtain the trusted application traffic.

[0009] In one embodiment, the trusted application rule base includes trusted application domain names; Matching the Host field value with the trusted application rule base includes matching the Host field value with the trusted application domain name.

[0010] In one embodiment, the primary filtering rule uses an exact match for a trusted system identifier in the user agent string as the matching condition; the primary filtering rule is configured in the rule set of the network intrusion detection engine to include continuous matching logic for HTTP request header newline characters, field names, field separators, and the trusted system identifier.

[0011] In one embodiment, S2 filters user agent information in the trusted application traffic based on primary filtering rules and outputs candidate traffic, including: S21. Using the network intrusion detection engine, extract the complete string corresponding to the User-Agent field from the HTTP request header of the trusted application traffic; S22. Match the complete string corresponding to the User-Agent field with the primary filtering rule to verify whether the complete string corresponding to the User-Agent field contains the newline character, field name, separator and trusted system identifier in sequence; If a match is found, the corresponding trusted application traffic is marked as the candidate traffic.

[0012] In one embodiment, S3 performs precise extraction of device information from the entire HTTP protocol message for the candidate traffic to obtain structured device information, including: S31. For the candidate traffic, a network intrusion detection engine is used to obtain the complete application layer payload of the currently processed HTTP protocol message; S32. Scan the complete application layer payload and search for and extract feature strings containing device information at multiple predetermined locations in the HTTP protocol message; S33. Obtain the embedded device model and system version from the complete string corresponding to the User-Agent field; S34. Integrate the feature string containing device information with the device model and system version to obtain the structured device information.

[0013] Secondly, this application provides a device information identification apparatus based on deep packet inspection, the apparatus comprising: The trusted application traffic filtering module is used to perform deep packet inspection on the input network data packets through the network intrusion detection engine, based on a pre-built trusted application rule base, to identify and filter trusted application traffic. The user agent information filtering module is used to filter user agent information in the trusted application traffic based on primary filtering rules and output candidate traffic. The device information extraction module is used to accurately extract device information from the entire HTTP protocol message for the candidate traffic to obtain structured device information; The log output module is used to associate the structured device information with the corresponding network 5-tuple information and output a value log file.

[0014] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the device information identification method based on deep packet inspection as described in the first aspect.

[0015] Fourthly, this application provides a readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the device information identification method based on deep packet inspection as described in the first aspect.

[0016] As can be seen from the technical solutions provided in the embodiments of this specification above, this solution uses a dual screening approach of trusted application filtering combined with primary UA filtering to eliminate interference from forged UAs and non-standard applications at the source, thus solving the problem of untrusted UAs in existing technologies. It also expands the scope of information extraction from the UA field in the HTTP protocol header to the entire HTTP protocol message, and uses Lua script regular expression matching to verify device information from multiple dimensions, avoiding bias from a single source. Furthermore, based on the mature Suricata engine and Lua scripts, no additional complex modules need to be developed, making it easy to implement in engineering. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating the device information identification method based on deep packet inspection provided in this application; Figure 2 A schematic diagram of the device information identification device based on deep packet inspection provided in this application; Figure 3 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] Various modifications and variations can be made to the specific embodiments described in this application without departing from the scope or spirit of this application, as will be apparent to those skilled in the art. Other embodiments derived from this application will be obvious to those skilled in the art. This application specification and embodiments are merely exemplary.

[0022] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.

[0023] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0024] Reference Figure 1 This document illustrates a flowchart of the device information identification method based on deep packet inspection provided in the embodiments of this application. It is understood that the device information identification method based on deep packet inspection provided in the embodiments of this application is implemented based on a network intrusion detection engine. Such a network intrusion detection engine may be, for example, Suricata. A network intrusion detection engine is a software framework or system that integrates multi-layer protocol parsing.

[0025] like Figure 1 As shown, the device information identification method based on deep packet inspection may include: S1. Using a network intrusion detection engine, based on a pre-built trusted application rule base, deep packet inspection is performed on the input network data packets to identify and filter trusted application traffic.

[0026] The trusted application rule base is pre-built and needs to be constructed in advance. The construction of the trusted application rule base is based on a multi-dimensional trustworthiness assessment system.

[0027] In one embodiment, the rules for building the trusted application rule base satisfy all of the following conditions: The company size corresponding to the application meets the preset conditions; When there are multiple company domains corresponding to an application, select the domain that has been tested a preset number of times; For a known model of test equipment, conduct multiple tests on the target application within different time ranges; In an internal network environment with a preset number of users, a blind test of the target application is conducted for a preset duration.

[0028] Specifically, the scope of the trusted application rule base is defined by the following aspects: 1) Assessing the company size of the operating entity behind the application. Larger companies tend to have more standardized output formats, and applications operated by larger companies are prioritized for recognition as trusted applications. 2) For multiple domain names that a company may use, only specific domain names that have undergone multiple rounds of rigorous testing are collected. 3) White-box personal testing: Individuals conduct multiple tests using various testing devices and at multiple time ranges. That is, testers use various known models of testing devices to conduct multiple proactive tests on the target application at different time ranges to verify the authenticity and consistency of its traffic device information. 4) Black-box scope testing: In an internal network environment containing dozens to hundreds of nodes, anonymous traffic monitoring and statistical analysis of the target application are conducted for no less than one month. For example, blind testing is conducted for up to one month within an internal network of nearly one hundred people to confirm that there is no large-scale forgery of its device information. Only application domain names that comprehensively meet the above four conditions are ultimately recognized as trusted applications, and corresponding trusted application filtering rules are generated. These trusted application filtering rules are then configured in the rule set of the network intrusion detection engine. The core matching condition for this filtering rule is that the content of the Host field in the HTTP request header matches the domain name of the trusted application.

[0029] The preset conditions, preset number of attempts, and preset number of participants can all be set according to actual needs.

[0030] In one embodiment, S1 uses a network intrusion detection engine to perform deep packet inspection on the input network packets based on a pre-built trusted application rule base, identifying and filtering trusted application traffic, including: S11. Capture the input network data packets, parse the network data packets, and extract the application layer payload of the HTTP traffic; S12. Locate and extract the Host field value from the HTTP request header from the application layer payload; S13. Match the Host field value with the trusted application rule base to obtain the trusted application traffic.

[0031] The trusted application rule base includes trusted application domain names; matching the Host field value with the trusted application rule base in S13 includes matching the Host field value with the trusted application domain name.

[0032] Specifically, the protocol parsing module of the network intrusion detection engine decapsulates the input network data packets layer by layer; when the transport layer protocol is identified as TCP and the target port is 80, it is determined that it may carry HTTP traffic, thereby triggering application layer protocol parsing, that is, extracting its application layer payload.

[0033] In the extracted HTTP application layer payload, locate the starting position of the HTTP request header; by parsing the HTTP header format, find and extract the Host field and its corresponding field value; the Host field value is usually a complete domain name or host address.

[0034] The extracted Host field value is matched against rule entries in the pre-built trusted application rule base; the rule entries use domain name or domain name characteristics (such as the subdomain .kugou.com) as matching conditions; this matching operation is performed by the rule matching module of the network intrusion detection engine, following the string matching or regular expression matching logic defined in the rule.

[0035] The determination is based on the matching results: If the Host field value successfully matches any rule entry in the trusted application rule base, the network traffic is determined to be trusted application traffic.

[0036] If a match fails, the network traffic is determined not to originate from a trusted application, and is either dropped or redirected to another processing path.

[0037] S2. In the trusted application traffic, the user agent information is filtered based on the primary filtering rules to output candidate traffic.

[0038] The primary filtering rule uses the trusted system identifier in the user agent string as the matching condition; the primary filtering rule is configured in the rule set of the network intrusion detection engine to include continuous matching logic for HTTP request header newline characters, field names, field separators and the trusted system identifier.

[0039] Specifically, in the rule set of the network intrusion detection engine, one or more rules are created for primary filtering. The core matching condition of the primary filtering rule is set as follows: precisely matching the value of the User-Agent field in the HTTP request header to a predefined, trusted system-level identifier. This trusted system-level identifier is a string that is difficult to generate naturally in a desktop browser environment through conventional emulation methods, such as the identifier string "Dalvik / 2.1.0" of the Dalvik virtual machine in the Android operating system. Based on the trusted system-level identifier, a rule matching pattern for the network intrusion detection engine is constructed. This matching pattern is a string containing a specific byte sequence used to precisely match the target field in the HTTP request header. The string is constructed according to the following format: the beginning part contains the hexadecimal representation of the newline character separating the HTTP header fields |0D 0A|; the middle part contains the target field name "User-Agent" and the following field separator ":" in a mixed hexadecimal and ASCII representation |0D 0A|User-Agent|3A 20|, where |3A 20| corresponds to the ASCII character ":"; the end part contains the ASCII string of the trusted system identifier "Dalvik / 2.1.0". That is, the specific content of the primary filtering rule in the rule set is a matching pattern containing a mixture of hexadecimal and ASCII codes, for example: content:"|0D 0A|User-Agent|3A 20|Dalvik / 2.1.0";, where |0D 0A| matches the newline character in the HTTP header, and |3A 20| matches ":" (colon-space), thus accurately locating and matching the User-Agent field and its value.

[0040] The rule matching pattern constructed above is written into the rule file of the network intrusion detection engine (Suricata) as the content of the keyword "content", forming a complete executable filtering rule; by loading the rule file, the rule is made effective in the engine's real-time traffic processing flow.

[0041] In one embodiment, S2 filters user agent information in the trusted application traffic based on primary filtering rules and outputs candidate traffic, including: S21. Using the network intrusion detection engine, extract the complete string corresponding to the User-Agent field from the HTTP request header of the trusted application traffic; S22. Match the complete string corresponding to the User-Agent field with the primary filtering rule to verify whether the complete string corresponding to the User-Agent field contains the newline character, field name, separator and trusted system identifier in sequence; If a match is found, the corresponding trusted application traffic is marked as the candidate traffic.

[0042] Specifically, for trusted application traffic output by S1, the network intrusion detection engine extracts the complete string corresponding to the User-Agent field from the HTTP request header of the traffic, such as Dalvik / 2.1.0 (Linux; U; Android 14; PHP110 Build / UKQ1.230924.001). The complete string corresponding to the User-Agent field is then matched against the primary filtering rules to verify whether the complete string corresponding to the User-Agent field sequentially contains the newline character, field name, separator, and trusted system identifier.

[0043] If the content of the User-Agent field successfully matches the trusted system underlying identifier (such as "Dalvik / 2.1.0"), the traffic is determined to have passed the initial trustworthiness verification, is marked as candidate traffic, and is allowed to enter the subsequent precise extraction process of device information.

[0044] If the match fails, the traffic is determined to have failed the initial trust verification. Even if it originates from a trusted application, it is still considered as potentially risky or low-trust traffic. For such traffic, it is either discarded or redirected to another processing path that is isolated from the subsequent precise extraction process of device information.

[0045] This embodiment adds a verification layer based on a specific User-Agent identifier to the trusted application traffic filtering described above. This verification layer is specifically designed to identify and filter out traffic that, although originating from trusted applications, may be generated by a PC desktop browser through device simulation debugging functions and carries a fake mobile device UA. Thus, before the traffic enters the final device information extraction stage, it further eliminates false alarms caused by browser simulation behavior and improves the credibility of the overall detection process.

[0046] S3. For the candidate traffic, accurately extract device information from the entire HTTP protocol message to obtain structured device information.

[0047] Specifically, for candidate traffic, it breaks away from the traditional limitation of extracting information only from the UA field, and extracts device information from multiple dimensions in the entire HTTP protocol message to obtain structured device information.

[0048] In one embodiment, S3 performs precise extraction of device information from the entire HTTP protocol message for the candidate traffic to obtain structured device information, including: S31. For the candidate traffic, a network intrusion detection engine is used to obtain the complete application layer payload of the currently processed HTTP protocol message.

[0049] Specifically, the Suricata engine obtains the complete application layer payload of the HTTP protocol message corresponding to the candidate traffic, rather than just extracting the protocol header, providing data support for multi-location information extraction, that is, expanding the collection and identification to the entire HTTP protocol information.

[0050] S32. Scan the complete application layer payload and search for and extract feature strings containing device information at multiple predetermined locations in the HTTP protocol message.

[0051] Specifically, the following is an example of how to find and retrieve data from a predetermined location: Application transmission protocol fields: For example, the clientostype android-34authkey information in the WeChat message transmission protocol can be used to determine that the device system is Android; HTTP request line (URI) parameters: For example, the device system is determined to be Android by the &os=android&channel=46& parameter in the URI link; Other HTTP header parameters: such as via X-Client-Info:model=JAD-AL00;os=Android;nqe-score=56;network=WIFI;signal-strength=4; extracts the device model as JAD-AL00 and the system as Android. System function identifier: For example, the device system is determined to be Windows by using User-Agent: Microsoft-CryptoAPI / 10.0.

[0052] S33. Obtain the embedded device model and system version from the complete string corresponding to the User-Agent field; for example, extract the system version as Android 14 and the device model as PHP110 from Dalvik / 2.1.0 (Linux; U; Android 14; PHP110 Build / UKQ1.230924.001).

[0053] S34. Integrate the feature string containing device information with the device model and system version to obtain the structured device information.

[0054] Specifically, the multi-location feature string information extracted by S32 is integrated with the device information in the UA field extracted by S33 to form standardized structured device information containing "device model, system version, and application source", thus avoiding the bias of information from a single source.

[0055] S4. Associate the structured device information with the corresponding network quintuple information and output the value log file.

[0056] Specifically, the structured device information is associated with the corresponding network 5-tuple information (obtained through Suricata's SCPacketTuple() function, including source IP, destination IP, protocol type, source port, and destination port), and combined with information such as timestamp (obtained through the os.time() function) and flow identifier (obtained through the SCFlowId() function), and encapsulated into JSON format data, which is then output to the log file.

[0057] For example, the storage path and naming rules for the log file are as follows: the WriteFile function of the Lua script is used to write the data to / app / suricata / var / log / suricata / eve / app-UA-Dalvik-Device-2024-05-20.json (the file name includes the date, generated by os.date("!%Y-%m-%d", os.time() + 28800)) for easy subsequent querying and analysis.

[0058] This application employs a dual screening approach, combining trusted application filtering with primary UA filtering, to eliminate interference from forged UAs and non-standard applications at the source, thus resolving the issue of untrusted UAs in existing technologies. It also expands the information extraction scope from the HTTP header UA field to the entire HTTP protocol message, combining Lua script regular expression matching for multi-dimensional verification of device information, avoiding bias from a single source. Furthermore, based on the mature Suricata engine and Lua scripts, no additional complex modules need to be developed, facilitating engineering implementation.

[0059] The following uses the Xiaohongshu (Little Red Book) app as an example to introduce the complete implementation process of the device information identification method based on deep packet inspection provided in this application: I. Preliminary Preparations Trusted application rule base construction: For the .xhscdn.com domain of the Xiaohongshu application, three rounds of white-box testing were first conducted using multiple models of devices (such as Android phones and Apple phones) at different times (8 am, 12 pm, and 8 pm). Then, a black-box blind test was conducted for one month by organizing 100 people on the internal network. After confirming that there were no anomalies, .xhscdn.com was included in the trusted application rule base.

[0060] Suricata rule configuration: Configure the traffic filtering rules for the Xiaohongshu APP, httpUA-Dalvik-device.lua: alert tcp-pkt $HOME_NET any -> any 80 (msg:"UA-Dalvik-device-Xiaohongshu";content:"|0D 0A|User-Agent|3A 20|Dalvik / 2.1.0"; content:"|0D 0A|Host|3A 20|";content:".xhscdn.com|0D 0A|"; distance:0; within:50; lua:scripts / Device / httpUA-Dalvik-device.lua; sid:2001; This rule specifies that only when the traffic meets the three conditions of "port 80, UA contains Dalvik / 2.1.0, and Host contains.xhscdn.com", the httpUA-Dalvik-device.lua script is called for subsequent processing.

[0061] II. Process Execution ①: Trusted application traffic filtering: Suricata captures network packets, extracts the Host field as xxx.xhscdn.com after parsing, and matches it with the trusted application rule library, marking it as Xiaohongshu trusted application traffic; ②: UA primary filtering: Extract the UA field of this traffic as Dalvik / 2.1.0 (Linux; U; Android14; PHP110 Build / UKQ1.230924.001), and match it with the content: "|0D 0A|User-Agent|3A 20|Dalvik / 2.1.0" in the rule, marking it as candidate traffic; ③: Device information extraction: Call the httpUA-Dalvik-device.lua script and perform regular matching: Extract the system version Android 14 and device model PHP110 from the UA field; Extract the device model JAD-AL00 (if it exists) from the X-Client-Info field in the HTTP header; After integration, the structured device information is obtained: {System: Android 14, Model: PHP110 / JAD-AL00, Application: Xiaohongshu}; ④: Log output: The script obtains the network 5-tuple (e.g., source IP: 192.168.1.100, destination IP: 10.0.0.5, protocol: TCP, source port: 54321, destination port: 80) and timestamp (2024-05-20T10:30:00+0800), encapsulates it as JSON data and writes it to the log file.

[0062] Example code is as follows: The httpUA-Dalvik-device.lua rule extracts device signal information and device system information from the User Agent (UA): --httpUA-Dalvik-device-- function init(args) local needs = {} needs["payload"] = tostring(true) return needs end function match(args) local payload = args['payload'] sid, rev, gid = SCRuleIds() day = os.date("!%Y-%m-%d", os.time() + 28800) local host = string.match(payload,'\x0D\x0AHost:\x20([%-%.%d%l]+)\x0D\x0A') if host == nil then host = "NULL" end local Device = string.match(payload,'.-Dalvik / 2.1.0 %(Linux; U;Android %d-; ([%w%-%s]-) Build / .+%)') if Device ~= nil and string.len(Device)<20 then local DeviceData = date("Device",Device,sid,host) WriteFile(" / app / suricata / var / log / suricata / eve / app-UA-Dalvik-Device-" .. day .. ".json", DeviceData) local WeChatOS = date("WeChat-OS-Version","Android",sid,host) WriteFile(" / app / suricata / var / log / suricata / eve / app-WeChat-OS-".. day .. ".json", WeChatOS) return 0 end end function WriteFile(filename,lolid1) local f =assert(io.open(filename,"a+")) f:write(lolid1) f:close() end function date(appkey,WeChatOSVersion,v,host) ipver, srcip, dstip, proto, sp, dp = SCPacketTuple() timeStamp = os.time() timestring = os.date("!%Y-%m-%dT%T", timeStamp + 28800) .. "." .."000000" .. "+0800" ids = SCFlowId() flow_id = string.format("%.0f", ids) IDDATA = '"tcp":{"appKey":"' .. appkey .. '","value":"' ..WeChatOSVersion .. '","sid":"' .. v .. '","host":"' .. host .. '"}' datas = '{"timestamp":"' .. timestring .. '","flow_id":' .. flow_id .. ',"event_type":"http","src_ip":"' .. srcip .. '","src_port":' .. sp ..',"dest_ip":"' .. dstip .. '","dest_port":' .. dp .. ',"proto":"TCP",' ..IDDATA .. '}\n' return datas end Reference Figure 2 The diagram illustrates a structural schematic of a device information identification apparatus based on deep packet inspection according to an embodiment of this application.

[0063] like Figure 2 As shown, a device information identification device based on deep packet inspection may include: The trusted application traffic filtering module 210 is used to perform deep packet inspection on the input network data packets through the network intrusion detection engine based on the pre-built trusted application rule base, and to identify and filter trusted application traffic. User agent information filtering module 220 is used to filter user agent information in the trusted application traffic based on primary filtering rules and output candidate traffic; Device information extraction module 230 is used to accurately extract device information from the entire HTTP protocol message for the candidate traffic to obtain structured device information; The log output module 240 is used to associate the structured device information with the corresponding network quintuple information and output a value log file.

[0064] Optionally, the rules for building the trusted application rule base must satisfy all of the following conditions: The company size corresponding to the application meets the preset conditions; When there are multiple company domains corresponding to an application, select the domain that has been tested a preset number of times; For a known model of test equipment, conduct multiple tests on the target application within different time ranges; In an internal network environment with a preset number of users, a blind test of the target application is conducted for a preset duration.

[0065] Optionally, the trusted application traffic filtering module 210 is also used for: Capture the input network packets and parse the network packets to extract the application layer payload of the HTTP traffic; Locate and extract the Host field value from the HTTP request header from the application layer payload; The Host field value is matched with the trusted application rule base to obtain the trusted application traffic.

[0066] Optionally, the trusted application rule base includes trusted application domains; Matching the Host field value with the trusted application rule base includes matching the Host field value with the trusted application domain name.

[0067] Optionally, the primary filtering rule uses an exact match of the trusted system identifier in the user agent string as the matching condition; the primary filtering rule is configured in the rule set of the network intrusion detection engine to include continuous matching logic for HTTP request header newline characters, field names, field separators and the trusted system identifier.

[0068] Optionally, the user agent information filtering module 220 is also used for: The network intrusion detection engine extracts the complete string corresponding to the User-Agent field from the HTTP request header of the trusted application traffic. The complete string corresponding to the User-Agent field is matched with the primary filtering rule to verify whether the complete string corresponding to the User-Agent field contains the newline character, field name, separator, and trusted system identifier in sequence. If a match is found, the corresponding trusted application traffic is marked as the candidate traffic.

[0069] Optionally, the device information extraction module 230 is also used for: For the candidate traffic, a network intrusion detection engine is used to obtain the complete application layer payload of the currently processed HTTP protocol message; The complete application layer payload is scanned, and feature strings containing device information are found and extracted at multiple predetermined locations in the HTTP protocol message; Retrieve the embedded device model and system version from the complete string corresponding to the User-Agent field; The structured device information is obtained by integrating the feature string containing device information with the device model and system version.

[0070] This embodiment provides a device information identification device based on deep packet inspection, which can execute the above-described method. Its implementation principle and technical effect are similar, and will not be described again here.

[0071] Figure 3This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 3 The diagram shows a structural schematic of an electronic device 300 suitable for implementing embodiments of this application.

[0072] like Figure 3 As shown, the electronic device 300 includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage section 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the device 300. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0073] The following components are connected to I / O interface 305: an input section 306 including a keyboard, mouse, etc.; an output section 307 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN card, modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0074] In particular, according to embodiments of this disclosure, the above references Figure 1 The described process can be implemented as a computer software program. For example, embodiments of this disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program containing program code for performing the aforementioned deep packet inspection-based device information identification method. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311.

[0075] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0076] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0077] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a mobile phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0078] In another aspect, this application also provides a storage medium, which may be the storage medium included in the aforementioned apparatus in the above embodiments; or it may be a standalone storage medium not assembled into a device. The storage medium stores one or more programs, which are used by one or more processors to execute the device information identification method based on deep packet inspection described in this application.

[0079] Storage media, including both permanent and non-permanent, removable and non-removable media, can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0080] It should be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0081] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A device information identification method based on deep packet inspection, characterized in that, The method includes: S1. Through the network intrusion detection engine, based on the pre-built trusted application rule base, deep packet inspection is performed on the input network data packets to identify and filter trusted application traffic. S2. In the trusted application traffic, the user agent information is filtered based on the primary filtering rules to output candidate traffic; S3. For the candidate traffic, accurately extract device information from the entire HTTP protocol message to obtain structured device information; S4. Associate the structured device information with the corresponding network quintuple information and output the value log file.

2. The device information identification method based on deep packet inspection according to claim 1, characterized in that, The construction rules for the trusted application rule base must satisfy all of the following conditions: The company size corresponding to the application meets the preset conditions; When there are multiple company domains corresponding to an application, select the domain that has been tested a preset number of times; For a known model of test equipment, conduct multiple tests on the target application within different time ranges; In an internal network environment with a preset number of users, a blind test of the target application is conducted for a preset duration.

3. The device information identification method based on deep packet inspection according to claim 1, characterized in that, S1, through a network intrusion detection engine based on a pre-built trusted application rule base, performs deep packet inspection on the input network data packets to identify and filter trusted application traffic, including: S11. Capture the input network data packets, parse the network data packets, and extract the application layer payload of the HTTP traffic; S12. Locate and extract the Host field value from the HTTP request header from the application layer payload; S13. Match the Host field value with the trusted application rule base to obtain the trusted application traffic.

4. The device information identification method based on deep packet inspection according to claim 3, characterized in that, The trusted application rule base includes trusted application domain names; Matching the Host field value with the trusted application rule base includes matching the Host field value with the trusted application domain name.

5. The device information identification method based on deep packet inspection according to claim 3, characterized in that, The primary filtering rule uses the exact match of the trusted system identifier in the user agent string as the matching condition; the primary filtering rule is configured in the rule set of the network intrusion detection engine to include continuous matching logic for HTTP request header newline characters, field names, field separators and the trusted system identifier.

6. The device information identification method based on deep packet inspection according to claim 5, characterized in that, S2 filters user agent information in the trusted application traffic based on primary filtering rules and outputs candidate traffic, including: S21. Using the network intrusion detection engine, extract the complete string corresponding to the User-Agent field from the HTTP request header of the trusted application traffic; S22. Match the complete string corresponding to the User-Agent field with the primary filtering rule to verify whether the complete string corresponding to the User-Agent field contains the newline character, field name, separator and trusted system identifier in sequence; If a match is found, the corresponding trusted application traffic is marked as the candidate traffic.

7. The device information identification method based on deep packet inspection according to claim 6, characterized in that, S3 performs precise extraction of device information from the entire HTTP protocol message for the candidate traffic to obtain structured device information, including: S31. For the candidate traffic, a network intrusion detection engine is used to obtain the complete application layer payload of the currently processed HTTP protocol message; S32. Scan the complete application layer payload and search for and extract feature strings containing device information at multiple predetermined locations in the HTTP protocol message; S33. Obtain the embedded device model and system version from the complete string corresponding to the User-Agent field; S34. Integrate the feature string containing device information with the device model and system version to obtain the structured device information.

8. A device information identification device based on deep packet inspection, characterized in that, The device includes: The trusted application traffic filtering module is used to perform deep packet inspection on the input network data packets through the network intrusion detection engine, based on a pre-built trusted application rule base, to identify and filter trusted application traffic. The user agent information filtering module is used to filter user agent information in the trusted application traffic based on primary filtering rules and output candidate traffic. The device information extraction module is used to accurately extract device information from the entire HTTP protocol message for the candidate traffic to obtain structured device information; The log output module is used to associate the structured device information with the corresponding network 5-tuple information and output a value log file.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the device information identification method based on deep packet inspection as described in any one of claims 1-7.

10. A readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the device information identification method based on deep packet inspection as described in any one of claims 1-7.

Images