Method and device for detecting https message for linux system

Abstract

The application relates to an HTTPS message detection method and device for a Linux system. The method comprises the following steps: a Linux system captures an HTTPS message; application layer plaintext data and environment data of the HTTPS message are extracted; skb structure data of the HTTPS message is extracted; the application layer data and the skb structure data are matched based on the environment data; after successful matching, the application layer data and the skb structure data are spliced to generate a plaintext message; and the plaintext message is detected by using an IDS / IPS intrusion detection engine. The HTTPS message detection method and device for the Linux system can bypass certificate authentication, extract and assemble the HTTPS decrypted message, form a message that can be detected by a common IDS / IPS engine, and improve message detection efficiency and accuracy.

Description

Technical Field

[0001] This disclosure relates to the field of computer information processing, and more specifically, to a method and apparatus for detecting HTTPS messages in a Linux system. Background Technology

[0002] The HTTP protocol has security flaws. Due to its lack of plaintext data transmission and message integrity checks, the HTTPS protocol has begun to be widely used. The HTTPS protocol is a network protocol built by adding TLS / SSL to the HTTP protocol, which can perform encrypted transmission and identity authentication. It mainly uses digital certificates, encryption algorithms, asymmetric keys and other technologies to encrypt Internet data transmission and achieve Internet transmission security protection.

[0003] While HTTPS protects the security of message transmission, it cannot prevent the transmission of malicious code and other data. If a message threat detection device cannot obtain the HTTPS message key, it cannot decrypt the encrypted data transmitted via HTTPS, thus hindering its security detection. Currently, third-party devices for identifying threats via HTTPS messages still need to obtain the HTTPS message key for decryption and detection. However, this method requires the customer to provide certificates to the third-party detection device, which actually increases the risk of key leakage. Due to various limitations, and with the stagnation of security detection technology based on feature analysis of HTTPS messages, traditional detection methods are essentially ineffective against attacks originating from HTTPS messages.

[0004] Therefore, a new method and device for detecting HTTPS messages on Linux systems is needed.

[0005] The information disclosed in the background section is only intended to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] In view of this, this application provides a method and apparatus for HTTPS packet detection in Linux systems, which can bypass certificate authentication, extract and assemble HTTPS decrypted packets to form packets that can be detected by commonly used IDS / IPS engines, thereby improving packet detection efficiency and accuracy.

[0007] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0008] According to one aspect of this application, a method for detecting HTTPS packets in a Linux system is proposed. The method includes: capturing HTTPS packets in the Linux system; extracting application-layer plaintext data and environment data from the HTTPS packets; extracting skb structure data from the HTTPS packets; matching the application-layer data and the skb structure data based on the environment data; concatenating the application-layer data and the skb structure data to generate a plaintext packet after successful matching; and detecting the plaintext packet using an IDS / IPS intrusion detection engine.

[0009] In one exemplary embodiment of this application, extracting the application layer plaintext data and environment data of the HTTPS message includes: using the uprobe technology in an SSL shared library to extract the application layer plaintext data and environment data of the HTTPS message.

[0010] In one exemplary embodiment of this application, before using the uprobe technology in the SSL shared library to extract the application layer plaintext data and environment data of the HTTPS message, the method further includes: obtaining the ELF file of the Linux system; parsing the ELF file to obtain the SSL / TLS encryption / decryption function offsets; hooking the entry and exit points of the SSL / TLS encryption / decryption functions using uprobe; and creating perf event resources.

[0011] In one exemplary embodiment of this application, the application layer plaintext data and environment data of the HTTPS message are extracted using the uprobe technology in an SSL shared library, including: creating a linked list based on the SSL shared library and sequentially polling for matching; obtaining an ELF dynamic symbol table based on the polling and matching; polling the ELF dynamic symbol table to obtain a specified function and offset; and obtaining the application layer plaintext data and environment data of the HTTPS message based on the specified function and offset.

[0012] In one exemplary embodiment of this application, after extracting the application layer plaintext data and environment data of the HTTPS message using the uprobe technology in the SSL shared library, the method further includes: sending the application layer plaintext data and the environment data to the user layer application via the perf event.

[0013] In one exemplary embodiment of this application, extracting the skb structure data of the HTTPS message includes: using cls_bpf technology in the kernel network driver to extract the skb structure data of the HTTPS message.

[0014] In one exemplary embodiment of this application, before using cls_bpf technology to extract the skb structure data of the HTTPS message in the kernel network driver, the method further includes: hooking the ingress function and egress function in QoS through a classifier in the traffic controller; and creating a perf event resource.

[0015] In one exemplary embodiment of this application, the skb structure data of the HTTPS message is extracted using the cls_bpf technology in the kernel network driver, including: inserting cls_bpf code into the ingress and egress functions of the classifier function in the kernel network driver; and extracting the skb structure data of the HTTPS message based on the ingress and egress functions.

[0016] In one exemplary embodiment of this application, after extracting the skb structure data of the HTTPS message using the cls_bpf technology in the kernel network driver, the method further includes: sending the skb structure data to the user-level application via the perf event.

[0017] In one exemplary embodiment of this application, after a successful match, the application layer plaintext data and the skb structure data are concatenated to generate a plaintext message, including: after a successful match, extracting encrypted application layer data from the HTTPS message based on the skb structure data; replacing the encrypted real-time application layer data with the application layer plaintext data to generate the plaintext message.

[0018] According to one aspect of this application, an HTTPS packet detection device for a Linux system is proposed. The device includes: a capture module for capturing HTTPS packets in the Linux system; a plaintext module for extracting application-layer plaintext data and environment data from the HTTPS packets; a structure module for extracting skb structure data from the HTTPS packets; a matching module for matching the application-layer data and the skb structure data based on the environment data; a splicing module for splicing the application-layer data and the skb structure data to generate a plaintext packet after successful matching; and a detection module for detecting the plaintext packets using an IDS / IPS intrusion detection engine.

[0019] According to one aspect of this application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the method as described above.

[0020] According to one aspect of this application, a computer-readable medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described above.

[0021] According to the HTTPS packet detection method and apparatus for Linux systems of this application, HTTPS packets are captured through the Linux system; application-layer plaintext data and environment data of the HTTPS packets are extracted; skb structure data of the HTTPS packets are extracted; the application-layer data and skb structure data are matched based on the environment data; after successful matching, the application-layer data and skb structure data are concatenated to generate plaintext packets; and the plaintext packets are detected using an IDS / IPS intrusion detection engine. This method can bypass certificate authentication, extract and assemble decrypted HTTPS packets to form packets that can be detected by commonly used IDS / IPS engines, thereby improving packet detection efficiency and accuracy.

[0022] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0023] The above and other objects, features, and advantages of this application will become more apparent from the detailed description of exemplary embodiments with reference to the accompanying drawings. The drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0024] Figure 1 This is a system schematic diagram illustrating an HTTPS packet detection method and apparatus for a Linux system according to an exemplary embodiment.

[0025] Figure 2 This is a system block diagram illustrating an HTTPS packet detection method and apparatus for a Linux system according to an exemplary embodiment.

[0026] Figure 3 This is a flowchart illustrating an HTTPS message detection method for a Linux system according to an exemplary embodiment.

[0027] Figure 4 This is a flowchart illustrating an HTTPS message detection method for a Linux system according to another exemplary embodiment.

[0028] Figure 5 This is a schematic diagram illustrating an HTTPS message detection method for a Linux system according to another exemplary embodiment.

[0029] Figure 6This is a block diagram illustrating an HTTPS packet detection apparatus for a Linux system according to another exemplary embodiment.

[0030] Figure 7 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0031] Figure 8 This is a block diagram illustrating a computer-readable medium according to an exemplary embodiment. Detailed Implementation

[0032] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0033] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0034] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0036] It should be understood that although the terms first, second, third, etc., may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below may be referred to as the second component without departing from the teachings of this application. As used herein, the term "and / or" includes all combinations of any one and more of the associated listed items.

[0037] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing this application, and therefore cannot be used to limit the scope of protection of this application.

[0038] The technical abbreviations used in this application are explained as follows:

[0039] Uprobe is a Linux kernel-based application probe. It performs various tracing and analysis operations through ftrace's / sys / debug / tracinginterface (a user-space API based on debugfs).

[0040] BPF (Berkeley Packet Filter) is a toolkit that allows technical personnel to more easily execute their own code within the kernel without needing in-depth knowledge of Linux kernel technology.

[0041] libbpf is a set of alternative tools for building BPF applications. It generates simple binaries that can be compiled once and run anywhere.

[0042] The TC (Traffic Control) module controls traffic on network devices using different algorithms (rate limiting, priority setting, etc.), and can retrieve the original packets from the ingress and egress points.

[0043] ELF (Executable and Linkable Format) is an executable and linkable file format. ELF files are object files for Unix systems, including relocatable object files, executable object files, and shared object files; the structure of this file can be recognized by the assembler, linker, or loader for linking or loading.

[0044] The applicant in this case, through research on existing technologies, discovered that BPF technology has received significant attention and development since its release in 1992 due to the need to maintain the Linux kernel's strong security, high performance, and continuous delivery capabilities. Among the BPF technologies, the bpftrace tool possesses kprobe and uprobe detection capabilities, which can be used to inject bytecode into kernel and library functions. This type of technology has also brought benefits to packet inspection.

[0045] During the application-layer decoding of HTTPS messages in a Linux system, libraries such as libssl / libgnutls are invoked, using the key or certificate obtained when connecting to the web application to decrypt the messages. For Linux kernel versions higher than 4.1, which utilize BPF technology, inserting bytecode into the object file appears feasible.

[0046] In existing technologies, after obtaining HTTPS packets from libpcap, Cisco's Joy can perform feature analysis on them. Joy is used to extract data features from real-time network traffic or pcap files, using a flow-oriented model similar to IPFIX or Netflow, and then representing these data features in JSON. It also includes analysis tools that can be applied to these data files.

[0047] Joy uses machine learning to extract original features from the original encrypted HTTPS data elements and then tests and verifies multiple algorithm models through a dataset to obtain a relatively reliable model. The message is then detected by the model to determine whether it is a threat and to take appropriate action.

[0048] Compared to methods like Wireshark that require obtaining keys or certificates from the client server, Joy is a better solution, capable of detecting most threat messages based on its signature model.

[0049] However, using Joy will require maintaining more code and incurring additional machine learning overhead. Many packet processing software programs based on DPI, such as IDS and IPS, already exist. Theoretically, we only need to pass the decrypted packets into these software engines to complete threat detection and processing. Using Joy, however, would require us to start from scratch, rebuilding and maintaining an entire solution, which would be a huge drain on manpower. Furthermore, the uncertainties introduced by machine learning could lead to customer distrust.

[0050] In view of the technical difficulties existing in the prior art, this application proposes a method for HTTPS packet detection in Linux systems. Based on EBPF technology, it bypasses certificate authentication and extracts and assembles the decrypted HTTPS packets into packets that can be detected by commonly used IDS / IPS engines, reducing the focus on actual packet threats. The method in this application allows for the separate processing of HTTPS packets into plaintext data for the detection engine using third-party software, even when an IDS / IPS solution already exists in the Linux system, without requiring keys or certificates.

[0051] The content of this application will be described in detail below with the aid of specific embodiments.

[0052] Figure 1This is a system block diagram illustrating an HTTPS packet detection method and apparatus for a Linux system according to an exemplary embodiment.

[0053] like Figure 1 As shown, system architecture 10 may include terminal devices 101, 102, and 103, network 104, server 105, and remote platform 106. Network 104 is used as a medium to provide communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0054] Users can use terminal devices 101, 102, and 103 to interact with the remote platform 106 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0055] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0056] Server 105 can be a server that provides message security detection. During the process of users accessing the remote platform 106 using terminal devices 101, 102, and 103, server 105 can analyze and process the HTTPS messages sent by terminal devices 101, 102, and 103, and feed back the processing results (whether they contain malicious code) to the administrator.

[0057] Server 105 may be configured based on a Linux system, for example; server 105 may extract application layer plaintext data and environment data of the HTTPS message, for example; server 105 may extract skb structure data of the HTTPS message, for example; server 105 may match the application layer data and the skb structure data based on the environment data, for example; server 105 may concatenate the application layer data and the skb structure data to generate a plaintext message after a successful match, for example; server 105 may use an IDS / IPS intrusion detection engine to detect the plaintext message, for example.

[0058] Server 105 can be a single physical server, or it can be composed of multiple servers. It should be noted that the HTTPS packet detection method for Linux systems provided in this application embodiment can be executed by server 105. Correspondingly, the HTTPS packet detection device for Linux systems can be set in server 105.

[0059] Figure 2 This is a schematic diagram illustrating an HTTPS packet detection method and apparatus for a Linux system according to an exemplary embodiment. Figure 2 As shown, a threat detection system for HTTPS encrypted protocol messages based on EFB technology can be established according to the technology in this application. This system may include a shared library file and function locator module, an ELF file parser module, an application layer data capture module, an HTTPS message capture module, a message assembly processor module, and a message detection engine module.

[0060] The shared library file and function location module can perform functions such as non-standard path parsing, standard path acquisition, shared path storage, and shared library matching.

[0061] The ELF file parsing module can perform functions such as obtaining ELF file paths and obtaining ELF file function offsets.

[0062] The application layer data capture module can realize functions such as loading uprobe, acquiring and analyzing application layer data, acquiring uprobe program data, storing and processing application data.

[0063] The HTTPS message capture module can perform functions such as loading cls_bdf, acquiring kernel network data, acquiring cls_bdf program data, and acquiring kernel network data.

[0064] The message assembly machine processing module can realize functions such as message matching mechanism, message assembly, message storage, and message playback.

[0065] The message detection engine module may include an HTTPS plaintext message processing program, an HTTPS threat detection program, and an HTTPS threat log reporting program, enabling various functions of message detection and identification.

[0066] Figure 3 This is a flowchart illustrating an HTTPS packet detection method for a Linux system according to another exemplary embodiment. The HTTPS packet detection method 30 for a Linux system includes at least steps S302 to S312.

[0067] like Figure 3 As shown, in S302, the Linux system captures HTTPS messages. Figure 2 As shown, HTTPS packets can be captured through methods such as loading with cls_bdf, obtaining kernel network data, obtaining program data with cls_bdf, and kernel network data.

[0068] In step S304, the application layer plaintext data and environment data of the HTTPS message are extracted. The application layer plaintext data and environment data of the HTTPS message can be extracted using the uprobe technology in an SSL shared library.

[0069] In one embodiment, the method may include, for example,: obtaining the ELF file of the Linux system; parsing the ELF file to obtain the offsets of the SSL / TLS encryption / decryption functions; hooking the entry and exit points of the SSL / TLS encryption / decryption functions using an uprobe; and creating perf event resources.

[0070] In one embodiment, the process may include, for example, creating a linked list based on an SSL shared library and sequentially polling for matching; obtaining an ELF dynamic symbol table based on the polling and matching; polling the ELF dynamic symbol table to obtain a specified function and offset; and obtaining the application layer plaintext data and environment data of the HTTPS message based on the specified function and offset.

[0071] In one embodiment, this may include, for example, sending the application-layer plaintext data and the environment data to the user-layer application via a perf event.

[0072] In S306, the skb structure data of the HTTPS message is extracted. The cls_bpf technique can be used in the kernel network driver to extract the skb structure data of the HTTPS message.

[0073] In one embodiment, this may include, for example, hooking the ingress and egress functions in QoS using a classifier in the traffic controller; and creating a perf event resource.

[0074] In one embodiment, it may include, for example, inserting the cls_bpf code into the ingress and egress functions of the classifier function in the kernel network driver; and extracting the skb structure data of the HTTPS message based on the ingress and egress functions.

[0075] In one embodiment, this may include, for example, sending the skb structure data to the user-level application via a perf event.

[0076] In S308, the application layer data and the skb structure data are matched based on the environmental data. The environmental data can match plaintext application layer data with the skb structure.

[0077] In step S310, after a successful match, the application layer data and the skb structure data are concatenated to generate a plaintext message. Alternatively, after a successful match, encrypted application layer data can be extracted from the HTTPS message based on the skb structure data; the encrypted real-time application layer data can then be replaced with the plaintext application layer data to generate the plaintext message.

[0078] More specifically, the encrypted application layer data in the complete message can be replaced with plaintext data, thus obtaining a complete plaintext HTTPS message, which can be directly stored as a message format or replayed for use by common IPS / IDS services to detect threats.

[0079] In S312, the plaintext packets are detected using an IDS / IPS intrusion detection engine. For example, after replaying the packets using the libpcap extension library, the IDS / IPS engine is used to obtain data from a specified network interface card, and HTTPS session packets are filtered and parsed. After obtaining the attack logs by matching attack rules, the attack logs are provided.

[0080] According to the HTTPS packet detection method for Linux systems in this application, HTTPS packets are captured through the Linux system; application-layer plaintext data and environment data of the HTTPS packets are extracted; skb structure data of the HTTPS packets are extracted; the application-layer data and skb structure data are matched based on the environment data; after successful matching, the application-layer data and skb structure data are concatenated to generate plaintext packets; and the plaintext packets are detected using an IDS / IPS intrusion detection engine. This method can bypass certificate authentication, extract and assemble decrypted HTTPS packets to form packets that can be detected by commonly used IDS / IPS engines, thereby improving packet detection efficiency and accuracy.

[0081] It should be clearly understood that this application describes how specific examples are formed and used, but the principles of this application are not limited to any details of these examples. Rather, based on the teachings of the disclosure of this application, these principles can be applied to many other embodiments.

[0082] Figure 4 This is a flowchart illustrating an HTTPS message detection method for a Linux system according to another exemplary embodiment. Figure 4 The process shown in step 40 is... Figure 2 The process shown is described in detail for S102 "".

[0083] like Figure 4 As shown, in S402, the SSL / TLS library file (ELF file) in the system is obtained.

[0084] In S404, the ELF file is parsed and the SSL / TLS encryption / decryption function offsets are located.

[0085] In S406, the uprobe is used to hook the entry and exit points of SSL / TLS encryption / decryption functions.

[0086] In S408, create the perf event.

[0087] In S410, the user-side application obtains the perf event.

[0088] In S412, the application layer plaintext data and other related data in the perf event are obtained.

[0089] In S414, the classifier in the flow controller TC hooks the ingress and egress functions.

[0090] In S416, create the perf event.

[0091] In S418, the user-side application obtains the perf event.

[0092] In S420, retrieve message data and other related data from the perf event.

[0093] In S422, the data on both sides of the message td is matched and concatenated into a plaintext message.

[0094] In S424, IPS / IDS detects plaintext messages.

[0095] The proposed HTTPS packet detection method for Linux systems directly utilizes Linux's dynamic link library management mechanism and ELF file disassembly. It only requires providing the fuzzy name of the required library file and its functions to locate the library file and its function offset.

[0096] The proposed HTTPS packet detection method for Linux systems uses Uprobe technology to directly obtain plaintext HTTPS application layer data and uses cls_bpf to obtain the complete packet. Therefore, it can obtain the complete plaintext HTTPS packet without providing a key or certificate.

[0097] The proposed HTTPS packet detection method for Linux systems utilizes the libpcap extension package's playback function, enabling IDS / IPS to quickly process the acquired HTTPS packets, forming a complete HTTPS attack detection system that requires no keys or certificates.

[0098] In summary, the HTTPS packet detection method for Linux systems proposed in this application has the following advantages:

[0099] (1) It does not depend on a specified Linux system, shared library path, or custom-generated shared libraries in the hypothetical scenario.

[0100] (2) By using ebpf technology, we can obtain HTTPS plaintext data even if we cannot obtain the key / certificate.

[0101] (3) Under the existing IPS / IDS service, only the third-party software development for plaintext packet acquisition can be carried out, reducing the secondary development of repetitive functions.

[0102] Originally, Linux obtained library function offsets directly from specified library files by manually executing shell commands. This required developers to be familiar with SSL library files and corresponding shell commands, and to manually add them to configuration files. Switching systems, changing file locations, or upgrading files could cause the original configuration to become ineffective.

[0103] For library files, the common practice in Linux is to first look for non-standard paths, that is, to store them in the / etc / ld.so.conf file, and then generate / etc / ld.so.cache through ldconfig. When ld.so loads shared libraries, it first looks in ld.so.cache, and then looks for standard library files ( / lib / , / usr / lib / or / lib64 / , / usr / lib64 / ).

[0104] In this application, the directory where the library files are located is obtained by parsing the Linux system configuration file " / etc / ld.conf.d", and the standard library files are also obtained at the same time. Figure 5 This is a schematic diagram illustrating an HTTPS message detection method for a Linux system according to another exemplary embodiment.

[0105] like Figure 5 As shown, first, a linked list is created and initialized; more specifically, a library file directory linked list and a matching linked list are created.

[0106] The library file directory chain includes the library file directory and the next node information.

[0107] The matching list includes the filename of the library to be matched, the path of the matching library file, the next node information, and the library file function list.

[0108] The library file function list includes the function name, function offset, and next node information.

[0109] Next, retrieve the configuration of the master configuration file, which contains the directory of all library file matching files.

[0110] Save the targets pointed to by these matching files to a linked list of library file directories.

[0111] Obtain the required matching library file name and its function.

[0112] Save the information to the matching list and the library file function list.

[0113] Poll the list of library file directories to obtain the library file paths and function offsets, and store them in a matching list and a function list. In subsequent processes, use the library files and function offsets as needed.

[0114] In practical applications, a linked list is created to sequentially poll the matching library file names and find the offsets of relevant functions within the library file based on the symbol table in the library file structure (ELF structure). This method supports all Linux systems to completely locate the file location and offset of functions in the target file. It obtains the ELF dynamic symbol table by polling the ELF header table and then polls to obtain the specified function and its offset.

[0115] More specifically, the function offsets in the library files (libssl.so / libgnutls.so, etc.) obtained through ebpf technology mentioned above are used to insert code into functions (SSL_write, SSL_read) within these files. Before and after the execution of these functions, plaintext HTTPS application-layer data and related environmental data are obtained and sent to the user-layer application via the perf event. This solution bypasses the HTTPS decryption step and directly obtains plaintext application-layer data.

[0116] Because cls_bpf enables potential programming of the classifier in the tc (traffic controller), control over functions within the classifier can be achieved through EBPF programming. This patent uses EBPF to insert code into the ingress and egress of the classifier to obtain the kernel skb structure and sends it to the user-layer application via perf events. This skb structure contains the complete HTTPS message and environmental data.

[0117] Those skilled in the art will understand that all or part of the steps of the above embodiments are implemented as a computer program executed by a CPU. When the computer program is executed by the CPU, it performs the functions defined by the method provided in this application. The program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk.

[0118] Furthermore, it should be noted that the above figures are merely illustrative representations of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0119] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0120] Figure 6 This is a block diagram illustrating an HTTPS packet detection apparatus for a Linux system according to another exemplary embodiment. Figure 6 As shown, the HTTPS packet detection device 60 for Linux systems includes: a capture module 602, a plaintext module 604, a structure module 606, a matching module 608, a splicing module 610, and a detection module 612.

[0121] The capture module 602 is used to capture HTTPS packets in Linux systems;

[0122] The plaintext module 604 is used to extract the application layer plaintext data and environment data of the HTTPS message; the plaintext module 604 is also used to extract the application layer plaintext data and environment data of the HTTPS message using the uprobe technology in the SSL shared library.

[0123] The structure module 606 is used to extract the skb structure data of the HTTPS message; the structure module 606 is also used to extract the skb structure data of the HTTPS message using the cls_bpf technology in the kernel network driver.

[0124] The matching module 608 is used to match the application layer data and the skb structure data based on the environmental data;

[0125] The splicing module 610 is used to splice the application layer data and the skb structure data to generate a plaintext message after a successful match; the splicing module 610 is also used to extract the encrypted application layer data from the HTTPS message based on the skb structure data after a successful match; and replace the encrypted real-time application layer data with the application layer plaintext data to generate the plaintext message.

[0126] The detection module 612 is used to detect the plaintext packets using the IDS / IPS intrusion detection engine.

[0127] The HTTPS packet detection device for Linux systems according to this application captures HTTPS packets through the Linux system; extracts application-layer plaintext data and environment data from the HTTPS packets; extracts skb structure data from the HTTPS packets; matches the application-layer data and skb structure data based on the environment data; after successful matching, concatenates the application-layer data and skb structure data to generate plaintext packets; and uses an IDS / IPS intrusion detection engine to detect the plaintext packets. This method can bypass certificate authentication, extract and assemble decrypted HTTPS packets to form packets that can be detected by commonly used IDS / IPS engines, thereby improving packet detection efficiency and accuracy.

[0128] Figure 7 This is a block diagram illustrating an electronic device according to an exemplary embodiment.

[0129] The following reference Figure 7 To describe an electronic device 700 according to this embodiment of the present application. Figure 7 The electronic device 700 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0130] like Figure 7 As shown, the electronic device 700 is presented in the form of a general-purpose computing device. The components of the electronic device 700 may include, but are not limited to: at least one processing unit 710, at least one storage unit 720, a bus 730 connecting different system components (including storage unit 720 and processing unit 710), a display unit 740, etc.

[0131] The storage unit stores program code that can be executed by the processing unit 710, causing the processing unit 710 to perform the steps described in this specification according to various exemplary embodiments of this application. For example, the processing unit 710 can perform actions such as... Figure 3 , Figure 4 , Figure 5 The steps are shown in the figure.

[0132] The storage unit 720 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 7201 and / or a cache storage unit 7202, and may further include a read-only memory unit (ROM) 7203.

[0133] The storage unit 720 may also include a program / utility 7204 having a set (at least one) program module 7205, such program module 7205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0134] Bus 730 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0135] Electronic device 700 can also communicate with one or more external devices 700' (e.g., keyboard, pointing device, Bluetooth device, etc.), enabling users to communicate with devices that interact with electronic device 700, and / or any device (e.g., router, modem, etc.) that allows electronic device 700 to communicate with one or more other computing devices. This communication can be performed via input / output (I / O) interface 750. Furthermore, electronic device 700 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 760. Network adapter 760 can communicate with other modules of electronic device 700 via bus 730. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0136] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software, or by combining software with necessary hardware. Therefore, as... Figure 8 As shown, the technical solution according to the embodiments of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) or on a network, and includes several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the above-described method according to the embodiments of this application.

[0137] The software product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0138] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0139] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0140] The aforementioned computer-readable medium carries one or more programs. When these programs are executed by a device, the computer-readable medium performs the following functions: a Linux system captures HTTPS packets; extracts application-layer plaintext data and environment data from the HTTPS packets; extracts skb structure data from the HTTPS packets; matches the application-layer data and the skb structure data based on the environment data; after successful matching, concatenates the application-layer data and the skb structure data to generate plaintext packets; and detects the plaintext packets using an IDS / IPS intrusion detection engine.

[0141] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0142] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0143] Exemplary embodiments of this application have been specifically shown and described above. It should be understood that this application is not limited to the detailed structures, arrangements, or implementation methods described herein; rather, this application is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A method for detecting HTTPS packets in a Linux system, characterized in that, include: Linux system captures HTTPS packets; Extracting the application layer plaintext data and environment data of the HTTPS message, including: using the uprobe technology in an SSL shared library to extract the application layer plaintext data and environment data of the HTTPS message; Extracting the skb structure data of the HTTPS message using cls_bpf technology in the kernel network driver includes: inserting cls_bpf code into the ingress and egress functions of the classifier function in the kernel network driver, and extracting the number of skb structures of the HTTPS message based on the ingress and egress functions; The application layer plaintext data and the skb structure data are matched based on the environmental data. After a successful match, the application layer plaintext data and the skb structure data are concatenated to generate a plaintext message, including: after a successful match, extracting the encrypted application layer data from the HTTPS message based on the skb structure data, and replacing the encrypted real-time application layer data with the application layer plaintext data to generate the plaintext message; The plaintext packets are detected using an IDS / IPS intrusion detection engine.

2. The method as described in claim 1, characterized in that, Before using the uprobe technology in the SSL shared library to extract the application layer plaintext data and environment data of the HTTPS message, the following steps are also included: Obtain ELF files from the Linux system; Parse the ELF file to obtain the offsets of the SSL / TLS encryption / decryption functions; Hook the entry and exit points of SSL / TLS encryption / decryption functions using an uprobe; Create perf event resources.

3. The method as described in claim 1, characterized in that, The application layer plaintext data and environment data of the HTTPS message are extracted using the uprobe technology in the SSL shared library, including: Create a linked list based on the SSL shared library and perform round-robin matching; The ELF dynamic symbol table is obtained based on the polling matching; Based on the ELF dynamic symbol table, the specified function and offset are obtained through polling. The application layer plaintext data and environment data of the HTTPS message are obtained based on the specified function and offset.

4. The method as described in claim 1, characterized in that, After extracting the application layer plaintext data and environment data of the HTTPS message using the uprobe technology in the SSL shared library, the process also includes: The application layer plaintext data and the environment data are sent to the user layer application via the perf event.

5. The method as described in claim 1, characterized in that, Before using the cls_bpf technique in the kernel network driver to extract the skb structure data of the HTTPS message, the following steps are also included: Hook the ingress and egress functions in QoS using a classifier in the flow controller; Create perf event resources.

6. The method as described in claim 1, characterized in that, After extracting the skb structure data of the HTTPS message using the cls_bpf technique in the kernel network driver, the following is also included: The skb structure data is sent to the user-level application via the perf event.

7. A device for detecting HTTPS packets in a Linux system, characterized in that, include: The capture module is used to capture HTTPS packets on Linux systems. The plaintext module is used to extract the application layer plaintext data and environment data of the HTTPS message, including: using the uprobe technology in the SSL shared library to extract the application layer plaintext data and environment data of the HTTPS message; The structure module is used to extract the skb structure data of the HTTPS message using the cls_bpf technology in the kernel network driver, including: inserting the cls_bpf code into the ingress and egress functions of the classifier function in the kernel network driver, and extracting the number of skb structures of the HTTPS message based on the ingress and egress functions; A matching module is used to match the application layer plaintext data and the skb structure data based on the environmental data; The splicing module is used to splice the application layer plaintext data and the skb structure data to generate a plaintext message after a successful match. This includes: extracting encrypted application layer data from the HTTPS message based on the skb structure data after a successful match, and replacing the encrypted real-time application layer data with the application layer plaintext data to generate the plaintext message. The detection module is used to detect the plaintext packets using the IDS / IPS intrusion detection engine.

Images