WO2009039679A1

WO2009039679A1 - Architecture and method for centralized system minimization and hardening management

Info

Publication number: WO2009039679A1
Application number: PCT/CN2007/002824
Authority: WO
Inventors: Hao Wang
Original assignee: Lucent Technologies Inc.
Priority date: 2007-09-26
Filing date: 2007-09-26
Publication date: 2009-04-02
Also published as: CN101796523A

Abstract

An architecture and method for realizing centralized system minimization and hardening management in a network comprising a plurality of servers. The architecture comprises a central manager adapted to receive a command for the system minimization, obtain predefined server status for one or more of the plurality of servers according to the command, and send the predefined server status to the one or more servers respectively; and a plurality of agents residing on the plurality of servers respectively, each agent being adapted to get current service and protocol status of its server in response to the command, and change the current service and protocol status to meet the predefined server status received from the central manager. The inventive solution greatly decreases the effort to minimize the services and protocols running on each server in a big network, and can help a network administrator analyze and understand the impact onto the system after the minimization.

Description

ARCHITECTURE AND METHOD FOR CENTRALIZED SYSTEM MINIMIZATION AND HARDENING MANAGEMENT

FIELD OF THE INVENTION

The present invention generally relates to the field of computer systems, more particularly, the invention relates to an architecture and method for realizing centralized system minimization and hardening management.

BACKGROUND OF THE INVENTION

How to secure computer systems against unauthorized access is one of the most pressing issues that system administrators face today. One way to reduce system vulnerabilities is to minimize the amount of software on a server. Fewer software components being on a server means fewer security holes to detect and fill. Many system penetrations are accomplished through the exploitation of security holes in the operating system itself. Thus, system minimization and protocol minimization on a server can greatly improve overall system security by reducing the sheer number of vulnerabilities. Overall system security is further improved by reducing the number of open ports available to the ones necessary for legitimate system functions.

For a complex network system with multiple servers running, every server needs to use the system minimization and protocol minimization procedure so that the whole network system can be secured. When the number of the servers grows, the effort to minimize them grows.

Fig.l illustrates the existing solution for network system minimization. For a computer network comprising a plurality of servers, as shown in Fig.1 , every server has its own system minimization tools and user interface. In order to accomplish the system minimization work, the network administrator has to log in every server and use its system minimization tools and user interface to make the server minimized, such as enabling/disabling one or more services and protocols on this server. Although the existing solution provides management tools and interface on each server, it needs the network administrator log on to the servers to do the system minimization work one by one. In a large cooperation, the number of servers may be very huge, thus the effort will be very big. In addition, because the system minimization work on each server is independent of the work on other servers, there is no centralized traceability. That is to say, it doesn't provide a good way for the administrator to get the current status of each server, and there is either no easy way to understand and manage the impact to the whole network system after the minimization.

SUMMARY OF THE INVENTION

The objective of the present invention is to provide a solution for network system minimization, which can keep the above procedure as a centralized manageable process, so that the network system administrator can make the whole system minimization and protocol minimization in one point using uniform interface.

In one aspect of the present invention, there is provided an architecture for realizing centralized system minimization and hardening management for a network comprising a plurality of servers. The architecture comprises a central manager adapted to receive a command for the system minimization, obtain predefined server status for one or more of the plurality of servers according to the command, and send the predefined server status to the one or more servers respectively; and a plurality of agents residing on the plurality of servers respectively, each agent being adapted to get current service and protocol status of its server in response to the command, and change the current service and protocol status to meet the predefined server status received from the central manager.

In another aspect of the present invention, there is provided a method for realizing centralized system minimization and hardening management for a network comprising a plurality of servers. The method comprises receiving a command for the system minimization by a central manager; obtaining predefined server status for one or more of the plurality of servers by the central manager according to the command; sending the predefined server status respectively from the central manager to the respective agents residing on the one or more servers; getting, by each agent, current service and protocol status of its server in response to the command; and changing the current service and protocol status by the each agent to meet the predefined server status.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, further objectives, and advantages thereof, will be best understood by reference to the following detailed description of the preferred embodiments when read in conjunction with the accompanying drawings, wherein:

Fig.l is a representation of a conventional architecture for network system minimization known in the prior art;

Fig.2 is a representation of a centralized system minimization and hardening management architecture in accordance with an embodiment of the present invention;

Fig.3 is a schematic flow chart diagram illustrating the configuration of predefined server status in accordance with an embodiment of the present invention;

Fig.4 is a schematic flow chart diagram illustrating the on-demand audit in accordance with an embodiment of the present invention; and

Fig.5 is a schematic flow chart diagram illustrating the automatic audit in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Fig.l shows schematically a conventional architecture for network system minimization known in the prior art, which has been discussed above in connection with the background of the present invention. Reference will now be made in detail to the preferred embodiments of the invention.

Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

Fig. 2 shows schematically a centralized system minimization and hardening management architecture 200 in accordance with an embodiment of the present invention. Architecture 200 is built on the basis of a network 210 comprising a plurality of servers 1...N. As indicated above, in order to enable the network system administrator to make the whole system minimization in one point using uniform interface, i.e. keeping the network system minimization as a centralized manageable process, the inventive solution is to use a central point to manage the system minimization of all the servers in the network 210. This central point can send command messages to the respective agent on each server, respectively, and each agent will do actual system minimization work according to the command messages. These agents can send specific log information back to the central point. Then the central point can save this information in some place for further review and analysis. Therefore, architecture 200 may include a central manager 202, a plurality of agents 204 residing on the plurality of servers respectively, an administration interface 206 and a database 208, as shown in Fig.2. Other elements may be presented, instead of or in addition to the above elements, in architecture 200 for other purposes without departing from the present invention.

Central manager 202 may receive and interpret command messages from the administration interface 206 or the agent 204, and read/write information according to the command messages by for example accessing the database 208. The central manager 202 may send information for minimization, such as predefined server status (which will be detailed hereinafter), to the agent 204. In addition, the central manager 202 may send command messages received from the administration interface 206 to the agent 204, and get information such as logs and records from the agent 204. In one embodiment, the central manager 202 is a system minimization management process that runs on one of the plurality of servers 1...N, such as a central server shown in Fig.2. Preferably, the central manager 202 is a multi-thread (or multi-process) program, so that it can do multiple jobs simultaneously.

Agent 204 may receive and interpret command messages from the central manager 202, get current status, such as service and protocol status, of its server according to the command messages, and send it back to the central manager 202. Moreover, the agent 204 may disable/enable specific services and protocols on the server according to the command messages received from the central manager 202, and audit current service and protocol status of its server by comparing the current service and protocol status with predefined status and then automatically changing the current status to the predefined status if there are discrepancies between them. In one embodiment, the agent 204 is a system minimization agent process living on each server that should be managed by administrator. In this case, managing means system minimization and hardening.

Administration interface 206 is possibly a GUI program that may or may not run on the same server of the central manager 202. Administrator 212 can login to the server that executes the administration interface 206 to do some work with respect to network system minimization, for instance, getting current service and protocol status of each server in the network, requesting enable/disable one or more services and protocols on one or more servers, configuring operational parameters for the minimization work, requesting each agent to audit current status of its server according to predefined status, etc. The operational parameters may comprise an expected server status predefined for the minimization work, and automatic audit period set for the agent 204. The predefined status can be used to all servers, or only be used to particular servers. In one embodiment, the administration interface 206 lives on a server that is the OA&M platform of the whole system, so that administrator 212 can easily access it. Further, the administration interface 206 is recommended to only interfaces with the central manager 202.

Database 208 may store the needed information of the minimization work, for example, the predefined status for the plurality of servers, and any other types of information such as logs and records from the agent 204. The predefined status describes an expected server status (e.g., service and protocol status) for the plurality of servers when the network system minimization is accomplished. In one embodiment, the predefined status comprises default global status provided by a network operator, the global predefined status configured by system administrator, and the predefined status for specific servers configured by system administrator. Accordingly, there will be some kinds of data tables in the database 208 to maintain the above-described predefined status. In one embodiment, the following kinds of data tables are presented.

The first kind of table is Server Table shown as below, which stores information of server ID and FLAG. Server ID is a server's unique identity, and the corresponding FLAG indicates whether this server has its own predefined status table. For example, if FLAG = yes, this server has its own predefined status table. Otherwise it has no its own predefined status table.

Server Table

The second kind of table is Global Predefined Status Table, which stores information of current and default global status of various services and protocols predefined for a plurality of servers. As an example, this kind of table may comprise a global predefined service status table (shown as below), which stores information of service ID, service name, default predefined status, and current predefined status. There is no information of server ID stored in this table since the global predefined status is applicable to all servers. Service ID is the unique identity of a service. Service name is the name of a service (e.g. "IP forwarding"). Default predefined status is the network operator recommended status of a given service. Current predefined status is the status for a given service configured by an administrator in terms of current minimization work. Moreover, this kind of table may also comprise a global predefined protocol status table with a structure similar to that of the global predefined service status table.

Global Predefined Service Status Table

Service ID Service Name Default Predefined Status Current Predefined Status

The third kind of table is Predefined Status Table for Given Servers, which stores information of current status of various services and protocols predefined for some specific servers. Similar to Global Predefined Status Table, Predefined Status Table for Given Servers may comprise a predefined service status table and a predefined protocol status table for such servers. As an example, the predefined service status table for given servers (shown as below) stores information of server ID, service ID, service name and current predefined status. Current predefined status is the predefined status configured by an administrator for a certain service on a given server.

Predefined Service Status Table for Given Servers

Moreover, there may be other operational tables in the database 208 to maintain other parameters and information which are configured for centralized system minimization or resulted from the execution of minimization work. The configuration of the predefined server status will be described below in detail with reference to Fig.3.

Fig.3 is a schematic flow chart diagram illustrating the configuration of predefined server status in accordance with an embodiment of the present invention. According to requirements of the minimization work, an administrator such as administrator 212 can configure various predefined status for one or more serves. The first recommended step for customer to use the inventive architecture is to configure the global predefined status applicable to all of the plurality of serves. Referring to Fig.3, when administrator 212 logins to the server that runs administration interface 206, in step 301 the administration interface 206 receives a request to show the current global predefined status. In step 302, the administration interface 206 sends "Get current global predefined status" command to central manager 202. The central manager 202 obtains the current global predefined status in step 303, for example by reading it from the database 208, and then sends it back to the administration interface 206 in step 304. If there is no global predefined status in the database 208, the default global status provided by the network operator will be read and sent to the administration interface 206. In step 305, the administration interface 206 shows the received information to the administrator 212. Then the administrator 212 changes the global predefined status for some services or protocols on the interface and submits the change in step 306. In step 307, the administration interface 206 sends "Change global predefined status" command and a new value of the global predefined status to the central manager 202, and then the central manager 202 saves the new global predefined status into the database 208 in step 308.

The schematic flow chart diagrams described herein are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.

In a normal situation, administrator doesn't need to configure special predefined status for homogeneous servers. However, people sometimes need special strategies for some specific servers. Referring to Fig.3 again, administrator 212 logins to the server that runs the administration interface 206 when he or she wants to configure the special predefined status for specific servers. Similarly, in step 301 the administrator 212 uses the administration interface 206 to request to show the current predefined status for some specific servers. In step 302 the administration interface 206 sends "Get current predefined status for specific servers" command and the IDs of the specific servers to the central manager 202, which differs from the configuration of the global predefined status. The central manager 202 obtains the current predefined status for the specific servers in step 303, for example by reading it from the database 208, and then sends it back to the administration interface 206 in step 304. If there is no predefined status for such servers in the database 208, the global server status will be read and sent to the administration interface 206. In step 305, the administration interface 206 shows the received information to the administrator 212. Then the administrator 212 changes the predefined status of some services or protocols for the specific servers on the interface and submits the change in step 306. In step 307, the administration interface 206 sends "Change predefined status for specific servers" command and a new value of the predefined status along with these servers' IDs to the central manager 202, and then the central manager 202 saves the new predefined status for these specific servers into the database 208 in step 308. In addition, the central manager 202 may mark into the database 208 that the specific servers have their own predefined status.

With the predefined status for the servers, administrator can perform system minimization in a centralized manner by specific operations on the uniform administration interface 206, for example, requesting to enable/disable one or more services and protocols on one or more servers by means of an audit command. Fig.4 is a schematic flow chart diagram illustrating the on-demand audit in accordance with an embodiment of the present invention. A scenario that an administrator does audit job of the whole system is illustrated by reference to Fig.4. Firstly, administrator 212 logins to the server that runs the administration interface 206. In step 401, the administrator 212 requests to do audit of the whole system on the administration interface 206. In step 402, the administration interface 206 sends "Audit" command to the central manager 202. Then the central manager 202 obtains in step 403 the predefined status for each server, for example by reading it from the database 208. If there is no special predefined status for the servers, the global predefined status will be read. In step 404, the central manager 202 sends "Audit" command and the predefined status to the respective agent 204 on each server, respectively. Step 403 and step 404 can also be occurs in a simultaneous way by "multithreaded" mechanism. Upon receiving the "Audit" command, the agent 204 scans the current status (including services and protocols status) of its server in step 405, and in step 406 compares it with the corresponding predefined status sent from the central manager 202. If there are discrepancies between them, the agent 204 will change the server's status according to the predefined status. In step 407, the agent 204 sends results of execution to the central manager 202. For example, the agent 204 sends "Complete Audit" information to the central manager 202 upon completing the audit job. If there is error happened during the audit job, the agent 204 just sends "Fail to Audit" information to the central manager 202. Then the central manager 202 sends back the results to the administration interface 206 in step 408. It is noted that by a good multithreaded design and implement, the administrator 212 can see the results of each server in a real-time manner.

In some particular environments, administrator may require to perform special operations for some specific servers. In this case, the audit procedure described above will be carried out for the specific servers. Referring to Fig.4 again, administrator 212 logins to the server that runs the administration interface 206. In step 401, the administrator 212 requests to do audit of the specific servers on the administration interface 206, wherein the servers need to audit can be selected from the administration interface 206. In step 402, the administration interface 206 sends "Audit" command to the central manager 202 along with a list of IDs of the specific servers. Then in step 403, the central manager 202 obtains the predefined status for each server in above list, for example by reading it from the database 208. If there is no special predefined status for the servers, the global predefined status will be read. In step 404, the central manager 202 sends "Audit" command and the predefined status to the respective agent 204 on each server in above list, respectively. Similarly, step 403 and step 404 can also be occurs in a simultaneous way by "multithreaded" mechanism. Upon receiving the "Audit" command, the agent 204 scans the current status (including services and protocols status) of its server in step 405, and in step 406 compares it with the corresponding predefined status sent from the central manager 202. If there are discrepancies between them, the agent 204 will change the server's status according to the predefined status. In step 407, the agent 204 sends results of execution to the central manager 202. For example, the agent 204 sends "Complete Audit" information to the central manager 202 upon completing the audit job. If there is error happened during the audit job, the agent 204 just sends "Fail to Audit" information to the central manager 202. Then the central manager 202 sends back the results to the administration interface 206 in step 408. Similar to the situation of the on-demand audit for all servers, the administrator 212 also can see the results of each server in a real-time manner by a good multithreaded design and implement.

In one embodiment, administrator 212 may request to get current status of servers in which he or she has interests, for example before issuing an audit command, so that the administrator 212 can track the status of such servers in real time and determine whether it is necessary to reconfigure current predefined status for these servers. Administrator 212 logins to the server that runs the administration interface 206, and sends "Query Status" command and a list of IDs of the interested servers to the central manager 202 through the administration interface 206. The central manager 202 then sends such "Query Status" command to the respective agents 204 on the interested servers, respectively. In response to this command, the agent 204 works out the current status of its server and sends it back to the central manager 202. The central manager 202 then sends the received information to the administration interface 206. The administration interface 206 shows the current status of the interested servers to the administrator 212.

For the inventive architecture, in addition to the above-described on-demand audit, the periodic automatic audit may be performed so as to make the whole system to always keep up with the predefined status. This needs an automatic audit period to be set at the respective agent 204 on each server respectively. In one embodiment, the administrator 212 logins to the server that runs the administration interface 206 and set the automatic audit period. The administration interface 206 sends "Change Automatic Audit Duration" command and a new value of the audit period to the central manager 202. Then the central manager 202 forwards such command messages to the respective agent 204 on each server, respectively. In response to receiving the above command and value, the agent 204 changes its internal timer according to the new automatic period. It is noted that if the administrator 212 doesn't configure the audit period, the automatic audit will be executed at the expiration of a default audit period, which may be hard coded in the agent 204.

Fig.5 is a schematic flow chart diagram illustrating the automatic audit in accordance with an embodiment of the present invention. In step 501, when the automatic audit timer times out, the agent 204 sends "Get predefined status" command to the central manager 202. Then the central manager 202 obtains the predefined status for the requested server in step 502, for example by reading it from the database 208. If there is no predefined status for the server, the global one will be read. In step 503, the predefined status for the server is sent to the respective agent 204 from the central manager 202. The agent 204 scans the current services and protocols status of its server in step 504, and compares it with the predefined status in step 505. If there are discrepancies between them, the agent 204 will change the server's status according to the predefined status. In step 506, the audit results will be sent from the agent 204 to the central manager 202, and the later will record the results in some place such as database 208.

It can be seen from the above description that the centralized mechanism of the present invention greatly decreases the effort to minimize the services and protocols running on each server in a big network, since it does not need the network administrator login to the servers to do the system minimization work one by one. And this solution also makes the management work traceable, which can help the network administrator analyze and understand the impact onto the system after the minimization. Moreover, because the solution of the present invention can greatly save management effort for big cooperation, it will be applicable to any other environments which may adopt centralized operations. The described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments.

The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.

Claims

CLAIMSWhat is claimed is:

1. An architecture for realizing centralized system minimization and hardening management in a network comprising a plurality of servers, comprising: a central manager adapted to receive a command for the system minimization, obtain predefined server status for one or more of the plurality of servers according to the command, and send the predefined server status to the one or more servers respectively; and a plurality of agents residing on the plurality of servers respectively, each agent being adapted to get current service and protocol status of its server in response to the command, and change the current service and protocol status to meet the predefined server status received from the central manager.

2. The architecture according to claim 1, wherein the architecture further comprises an administration interface adapted to communicate with the central manager so as to configure operational parameters for the plurality of servers and issue the command to the each agent via the central manager.

3. The architecture according to claim 2, wherein the operational parameters comprise audit period and the predefined server status.

4. The architecture according to claim 3, wherein the each agent is configured with the audit period to automatically audit the current service and protocol status of its server at the expiration of the audit period.

5. The architecture according to claim 4, wherein the architecture further comprises a database adapted to store the predefined server status, and the central manager is further adapted to access the predefined server status from the database.

6. The architecture according to claim 5, wherein the each agent is further adapted to: enable and disable one or more services and protocols on its server by changing the current service and protocol status of the server, and send log information of its server to the central manager.

7. The architecture according to claim 6, wherein the central manager is further adapted to receive and save the log information into the database.

8. The architecture according to claim 7, wherein the command for the system minimization received by the central manager is sent from the administration interface.

9. The architecture according to claim 8, wherein the central manager is further adapted to: send the command to the respective agents on the one or more servers along with their respective predefined server status, and return results of execution received from the respective agents to the administration interface.

10. The architecture according to claim 7, wherein the command for the system minimization received by the central manager is sent from the respective agents at the expiration of the audit period.

11. The architecture according to any one of claims 2 to 10, wherein the central manager is further adapted to: get current service and protocol status of at least one of the plurality of servers from its agent, and forward the current service and protocol status to the administration interface.

12. A method for realizing centralized system minimization and hardening management in a network comprising a plurality of servers, comprising: receiving a command for the system minimization by a central manager; obtaining predefined server status for one or more of the plurality of servers by the central manager according to the command; sending the predefined server status respectively from the central manager to the respective agents residing on the one or more servers; getting, by each agent, current service and protocol status of its server in response to the command; and changing the current service and protocol status by the each agent to meet the predefined server status.

13. The method according to claim 12, further comprising communicating with the central manager by an administration interface so as to configure operational parameters for the plurality of servers and issue the command to each agent via the central manager.

14. The method according to claim 13, wherein the operational parameters comprise audit period and the predefined server status.

15. The method according to claim 14, wherein configuring the audit period comprises setting the audit period at each agent to enable the agent automatically audit the current service and protocol status of its server at the expiration of the audit period.

16. The method according to claim 15, further comprising storing the predefined server status in a database, and wherein the obtaining and configuring the predefined server status are performed by the central manager by accessing the database.

17. The method according to claim 16, further comprising: enabling and disabling one or more services and protocols on the one or more servers by changing their current service and protocol status, and sending log information of the one or more servers by their respective agents to the central manager.

18. The method according to claim 17, further comprising receiving and saving the log information into the database by the central manager.

19. The method according to claim 18, wherein the command for the system minimization received by the central manager is sent from the administration interface.

20. The method according to claim 19, further comprising: sending the command from the central manager to the respective agents on the one or more servers along with their respective predefined server status, and returning results of execution from the respective agents to the administration interface via the central manager.

21. The method according to claim 18, wherein the command for the system minimization received by the central manager is sent from the respective agents at the expiration of the audit period.

22. The method according to any one of claims 13 to 21, further comprising: getting current service and protocol status of at least one of the plurality of servers from its agent by the central manager, and forwarding the current service and protocol status from the central manager to the administration interface.