JP2006215926A - Device management system, device and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To automatically detect a device which can change a community name from a network device responding to a default community name. <P>SOLUTION: In a system which manages a device connected to a network by a prescribed management protocol, a device responding to a 1st request by a default community name and a device responding to a 2nd request by a changed community name are searched by using a prescribed management protocol (S501). A device which is the same product with the device responded to the 2nd request is extracted out of the devices responded to the 1st request (S507-S509) and the extracted device is made as a device which can change the community name. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a device management technique in a computer network.

  SNMP (Simple Network Management Protocol) is a protocol for managing a network such as a LAN (Local Area Network). SNMP is not only used as a network based on TCP / IP, but is also widely used as a network management protocol for networks based on protocols other than TCP / IP.

  Normally, in this network management, management is performed by accessing a MIB (Mnagement Information Base) of a network device to be managed from a PC (Personal Computer) that manages the network device using SNMP. Here, the PC that manages the network device is called a manager, and the managed network device is called an agent. The MIB has a tree-structured data structure, and a uniquely identifiable identifier called an object ID is assigned to all nodes (objects). This MIB structure is called SMI (Structure for Management Information) and is defined in RFC 1155 “Structure and Identification of Management Information for TCP / IP-based Internets” (Non-Patent Document 1). SNMP is defined in RFC 1157 “A Simple Network Management Protocol” (Non-Patent Document 2).

  In SNMPv1, which is one of the SNMP versions, five messages of GetRequest, GetNextRequest, SetRequest, GetResponse, and Trap are used for information exchange between the manager and the agent. The GetRequest message is transmitted from the manager to the agent, and is used to acquire the value of the object specified by the object ID. The GetNextRequest message is transmitted from the manager to the agent, and is used to acquire the value of the object next to the object specified by the object ID according to the order of the object ID. The SetRequest message is transmitted from the manager to the agent, and is used to set the value of the node specified by the object ID. The GetResponse message is transmitted from the agent to the manager, and is used to return a response from the agent in response to a request (GetRequest, GetNextRequest, or SetRequest) from the manager. The Trap message is transmitted from the agent to the manager, and is used to actively notify the occurrence of an abnormality or event from the agent to the manager.

  The SNMP message includes a version number, a community name, and a PDU (Protocol Data Unit). The coding method is ASN. 1 (Abstract Syntax Notation 1) BER (Basic Encoding Rule). Managers and agents that implement SNMP must support five PDUs corresponding to each SNMP message: GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU, GetResponse-PDU, and Trap-PDU.

  FIG. 3 shows the data format of each PDU excluding the Trap-PDU. In FIG. 3, reference numeral 301 denotes an SNMP message. An area 302 stores SNMP version information. For example, in the case of SNMPv1, a value “0” is set. Reference numeral 303 denotes an area for setting a community name (community name) in which an agent to be managed by SNMP and a manager managing the agent are grouped. The agent compares the community name set in the SNMP message received from the manager with the community name to which the agent belongs, and accepts the SNMP message only when they match. Reference numeral 304 denotes an area in which a PDU is stored, and details of the structure of the PDU are shown in 305.

  In the SNMP message, information on the message type (GetRequest, GetNextRequest, SetRequest) is stored in the header of a PDU (not shown).

  Reference numeral 306 denotes an area in which a request ID is stored, and is used to identify individual requests and corresponding responses when the manager issues GetRequest, GetNextRequest, and SetRequest requests. Upon receiving a request from the manager, the agent sets the same value as the request ID set in the request from the manager in the area 306 when outputting GetResponse. This allows the manager to determine which request the received response is for. An area 307 stores an error status. The error status is used when notifying the content of an error by a GetResponse message transmitted from the agent to the manager when there is an error in the SNMP message requested by the manager. No error (noError) is always set in the area 307 in the PDU when requested by the manager. Reference numeral 308 denotes an area in which an error index indicating which object has an error on the requested SNMP message is stored.

  Reference numeral 309 denotes an area for storing an array (variable-bindings) of pairs of object names (310, 312) and their values (311 and 313). In the SNMP message, as shown in the figure, requests for a plurality of objects (object name / value pairs) can be stored in one message. In the PDU at the time of request, values 311 and 313 generally store data indicating NULL.

  On the other hand, as a method for efficiently discovering and using various resources (printers, multifunction peripherals, scanners, etc.) on the network to be managed, what is called a directory service is provided. The directory service is a telephone directory related to the network, and is used for storing various information. Specific examples of the directory system include LDAP (Lightweight Directory Access Protocol) defined by RFC1777 and Novell's NDS (NetWare Directory Service). In an environment where the directory service cannot be used, it is possible to search for a network device using SNMP broadcast or the like.

In a general network device management system, a network device connected to the network is searched using SNMP / MIB or a directory service, and the status of the network device and various information set in the network device are displayed. Can be changed. Recently, the network device management information centrally managed on the server PC is accessed from a plurality of client PCs via a Web browser, and a list of network devices connected to the network is displayed. The development of Web applications that can display and / or change various types of information and various information set in network devices has become active.
JP 2003-316672-A Request for Comments 1155 (Structure and Identification of Management Information for TCP / IP-based Internets), http://www.ietf.org/rfc/rfc1155.txt Request for Comments 1157 (A Simple Network Management Protocol (SNMP)), http://www.ietf.org/rfc/rfc1157.txt

  However, in recent years, vulnerabilities related to the implementation (security) of SNMP have been pointed out in network devices and network device management systems realized by SNMP / MIB as shown in the conventional example.

  As one of the countermeasures against the vulnerability of SNMP, the default community name (hereinafter referred to as default community name) is not used, but the value of “public” or “private” is used. It is recommended to use a custom community name. Patent Document 1 proposes to dynamically generate community names to improve security.

  On the other hand, in some network devices before the SNMP vulnerability is pointed out, there is an implementation that can be accessed only with a default community name. In other words, there may be a mixture of community names that can be changed and those that cannot. However, in a general network device management system, it is not possible to determine whether or not a network name to be managed can be changed in a community name.

  The present invention has been made in view of the above problems, and an object thereof is to automatically detect a device capable of changing a community name from a network device responding to a default community name.

In order to achieve the above object, a device management apparatus according to an aspect of the present invention has the following arrangement. That is,
A device management apparatus that manages devices connected to a network using a predetermined management protocol,
Search means for searching for a device responding to the first request with the default community name and a device responding to the second request with the changed community name using the predetermined management protocol;
Extraction means for extracting a device determined to be a product of the same type as the device responding to the second request, as a device whose community name can be changed, from among the devices responding to the first request.

A device management system according to another aspect of the present invention for achieving the above object has the following configuration. That is,
A device management system comprising a plurality of devices connected to a network and a management device that manages the plurality of devices with a predetermined management protocol,
Search means for searching for a device responding to a first request with a default community name and a device responding to a second request with a changed community name from the plurality of devices using the predetermined management protocol;
Extraction means for extracting a device determined to be a product of the same type as the device responding to the second request, as a device whose community name can be changed, from among the devices responding to the first request.

Furthermore, a device management method according to another aspect of the present invention for achieving the above object is as follows:
A device management method for managing a device connected to a network using a predetermined management protocol,
Searching for a device that responds to a first request with a default community name and a device that responds to a second request with a changed community name using the predetermined management protocol;
An extraction step of extracting a device determined to be a product of the same type as the device responding to the second request among devices responding to the first request as a device whose community name can be changed.

  According to the present invention, a device capable of changing a community name can be automatically detected from network devices responding to a default community name.

  Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings.

  FIG. 1 is a diagram illustrating a configuration example of a network in which the network device management system of the present embodiment can operate.

  In FIG. 1, a network device to be managed, a server PC for network management, and a client PC for network management are all connected to the LAN 100. 101a to 101e are color printers, 102a to 102e are monochrome printers, 103a to 103e are multifunction devices (devices that have a copy function, fax function, and printer function), 104a to 104e are scanners, each equipped with a network interface card, etc. By doing so, it is connected to the LAN 100 as a network device. These network devices are network devices that can be managed by the network device management system of the present embodiment, can be searched by a method such as a directory service, and can acquire and set information by SNMP / MIB.

  105a to 105e are PCs (Personal Computers) connectable to the network. In these PCs, the network device management software of this embodiment can be operated. In addition, the network device management system according to the present invention may be implemented as a Web-based application in the PCs 105a to 105e. In other words, the network device management software is operated on any one PC (server PC), and the other PC (client PC) accesses the network management software running on the server PC via a Web browser. This makes it possible to use the network device management system. At this time, a network device management system operating on the same server PC may be accessed from a Web browser on the server PC.

  In FIG. 1, color printers 101a and b, monochrome printer 102a, multifunction peripherals 103a and 103b, and scanners 104a and 104b are network devices belonging to the community name “my_community_a”, and color printers 101c and 101d, monochrome printer 102b, c, the multifunction peripherals 103c, d, and the scanner 104c are network devices belonging to the community name “my_community_b”, and the color printer 101e, the monochrome printer 102d, e, the multifunction peripheral 103e, and the scanners 104d, e are assigned to the community name “my_community_c”. The network device to which it belongs. These network devices need to be set with community names so as to respond to the custom community names as described above. However, there are cases where a network device that has not been changed in community name or a network device that cannot change the community name is connected. In the case of such a network device, access by a custom community name is not possible, and access by a default community name (“public”, “private”, etc.) is necessary.

  FIG. 2A is a block diagram illustrating a configuration example of PCs (105a to 105e) on which the network device management software according to the present embodiment can operate.

  In FIG. 2A, reference numeral 200 denotes a PC on which network device management software operates, which is equivalent to 105a to 105e in FIG. The PC 200 is stored in the ROM 202 or the HD (Hard Disk Drive) 211, or supplied from the FD (Floppy (registered trademark) disk drive) 212, CD (CD-ROM drive) 213, or DVD (DVD-ROM drive) 214. A CPU 201 that executes network management software is provided, and the devices connected to the system bus 204 are comprehensively controlled.

  Reference numeral 203 denotes a RAM which functions as a main memory and work area for the CPU 201. Reference numeral 205 denotes a KBC (keyboard controller) that controls input signals from a KB (keyboard) 209, a pointing device (not shown), and the like. Reference numeral 206 denotes a CRTC (CRT controller) which controls display on a CRT (CRT display) 210. Reference numeral 207 denotes a DKC (disk controller) that controls access to the HD 211, FD 212, CD 213, and DVD 214 that store a boot program, various applications, editing files, user files, network management software, and the like. Reference numeral 208 denotes a NIC (network interface card) that exchanges data with other network devices via the LAN 100 in both directions. In all the descriptions below, unless otherwise noted, the execution subject is the CPU 201 on the hardware, and the software control subject is the network device management software installed in the HD (hard disk) 211.

  FIG. 2B is a diagram illustrating a configuration example of a network device (agent) to be managed by the network device management system according to the present embodiment. The device 250 indicates, for example, the monochrome printers 102a to 102e. The color printers 101a to 101e, the multifunction peripherals 103a to 103e, and the scanners 104a to 104e have the same configuration related to network communication.

  2B, the CPU 251 controls the overall operation of the network device 250 according to a program stored in the ROM 252. The printer engine 254 is controlled by the CPU 251 via the interface 253, and forms a visible image on a recording medium. The flash ROM 256 is an electrically rewritable data ROM and stores an MIB 265a. The RAM 257 provides a work area for the CPU 251 to execute various controls. A function as a video memory for the printer engine 254 is also included. The NB 258 is a network board that connects the LAN 100 and the network device 250.

  FIG. 4 is a flowchart showing an example of processing related to searching for a network device connected on the network in the network device management system of the present embodiment. In FIG. 4, “Manager” is a network device management system, and corresponds to the PCs 105 a to 105 e in this embodiment. An “agent” is a network device to be managed. In this embodiment, the “agent” indicates the monochrome printers 102a to 102e, and corresponds to the color printers 101a to 101e, the multifunction peripherals 103a to 103e, and the scanners 104a to 104e. .

  The processes in steps S401 to S407, steps S412 to S418, and steps S423 to S426 are executed on the manager. Further, the processes of steps S408 to S411 and steps S419 to S422 are processes executed on the i-th agent. Assuming that the number of all agents connected on the network is N, the processes of steps S404 to S425 are repeated while i is 0 to N-1.

  In step S401, a network device connected to the network is searched using a directory service or SNMP broadcast, and the process proceeds to step S402. In step S402, an index variable i for sequentially referring to the network devices searched in step S401 is initialized to “0”, and the process proceeds to step S403. In the device search, agents are registered in a predetermined order and assigned index numbers.

  In step S403, the value of the index variable i is compared with the number of network devices searched in step S401. If the value of the index variable i is smaller than the number of network devices, the process proceeds to step S404 (step S403: Otherwise, the process ends (No at step S403).

  In step S404, GetRequest is transmitted with the default community name to the network device referred to by the index variable i, and the process proceeds to step S405. In step S405, a timer for monitoring a response to the GetRequest transmitted in step S404 is started, and the process proceeds to step S406. In step S406, it is checked whether or not the response waiting timer started in step S405 has timed out. If timed out, the process proceeds to step S407 (step S406: Yes). If a response by GetResponse is received from the i-th agent before the timeout, the process proceeds from step S406 to step S412. In step S407, the fact that the i-th agent did not respond to the community name of GetRequest transmitted in step S404 is stored (indicating that there was no response in the response 605 to the default community name described later in FIG. 6). "0" is stored), and the process proceeds to step S415. In step S414, “1” indicating that a response has been made to the default community name is stored in the response 605 to the default community name.

  In FIG. 4, if GetResponse cannot be received before the response waiting timer times out, the process immediately proceeds to step S407. However, the GetRequest retransmission process in step S404 may be repeated an appropriate number of times.

  On the other hand, when the i-th agent receives the GetRequest transmitted in step S404 (step S408), the processes in steps S409 to S411 are performed. In step S409, the i-th agent analyzes the GetRequest received in step S408, and if it is a respondable GetRequest, the process proceeds to step S411 (step S409: Yes). The process proceeds to step S410 (step S410: No). Here, the responseable GetRequest is a GetRequest transmitted with a community name that can be accepted by the i-th agent, and indicates the content of the error even when the information acquisition process itself by GetRequest fails. GetResponse is sent to the manager. The GetRequest that cannot be responded is a GetRequest that is transmitted with a community name that cannot be accepted by the i-th agent. For this GetRequest, an SNMP message such as GetResponse is not transmitted from the agent to the manager.

  In step S410, the i-th agent performs error processing related to GetRequest received in step S408, and ends processing in the agent related to GetRequest received in step S408. The error process executed here includes, for example, a process of counting up a reception counter of an SNMP message transmitted with an illegal community name counted inside the agent.

  In step S411, the i-th agent transmits GetResponse to the manager as a response to the GetRequest received in step S408, and the processing in the agent regarding the GetRequest received in step S408 ends.

  Returning to the manager process, if GetResponse is received from the i-th agent before the response waiting timer expires (step S412), the process proceeds to step S413. In step S413, the GetRequest response waiting timer started in step S405 is stopped, and the process proceeds to step S414. By the timer stop process, the timer timeout monitoring process executed in step S406 is also stopped. In step S414, the fact that the i-th agent has responded to the community name of GetRequest transmitted in step S404 is stored, and the process proceeds to step S415. Considering that there is a device that responds to both the default community name and the custom community name, in the present embodiment, even after responding to the default community name, the processing from step S415 is performed. In step S414, information (device name 601, product name 602, network interface board (NB) name 603) as shown in the list of FIG. 6 is received from the i-th agent by a request using the default community name. It is acquired and registered in the table 600 and stored in the RAM 203.

  Note that the default community name used in step S404 is, for example, a character string held in advance by the network device management system, and for example, “public” or “private” is applied. The series of processes related to the default community name from step S404 to step S414 is only described for one community name in this embodiment, but is set in the SNMP message when processing a plurality of community names. The process from step S404 to step S414 may be repeated a plurality of times while changing the community name. For example, as described above, if it is necessary to check responses for two community names “public” and “private”, the processing from step S404 to step S414 is repeated twice.

  In step S415, GetRequest is transmitted with a unique community name (hereinafter referred to as a custom community name) preset for the network device referred to by the index variable i, and the process proceeds to step S416.

  In step S416, a timer for monitoring a response to the GetRequest transmitted in step S415 is started, and the process proceeds to step S417. In step S417, it is checked whether or not the response waiting timer started in step S416 has timed out. If timed out, the process proceeds to step S418 (step S417: Yes). If the response waiting timer times out, the GetRequest retransmission process in step S415 may be repeated an appropriate number of times.

  In step S418, the fact that the i-th agent did not respond to the community name of GetRequest transmitted in step S415 is stored (indicating that there was no response to the response 606 to the custom community name in FIG. 6). "0" is stored), and the process proceeds to step S426. On the other hand, if GetResponse is received from the i-th agent before the response waiting timer expires, the processing from step S423 onward is executed.

  In the i-th agent, when the manager receives the GetRequest transmitted in step S415 (step S419), the process proceeds to step S420. In step S420, the i-th agent analyzes the GetRequest received in step S419, and if it is a respondable GetRequest, the process proceeds to step S422 (step S420: Yes). The process proceeds to step S421 (step S420: No). Here, the GetRequest that can be responded is a GetRequest that is transmitted with a community name that can be accepted by the i-th agent, and even if the information acquisition process itself by GetRequest fails, GetResponse that indicates the content of the error Is sent to the manager. Further, a GetRequest that cannot be answered is a GetRequest that is transmitted with a community name that cannot be accepted by the i-th agent, and for this GetRequest, an SNMP message such as GetResponse is not transmitted from the agent to the manager.

  In step S421, the i-th agent performs error processing related to GetRequest received in step S419, and ends the processing in the agent related to GetRequest received in step S19. The error process executed here includes, for example, a process of counting up a reception counter of an SNMP message transmitted with an illegal community name counted inside the agent.

  In step S422, the i-th agent transmits GetResponse to the manager as a response to the GetRequest received in step S419, and the processing in the agent regarding the GetRequest received in step S419 ends.

  When the manager receives the GetResponse transmitted from the i-th agent in step S422, the manager advances the process to step S424, and stops the GetRequest response waiting timer started in step S416. By the timer stop process, the timer timeout monitoring process executed in step S417 is also stopped. In step S425, the fact that the i-th agent has responded to the custom community name of GetRequest transmitted in step S415 is stored ("1" is stored in response 605 to the custom community name), and in step S426. move on. In step S425, information (device name 601, product name 602, network interface board (NB) name 603) as shown in the list of FIG. 6 is received from the i-th agent by a request using the custom community name. Acquired and registered in the table 600 stored in the RAM 203.

  The custom community name used in step S415 is, for example, a character string preset by the network device administrator in a step not shown in the figure, such as “my_community_a”, “my_community_b”, “my_community_c”, etc. Any string can be used. Further, the series of processes related to the community name designated by the network device administrator from step S415 to step S425 describes only a process for one custom community name in this embodiment, but processes a plurality of custom community names. If so, the process from step S415 to step S425 is repeated a plurality of times while changing the community name set in the SNMP message. For example, when the three custom community names “my_community_a”, “my_community_b”, and “my_community_c” are examined as in the present embodiment, the processing from step S415 to step S425 is repeated three times.

  In step S426, “1” is added to the value of the index variable i for referring to the network device searched in step S401, and the process returns to step S403.

  In FIG. 4, in the GetRequest transmitted from the manager to the agent, it is assumed that an acquisition request for the MIB object that is always implemented by the agent to be managed is made. In this embodiment, it is assumed that information necessary for managing network devices such as a device name, a product name, and a network interface board name shown in FIG. In the example of FIG. 6, the device name 601 is sysName.0 (object ID is 1.3.6.1.2.1.1.5.0), and the product name 602 is hrDeviceDescr.1 (object ID is 1.3.6.1.2.1. 25.3.2.1.3.1) and ifDescr.1 (object ID is 1.3.6.1.2.1.2.2.1.2.1) as the network interface board name 603, respectively. Further, the response status of the community name recorded in steps S407, S414, S418, and S425 is reflected in the response 605 to the default community and the response 606 to the custom community name. The response 605 to the default community name and the response 606 to the custom community name store “0” when there is no response and “1” when there is a response.

  In the present embodiment, it is checked whether or not a custom community name can be set in an agent to which a default community name is given by the above processing. FIG. 5 is a flowchart showing an example of processing for searching for a network device responding to the default community name and checking whether or not the community name can be changed in the searched network device in the network device management system according to the present embodiment. is there.

  In FIG. 5, in step S501, the network device search process shown in the flowchart of FIG. 4 (including the response community name check (if the device is simply searched, only the community name specified by the user is searched). However, in this embodiment, even when there is a community name designated by the user, a search with the default community name is required)), and the process proceeds to step S502. In step S502, an index variable i for referencing the network device (agent) information searched in step S501 (for example, information as shown in FIG. 6) in order is initialized to “0”, and the process proceeds to step S503. .

  In step S503, the value of the index variable i is compared with the number of network devices searched in step S501. If the value of the index variable i is smaller, the process proceeds to step S504 (step S503: Yes), otherwise In the case of, this processing is terminated. If a network device that responds to the default community name and can change the community name is detected by the processing from step S504 to step S511, which will be described later, when this processing is finished, FIG. By displaying a message box as shown, the network device administrator may be prompted to change the community name. In FIG. 7, reference numeral 700 denotes a window for displaying a message prompting the change of the community name. Reference numerals 701 and 702 denote lists of network devices that respond to the default community name and are determined to be able to change the community name. Is a button for closing the window 700. The processing when a network device that responds to the default community name and that can change the community name is detected is not limited to the above. For example, a UI for automatically changing the community name of the shared printer 03 or 12 in FIG. 7 may be automatically started, or processing such as automatically changing the community name to a custom community name may be executed. .

  Steps S504 to S511 are processes related to the network device referred to by the index variable i. In step S504, it is determined whether or not the i-th network device has responded to the default community name (for example, it can be determined by checking the response 605 to the default community name), and the response is to the default community name. The process proceeds to step S505 (step S504: Yes), otherwise the process proceeds to step S512 (step S505: No). For example, in the example illustrated in FIG. 6, the shared printers 03, 06 to 10, and 12 respond to the default community name “public”.

  In step S505, an index variable j for searching for the same product as the i-th network device determined to respond to the default community name in step S504 is initialized to “0”, and the process proceeds to step S506. By using the index variable j, it is assumed that the network device information searched in step S501 can be referred to in the same manner as the index variable i.

  Steps S507 to S509 are processes related to the network device that can be referred to by the index variable i and the network device that can be referred to by the index variable j. The processes in steps S507 to S509 are executed for all network devices (steps S506 and S510).

  In step S507, it is determined whether the value of the index variable i is equal to the value of the index variable j. If the values are not equal, the process proceeds to step S508 (step S507: Yes), and if the values are equal, the process proceeds to step S511 (step S511). S507: No). This is because, when the value of the index variable i is equal to the value of the index variable j, the network device information that can be referred to by these variables indicates the same information, so it is not necessary to determine whether or not they are the same product.

  In step S508, information on the network device referred to by the index variable i and the network device referred to by the index variable j are compared. As a result of the comparison, if it is determined that these network devices are the same product, the process proceeds to step S509 (step S508: Yes), otherwise the process proceeds to step S511 (step S508: No). In this embodiment, whether or not they are the same product is determined based on whether or not the product name 602 and the network interface board name 603 in FIG. 6 are equal. Therefore, in the example of FIG. 6, the shared printers 01 to 05, the shared printers 06 to 10, the shared printers 11 to 15, and the shared scanners 01 to 05 are determined as the same product. Note that if the system can determine whether the product is the same using only one of the product name 602 and the board name 603, the determination may be made using either one.

  In step S509, whether the network device that can be referred to by the index variable j is responding to the custom community name specified by the network device administrator (in this embodiment, “my_community_a”, “my_community_b”, or “my_community_c”) (For example, it can be determined by checking the response 606 to the custom community name). If it is determined that it is responding to the custom community name, the process proceeds to step S510 (step S509: Yes), otherwise the process proceeds to step S511 (step S509: No).

  For example, in the example shown in FIG. 6, the shared printers 01, 02, 04, 05, 11, 13-15, and the shared scanners 01-05 respond to the custom community name. In this embodiment, the network device responding to the custom community name is determined to be a network device that can change the community name. Therefore, in the example of FIG. 6, the shared printers 01 to 05 are determined to be network devices whose community names can be changed because there are network devices (shared printers 01, 02, 04, 05) responding to the custom community name. Since all of the shared printers 06 to 09 respond to the default community name (“public”), it can be determined that the network name cannot be changed.

  However, the shared printers 06 to 09 may actually be network devices that can change the community name. An object of the present embodiment is to prevent a network device that may not be able to change the community name from being prompted to change the default community name. Therefore, when all the same products can be operated with the default community name even though the community name can be changed, they are handled as network devices that cannot change the community name.

  In step S511, it is stored that the network device that can be referred to by the index variable i is a network device that can respond to the default community name and can change the community name, and proceeds to step S512. This result is stored, for example, in an entry (not shown) of the management table in FIG.

In step S511, “1” is added to the value of the index variable j, and the process returns to step S506.
In step S512, “1” is added to the value of the index variable i, and the process returns to step S503.

  As described above, according to the network device management system of the present embodiment, network devices responding to the default community name are automatically detected from the managed network devices, and the community name of these network devices is further detected. It is automatically determined whether the change is possible. Therefore, it is possible to display only network devices that can change the community name and respond to the default community name to the network device manager. Therefore, the network device administrator can efficiently perform the process of changing the default community name, which is one of the SNMP vulnerability countermeasures, and the user convenience is improved.

  In the above embodiment, whether or not the products are of the same type is determined based on information (product name, network board name) collected using SNMP. However, these pieces of information are transmitted via different protocols. May be collected manually or may be manually input. In addition to SNMP, examples of management protocols include SLP multicast. SLP multicast has a scope name as a community name of SNMP v1, and the above-described processing can be applied.

  FIG. 8 is a diagram showing a memory map of a CD-ROM which is an example of a storage medium. Reference numeral 9999 denotes an area in which directory information is stored, and indicates positions of an area 9998 in which subsequent installation programs are stored and an area 9997 in which network device management software is stored. An area 9998 stores an installation program. Reference numeral 9997 denotes an area where network device management software is stored. When the network device management software of the present invention is installed in the PC 200, the installation program stored in the area 9998 storing the installation program is first loaded into the system and executed by the CPU 201. Next, the installation program executed by the CPU 201 reads the network device management software from the area 9997 where the network device management software is stored, and stores it in the hard disk 211.

  Note that the present invention may be applied to a system or an integrated device including a plurality of devices (for example, a host computer, an interface device, a reader, etc.) or an apparatus including a single device.

  In addition, a storage medium in which a program code of software that realizes the functions of the above-described embodiments is supplied to a system or apparatus, and the computer (or CPU or MPU) of the system or apparatus stores the program code in the storage medium. It goes without saying that the object of the present invention can also be achieved by reading and executing. In this case, the program code itself read from the storage medium realizes the novel function of the present invention, and the storage medium storing the program code constitutes the present invention. As a storage medium for supplying the program code, for example, a floppy (registered trademark) disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, DVD-ROM, magnetic tape, nonvolatile memory card, A ROM or the like can be used.

  In addition, the functions of the above-described embodiments are realized by executing the program code read by the computer, and the OS running on the computer is part of the actual processing based on the instruction of the program code. Alternatively, the functions of the above-described embodiment can be realized by performing all of them and performing the processing.

  Further, after the program code read from the storage medium is written to a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. The CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments can be realized by the processing.

  The present invention can also be applied to a case where the program is distributed to a requester via a communication line such as personal computer communication from a storage medium in which a program code of software realizing the functions of the above-described embodiments is recorded. Needless to say.

It is a figure which shows the structural example of the network in which the network device management system of this embodiment can operate | move. It is a figure which shows the internal structure of PC which can operate the network device management system of this embodiment. It is a figure which shows the internal structural example of the network device of this embodiment. It is a figure which shows the format of an SNMP message (except Trap). It is a flowchart which shows the process relevant to the search of a network device in the network device management system of this embodiment. It is a flowchart which shows an example of the process which searches the network device which can respond to a default SNMP community name and can change an SNMP community name in the network device management system of this embodiment. It is a figure which shows an example of the information regarding the network device searched in the network device management system of this embodiment. In the network device management system according to the present embodiment, a message prompting the change of the community name for a network device that responds to the default community name and can change the community name among the network device search results shown in FIG. It is a figure which shows an example. It is a figure which shows the memory map of CD-ROM which is an example of the storage medium in which the program of this invention was stored.

Claims (13)

A device management apparatus that manages devices connected to a network using a predetermined management protocol,
Search means for searching for a device responding to the first request with the default community name and a device responding to the second request with the changed community name using the predetermined management protocol;
An extraction unit that extracts a device determined to be a product of the same type as that of the device responding to the second request among devices responding to the first request as a device capable of changing a community name; Device management device.   The device management apparatus according to claim 1, further comprising a presentation unit that presents the device extracted by the extraction unit as a device whose community name can be changed.   The device management apparatus according to claim 1, wherein the predetermined management protocol is SNMP.   The device management apparatus according to claim 1, wherein the extraction unit extracts a device based on information collected from each device according to the predetermined management protocol.   5. The device management apparatus according to claim 1, wherein the extraction unit extracts a device based on a product name acquired from the device responding to the first or second request. 6. . A device management system comprising a plurality of devices connected to a network and a management device that manages the plurality of devices with a predetermined management protocol,
Search means for searching for a device responding to a first request with a default community name and a device responding to a second request with a changed community name from the plurality of devices using the predetermined management protocol;
An extraction unit that extracts a device determined to be a product of the same type as that of the device responding to the second request among devices responding to the first request as a device capable of changing a community name; Device management system. A device management method for managing a device connected to a network using a predetermined management protocol,
Searching for a device that responds to a first request with a default community name and a device that responds to a second request with a changed community name using the predetermined management protocol;
An extraction step of extracting a device determined to be a product of the same type as the device responding to the second request among devices responding to the first request as a device whose community name can be changed. Device management method.   The device management method according to claim 7, further comprising a presentation step of presenting the device extracted in the extraction step as a device whose community name can be changed.   The device management method according to claim 7, wherein the predetermined management protocol is SNMP.   8. The device management method according to claim 7, wherein the extraction step performs device extraction based on information collected from each device by the predetermined management protocol.   The device management method according to claim 7, wherein the extraction step performs device extraction based on a product name acquired from a device that responds to the first or second request. .   A control program for causing a computer to execute the device management method according to claim 7.   A storage medium storing a control program for causing a computer to execute the device management method according to claim 7.

Images