Vulnerability scanning engine implementation method and device, vulnerability scanning method and electronic device
By using a vulnerability scanning engine developed in Go, the problems of complex deployment and difficult expansion of the OpenVAS framework are solved, and an efficient and flexible vulnerability scanning solution is achieved, which is suitable for multi-platform environments.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING KNOWNSEC INFORMATION TECHNOLOGY CO LTD
- Filing Date
- 2022-10-08
- Publication Date
- 2026-07-24
AI Technical Summary
The existing OpenVAS vulnerability scanning framework is complex to deploy and not easily scalable, making it difficult to meet the needs of modern network security.
A vulnerability scanning engine is implemented using the Go programming language, including a lexical parser, plugin loader, scheduler, and result parsing unit. The Go language is used to generate the scanner and multiple vulnerability scanning plugins, generate an installation package, and support multi-platform deployment and plugin expansion.
It achieves high-performance vulnerability scanning, is easy to deploy, can quickly analyze and locate problems, and can be easily extended with vulnerability scanning plugins, making it suitable for multiple platforms.
Smart Images
Figure CN115544518B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and more specifically, to a vulnerability scanning engine implementation method, apparatus, vulnerability scanning method, and electronic device. Background Technology
[0002] Host vulnerability scanning is a host-based scanning method that uses a vulnerability database to detect the security vulnerabilities of a specified remote or local computer system through scanning and other means, and is a security detection behavior that discovers vulnerabilities.
[0003] By scanning for network and security vulnerabilities, system administrators can discover the allocation of various TCP / IP ports, open services, web service software versions, and security vulnerabilities of these services and software on the network that the web servers they maintain. Network security vulnerability scanning technology also uses an active, non-destructive approach to examine whether a system is potentially vulnerable to attack and crash. It utilizes a series of scripts to simulate attack behavior on the system and analyzes the results. This technology is commonly used for simulated attack experiments and security audits.
[0004] Currently, OpenVAS is commonly used for vulnerability scanning. OpenVAS is part of Greenbone Networks' commercial vulnerability management solution; it's a framework integrating multiple services and tools, providing a powerful and comprehensive vulnerability scanning and management solution. However, the open-source OpenVAS has formed a complete framework, containing many necessary components, making deployment relatively complex and not easily scalable. Summary of the Invention
[0005] This application provides a vulnerability scanning engine implementation method, vulnerability scanning method, device, electronic device, and readable storage medium. It can implement the vulnerability scanning engine based on the open-source programming language Golang. The engine inherits the high performance characteristics of Go, which facilitates the analysis and location of problems and is easy to deploy. Furthermore, the engine implements vulnerability scanning based on vulnerability scanning plugins, which can be easily extended.
[0006] The embodiments of this application can be implemented as follows:
[0007] In a first aspect, embodiments of this application provide a method for implementing a vulnerability scanning engine. The vulnerability scanning engine includes a scanner and a vulnerability scanning plugin. The scanner includes a lexical analyzer, a function to be used, a plugin loader, a scheduler, and a result parsing unit. The method includes:
[0008] According to the yacc lexical analyzer standard, the syntax of the target language is implemented using the Go language to obtain the lexical analyzer, wherein the target language is the language used by the vulnerability scanning plugin;
[0009] The Go programming language is used to generate the functions to be used, the plugin loader, the scheduler, and the result parsing unit.
[0010] Obtain multiple vulnerability scanning plugins;
[0011] An installation package is generated based on the generated scanner and the multiple vulnerability scanning plugins.
[0012] Secondly, embodiments of this application provide a vulnerability scanning method, the method comprising:
[0013] Input scanning parameters into the vulnerability scanning engine, wherein the vulnerability scanning engine is obtained based on any of the vulnerability scanning engine implementation methods described in the foregoing embodiments, and the scanning parameters are controlled by means of command line, file, environment variable configuration, and the scanning parameters include a scanning target list and a plugin list, wherein the scanning target list includes at least one scanning target, and the plugin list includes the plugin identifier of the vulnerability scanning plugin;
[0014] The vulnerability scanning engine is used to perform a scan based on the scanning parameters to obtain a summary scan result.
[0015] Thirdly, embodiments of this application provide a vulnerability scanning engine implementation apparatus. The vulnerability scanning engine includes a scanner and a vulnerability scanning plugin. The scanner includes a lexical parser, a function to be used, a plugin loader, a scheduler, and a result parsing unit. The apparatus includes:
[0016] The first obtaining module is used to implement the syntax of the target language in Go language according to the standard of the yacc lexical analyzer, so as to obtain the lexical analyzer, wherein the target language is the language used by the vulnerability scanning plugin;
[0017] The first obtaining module is further configured to use the Go language to generate the function to be used, the plugin loader, the scheduler, and the result parsing unit;
[0018] The second acquisition module is used to acquire multiple vulnerability scanning plugins;
[0019] The installation package generation module is used to generate an installation package based on the generated scanner and the multiple vulnerability scanning plugins.
[0020] Fourthly, embodiments of this application provide a vulnerability scanning device, the device comprising:
[0021] The control module is used to input scanning parameters to the vulnerability scanning engine. The vulnerability scanning engine is based on the vulnerability scanning engine implementation method. The scanning parameters are controlled by means of command line, file, and environment variable configuration. The scanning parameters include a scan target list and a plugin list. The scan target list includes at least one scan target, and the plugin list includes the plugin identifier of the vulnerability scanning plugin.
[0022] The scanning module is used to perform a scan using the vulnerability scanning engine based on the scanning parameters and obtain a summary scan result.
[0023] Fifthly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor can execute the machine-executable instructions to implement the vulnerability scanning engine implementation method described in the foregoing embodiments, or to implement the vulnerability scanning method described in the foregoing embodiments.
[0024] Sixthly, embodiments of this application provide a readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the foregoing embodiments.
[0025] This application provides a vulnerability scanning engine implementation method, vulnerability scanning method, apparatus, electronic device, and readable storage medium. The vulnerability scanning engine includes a scanner and vulnerability scanning plugins. The scanner includes a lexical analyzer, a function to be used, a plugin loader, a scheduler, and a result parsing unit. Based on the yacc lexical analyzer standard, the syntax of the target language is implemented using Go to obtain the lexical analyzer, wherein the target language is the language used by the vulnerability scanning plugins. The function to be used, the plugin loader, the scheduler, and the result parsing unit are generated using Go, and multiple vulnerability scanning plugins are obtained. Finally, an installation package is generated based on the generated scanner and the multiple vulnerability scanning plugins. Thus, a vulnerability scanning engine implemented based on Go inherits the high-performance characteristics of Go, facilitates problem analysis and localization, is easy to deploy, and can be easily extended with vulnerability scanning plugins. Attached Figure Description
[0026] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0027] Figure 1A block diagram illustrating an electronic device provided in an embodiment of this application;
[0028] Figure 2 A flowchart illustrating the vulnerability scanning engine implementation method provided in this application embodiment;
[0029] Figure 3 for Figure 2 A flowchart illustrating the sub-steps included in step S140;
[0030] Figure 4 A flowchart illustrating the vulnerability scanning method provided in this application embodiment;
[0031] Figure 5 for Figure 4 A flowchart illustrating the sub-steps included in step S220;
[0032] Figure 6 for Figure 5 A flowchart illustrating the sub-steps included in the neutron step S221;
[0033] Figure 7 A block diagram illustrating the vulnerability scanning engine implementation device provided in the embodiments of this application;
[0034] Figure 8 This is a block diagram of a vulnerability scanning device provided in an embodiment of this application.
[0035] Icons: 100 - Electronic device; 110 - Memory; 120 - Processor; 130 - Communication unit; 200 - Vulnerability scanning engine implementation device; 210 - First acquisition module; 220 - Second acquisition module; 230 - Installation package generation module; 300 - Vulnerability scanning device; 310 - Control module; 320 - Scanning module. Detailed Implementation
[0036] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0037] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0038] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 a process, method, article, or apparatus. Without further limitations, 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 said element.
[0039] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.
[0040] Please refer to Figure 1 , Figure 1 This is a block diagram of an electronic device 100 provided in an embodiment of this application. The electronic device 100 may be, but is not limited to, a computer, a server, etc. Depending on the application scenario, the electronic device 100 may be used to implement a vulnerability scanning engine, or may utilize the vulnerability scanning engine to perform vulnerability scanning. The electronic device 100 includes a memory 110, a processor 120, and a communication unit 130. The memory 110, processor 120, and communication unit 130 are electrically connected directly or indirectly to each other to achieve data transmission or interaction. For example, these components may be electrically connected to each other through one or more communication buses or signal lines.
[0041] The memory 110 is used to store programs or data. The memory 110 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.
[0042] The processor 120 is used to read / write data or programs stored in the memory 110 and execute corresponding functions. For example, the memory 110 stores a vulnerability scanning engine implementation device or a vulnerability scanning device, which includes at least one software functional module that can be stored in the memory 110 in the form of software or firmware. The processor 120 executes various functional applications and data processing by running the software programs and modules stored in the memory 110, such as the vulnerability scanning engine implementation device in the embodiments of this application, thereby implementing the vulnerability scanning engine implementation method in the embodiments of this application; or, for example, the processor 120 implements the vulnerability scanning method in the embodiments of this application by running the vulnerability scanning device.
[0043] The communication unit 130 is used to establish a communication connection between the electronic device 100 and other communication terminals through the network, and to send and receive data through the network.
[0044] It should be understood that, Figure 1 The structure shown is only a schematic diagram of the electronic device 100. The electronic device 100 may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.
[0045] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating the vulnerability scanning engine implementation method provided in this application embodiment. The method can be applied to the aforementioned electronic device 100. The specific flow of the vulnerability scanning engine implementation method is described in detail below. In this embodiment, the vulnerability scanning engine includes a scanner and a vulnerability scanning plugin. The scanner includes a lexical parser, a function to be used, a plugin loader, a scheduler, and a result parsing unit. The method includes steps S110 to S140.
[0046] Step S110: According to the yacc lexical analyzer standard, implement the syntax of the target language using the Go language to obtain the lexical analyzer.
[0047] In this embodiment, the target language's syntax can be implemented using Go, based on the yacc lexical analyzer's custom standards, thereby generating the lexical analyzer using Go. This process can be as follows: Write the corresponding syntax file in Go according to the yacc lexical analyzer's syntax, and then use the yacc tool to generate the corresponding Go version of the analyzer.
[0048] The target language is the language used by the vulnerability scanning plugin. The lexical analyzer is used to parse the plugin based on the target language into a syntax tree. For example, if the target language is Nasl, the above steps involve using yacc to generate a Go version of the Nasl lexical analyzer, which can parse the Nasl plugin into a syntax tree.
[0049] Go (Golang) is a statically typed, compiled, concurrent programming language developed by Google, featuring garbage collection. Nasl (Nessus Attack Scripting Language) is a scripting language designed for the Nessus security scanner. Its purpose is to allow anyone to write test code for a given security vulnerability within minutes, and to allow people to share their test code without worrying about what operating system they are using.
[0050] Step S120: Use the Go language to generate the function to be used, plugin loader, scheduler and result parsing unit.
[0051] In this embodiment, the Go programming language can also be used to generate functions that the vulnerability scanning engine needs to use when performing vulnerability scanning. These functions can be those used by the lexical analyzer during lexical analysis, and can be specifically set according to actual needs.
[0052] A plugin loader can also be generated using the Go language. This plugin loader is used to load the corresponding vulnerability scanning plugins when the vulnerability scanning engine needs to be used for vulnerability scanning.
[0053] A scheduler and a result parsing unit can also be generated using the Go language. The scheduler is used for task allocation and management, while the result parsing unit is used to summarize the information obtained by executing the vulnerability scanning plugin to obtain the scan summary results.
[0054] Step S130: Obtain multiple vulnerability scanning plugins.
[0055] The vulnerability scanning plugin obtained uses the target language.
[0056] Step S140: Generate an installation package based on the generated scanner and the plurality of vulnerability scanning plugins.
[0057] Steps S110 and S120 can be used to implement a scanner using the Go language, and then based on the generated scanner and the obtained multiple vulnerability scanning plugins, an installation package corresponding to the vulnerability scanning engine can be generated.
[0058] Thus, a vulnerability scanning engine was implemented based on the open-source programming language Golang. This engine inherits Go's high-performance characteristics, facilitating problem analysis and localization. For example, Go provides the pprof tool to analyze memory and CPU usage, and the trace tool to easily trace stack traces. Based on memory and CPU usage, as well as stack traces, problem analysis and localization are easily achieved. Furthermore, the vulnerability scanning engine implemented in this embodiment is primarily for vulnerability scanning and does not include components for implementing other services, thus consuming fewer resources and being easy to deploy. In addition, this vulnerability scanning engine uses existing vulnerability scanning plugin languages, allowing for easy extension of vulnerability scanning plugins.
[0059] As one possible implementation, the vulnerability scanning plugin is a Nasl plugin, the target language is Nasl, and the syntax of the target language is Nasl. The scanner implemented in Go includes a Nasl lexical parser for resolving the Nasl plugin. After parsing the loaded plugin using this Nasl lexical parser, the corresponding network request operations can be executed according to the Nasl code.
[0060] The specific Nasl syntax implemented in Go can be determined based on actual needs. For example, the implemented Nasl syntax may include at least one of the following: type definition, basic operator definition, arithmetic operations, string operations, comparison operators, logical operators, bitwise operators, loop control flow, variable definition, function definition, and function call.
[0061] As one possible implementation, the functions to be used include built-in functions of the Nasl language and Nasl library functions. These functions may include at least one of the following: knowledge base functions, report generation functions, description functions, glue functions, network functions, string manipulation functions, HTTP functions, IP manipulation functions, and password processing functions.
[0062] The knowledge base stores intermediate values generated during the execution of each plugin, providing them for use by subsequent plugins and avoiding redundant logic. Knowledge base functions are used to perform operations such as inserting and retrieving values from the knowledge base, such as `set_kb_item` and `get_kb_item`.
[0063] When the functions to be used include knowledge base functions, a knowledge base can also be built based on a Redis database. The knowledge base functions are used to operate on the knowledge base, and the knowledge base is used to record information discovered during the scanning process. That is, Redis is used to implement support for knowledge base functions such as "set_kb_item" and "get_kb_item" in NAS. Host information discovered during the plugin scanning process (including port allocation, open services, service software versions, etc.) can be recorded, facilitating subsequent plugin use, reducing redundant scanning, and improving scanning efficiency.
[0064] Data from other asset scanning tools, such as nmap, zmap, and masscan, can also be integrated into this knowledge base to expand its information. For example, port information scanned using other tools can be stored in this knowledge base. This reduces the need for redundant scanning plugins.
[0065] Plugins may have dependencies on each other. For example, a later plugin might determine whether to execute a service based on the services running on port 80 scanned by the previous plugin, thus identifying the service version. Plugin A might determine the version of service 1; if service 1 is not among the services running on port 80, then plugin A can choose not to run. Plugins exchange information with each other through a knowledge base.
[0066] In this embodiment, the scanner's scanning parameters can be controlled through three configuration methods: command line, file, and environment variables. The scanning parameters can include configurations for: a scan target list, a plugin list, timeout, Redis, and logs. The command line parsing is implemented using the `falag` library from the Go standard library, and a YAML configuration file is used. The scan target list includes the targets to be scanned, each represented by an IP address. The plugin list can include plugin identifiers for the vulnerability scanning plugins to be used. When configuring Redis, the Redis address, username, password, etc., can be configured, facilitating the storage of relevant information in the knowledge base. When configuring logs, the output filename, log level, etc., can be configured; the log level indicates the type of information to be recorded in the log.
[0067] The plugin loader loads vulnerability scanning plugins according to the configuration and parses them using the lexical analyzer obtained in step S110. This parsing process can be divided into preloading and execution. During preloading, the plugin loader reads the plugins, and the lexical analyzer performs plugin dependency analysis and priority analysis to form a plugin dependency chain. The execution order of plugins at different levels is determined based on their respective priorities. Then, the plugins are executed sequentially according to the dependency chain, and later-executed plugins can reference the results of previously executed plugins through a knowledge base.
[0068] The specific vulnerability scanning plugins loaded can be determined based on the actual situation. For example, all plugins in the plugin list can be loaded, only some plugins can be loaded, or, if the user or other devices have specified vulnerability scanning plugins for different scanning targets, only the vulnerability scanning plugin corresponding to a specific scanning target can be loaded when scanning a certain target.
[0069] The scheduler can utilize Go's grooutine feature to scan multiple targets in parallel. During this process, the scheduler can divide multiple targets and plugins into multiple "workers" for execution, improving CPU utilization and accelerating the scanning speed. Specifically, a target and its corresponding plugins are assigned to one "worker," and different targets can reside in different "workers."
[0070] The result parsing unit aggregates the scan results of each scan target to obtain an aggregated result; and, when a plugin generates CPE information, it matches the CPE information generated by each plugin with a preset component table to obtain a matching result. The component table includes vulnerability information corresponding to different components; by matching with the component table, it can be determined whether the vulnerability corresponding to the CPE information exists. The final output of the aggregated and matching results is a scan summary result.
[0071] Please refer to Figure 3 , Figure 3 for Figure 2 A flowchart illustrating the sub-steps included in step S140. In this embodiment, step S140 may include sub-steps S141 to S142.
[0072] Sub-step S141: Based on multiple preset platform types, the Go language scanner file is cross-compiled to obtain binary files corresponding to different platform types.
[0073] Sub-step S142: For each platform type, based on the binary file corresponding to that platform type and the multiple vulnerability scanning plugins, generate an installation package corresponding to that platform type.
[0074] For example, if the platform types include Windows, Linux, and macOS, the Go language scanner file can be cross-compiled to obtain the corresponding binary files for each of these three platform types, i.e., compiled into binary executable programs. Specifically, the Windows executable file has a .exe extension, while Linux and macOS, being Unix-like systems, do not have an extension and are simply executable files. After obtaining the three types of binary files, a compressed package can be generated based on each binary file and the various vulnerability scanning plugins, resulting in three installers. Each installer includes the binary file corresponding to one platform type and the various vulnerability scanning plugins. This simplifies deployment and allows for portability across multiple platforms.
[0075] In this embodiment, the vulnerability scanning engine is implemented using the Go programming language. When adjustments to Nasl functions are needed, the Nasl implementation in the source code can be directly modified, thus allowing for convenient control over the Nasl function implementation and facilitating program analysis and optimization. Furthermore, asset scanning tool data can be integrated to expand the knowledge base. Component matching functionality can also be implemented through CPE analysis, further expanding vulnerability scanning data. The high concurrency performance of the Go programming language can also be leveraged to improve scanning efficiency. This engine uses existing Nasl plugin languages, allowing for easy expansion of vulnerability scanning plugins.
[0076] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating the vulnerability scanning method provided in an embodiment of this application. In this embodiment, the method may include steps S210 to S220.
[0077] Step S210: Input scanning parameters into the vulnerability scanning engine.
[0078] The vulnerability scanning engine is based on the aforementioned vulnerability scanning engine implementation method. The scanning parameters are controlled via command line, file, or environment variable configuration. The scanning parameters include a target list and a plugin list. The target list includes at least one target, and the plugin list includes the plugin identifier of the vulnerability scanning plugin.
[0079] Step S220: Use the vulnerability scanning engine to perform a scan based on the scanning parameters to obtain a summary scan result.
[0080] In this embodiment, the scan summary results may include aggregation results and matching results. This can be achieved through... Figure 5 The scan summary results are obtained as shown. Please refer to... Figure 5 , Figure 5 for Figure 4 A flowchart illustrating the sub-steps included in step S220. In this embodiment, step S220 may include sub-steps S221 to S223.
[0081] Sub-step S221: Based on the scanning parameters, the scanner executes the corresponding vulnerability scanning plugin for each scanning target to obtain the scanning results and CPE information obtained by each vulnerability scanning plugin.
[0082] Optionally, when the vulnerability scanning plugin is a NASL plugin, the plugin can be executed as follows: Figure 6 As shown. Please refer to... Figure 6 , Figure 6 for Figure 5 A flowchart illustrating the sub-steps included in neutron step S221. In this embodiment, sub-step S221 may include sub-steps S2211 to S2212.
[0083] Sub-step S2211: Use the plugin loader to read Nasl plugins and use the lexical parser to parse the read Nasl plugins to obtain the plugin dependency list.
[0084] Sub-step S2212: Execute the Nasl plugins sequentially according to the plugin dependency chain, and save the execution results to the knowledge base for use by other Nasl plugins.
[0085] The analysis includes the analysis of plugin dependencies and the analysis of plugin priorities.
[0086] The NASL plugin resolution process can be divided into preloading and execution. During preloading, the plugin dependencies in the "script_dependencies" function of the NASL plugin are analyzed, and a plugin dependency list is formed according to the categories set in the "script_category" function. Plugins are executed sequentially according to the dependency list, and later executed plugins can reference the results of previously executed plugins through a knowledge base. The "script_dependencies" function is called within the plugin to set other plugins that the plugin depends on. Each plugin calls the "script_category" function.
[0087] For example, the `script_category` function can be used to categorize the required plugins into 10 levels. Plugins at level 1 are run first. Since plugins at level 1 also have dependencies set by `script_depencies`, their execution order also needs to be determined according to the dependencies set by the `script_depencies` function. Therefore, the plugin dependency list obtained from the `script_dependencies` and `script_category` functions can be used.
[0088] In addition, when the scanner executes the vulnerability scanning plugin, the scheduler can utilize the Go language grooutine feature to perform parallel scanning on the multiple scanning targets, thereby improving CPU utilization and speeding up the scanning process.
[0089] By running vulnerability scanning plugins, you can obtain the scan results output by each plugin. Some vulnerability scans will also generate CPE information.
[0090] In sub-step S222, the result parsing unit aggregates the scanning results corresponding to each scanning target to obtain the aggregated result.
[0091] By aggregating the scan results, the results can be made more intuitive.
[0092] In sub-step S223, the result parsing unit matches the CPE information obtained by each vulnerability scanning plugin with a preset component table to obtain the matching result.
[0093] The component table includes vulnerability information for each different component.
[0094] To perform the corresponding steps in the above embodiments and various possible methods, an implementation method for a vulnerability scanning engine implementation device 200 and a vulnerability scanning device 300 is given below. Optionally, the device can adopt the above-described... Figure 1 The device structure of the electronic device 100 shown is illustrated. It should be noted that the device provided in this embodiment has the same basic principle and technical effects as the embodiments described above. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments.
[0095] Please refer to Figure 7 , Figure 7This is a block diagram of a vulnerability scanning engine implementation device 200 provided in an embodiment of this application. The vulnerability scanning engine includes a scanner and vulnerability scanning plugins. The scanner includes a lexical parser, a function to be used, a plugin loader, a scheduler, and a result parsing unit. The vulnerability scanning engine implementation device 200 may include a first acquisition module 210, a second acquisition module 220, and an installation package generation module 230.
[0096] The first obtaining module 210 is used to implement the syntax of the target language using the Go language according to the yacc lexical analyzer standard, in order to obtain the lexical analyzer. The target language is the language used by the vulnerability scanning plugin.
[0097] The first obtaining module 210 is also used to generate the function to be used, the plugin loader, the scheduler and the result parsing unit using the Go language.
[0098] The second acquisition module 220 is used to acquire multiple vulnerability scanning plugins.
[0099] The installation package generation module 230 is used to generate an installation package based on the generated scanner and the multiple vulnerability scanning plugins.
[0100] Please refer to Figure 8 , Figure 8 This is a block diagram of a vulnerability scanning device 300 provided in an embodiment of this application. The vulnerability scanning device 300 may include a control module 310 and a scanning module 320.
[0101] The control module 310 is used to input scanning parameters to the vulnerability scanning engine. The vulnerability scanning engine is based on the aforementioned vulnerability scanning engine implementation method. The scanning parameters are controlled via command line, file, or environment variable configuration. The scanning parameters include a list of scanning targets and a list of plugins. The list of scanning targets includes at least one scanning target, and the list of plugins includes the plugin identifiers of the vulnerability scanning plugins.
[0102] The scanning module 320 is used to perform a scan using the vulnerability scanning engine based on the scanning parameters, and obtain a summary scan result.
[0103] Optionally, the above modules can be stored in the form of software or firmware. Figure 1 The memory 110 shown is either stored in or embedded in the operating system (OS) of the electronic device 100, and can be used by... Figure 1 The processor 120 executes the program. Meanwhile, the data and program code required to execute the above modules can be stored in the memory 110.
[0104] This application also provides a readable storage medium storing a computer program thereon, which, when executed by a processor, implements the vulnerability scanning engine implementation method or the vulnerability scanning method.
[0105] In summary, this application provides a vulnerability scanning engine implementation method, vulnerability scanning method, apparatus, electronic device, and readable storage medium. The vulnerability scanning engine includes a scanner and vulnerability scanning plugins. The scanner includes a lexical analyzer, a function to be used, a plugin loader, a scheduler, and a result parsing unit. Based on the yacc lexical analyzer standard, the syntax of the target language is implemented using Go to obtain the lexical analyzer, wherein the target language is the language used by the vulnerability scanning plugins. The function to be used, the plugin loader, the scheduler, and the result parsing unit are generated using Go, and multiple vulnerability scanning plugins are obtained. Finally, an installation package is generated based on the generated scanner and the multiple vulnerability scanning plugins. Thus, a vulnerability scanning engine implemented using Go inherits the high-performance characteristics of Go, facilitates problem analysis and localization, is easy to deploy, and can be easily extended with vulnerability scanning plugins.
[0106] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. 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 a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive 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 a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0107] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0108] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0109] The above description is merely an optional embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A vulnerability scanning method, characterized in that, The method includes: Input scanning parameters into the vulnerability scanning engine. The scanning parameters can be controlled by means of command line, file, or environment variable configuration. The scanning parameters include a list of scanning targets and a list of plugins. The list of scanning targets includes at least one scanning target, and the list of plugins includes the plugin identifier of the vulnerability scanning plugin. The vulnerability scanning engine is used to perform a scan based on the scanning parameters to obtain a summary scan result. The vulnerability scanning engine includes a scanner and vulnerability scanning plugins. The scanner includes a lexical analyzer, a function to be used, a plugin loader, a scheduler, and a result parsing unit. The vulnerability scanning engine is obtained as follows: Based on the yacc lexical analyzer standard, the syntax of the target language is implemented using Go to obtain the lexical analyzer, wherein the target language is the language used by the vulnerability scanning plugins; the function to be used, the plugin loader, the scheduler, and the result parsing unit are generated using Go; multiple vulnerability scanning plugins are obtained; and an installation package is generated based on the generated scanner and the multiple vulnerability scanning plugins. The scan summary results include aggregation results and matching results. The process of using the vulnerability scanning engine to perform a scan based on the scanning parameters to obtain the scan summary results includes: Based on the scanning parameters, the scanner executes the corresponding vulnerability scanning plugin for each scanning target to obtain the scanning results and CPE information obtained by each vulnerability scanning plugin; The result parsing unit aggregates the scanning results corresponding to each scanning target to obtain the aggregated result. The result parsing unit matches the CPE information obtained by each vulnerability scanning plugin with a preset component table to obtain the matching result. The component table includes the vulnerability information corresponding to each different component.
2. The method according to claim 1, characterized in that, The vulnerability scanning plugin is a Nasl plugin, and the target language syntax is Nasl syntax. The Nasl syntax includes at least one of the following syntaxes: type definition, basic operator definition, arithmetic operations, string operations, comparison operators, logical operators, bitwise operators, loop control flow, variable definition, function definition, and function call; and / or, The functions to be used include built-in functions of the Nasl language and Nasl library functions, including at least one of the following: knowledge base functions, report generation functions, description functions, glue functions, network functions, string manipulation functions, HTTP functions, IP manipulation functions, and password processing functions.
3. The method according to claim 1, characterized in that, When the function to be used includes a knowledge base function, the method further includes: A knowledge base is built based on a Redis database, wherein the knowledge base functions are used to operate on the knowledge base, and the knowledge base is used to record information discovered during the scanning process.
4. The method according to any one of claims 1-3, characterized in that, The step of generating an installation package based on the generated scanner and the multiple vulnerability scanning plugins includes: Based on multiple preset platform types, the Go language scanner file is cross-compiled to obtain binary files corresponding to different platform types; For each platform type, an installation package corresponding to that platform type is generated based on the binary file for that platform type and the multiple vulnerability scanning plugins.
5. The method according to any one of claims 1-3, characterized in that, The vulnerability scanning plugin is a NASL plugin. The scanner executes the corresponding vulnerability scanning plugin for each scanning target, including: The plugin loader is used to read Nasl plugins, and the lexical parser is used to parse the read Nasl plugins to obtain a plugin dependency list. The parsing includes the analysis of plugin dependency relationships and the analysis of plugin priority. The Nasl plugins are executed sequentially according to the plugin dependency chain, and the execution results are saved to the knowledge base for use by other Nasl plugins.
6. The method according to claim 5, characterized in that, When the list of scanning targets includes multiple scanning targets, the scanner executes a corresponding vulnerability scanning plugin for each scanning target, including: The scheduler utilizes the Go language's grooutine feature to perform parallel scanning of the multiple scanning targets.
7. An electronic device, characterized in that, It includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the vulnerability scanning method according to any one of claims 1-6.