Lightweight routing inspection method and system for Linux server

Abstract

The invention discloses a lightweight inspection method and system for a Linux server, and belongs to the technical field of information security. The method comprises the following steps: carrying out instantiation on a Problem Daemon inspection item; a Problem Manager instance is operated, and the Problem Manager instance is The Problem Daemon instance is operated in a Goroutine mode, and an inspection result is obtained; and the inspection result is transmitted to the Export instance by a channel mechanism based on a Goroutine mode. According to the technical scheme, a plug-in type extensible framework is adopted, routing inspection of different resource granularities of the Linux server is abstracted into different Problem Daemon Plugins, and meanwhile routing inspection implementation of an integrated open source community concerning a certain resource granularity of the Linux server is supported. According to the invention, by means of the cross-platform compiling and cross-platform operation capabilities of the Go language, the capability of operating a set of inspection system on different Linux release versions is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of information security, and in particular to a method and system for lightweight inspection of Linux servers. Background Art

[0002] Server inspection is an important step to ensure the safe and stable operation of the server, and is one of the most important links in the operation and maintenance guarantee system. Through regular server security inspections, you can detect security vulnerabilities in the server, discover existing security risks and repair them in a timely manner to prevent problems before they occur.

[0003] Inspections on Linux servers are mainly carried out through port scanning, vulnerability scanning, log analysis, configuration auditing and other methods to discover security vulnerabilities and potential risks on the server; the inspection system is either an expensive commercial product, such as Nessus (the world's number one vulnerability scanning solution), or a heavyweight implementation of the open source community, such as OpenVAS (an open source vulnerability assessment system that provides comprehensive vulnerability management functions), or security operation and maintenance personnel develop scripts based on scripting languages ​​​​(Shell / Python / Ansible, etc.) to implement inspections; at the same time, there are many distributions of Linnx servers, and enterprises often need to invest a lot of money and manpower to implement a unified inspection mechanism.

[0004] Through the above analysis, the prior art has the following problems and defects:

[0005] (1) Commercial products are relatively expensive and customized development is difficult to achieve;

[0006] (2) Open source implementations often focus on inspections in a certain dimension, and involve a large amount of customized development;

[0007] (3) The system needs to be scalable and support customized inspection items for security operations and maintenance personnel;

[0008] (4) It is difficult to use a unified inspection system to cover different distributions of Linux servers. Summary of the invention

[0009] The purpose of the present invention is to provide a method and system for lightweight inspection of Linux servers.

[0010] In order to solve the above technical problems, the present invention provides a method for lightweight inspection of Linux servers, comprising the following steps:

[0011] Instantiate the Problem Daemon inspection item;

[0012] Run the Problem Manager instance;

[0013] Run the Problem Daemon instance in Goroutine mode to obtain the inspection results;

[0014] The Goroutine-based channel mechanism passes the inspection results to the Exporter instance.

[0015] Preferably, the Problem Daemon inspection item is instantiated, specifically including the following steps:

[0016] Configure the Problem Daemon inspection item and register the kernel log listener Exporter;

[0017] When the Linux Server Problem Detector main process starts, the Problem Daemon inspection items and Exporter are initialized to obtain the initialization results.

[0018] Preferably, before running the Problem Manager instance, the following steps are also included:

[0019] Pass the initialization result to the Problem Manager and initialize the Problem Manager instance.

[0020] Preferably, the Problem Daemon instance is run in Goroutine mode to obtain the inspection result, which specifically includes the following steps:

[0021] Design the Log Watcher mechanism based on Kernel Problem Daemon Plugin, implement a Log Watcher for each log file and register it when the plugin is started;

[0022] The Log Watch mechanism scans and analyzes log files based on predefined inspection rules, obtains rule matching results as matching results, and reports them to the Problem Manager instance.

[0023] Preferably, the predefined inspection rules are based on regular expressions and keyword analysis filtering mechanisms.

[0024] Preferably, the inspection results are passed to the Exporter instance based on the Goroutine channel mechanism, which specifically includes the following steps:

[0025] Register the Exporter's Handler;

[0026] When the Problem Daemon Plugin reports the inspection results, the Problem Manager calls the registered DBExporter Handler to store the inspection results in the database DB for subsequent generation of inspection reports.

[0027] Preferably, registering the Exporter's Handler specifically includes the following steps:

[0028] According to the database connection configuration parameters, the database connection is instantiated and the data is stored in the database DB.

[0029] The present invention also provides a system for lightweight inspection of Linux servers, which is used to implement the method for lightweight inspection of Linux servers according to any one of claims 1 to 7, and is characterized in that it includes:

[0030] Instantiation module, used to instantiate Problem Daemon inspection items;

[0031] Run module, used to run the Problem Manager instance;

[0032] Inspection module, used to run Problem Daemon instance in Goroutine mode to obtain inspection results;

[0033] The transfer module is used to transfer the inspection results to the Exporter instance based on the Goroutine channel mechanism.

[0034] Compared with the prior art, the present invention has the following beneficial effects:

[0035] The present invention is a lightweight technical solution that adopts a plug-in extensible architecture, abstracts the inspection of different resource granularities of Linux servers into different Problem Daemon Plugins, and supports the integration of open source communities to implement inspections of certain resource granularities of Linux servers. The present invention uses the cross-platform compilation and cross-platform operation capabilities of the Go language to realize the ability of a set of inspection systems to run on different Linux distributions.

[0036] The present invention adopts a lightweight implementation method as a whole. Enterprises do not need to adopt expensive commercial products, nor do they need to select solutions from a large number of open source implementations. This can help enterprises save a lot of money and labor costs and greatly improve work efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The specific implementation modes of the present invention are further described in detail below with reference to the accompanying drawings.

[0038] Figure 1 This is a schematic diagram of the architecture of a system for lightweight inspection of Linux servers;

[0039] Figure 2 It is the implementation principle of Problem Manager;

[0040] Figure 3 It is the implementation principle of Kernel Problem Daemon Plugin;

[0041] Figure 4 This is the implementation principle of DB Exporter. DETAILED DESCRIPTION

[0042] Many specific details are set forth in the following description to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present invention, so the present invention is not limited to the specific implementation disclosed below.

[0043] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0044] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0045] The present invention is further described in detail below in conjunction with the accompanying drawings:

[0046] The present invention provides a method for lightweight inspection of a Linux server, comprising the following steps:

[0047] Instantiate the Problem Daemon inspection item;

[0048] Run the Problem Manager instance;

[0049] Run the Problem Daemon instance in Goroutine mode to obtain the inspection results;

[0050] The Goroutine-based channel mechanism passes the inspection results to the Exporter instance.

[0051] Preferably, the Problem Daemon inspection item is instantiated, specifically including the following steps:

[0052] Configure the Problem Daemon inspection item and register the kernel log listener Exporter;

[0053] When the Linux Server Problem Detector main process starts, the Problem Daemon inspection items and Exporter are initialized to obtain the initialization results.

[0054] Preferably, before running the Problem Manager instance, the following steps are also included:

[0055] Pass the initialization result to the Problem Manager and initialize the Problem Manager instance.

[0056] Preferably, the Problem Daemon instance is run in Goroutine mode to obtain the inspection result, which specifically includes the following steps:

[0057] Design the Log Watcher mechanism based on Kernel Problem Daemon Plugin, implement a Log Watcher for each log file and register it when the plugin is started;

[0058] The Log Watch mechanism scans and analyzes log files based on predefined inspection rules, obtains rule matching results as matching results, and reports them to the Problem Manager instance.

[0059] Preferably, the predefined inspection rules are based on regular expressions and keyword analysis filtering mechanisms.

[0060] Preferably, the inspection results are passed to the Exporter instance based on the Goroutine channel mechanism, which specifically includes the following steps:

[0061] Register the Exporter's Handler;

[0062] When the Problem Daemon Plugin reports the inspection results, the Problem Manager calls the registered DBExporter Handler to store the inspection results in the database DB for subsequent generation of inspection reports.

[0063] Preferably, registering the Exporter's Handler specifically includes the following steps:

[0064] According to the database connection configuration parameters, the database connection is instantiated and the data is stored in the database DB.

[0065] The present invention also provides a system for lightweight inspection of Linux servers, which is used to implement the method for lightweight inspection of Linux servers according to any one of claims 1 to 7, and is characterized in that it includes:

[0066] Instantiation module, used to instantiate Problem Daemon inspection items;

[0067] Run module, used to run the Problem Manager instance;

[0068] Inspection module, used to run Problem Daemon instance in Goroutine mode to obtain inspection results;

[0069] The transfer module is used to transfer the inspection results to the Exporter instance based on the Goroutine channel mechanism.

[0070] In order to better illustrate the technical effect of the present invention, the present invention provides the following specific embodiments to illustrate the above technical process:

[0071] Embodiment 1: A system for lightweight inspection of Linux servers, which uses a unified inspection system to cover different distributions of Linux servers.

[0072] This embodiment is implemented in this way. The inspection system is implemented using the Go programming language (a statically strongly typed, compiled, concurrent programming language developed by Google with garbage collection function). With the help of the cross-platform compilation and cross-platform operation capabilities of the Go language, a lightweight inspection system that can run on different Linux distributions is implemented. The system implementation scheme is as follows:

[0073] (1) System architecture

[0074] The system is implemented with a plug-in extensible architecture to support inspection items of different resource granularities of the server and inspection items customized by security operation and maintenance personnel. Figure 1 As shown:

[0075] The system core consists of three parts. The Problem Manager module is the core of the entire system. It provides ProblemDaemon Plugin interface definition, loads various Problem Daemon Plugins, exposes Problem reporting interface, collects server problems reported by each Problem Daemon Plugin and pushes the problems to Problem Exporter to support the generation of inspection reports or integration with the monitoring and alarm system.

[0076] Problem Daemon Plugin implements the Problem Deamon Plugin API interface, implements the inspection logic of inspection items of different resource granularities, and reports the inspection results to the problem reporting interface of Problem Manager, running in this system in the form of GoRoutine (a lightweight concurrent mechanism similar to threads provided by the Go programming language).

[0077] Problem Exporter defines the Exporter API. The system provides a DB Exporter by default to store server inspection problems in the database so that inspection reports can be generated. It also supports custom Exporter mechanisms to achieve integration with third-party systems such as monitoring and alarm.

[0078] (2) System compilation

[0079] The source code of this system is implemented in the Go programming language. With the help of the Go language's cross-platform compilation and cross-platform running capabilities, it can be compiled into binary files that run on different Linux distributions.

[0080] (3) System operation

[0081] This system runs on different Linux distributions as a system service, and various Problem Daemon Plugins run in the main process of Linux Server Problem Detector as Go Goroutine. The inspection items of various Problem Daemon Plugins are defined in the form of JSON configuration files, which are built into the Problem Daemon Plugin by default, or customized when Linux Server Problem Detector is running.

[0082] This embodiment provides a method for lightweight inspection of a Linux server, including the following steps:

[0083] 1. Problem Manager Implementation:

[0084] like Figure 2 As shown, the implementation principle of the Problem Manager module, the core component of this system, is as follows:

[0085] The system defines the interface between Problem Daemon and Exporter. When the main process starts, it initializes Problem Daemon and Exporter first, passes the initialization result to Problem Manager and initializes the ProblemManager instance. Then the instance runs, and runs the initialized Problem Daemon instance in Goroutine mode. With the help of the Goroutine channel mechanism, the problems found by Problem Daemon are passed to the corresponding Exporter.

[0086] 2. Kernel Problem Daemon Plugin Implementation

[0087] like Figure 3 As shown in the figure, the implementation principle of Problem Daemon Plugin is demonstrated by taking Kernel Problem Daemon Plugin as an example. Because the storage locations of kernel operation log files of different Linux distributions are different (for example, common log file paths include / dev / kmsg, / var / log / kern.log, / var / log / journal, etc.) and log formats are different, Kernel Problem Daemon Plugin designs a Log Watcher mechanism to address this problem. A Log Watcher is implemented for each log file and registered when the plugin is started; the Log Watch mechanism scans and analyzes log files based on predefined inspection rules (mainly based on regular expressions and keyword analysis and filtering mechanisms) and reports the rule matching results to Problem Manager.

[0088] 3. DB Exporter Implementation

[0089] like Figure 4As shown in the figure, the implementation principle of Exporter is shown by taking DB Exporter as an example. Exporter has multiple implementations. Different types of Exporter implementations need to call the registration interface for registration and register the Exporter's Handler (implementation instantiation of database connection and data storage in database DB according to the provided database connection configuration parameters). When Problem Daemon Plugin reports the inspection results, Problem Manager calls the registered DB ExporterHandler to store the inspection results in DB for subsequent generation of inspection reports.

[0090] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of the modules, modules or units is only a logical function division, and there may be other division methods in actual implementation, for example, multiple units, modules or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0091] The units may or may not be physically separated, and the components displayed as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0092] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0093] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part, and / or installed from a removable medium. When the computer program is executed by the central processing unit (CPU), the above-mentioned functions defined in the method of the present invention are executed. It should be noted that the above-mentioned computer-readable medium of the present invention can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, but not limited to, a system, device or device of an electrical, magnetic, optical, electromagnetic, infrared segment, or semiconductor, or any combination of the above.

[0094] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0095] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A method for lightweight inspection of Linux servers, characterized in that: The following steps are involved: Instantiate the Problem Daemon inspection item; Run the Problem Manager instance; Run the Problem Daemon instance in Goroutine mode to obtain the inspection results; The Goroutine-based channel mechanism passes the inspection results to the Exporter instance.

2. The method for lightweight inspection of Linux servers according to claim 1, characterized in that: Instantiate the ProblemDaemon inspection item, including the following steps: Configure the Problem Daemon inspection item and register the kernel log listener Exporter; When the Linux Server Problem Detector main process starts, the Problem Daemon inspection items and Exporter are initialized to obtain the initialization results.

3. The method for lightweight inspection of Linux servers according to claim 2, characterized in that: Before running the ProblemManager instance, the following steps are also included: Pass the initialization result to the Problem Manager and initialize the Problem Manager instance.

4. The method for lightweight inspection of Linux servers according to claim 3, characterized in that: Run the Problem Daemon instance in Goroutine mode to obtain the inspection results. The specific steps include: Design the Log Watcher mechanism based on Kernel Problem Daemon Plugin, implement a Log Watcher for each log file and register it when the plugin is started; The Log Watch mechanism scans and analyzes log files based on predefined inspection rules, obtains rule matching results as matching results, and reports them to the Problem Manager instance.

5. The method for lightweight inspection of Linux servers according to claim 4, characterized in that: The predefined inspection rules are based on regular expressions and keyword analysis and filtering mechanisms.

6. The method for lightweight inspection of Linux servers according to claim 5, characterized in that: The Goroutine-based channel mechanism passes the inspection results to the Exporter instance, which includes the following steps: Register the Exporter's Handler; When the Problem Daemon Plugin reports the inspection results, the Problem Manager calls the registered DBExporter Handler to store the inspection results in the database DB for subsequent generation of inspection reports.

7. The method for lightweight inspection of Linux servers according to claim 6, characterized in that: Registering the Exporter Handler includes the following steps: According to the database connection configuration parameters, the database connection is instantiated and the data is stored in the database DB.

8. A system for lightweight inspection of Linux servers, used to implement the method for lightweight inspection of Linux servers as described in any one of claims 1 to 7, characterized in that: include: Instantiation module, used to instantiate Problem Daemon inspection items; Run module, used to run the Problem Manager instance; Inspection module, used to run Problem Daemon instance in Goroutine mode to obtain inspection results; The transfer module is used to transfer the inspection results to the Exporter instance based on the Goroutine channel mechanism.

Images