Information processing system
The information processing system addresses the challenge of identifying network communication sources by inserting client-specific information into packets and extracting it on a server device, facilitating effective malware management in complex network environments.
Patent Information
- Application Number
- JP2025001870
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2018-12-27
- Filing Date
- 2025-01-06
- Publication Date
- 2025-04-10
- Estimated Expiration
- 2039-12-18
AI Technical Summary
Existing techniques struggle to accurately identify the source of network communication in complex network environments with external devices like routers and firewalls, leading to difficulties in managing and mitigating malware threats.
An information processing system that includes a client terminal device equipped with monitoring and adding capabilities to insert client-specific information into packets, and a server device that receives and extracts this information to identify the source of communication.
This solution enables easy specification of the communication source, allowing for effective management and mitigation of malware threats, even in environments with external network devices.
Smart Images

Figure 2025061036000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to an information processing system, a server device, a control method for a server device, and a program. [Background technology]
[0002] Some malware communicates with dangerous destinations such as C&C (command and control) servers to receive instructions from hackers or send stolen confidential information. To deal with this, countermeasures have been taken to prevent damage caused by malware by making a list of destination information (URLs, IP addresses, etc.) of dangerous destinations in advance and blocking communications to destinations on the list. While this method can prevent direct damage caused by malware, it has the problem that it cannot take measures against malware that remains on the client side. For this reason, it is necessary to identify the source of the communication and take measures.
[0003] Therefore, one technique for identifying the source of network communication is to refer to the MAC address in an Ethernet (registered trademark) frame. However, since the MAC address is information that can only be transmitted within the same segment, it is assumed that there is no other network device between the source client and the network device that performs the identification. However, in the case of a typical network configuration in a company or government agency, various external devices such as routers and firewalls exist along the network. Therefore, in such an environment, the source of network communication becomes the MAC address of the external device, and the client cannot be identified. There is also a method of managing the source of network communication in an external device, but this makes the management complicated.
[0004] Another technique is to refer to the source IP address. However, since IP addresses are not always fixed to one computer, it is often impossible to identify the computer name from the IP address for communication from a month ago, for example. Therefore, Prior Art Document 1 discloses a technique for identifying the source client by embedding client information in the request URL. [Prior art documents] [Patent documents]
[0005] [Patent Document 1] JP 2004-240559 A Summary of the Invention [Problem to be solved by the invention]
[0006] However, in Prior Art Document 1, the location where the URL is analyzed is the web server, which is beyond the control of the user or administrator, and therefore cannot be applied to communications outside of the user's or administrator's control. For example, this technology cannot be applied to C&C servers used by malware, which are installed and managed by cybercriminals. Therefore, the present invention aims to easily identify the source of communications. [Means for solving the problem]
[0007] The present invention relates to, for example, an information processing system, The system includes a client terminal device, an information device, and a server device, The client terminal device A monitoring means for monitoring packets; an adding means for adding client-specific information to the packets monitored by the monitoring means; a transmitting means for transmitting the packet added by the adding means to the information device; Equipped with The server device includes: receiving means for receiving the packet from the information device; an extraction means for extracting the client-specific information from the packet received by the receiving means; The present invention is characterized by comprising: Effect of the Invention
[0008] According to the present invention, the source of a communication can be easily identified. [Brief description of the drawings]
[0009] [Figure 1] FIG. 1 is a system configuration diagram showing an example of the configuration of an information processing system. [Diagram 2] 13 is a flowchart showing the processing of the client terminal device 10. [Diagram 3] 13 is a flowchart showing the process of the server device 20. [Figure 4] FIG. 13 illustrates an example of a packet. [Diagram 5] 13 is a flowchart showing the process of the server device 20. [Figure 6] FIG. 11 is a diagram showing an example of an operation history. [Figure 7] 13 is a flowchart showing the process of the server device 20. [Figure 8] FIG. 13 is a diagram illustrating an example of an operation history. [Figure 9] 13 is a flowchart showing the process of the server device 20. [Figure 10] FIG. 11 is a diagram showing an example of an operation history. [Figure 11] 13 is a flowchart showing the process of the server device 20. [Figure 12] FIG. 1 is a system configuration diagram showing an example of the configuration of an information processing system. [Figure 13] FIG. 11 is a sequence diagram showing login restrictions. [Figure 14] FIG. 13 illustrates an example of an account management table. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0010] [First embodiment] <System configuration diagram> First, the configuration of the information processing system according to this embodiment will be described with reference to the system configuration diagram of FIG. 1. As shown in FIG. 1, the information processing system according to this embodiment has computers, i.e., information processing devices 10, 20, and 50, and each information processing device is connected to a network 30 such as a LAN or the Internet. Hereinafter, the information processing device 10 will be referred to as a client terminal device, the information processing device 20 as a server device (e.g., a proxy server), and the information processing device 50 as an information device (e.g., a router, a firewall, etc.). Note that there may be more than one client terminal device 10 and information device 50. There may be more than one server device 20, and some or all of the functions of the server device 20 may be realized by multiple server devices 20 that are installed in a distributed manner. In addition, the client terminal device 10, the server device 20, and the information device 50 may be any device as long as they are capable of executing each process described below as being performed by an information processing device such as a PC or a mobile terminal device.
[0011] <Client terminal device> In the client terminal device 10, the arithmetic device 10C is a microprocessor (CPU). The arithmetic device 10C starts an operating system (OS) stored in the storage device 10B according to a boot program such as a BIOS stored in the ROM of the memory 10E, and further starts various programs according to the OS or user operations. This storage device 10B stores computer programs and data for causing the arithmetic device 10C to execute the OS and various processes to be described later as those performed by this device. The computer programs include a client program 10F and a browser 10G.
[0012] The client program 10F is a program for managing data and programs of the client terminal device 10, and has functions such as monitoring packets, adding client-specific information (e.g., computer name, name of the program that sent the packet, etc.) to the message header of the HTTP request of the packet, and sending the packet. The client program 10F may also have a function for monitoring the operation of the client terminal device 10 and storing it in the storage device 10B as an operation history, and a control function for following commands from the server device 20 (e.g., a command to apply a patch program, a virus scan command, a quarantine command, etc.). The client program 10F may also have an output function for outputting the operation history (e.g., storing it in the storage device 10B, sending it to the server device 20).
[0013] 6 is a diagram showing an example of an operation history. When a communication request is made from the client terminal device 10, the date and time of the request, the logged-in user name, the computer name (PC name), the requested URL (access destination URL), and the like are recorded. For example, record 601 indicates that a communication request was made to the access destination URL "http: / / aaa.com" from a PC name "PC-A" in which a user name "userA" was logged in on the date "2019 / 08 / 10" at time "14:00:00". Note that the recorded information is not limited to this.
[0014] The computer programs and data stored in the storage device 10B are loaded into the RAM of the memory 10E as appropriate under the control of the arithmetic device 10C, and are processed by the arithmetic device 10C. The OS may be, for example, Windows (registered trademark), MacOS, Linux (registered trademark), iOS, Android, or the like.
[0015] The storage device 10B is a hard disk drive (HDD) or a solid state drive (SSD), and stores the client program 10F that runs on the client terminal device 10 in addition to the OS. The I / O device 10A is an input / output interface (I / F) for connecting to a pointing device (such as a mouse) or a keyboard, or a display incorporating a touch panel. The keyboard may be a software keyboard. The I / O device 10A may also be a voice-based input unit including a microphone that recognizes the input voice of the operator using a voice recognition function and transmits the recognized voice to the arithmetic device 10C. The I / O device 10A also functions as a user interface (UI) for displaying information.
[0016] The network I / F 10D is an interface with the network 30, and is a communication circuit for communicating with other information processing devices (such as a Web server). The arithmetic device 10C transmits a request packet issued from a program such as the browser 10G to the other information processing device (such as a Web server) that is the destination, via the network I / F 10D.
[0017] <Server device> The hardware configuration of the server device is assumed to be the same as that of the client terminal device 10 described above, as shown in Fig. 1. That is, the arithmetic device 20C of the server device 20 uses computer programs and data stored in the storage device 20B of the server device 20 to perform data communication with other information processing devices via the network I / F 20D of the server device 20, and executes each process described below as being performed by the server device 20. Also, a server program 20F is stored in the storage device 20B of the server device 20.
[0018] In the server device 20, the arithmetic device 20C is a microprocessor (CPU). The arithmetic device 20C starts the OS stored in the storage device 20B according to a boot program such as a BIOS stored in the ROM of the memory 20E. Then, the arithmetic device 20C receives a request packet from the client terminal device 10 connected via the network 30, and transmits the request packet to another information processing device (e.g., a Web server) on the Internet that is the destination.
[0019] The storage device 20B is an HDD, an SSD, or the like, and stores a server program 20F that runs on the server device 20. The network I / F 20D is an interface with the network 30, and is a communication circuit for communicating with other information processing devices such as the client terminal device 10.
[0020] The server program 20F divides request packets received from a plurality of client terminal devices 10 via the network I / F 20D into HTTP request message headers, and extracts information about the client terminal devices 10 described by the client program 10F on the client terminal devices 10. In addition, the server program 20F can store and manage the operation history of the client terminal devices 10 transmitted from the client terminal devices 10 connected via the network 30 in the storage device 20B, and can also send commands such as a patch application command, a virus scan command, and a quarantine command to the client terminal devices 10.
[0021] The server device 20 is installed on the boundary between the network 30 on the client terminal device 10 side and the Internet 40. With this configuration, all packets exchanged between the network 30 and the Internet 40 can be routed through the server device 20, and the present invention can be applied to all packets exchanged.
[0022] In addition, although the server device 20 and the client terminal device 10 are both installed inside a LAN in FIG. 1, the server device 20 may be installed on the Internet 40 as long as it is connectable to the client terminal device 10 via the network 30.
[0023] <Information equipment> In a typical network environment such as in a company or a government office, an information device 50 is installed between a client terminal device 10 and a server device 20. The information device 50 is a device that relays communication from the client terminal device 10 to the server device 20, and is, for example, other network devices such as a router, a firewall, or a UTM (Unified Threat Management). In the case of the configuration of Fig. 1, in the case of a packet of an Ethernet (registered trademark) frame exchanged between the information device 50 and the server device 20, the source MAC address is that of the information device 50, so it is impossible to identify the source client using the MAC address.
[0024] <Processing of client terminal device> 2 is a flowchart of a process performed by the client terminal device 10 according to this embodiment. The arithmetic device 10C monitors the transmission of a packet (for example, a request packet) by some program (for example, the browser 10G) in the client terminal device 10 (step S201).
[0025] The arithmetic device 10C judges whether or not a certain program has attempted to transmit a packet to another information processing device (e.g., a Web server) (step S202). If it is judged that a packet transmission has been attempted (YES in step S202), the arithmetic device 10C suspends the transmission of the packet (step S203).
[0026] Next, the arithmetic device 10C records client-specific information indicating information about the client terminal device 10 as a unique header in the message of the HTTP request in the packet to be transmitted (step S204). The client-specific information includes, for example, information indicating the client terminal device (such as a computer name), information indicating the user (such as a user name), and information indicating the program that transmitted the packet (such as the name of the program that made the request, the process name, etc.).
[0027] 4 is a diagram showing an example of a message header of an HTTP request in a packet edited by the arithmetic device 10C. In this example, in addition to normal headers such as User-Agent, there is an "ADDHEADER" header added by the client program 10F, in which the computer name of the client terminal device 10, "TestPCNAME.test.com", and the name of the program that made the request, "iexplore.exe", are recorded. Note that a method for identifying the program name that sent the request packet and the destination URL is a publicly known technique (for example, JP 2012-185799 A), and therefore a description thereof will be omitted.
[0028] After recording the client-specific information in the message header of the HTTP request in the packet, the arithmetic device 10C transmits the packet whose transmission was temporarily suspended in step S203 (step S205). Note that, in the above description, the browser 10G is given as an example of a program that transmits packets, but this program is not limited to the browser 10G and may be a general application (spreadsheet software, word processing software, etc.) or a process.
[0029] <Server device processing> 3 is a flowchart showing the process of the server device 20. In the following description, the server device 20 will be described as a proxy server, but is not limited to this.
[0030] 1, a packet transmitted from the client terminal device 10 reaches the proxy server 20 via the information device 50 before reaching the Internet 40. When the packet reaches the proxy server 20, the server program 20F in the proxy server 20 first receives the packet (step S301).
[0031] The arithmetic device 20C attempts to extract information unique to the sender client from all received packets. Specifically, the following process is performed for all received packets. The arithmetic device 20C divides the data of the message header of the HTTP request in the packet into header name units (step S302). It is determined whether or not a header added by the client program 10F (arithmetic device 10C) of the client terminal device 10 is present in the divided headers (step S303). The determination is performed using a table stored in advance in the storage device 20B to determine whether the header name is unique and added by the client program 10F (arithmetic device 10C). The table stores information unique to the client program 10F, such as "ADDHEADER" as shown in FIG. 4.
[0032] If the corresponding header exists, the character string recorded in the header is recognized as client-specific information (such as computer name and program name) of the client terminal device 10 and extracted (step S304). As a result, the information of the client that sent the packet can be identified on the proxy server (step S305). By identifying the client information, for example, when blocking communication to a dangerous connection destination to prevent damage caused by malware, measures can also be taken against malware remaining on the client side.
[0033] A specific explanation will be given using Figure 4. For example, when the server program 20F receives a packet as shown in Figure 4, it first divides it into header name units. Since the header contains the "ADDHEADER" header added by the client program 10F, it obtains the character string "TestPCNAME.test.co;iexplore.exe" from the header and divides it with a semicolon. This reveals that the name of the sending computer is "TestPCNAME.test.co" and that the name of the program that sent the packet is "iexplore.exe."
[0034] The header name and the header format added by the client program 10F are determined in advance between the server program 20F and the client program 10F, and are stored in the storage devices 10B and 20B, respectively.
[0035] As mentioned above, the location where packets are analyzed (for example, the location where the source of the communication is identified) is not set at the end of the communication path (such as a web server), but at a location along the communication path that can be managed by an administrator (such as a proxy server). This allows all packets to be analyzed without being affected by the destination of the communication, making it possible to easily and accurately identify the source of the communication.
[0036] [Second embodiment] By identifying the source client of the packet, for example, the following effects can be obtained. When a server device (e.g., a proxy server) receives a packet whose destination URL is a dangerous website by adding a "computer name" and a "program name that made the request" as client-specific information, the server device can identify the computer and program that made the access request to the dangerous website from the client-specific information added to the received packet. The following describes the processing after the server device identifies the source client and program that made the packet. Note that most of the operations of this embodiment are common to those of the first embodiment, so only operations that differ from the first embodiment will be described here, and common operations will not be described.
[0037] FIG. 5 is a flowchart showing the process of the server device 20. The arithmetic device 20C judges whether the received packet is a request to a dangerous website (step S501). The judgment of whether the packet is for accessing a dangerous website is made by comparing "Host" and the like included in the standard header of the HTTP request header with a list of host names of dangerous websites pre-stored in the storage device 20B. If it is judged that the website is not dangerous (NO in step S501), the packet is sent to the destination and the process is terminated. In the above description, the server device 20 judges whether the received packet is a request to a dangerous website, but the judgment may be made by a device (e.g., UTM) (not shown) connected to the network 30. In that case, step S501 is omitted.
[0038] The arithmetic device 20C judges whether the identified program is a web browser (step S502). The judgment of whether the program is a web browser is based on the program information indicating the web browser stored in advance in the storage device 20B. If the identified program is a web browser, it can be inferred that the program was jumped from a dangerous URL described in the phishing email, for example. If it is judged to be a web browser (YES in step S502), the arithmetic device 20C changes the email settings of the client (step S503). For example, in order to prevent the phishing email from being delivered, the destination to which the phishing email was sent is checked from the operation history of the client identified in step S502, and the settings are changed so that emails from that destination are not received. The email settings may be stored in the server device 20, the client terminal device 10, or a mail server (not shown).
[0039] The server program 20F judges whether the identified program is a general application (step S504). The judgment of whether the program is a general application is based on program information indicating the general application stored in advance in the storage device 20B. If the application is a general application (for example, a spreadsheet software, a word processing software, etc.), it is assumed that the request exploits a vulnerability of the general application. If the application is judged to be a general application (YES in step S504), the arithmetic device 20C applies a correction program for correcting the vulnerability to the client terminal device 10 (step S505). Note that the general application and the acquisition destination (download server) of the correction program may be associated with each other and stored in advance in the storage device 20B, and the corresponding acquisition destination may be accessed to acquire the correction program, and the correction program may be applied to the client terminal device 10. Also, the correction program may be associated with the general application and stored in advance in the storage device 20B.
[0040] If the arithmetic device 20C determines that the identified program is not a general application (NO in step S504), it transmits a virus scan or isolation command to the client terminal device 10 (step S506). If the identified program is not a web browser or a general application, it can be assumed that the malware itself is communicating with a dangerous destination such as a C&C server. Therefore, measures such as performing a virus scan in the client terminal device 10, isolating it from the network, and preventing the infection from spreading are necessary. Note that the web browser and general application, which are the predetermined programs used as the judgment criteria in steps S502 and S504, are merely examples and are not limited to these.
[0041] As described above, by adding client-specific information (client information), it is possible to grasp the situation on the client terminal device side, which cannot be determined from normal packets alone, and to take appropriate measures immediately.
[0042] [Third embodiment] In this embodiment, a process is described in which damage from a seemingly harmless website is discovered and dealt with by using an operation history. Note that most of the operations of this embodiment are common to the first and second embodiments, so only operations that differ from the first and second embodiments are described here, and explanations of common operations are omitted.
[0043] Referring to the operation history in Figure 6, record 602 records that a user with the user name "userC" accessed the URL "http: / / aaa.com" on a PC named "PC-C" on the date "2019 / 11 / 18" and time "11:00:00". If it turns out that "http: / / aaa.com" is a dangerous website, it is first necessary to take measures such as running a virus scan on "PC-C" that accessed the URL "http: / / aaa.com" or prohibiting access to the URL.
[0044] However, not all dangerous websites are created by malicious individuals. There are also cases where the URL of a normal website is taken over by a malicious third party and altered to perform dangerous actions such as distributing malware. Also, the determination of whether the URL is dangerous or not is made after an investigation by an antivirus vendor, so it is not the moment the website is altered, but after some time has passed. Therefore, even when a website is determined to be harmless, it may have already been altered into a dangerous website, so measures such as virus scans must be taken for PCs that accessed the URL before it was determined to be dangerous.
[0045] Fig. 7 is a flowchart showing the processing of the server device 20. In the flowchart of Fig. 7, the same processing steps as those shown in Fig. 5 are given the same step numbers, and the description of these processing steps will be omitted.
[0046] First, in step S501, it is assumed that the arithmetic device 20C determines that a URL (e.g., "http: / / aaa.com") that a certain client terminal device 10 (e.g., "PC-C") is attempting to access is dangerous. Thereafter, the arithmetic device 20C refers to the operation history recorded in all the client terminal devices 10 recorded in the storage device 20B (step S701). Next, the arithmetic device 20C determines whether or not the operation history includes any access to the URL determined to be dangerous from a client terminal device other than the client terminal device 10 (e.g., "PC-C") that transmitted the packet detected in step S501 (step S702).
[0047] Referring to the operation history in FIG. 6, it can be seen in record 601 that the URL "http: / / aaa.com" was also accessed by a PC named "PC-A" on the date "2019 / 08 / 10" and the time "14:00:00".
[0048] If the arithmetic device 20C does not confirm access by another client terminal device 10 (NO in step S702), it does nothing and moves the process to step S502. If the access is confirmed (YES in step S702), the arithmetic device 20C transmits a virus scan or quarantine command to the client terminal device 10 (for example, "PC-A") (step S703).
[0049] For example, in the case of the operation history of FIG. 6, since access to the URL "http: / / aaa.com" by "PC-A" is confirmed, the arithmetic device 20C issues a command such as a virus scan to "PC-A."
[0050] As mentioned above, by referring to the operation history, it is possible to discover damage from seemingly harmless websites and take action to address the problem.
[0051] [Fourth embodiment] In this embodiment, a process for discovering and dealing with damage from a Web site even when the local time is changed in the client terminal device 10 will be described.
[0052] In the third embodiment, the arithmetic device 20C refers to the operation history to perform processing to determine whether a dangerous URL has been accessed in the past from another client terminal device 10. However, if the "time" in the operation history is recorded based on the local time of the client terminal device 10, changing the local time from the original time will also change the time in the operation history.
[0053] Although the above problems can be prevented by prohibiting changes to the local time itself, it is not appropriate to prohibit changes to the time in general, as this would hinder time changes for non-malicious purposes such as program testing and reduce convenience. Therefore, a means is needed that allows changes to the local time while still making it possible to obtain the correct time in the operation history.
[0054] Therefore, when the local time of the client terminal device 10 is changed, the calculation device 10C stores the time difference between before and after the change, and records the difference (offset) in the operation history. An example of recording the time difference (offset) in the operation history is shown in FIG. 8.
[0055] Fig. 8 is a diagram showing an example of an operation history. Fig. 8 has the same meaning as the operation history shown in Fig. 6, but in addition to Fig. 6, a time difference (offset) when the local time of the client terminal device 10 is changed is recorded. In record 801, a value of "+48:00" is recorded as the offset value, which indicates that the local time has been shifted back 48 hours.
[0056] Fig. 9 is a flowchart showing the processing of the server device 20. In the flowchart of Fig. 9, the same processing steps as those shown in Fig. 5 are given the same step numbers, and the description of these processing steps will be omitted.
[0057] In step S501, it is assumed that the URL "http: / / aaa.com" accessed by the PC named "PC-C" on the date "2019 / 11 / 18" at the time "11:00:00" is determined to be a dangerous website by the arithmetic device 20C. The arithmetic device 20C refers to the operation history recorded in all the client terminal devices 10 stored in the storage device 20B to determine whether the same URL "http: / / aaa.com" has been accessed previously by another client terminal device 10 (step S901).
[0058] The arithmetic device 20C recalculates the time using the offset value (step S902). For example, in the record 801 in Fig. 8, there is an operation history in which "PC-A" accessed "http: / / aaa.com" on the date "2019 / 11 / 19" at the time "14:00:00", but since the time offset records that this operation history is 48 hours ahead of the original time, when the time is recalculated taking into account the offset, the date becomes "2019 / 11 / 17" and the time becomes "14:00:00".
[0059] The arithmetic device 20C applies the time recalculated in step S902 and determines whether or not there is a history of accessing the URL "http: / / aaa.com" in the past (step S903). For example, the record 801 in Fig. 8 confirms that "http: / / aaa.com" was accessed in "PC-A" on the date "2019 / 11 / 17" recalculated in step S902 and at the time "14:00:00".
[0060] If the arithmetic device 20C does not confirm access by another client terminal device 10 (NO in step S903), it does nothing and moves the process to step S502. If the access is confirmed (YES in step S903), the arithmetic device 20C transmits a virus scan or quarantine command to the client terminal device 10 (for example, "PC-A") (step S904).
[0061] For example, in the case of the operation history of Fig. 8, since access to the URL "http: / / aaa.com" by "PC-A" is confirmed, the arithmetic device 20C issues a command such as a virus scan to "PC-A". Therefore, measures such as issuing a virus scan command to "PC-A" can be taken.
[0062] As described above, even if the local time is changed on the client terminal device 10, the same measures as in the third embodiment can be taken by recording the offset value of the changed time in the operation history.
[0063] [Fifth embodiment] In this embodiment, a process for discovering and dealing with a client terminal device in which lurking malware exists by using a hash value will be described. Note that most of the operations of this embodiment are common to the operations of the first to fourth embodiments, so only the operations that differ from the first to fourth embodiments will be described here, and the common operations will be omitted.
[0064] In the third and fourth embodiments, the arithmetic device 20C refers to the operation history to perform a process of determining whether a dangerous website has been accessed from another client terminal device 10 in the past. In this embodiment, the hash value of a program that has transmitted a packet from the client terminal device 10 (a program that runs on the client terminal device 10 and transmits a request packet to the outside via the network I / F 10D and the network 30) is added to the HTTP request message header in the packet as client-specific information. In addition, the hash value of the program that transmitted the packet (a program that has made a communication request) is recorded in the operation history.
[0065] FIG. 10 shows an example of an operation history with a hash value added. FIG. 10 is a diagram showing an example of an operation history. It has the same meaning as the operation history shown in FIG. 6 and FIG. 8, but in addition to FIG. 8, a hash value of a program that made a communication request is recorded. The hash value is calculated by the client program 10F using an algorithm such as SHA-1 or SHA-256 with the binary value of the program as a key, and is then recorded in the storage device 10B as an operation history.
[0066] Record 1001 records a hash value of "AAAAAA...", which indicates that the program with the hash value "AAAAAA..." made the communication request. The hash values of records 1001 and 1002 match, "AAAAAA...", which indicates that the two communication requests were made by the exact same program, even though they were issued from different client terminal devices 10 (PC-A, PC-C).
[0067] Fig. 11 is a flowchart showing the process of the server device 20. In the following, as an example, a description will be given assuming that the operation history shown in Fig. 10 is recorded.
[0068] First, in step S501, it is assumed that the arithmetic device 20C determines that a URL (for example, "http: / / 01234.com") that a certain client terminal device 10 is attempting to access is dangerous. In the following, it is assumed that a program with a hash value of "AAAAAA..." accessed the URL "http: / / 01234.com" from "PC-X" on the date "2019 / 11 / 21" at time "16:00:00".
[0069] After that, the arithmetic device 20C refers to the operation histories recorded in all the client terminal devices 10, which are recorded in the storage device 20B (step S1101).
[0070] Next, the calculation device 20C acquires the hash value ("AAAAAA...") of the program added to the request packet as client-specific information, and determines from the operation history referenced in step S1101 whether there is communication by a program having the same hash value as the hash value acquired in the past (step S1102).
[0071] If communication using a program with the same hash value has occurred in the past (YES in step S1102), this means that the exact same program that accessed the dangerous URL ("http: / / 01234.com") exists. In the case of the operation history shown in Figure 10, there is no trace of past access to the URL "http: / / 01234.com", but communication using the hash value "AAAAAA..." matches two records in the operation history, record 1001 and record 1002.
[0072] If the program with the hash value "AAAAAA..." is malware, even if the URLs "http: / / aaa.com" and "http: / / ddd.com" stored in the operation history are determined to be not dangerous, there is a high possibility that these are dangerous sites such as unknown C&C servers. Therefore, since it is found that the same malware has already infiltrated PC names "PC-A" and "PC-C", the computing device 20C transmits a virus scan or quarantine command to these client terminal devices 10 (step S1103).
[0073] As described above, by using hash values, it is possible to discover client terminal devices in which lurking malware exists without accessing dangerous URLs, and to take action against those client terminal devices.
[0074] [Sixth embodiment] In this embodiment, a process will be described in which a user account is used to restrict login to other client terminal devices by the same user who attempts to access a dangerous Web site.
[0075] In the first embodiment, the computer name of the client terminal device 10 is added as client-specific information to the message header of the HTTP request sent from the client terminal device 10, thereby identifying the client terminal device 10 that attempted to access a dangerous website, and taking measures such as isolating it from the network. However, even if some measures are taken against the client terminal device 10, if the user of that client terminal device 10 uses another client terminal device 10, there is a possibility that the user will attempt to connect to a similarly dangerous website.
[0076] Therefore, in this embodiment, the computing device 10C adds a user account (user name), which is information indicating the logged-in user, as client-specific information, so that the server device 20 can identify the user account that was logged in to the client terminal device 10 when the dangerous website was accessed, and can use the identified user account to restrict login to the client terminal device 10 by the same user.
[0077] Fig. 12 is a system configuration diagram showing an example of the configuration of an information processing system. The information processing system shown in Fig. 12 includes a server device 60 and a plurality of client terminal devices 11 in addition to the configuration of the information processing system shown in Fig. 1. Since most of the server device 60 is common to the server management device 20, the description will be omitted below, and only the different parts will be described. Note that most of the operations of this embodiment are common to the operations of the first to fifth embodiments, so here, only the operations that are different from the first to fifth embodiments will be described, and the description of the common operations will be omitted.
[0078] The server device 60 stores a login management program 60F that manages the login of all the client terminal devices 10 present in the network 30. The login management program 60F and the server program 20F may be configured to be implemented on the same server device.
[0079] The storage device 60B also records an account management table in which the user accounts (account names) of all the client terminal devices 10 present in the network 30 are associated with login restrictions (permission / denial). An example of the account management table is shown in FIG. 14. As will be described later, the account management table is recorded by identifying user accounts that have accessed dangerous websites. The account management table may also be recorded by an administrator. A login management program 60F that manages logins is loaded into the RAM of the memory 60E as appropriate under the control of the computing device 60C, and becomes a target for processing by the computing device 60C.
[0080] In this embodiment, when logging in to the client terminal device 10, the process shown in Fig. 13 is performed. Fig. 13 is a sequence diagram showing login restrictions. In any client terminal device 10, the arithmetic device 10C of the client device 10 detects that a user has attempted to log in (step S1301).
[0081] The arithmetic device 10C inquires of the server device 60 via the network I / F 10D and the network 30 whether login is possible (step S1302). In addition, when making the inquiry, the user account attempting to log in is also transmitted together.
[0082] The arithmetic device 60C that has received the inquiry compares the loaded user account with the user account included in the inquiry based on the account management table stored in the storage device 60B, and determines whether login is permitted (step 1303).
[0083] The arithmetic device 60C returns a response indicating the result of the determination (login permission or denial) to the client terminal device 10 that made the inquiry (step S1304).
[0084] The arithmetic unit 10C of the client terminal device 10 permits or denies the login based on the received judgment result. For example, as shown in Fig. 14, the login from userA is permitted, and the login from userB is denied.
[0085] Suppose a user accesses a dangerous website (determined as YES in step S501 in FIG. 5). As described above, in this embodiment, the arithmetic device 10C adds the logged-in user account to the request packet, so that the arithmetic device 20C can identify the user account that made the request. Then, the arithmetic device 20C records the login restriction corresponding to the user account of the user who accessed the dangerous website as "Rejected" in the account management table recorded in the storage device 60B of the server device 60 via the network I / F 20D and the network 30.
[0086] As described above, when a user who has attempted to access a dangerous website attempts to log in from another client terminal device, the login can be prohibited, thereby preventing the same user from accessing dangerous websites again.
[0087] <Other embodiments> The present invention can also be realized by a process in which a program for implementing one or more of the functions of the above-described embodiments is supplied to a system or device via a network or a storage medium, and one or more processors in a computer of the system or device read and execute the program. The present invention can also be realized by a circuit (e.g., ASIC) that implements one or more of the functions.
Claims
1. An information processing system, The system includes a client terminal device, an information device, and a server device, The client terminal device A monitoring means for monitoring packets; an adding means for adding client-specific information to the packets monitored by the monitoring means; a transmitting means for transmitting the packet added by the adding means to the information device; Equipped with The server device includes: receiving means for receiving the packet from the information device; an extraction means for extracting the client-specific information from the packet received by the receiving means; An information processing system comprising:
2. 2. The information processing system according to claim 1, wherein the server device is a proxy server.
3. 3. The information processing system according to claim 1, wherein the information device is a router, a firewall, or a UTM.
4. An information processing system according to any one of claims 1 to 3, characterized in that the client-specific information is any one or a combination of information indicating the client terminal device, information indicating a user, and information indicating a program that sent the packet.
5. The server device includes: Furthermore, 5. An information processing system according to claim 1, further comprising a first determination means for determining whether the information indicating the program that transmitted the packet, which is the client-specific information, is information indicating a specified program.
6. The monitoring means monitors operations of the client terminal device, The client terminal device further comprises:
6. The information processing system according to claim 1, further comprising an output unit that outputs the operations monitored by the monitoring unit as an operation history.
7. the operation history includes information indicating a destination of the packet; The server device includes: Furthermore, 7. The information processing system according to claim 6, further comprising a second determination unit that determines whether or not the operation history contains information indicating a destination of a specific packet.
8. the operation history includes an offset value that is a difference between a time before the change and a time after the change of the client terminal device; The server device includes: Furthermore, a calculation means for calculating a time of the client terminal device based on the offset value, 8. The information processing system according to claim 7, wherein the second determination means makes a determination based on the time calculated by the calculation means.
9. the operation history includes a hash value of a program that transmitted the packet, The server device includes: Furthermore, 7. The information processing system according to claim 6, further comprising a third determination unit that determines whether or not the operation history contains a specific hash value.
10. An information processing system as described in any one of claims 1 to 9, characterized in that the extraction means extracts information indicating a user from the received packet and records the information indicating the user in a table in which the information indicating the user is associated with information regarding restrictions on logging into the client terminal device.
11. The client terminal device When a login attempt is made to the client terminal device, information including information indicating a user of the client terminal device is transmitted to the server device; The server device includes:
11. The information processing system according to claim 10, further comprising: a step of determining whether or not a login restriction to the client terminal device is to be made based on the table and which is based on information indicating a user of the client terminal device that has been received.
12. a receiving means for receiving a packet transmitted from a client terminal via an information device; A determination means for determining whether or not a packet received by the receiving means contains predetermined client-specific information; an extraction means for extracting the client-specific information from the packet when the determination means determines that the packet contains the client-specific information; A server device comprising:
13. a receiving step of receiving, via an information device, a packet transmitted from a client terminal; a determination step of determining whether or not the packet received in the receiving step includes predetermined client-specific information; an extraction step of extracting the client-specific information from the packet when it is determined in the determination step that the client-specific information is included; A method for controlling a server device, comprising:
14. Computer, a receiving means for receiving a packet transmitted from a client terminal via an information device; A determination means for determining whether or not a packet received by the receiving means contains predetermined client-specific information; an extracting means for extracting the client-specific information from the packet when the determining means determines that the client-specific information is included in the packet; A program to function as a
Citation Information
Patent Citations
System for specifying penetration point
JP2005217692A
Communication system, repeater, and communication method in repeater
JP2011147092A
User terminal protection method and system
JP2011186728A
Access restriction processing device and method for web-type information processing system
JP2004240559A