Information processing system

Abstract

To simply specify the transmission source of a communication.SOLUTION: An information processing system includes a client terminal device, an information apparatus, and a server device, the client terminal device includes monitoring means for monitoring a packet, addition means for adding information unique to a client to the packet monitored by the monitoring means, and transmission means for transmitting the packet added by the addition means to the information apparatus, and the server device includes reception means for receiving the packet from the information apparatus, and extraction means for extracting the information unique to the client from the packet received by the reception means.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to an information processing system Mu .

Background Art

[0002] Among malware, there are some that communicate with dangerous destinations such as C&C (command and control) servers, receive instructions from hackers, or transmit stolen confidential information. In response to this, countermeasures such as listing in advance the connection destination information (URL, IP address, etc.) of dangerous destinations and blocking communication to destinations on the list are taken to prevent damage caused by malware. According to this method, direct damage caused by malware can be prevented, but there is a problem that no countermeasures can be taken against the malware remaining on the client side. Therefore, it is necessary to identify the source of communication and take countermeasures

[0003] Therefore, as a method for identifying the source of network communication, there is a technique of referring 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 identifies the source. However, in the case of a general network configuration within a company or government agency, various external devices such as routers and firewalls exist in the middle of the network. Therefore, in such an environment, the source of network communication becomes the MAC address of an external device, and the client cannot be identified. Also, there is a method of managing the source of network communication in an external device, but the management becomes complicated

[0004] Another approach involves referencing the source IP address. However, since IP addresses are not always fixed to a single computer, it is often impossible to identify the computer name from the IP address for communication from, for example, a month ago. Therefore, prior art document 1 discloses a technique that identifies the source client by embedding client information within the request URL. [Prior art documents] [Patent Documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2004-240559 [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] However, prior art document 1 assumes that the URL is analyzed at the web server, which is beyond the control of users and administrators, and therefore cannot be applied to communications outside of their control. For example, C&C servers used by malware are set up and managed by cybercriminals, so this technology cannot be applied to them. Therefore, the present invention aims to easily identify the source of communications. [Means for solving the problem]

[0007] The present invention is, for example, an information processing system, It has a client terminal device, information equipment, and a server device. The aforementioned client terminal device is A monitoring means for monitoring packets, Packets monitored by the aforementioned monitoring means As a message header in the HTTP request A recording means for recording client-specific information, In the aforementioned recording means Record client-specific information. done Includes message headers of HTTP request A transmission means for transmitting packets to the information device Equipped with, The server device receiving means for receiving the packet from the information device, the packet received by the receiving means from, said HTTP request message header Recorded as extracting means for extracting the client-specific information and ru is characterized by

Effect of the Invention

[0008] According to the present invention, the transmission source of communication can be easily specified.

Brief Description of the Drawings

[0009] [Figure 1] It is a system configuration diagram showing a configuration example of an information processing system. [Figure 2] It is a flowchart showing the processing of the client terminal device 10. [Figure 3] It is a flowchart showing the processing of the server device 20. [Figure 4] It is a diagram showing an example of a packet. [Figure 5] It is a flowchart showing the processing of the server device 20. [Figure 6] It is a diagram showing an example of an operation history. [Figure 7] It is a flowchart showing the processing of the server device 20. [Figure 8] It is a diagram showing an example of an operation history [Figure 9] It is a flowchart showing the processing of the server device 20. [Figure 10] It is a diagram showing an example of an operation history. [Figure 11] It is a flowchart showing the processing of the server device 20. [Figure 12] It is a system configuration diagram showing a configuration example of an information processing system. [Figure 13] It is a sequence diagram showing login restrictions. [Figure 14]This is a diagram showing an example of an account management table.

Mode for Carrying Out the Invention

[0010] [First Embodiment] <System Configuration Diagram> First, the information processing system configuration according to this embodiment will be described using the system configuration diagram of FIG. 1. As shown in FIG. 1, the information processing system according to this embodiment has computers, that is, information processing apparatuses 10, 20, and 50, and each information processing apparatus is connected to a network 30 such as a LAN or the Internet. Hereinafter, the information processing apparatus 10 will be referred to as a client terminal apparatus, the information processing apparatus 20 will be referred to as a server apparatus (for example, a proxy server), and the information processing apparatus 50 will be referred to as an information device (for example, a router, a firewall, etc.). Note that there may be a plurality of client terminal apparatuses 10 and information devices 50. There may be a plurality of server apparatuses 20, and a part or all of the functions of the server apparatus 20 may be realized by a plurality of server apparatuses 20 installed in a distributed manner. Further, the client terminal apparatus 10, the server apparatus 20, and the information device 50 may be any apparatus as long as it can execute each process described later as a process performed by an information processing apparatus such as a PC or a mobile terminal apparatus.

[0011] <Client Terminal Apparatus> In the client terminal apparatus 10, the arithmetic unit 10C is a microprocessor (CPU). The arithmetic unit 10C starts an operating system (OS) stored in the storage device 10B according to a boot program such as BIOS stored in the ROM of the memory 10E, and further starts various programs according to the OS or the user's operation. In this storage device 10B, an OS, a computer program for causing the arithmetic unit 10C to execute each process described later as a process performed by this apparatus, and data are stored. This computer program includes 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 for example, it 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 packets. The client program 10F may also have functions to monitor the operation of the client terminal device 10 and store it as an operation history in the storage device 10B, and control functions to follow instructions from the server device 20 (e.g., instructions to apply a patch, instructions to scan for viruses, instructions to quarantine, etc.). The client program 10F may also have an output function to output the operation history (e.g., to store it in the storage device 10B, to send it to the server device 20).

[0013] Figure 6 shows 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 username, the computer name (PC name), and the URL to which the request is made (access URL) are recorded. For example, record 601 indicates that on the date "2019 / 08 / 10" at the time "14:00:00", a communication request was made from PC name "PC-A" to the access URL "http: / / aaa.com" by the logged-in user "userA". Note that the information recorded is not limited to this.

[0014] Computer programs and data stored in the storage device 10B are loaded into the RAM of the memory 10E as appropriate, according to the control of the arithmetic unit 10C, and become subject to processing by the arithmetic unit 10C. The operating system can be, for example, Windows®, MacOS, Linux®, iOS, or Android.

[0015] The storage device 10B is a hard disk drive (HDD) or solid-state drive (SSD), and stores the OS as well as client programs 10F that run on the client terminal device 10. The I / O device 10A is an input / output interface (I / F) for connecting to a pointing device (such as a mouse) or keyboard, or a display with a built-in touch panel. The keyboard may be a software keyboard. The I / O device 10A may also be a voice input unit including a microphone that recognizes the operator's voice input using a voice recognition function and transmits the recognized voice to the arithmetic unit 10C. The I / O device 10A also functions as a user interface (UI) for displaying information.

[0016] Network I / F 10D is an interface to network 30 and is a communication circuit for communicating with other information processing devices (e.g., a web server). The arithmetic unit 10C sends request packets sent from programs such as browser 10G to the destination information processing device (e.g., a web server) via network I / F 10D.

[0017] <Server equipment> 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 Figure 1. That is, the arithmetic unit 20C of the server device 20 uses the computer programs and data stored in the storage device 20B of the server device 20 to communicate with other information processing devices via the network interface 20D of the server device 20, and also executes the various processes described later as being performed by the server device 20. In addition, the server program 20F is stored in the storage device 20B of the server device 20.

[0018] In the server device 20, the arithmetic unit 20C is a microprocessor (CPU). The arithmetic unit 20C starts the OS stored in the storage device 20B according to a boot program such as the BIOS stored in the ROM of memory 20E. Then, it receives request packets from client terminal devices 10 connected via the network 30 and sends the request packets to other information processing devices (for example, a web server) on the internet that are the destination.

[0019] The storage device 20B is an HDD or SSD, and stores the server program 20F that runs on the server device 20. The network interface 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 the request packets received from multiple client terminal devices 10 via the network interface 20D into HTTP request message headers and extracts information about the client terminal devices 10 as described by the client program 10F on each client terminal device 10. It can also 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 send commands such as patch application commands, virus scan commands, and quarantine commands 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. By adopting 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 exchanged packets.

[0022] Furthermore, although both the server device 20 and the client terminal device 10 are located within the LAN in Figure 1, the server device 20 may be located on the Internet 40, provided that it can be connected to the client terminal device 10 via the network 30.

[0023] <Information equipment> In typical network environments such as those of companies and government offices, an information device 50 is installed between the client terminal device 10 and the 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, a router, firewall, UTM (Unified Threat Management), or other network device. In the configuration shown in Figure 1, for Ethernet® frame packets exchanged between the information device 50 and the server device 20, the source MAC address will be that of the information device 50, making it impossible to identify the source client using the MAC address.

[0024] <Processing by client terminal device> Figure 2 is a flowchart of the processing performed by the client terminal device 10 according to this embodiment. The arithmetic unit 10C monitors the transmission of packets (e.g., request packets) by some program (e.g., browser 10G) in the client terminal device 10 (step S201).

[0025] The arithmetic unit 10C determines whether a program has attempted to send a packet to another information processing device (for example, a web server) (step S202). If it is determined that an attempt has been made to send a packet (YES in step S202), the transmission of that packet is temporarily suspended (step S203).

[0026] Next, the arithmetic unit 10C records client-specific information indicating information about the client terminal device 10 as its own header in the HTTP request message within the packet it is about to send (step S204). The client-specific information includes, for example, information indicating the client terminal device (such as the computer name), information indicating the user (such as the username), and information indicating the program that sent the packet (such as the name of the program that made the request, the process name, etc.).

[0027] Figure 4 shows an example of the message header of an HTTP request in a packet edited by the computing unit 10C. In this example, in addition to the usual headers such as User-Agent, there is an "ADDHEADER" header added by the client program 10F, which records the computer name of the client terminal device 10, "TestPCNAME.test.com", and the name of the program that made the request, "iexplore.exe". Note that the method for identifying the program name that sent the request packet and the destination URL is known technology (for example, Japanese Patent Publication No. 2012-185799), so an explanation is omitted.

[0028] Once client-specific information is recorded in the message header of the HTTP request within the packet, the arithmetic unit 10C sends the packet that was temporarily suspended in step S203 (step S205). Note that while the browser 10G is used as an example of a program that sends packets in the above explanation, this program is not limited to the browser 10G; it can be a general application (spreadsheet software, word processing software, etc.) or process.

[0029] <Server device processing> Figure 3 is a flowchart showing the processing of the server device 20. Note that, in the following explanation, the server device 20 will be described as a proxy server, but it is not limited to this.

[0030] In the configuration shown in Figure 1, packets sent from the client terminal device 10 reach the proxy server 20 via the information device 50 before reaching the internet 40. When a packet reaches the proxy server 20, the server program 20F within the proxy server 20 receives the packet first (step S301).

[0031] The arithmetic unit 20C attempts to extract client-specific information from all received packets. Specifically, it performs the following processing on all received packets: The arithmetic unit 20C divides the message header data of the HTTP request in the packet into header name units (step S302). It determines whether there is a header added by the client program 10F (arithmetic unit 10C) of the client terminal device 10 among the divided headers (step S303). The determination is made using a table pre-stored in the storage device 20B, which determines whether the header name is unique to the client program 10F (arithmetic unit 10C) and so on. The table stores client program 10F-specific information, such as "ADDHEADER" as shown in Figure 4.

[0032] If the relevant header exists, the string recorded in that header is recognized as client-specific information (computer name, program name, etc.) 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 dangerous destinations to prevent damage from malware, countermeasures can also be taken against malware remaining on the client side.

[0033] Let's explain this in detail using Figure 4. For example, when server program 20F receives a packet like the one shown in Figure 4, it first divides it into header names. Among the headers, there is an "ADDHEADER" header added by client program 10F, so the string "TestPCNAME.test.co;iexplore.exe" is extracted and split by semicolons. This reveals that the source computer name is "TestPCNAME.test.co" and that the program that sent the packet is "iexplore.exe".

[0034] The header name and header format to be added by the client program 10F are predetermined between the server program 20F and the client program 10F and stored in the storage devices 10B and 20B, respectively.

[0035] As mentioned above, the location where packets are analyzed (for example, the location that identifies the source of the communication) is not at the end of the communication path (such as a web server), but rather somewhere along the communication path that can be managed by the administrator (such as a proxy server). This allows for the analysis of all packets without being affected by the destination of the communication, and enables the simple and accurate identification of the source of the communication.

[0036] [Second Embodiment] Identifying the source client of a packet can yield several benefits, such as the following: The client terminal adds client-specific information, including the computer name and the name of the program that made the request. When a server (e.g., a proxy server) receives a packet with a destination URL that is a dangerous website, it can identify the computer and program that made the access request to the dangerous website based on the client-specific information attached to the received packet. The following describes the processing after the server has identified the source client and program of the packet. Since most of the operation in this embodiment is the same as in the first embodiment, only the differences from the first embodiment will be described here, and the common operations will be omitted.

[0037] Figure 5 is a flowchart showing the processing of the server device 20. The arithmetic unit 20C determines whether the received packet is a request to a dangerous website (step S501). The determination of whether the packet is for accessing a dangerous website is made by comparing the "Host" and other headers included in the standard HTTP request header with a list of dangerous website hostnames stored in the storage device 20B. If it is determined that it is not a dangerous website (NO in step S501), the packet is sent to the destination and processing ends. In the above explanation, the server device 20 determines whether the received packet is a request to a dangerous website, but the determination may also be made by an unillustrated device connected to the network 30 (for example, a UTM). In that case, step S501 is omitted.

[0038] The arithmetic unit 20C determines whether the identified program is a web browser or not (step S502). The determination of whether it is a web browser or not is made based on program information indicating a web browser that is pre-stored in the storage device 20B. If the identified program is a web browser, it can be inferred, for example, that the user jumped from a dangerous URL contained in a phishing email. Therefore, if it is determined to be a web browser (YES in step S502), the arithmetic unit 20C changes the client's email settings (step S503). For example, in order to prevent phishing emails from being received, the destination of the phishing email is checked from the client's operation history identified in step S502, and the settings are changed so that emails from that destination are not received. Note that the email settings may be stored in the server device 20, or in the client terminal device 10 or an email server (not shown).

[0039] The server program 20F determines whether the identified program is a common application or not (step S504). The determination of whether it is a common application or not is made based on program information indicating a common application that is pre-stored in the storage device 20B. If it is a common application (for example, a spreadsheet program, a word processing program, etc.), it is presumed that the request is exploiting a vulnerability in a common application. Therefore, if it is determined to be a common application (YES in step S504), the arithmetic unit 20C applies a patch program to correct the vulnerability to the client terminal device 10 (step S505). Alternatively, the storage device 20B may be pre-stored in association with common applications and the source (download server) for obtaining the patch program, and the corresponding source may be accessed to obtain the patch program and apply it to the client terminal device 10. Alternatively, the patch program may be pre-stored in the storage device 20B in association with a common application.

[0040] If the arithmetic unit 20C determines that the identified program is not a typical application (NO in step S504), it sends a virus scan or quarantine command to the client terminal device 10 (step S506). If the identified program is not a web browser or a typical application, it can be inferred that the malware itself is communicating with a dangerous destination such as a C&C server. Therefore, measures such as performing a virus scan on the client terminal device 10, isolating it from the network, or taking measures to prevent the infection from spreading are necessary. Note that the specified programs used as criteria for determination in steps S502 and S504, such as web browsers and typical applications, are just examples and are not limited to them.

[0041] As mentioned above, by adding client-specific information (client information), it becomes possible to understand the status of the client terminal device, which cannot be determined from normal packets alone, and to take appropriate countermeasures immediately.

[0042] [Third Embodiment] This embodiment describes a process for detecting and addressing damage from seemingly harmless websites by using the operation history. Since most of the operations in this embodiment are the same as those in the first and second embodiments, only the operations that differ from the first and second embodiments will be described here, and the common operations will be omitted.

[0043] Referring to the operation history in Figure 6, record 602 shows that on the date "2019 / 11 / 18" and at the time "11:00:00", the user "userC" accessed the URL "http: / / aaa.com" on the PC named "PC-C". If "http: / / aaa.com" is found to be a dangerous website, the first step is to perform a virus scan on "PC-C" that accessed the URL "http: / / aaa.com", or to block access to that URL.

[0044] However, not all dangerous websites are created by malicious actors. In some cases, a URL that was originally a normal website may be hijacked by a malicious third party and altered to perform dangerous actions such as distributing malware. Furthermore, the determination of whether a URL is dangerous is made after an investigation by an antivirus vendor, so it is not made at the moment the website is altered, but some time later. Therefore, even if a URL is determined to be harmless, it may have already been altered into a dangerous website, so it is necessary to perform virus scans and other measures on PCs that accessed the URL before it was determined to be dangerous.

[0045] Figure 7 is a flowchart showing the processing of the server device 20. Note that in the flowchart of Figure 7, the same processing steps as those shown in Figure 5 are given the same step numbers, and explanations for these processing steps are omitted.

[0046] First, in step S501, suppose the computing unit 20C determines that a URL (for example, "http: / / aaa.com") that a certain client terminal device 10 (for example, "PC-C") attempted to access is dangerous. Then, the computing unit 20C refers to the operation history recorded by all client terminal devices 10 stored in the storage device 20B (step S701). Next, the computing unit 20C determines whether there is any access to the URL determined to be dangerous from a client terminal device 10 other than the one that sent the packet detected in step S501 (for example, "PC-C") in the operation history (step S702).

[0047] Referring to the operation history in Figure 6, we can see in record 601 that PC-A accessed the URL "http: / / aaa.com" on the date "2019 / 08 / 10" at the time "14:00:00".

[0048] If no access by another client terminal device 10 is detected by the arithmetic unit 20C (NO in step S702), it proceeds to step S502 without taking any action. If access is detected (YES in step S702), the arithmetic unit 20C sends a virus scan or quarantine command to the relevant client terminal device 10 (for example, "PC-A") (step S703).

[0049] For example, in the operation history shown in Figure 6, since access to the relevant URL "http: / / aaa.com" by "PC-A" was confirmed, the computing unit 20C issues commands such as a virus scan to "PC-A".

[0050] As mentioned above, by referring to the operation history, it is possible to detect and address damage from seemingly harmless websites.

[0051] [Fourth Embodiment] This embodiment describes a process for detecting and addressing damage from a website even when the local time on the client terminal device 10 is changed.

[0052] In the third embodiment, the computing unit 20C performed a process to determine whether there had been previous access to a dangerous URL from another client terminal device 10 by referring to the operation history. However, if the "time" of 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] While prohibiting changes to the local time altogether would prevent the aforementioned problems, it would also hinder time changes for harmless purposes such as program testing, thus impairing usability. Therefore, a simple ban on changing the time is not appropriate. A method is needed that allows changes to the local time while still obtaining the correct time in the operation history.

[0054] Therefore, when the local time of the client terminal device 10 is changed, the arithmetic unit 10C stores the time difference between before and after the change and records that difference (offset) in the operation history. An example of recording the time difference (offset) in the operation history is shown in Figure 8.

[0055] Figure 8 shows an example of an operation history. Figure 8 has the same meaning as the operation history shown in Figure 6, but in addition to Figure 6, it also records the time difference (offset) when the local time of the client terminal device 10 is changed. Record 801 records the offset value as "+48:00", which indicates that the local time has been shifted back by 48 hours.

[0056] Figure 9 is a flowchart showing the processing of the server device 20. In the flowchart of Figure 9, the same processing steps as those shown in Figure 5 are given the same step numbers, and explanations for these processing steps are omitted.

[0057] In step S501, suppose that on the date "2019 / 11 / 18" and at the time "11:00:00", the arithmetic unit 20C determined that the URL "http: / / aaa.com" accessed by PC-name "PC-C" is a dangerous website. To determine whether the same URL "http: / / aaa.com" has been accessed by other client terminal devices 10 in the past, the arithmetic unit 20C refers to the operation history recorded by all client terminal devices 10 stored in the storage device 20B (step S901).

[0058] The arithmetic unit 20C recalculates the time using the offset value (step S902). For example, record 801 in Figure 8 contains an operation history in which "PC-A" accessed "http: / / aaa.com" on the date "2019 / 11 / 19" at the time "14:00:00". However, the time offset records that this operation history is 48 hours ahead of the original time. Therefore, when the time is recalculated taking the offset into account, the date becomes "2019 / 11 / 17" and the time becomes "14:00:00".

[0059] The arithmetic unit 20C applies the time recalculated in step S902 and determines whether or not there is a history of accessing the relevant URL "http: / / aaa.com" in the past (step S903). For example, in Figure 8, record 801 confirms that "PC-A" accessed "http: / / aaa.com" on the date "2019 / 11 / 17" and at the time "14:00:00" as recalculated in step S902.

[0060] If no access by another client terminal device 10 is detected by the arithmetic unit 20C (NO in step S903), it proceeds to step S502 without taking any action. If access is detected (YES in step S903), the arithmetic unit 20C sends a virus scan or quarantine command to the relevant client terminal device 10 (for example, "PC-A") (step S904).

[0061] For example, in the operation history shown in Figure 8, since access to the relevant URL "http: / / aaa.com" by "PC-A" was confirmed, the arithmetic unit 20C issues a command to "PC-A" to perform a virus scan, etc. Therefore, countermeasures such as issuing a virus scan command to "PC-A" can also be taken.

[0062] As described above, even if the local time on the client terminal device 10 is changed, 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] This embodiment describes a process for detecting and dealing with client terminal devices containing hidden malware by using hash values. Since most of the operations of this embodiment are the same as those of the first to fourth embodiments, 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 computing unit 20C performed a process to determine whether there had been previous access to a dangerous website from other client terminal devices 10 by referring to the operation history. In this embodiment, the hash value of the program that sent the packet from the client terminal device 10 (a program that runs on the client terminal device 10 and sends the request packet to the outside via the network I / F 10D and 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 sent the packet (the program that made the communication request) is recorded in the operation history.

[0065] Figure 10 shows an example of adding a hash value to the operation history. Figure 10 is a diagram showing an example of an operation history. It has the same meaning as the operation history shown in Figures 6 and 8, but in addition to Figure 8, the hash value of the program that made the communication request is also recorded. The hash value is calculated by the client program 10F using the binary value of the program as the key and an algorithm such as SHA-1 or SHA-256, and is then recorded in the storage device 10B as the operation history.

[0066] Record 1001 contains the hash value "AAAAAA...", which indicates that the program with the hash value "AAAAAA..." made the communication request. Furthermore, the hash values ​​of record 1001 and record 1002 match at "AAAAAA...", which indicates that the two communication requests were made by the exact same program, even though they originated from different client terminal devices 10 (PC-A and PC-C).

[0067] Figure 11 is a flowchart showing the processing of the server device 20. In the following explanation, we will assume, as an example, that the operation history shown in Figure 10 is recorded.

[0068] First, let's assume that in step S501, the computing unit 20C determines that a URL (for example, "http: / / 01234.com") that a certain client terminal device 10 attempted to access is dangerous. In the following explanation, we will assume that on the date "2019 / 11 / 21" at the time "16:00:00", a program with the hash value "AAAAAA..." accessed the URL "http: / / 01234.com" from "PC-X".

[0069] Subsequently, the arithmetic unit 20C refers to the operation history recorded by all client terminal devices 10 stored in the storage device 20B (step S1101).

[0070] Next, the arithmetic unit 20C obtains the hash value of the program ("AAAAAA...") that has been added to the request packet as client-specific information, and determines from the operation history referenced in step S1101 whether there is any communication by a program with the same hash value as the hash value obtained in the past (step S1102).

[0071] If there is past communication from a program with the same hash value (step S1102 YES), it means that there is a program that is exactly the same as the one that accessed the dangerous URL ("http: / / 01234.com"). In the operation history shown in Figure 10, there is no trace of past access to the URL "http: / / 01234.com", but there are two instances of communication with the hash value "AAAAAA..." in the operation history records 1001 and 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 were determined to be harmless, they are highly likely to be dangerous sites such as unknown C&C servers. Therefore, it is determined that the same malware has already infiltrated PCs named "PC-A" and "PC-C," and the computing unit 20C sends a virus scan or quarantine command to these client terminal devices 10 (step S1103).

[0073] As mentioned above, by using hash values, it is possible to detect client terminal devices containing hidden malware without accessing dangerous URLs, and to take countermeasures against those client terminal devices.

[0074] [Sixth Embodiment] This embodiment describes a process that uses a user account to restrict logins on other client terminal devices by the same user who attempted to access a dangerous website.

[0075] In the first embodiment, the computer name of the client terminal device 10 was added to the message header of the HTTP request sent from the client terminal device 10 as client-specific information, thereby identifying the client terminal device 10 that attempted to access a dangerous website, and measures such as isolating it from the network were taken. However, even if some measures are taken against the client terminal device 10, if the user who used that client terminal device 10 uses a different client terminal device 10, there is a possibility that they may attempt to connect to a similar dangerous website.

[0076] Therefore, in this embodiment, the arithmetic unit 10C adds user account information (username), which is information indicating the logged-in user, as client-specific information. As a result, the server device 20 can identify the user account that was logged into the client terminal device 10 when accessing a dangerous website, and can use the identified user account to restrict logins to the client terminal device 10 by the same user.

[0077] Figure 12 is a system configuration diagram showing an example of the configuration of an information processing system. The information processing system shown in Figure 12 includes a server device 60 and multiple client terminal devices 11, in addition to the configuration of the information processing system shown in Figure 1. Since most of the server device 60 is the same as the server management device 20, its description will be omitted below, and only the differences will be described. Furthermore, since most of the operation of this embodiment is the same as the operation of the first to fifth embodiments, only the operations that differ from the first to fifth embodiments will be described here, and the common operations will be omitted.

[0078] The server device 60 stores a login management program 60F that manages logins for all client terminal devices 10 within the network 30. Note that the login management program 60F and the server program 20F may be implemented on the same server device.

[0079] Furthermore, the storage device 60B stores an account management table that associates user accounts (account names) and login restrictions (allowed / denied) of all client terminal devices 10 present in the network 30. Figure 14 shows an example of the account management table. The account management table is recorded by identifying user accounts that have accessed dangerous websites, as will be described later. Note that the account management table may also be recorded by an administrator. The login management program 60F, which manages logins, is loaded into the RAM of memory 60E as appropriate according to the control of the arithmetic unit 60C and becomes subject to processing by the arithmetic unit 60C.

[0080] Furthermore, in this embodiment, when logging in to the client terminal device 10, the process shown in Figure 13 is performed. Figure 13 is a sequence diagram showing login restrictions. The arithmetic unit 10C of the client terminal device 10 detects that a user has attempted to log in to any client terminal device 10 (step S1301).

[0081] The computing unit 10C queries the server device 60 via the network interface 10D and network 30 to determine if login is possible (step S1302). The user account attempting to log in is also transmitted along with the query.

[0082] Upon receiving the query, the arithmetic unit 60C compares the loaded user account with the user account included in the query based on the account management table stored in the storage device 60B, and determines whether login is possible (step 1303).

[0083] The computing unit 60C returns a response to the client terminal device 10 that initiated the inquiry, indicating the result of the determination (whether to allow or deny login) (step S1304).

[0084] The computing unit 10C of the client terminal device 10 grants or denies login based on the received determination result. For example, as shown in Figure 14, login from userA is granted, while login from userB is denied.

[0085] Suppose a user accesses a dangerous website (assuming the result is YES in step S501 of Figure 5). As described above, in this embodiment, the arithmetic unit 10C adds the logged-in user account to the request packet, so the arithmetic unit 20C can identify the user account that made the request. Therefore, the arithmetic unit 20C records "denied" as the login restriction corresponding to the user account of the user who accessed the dangerous website in the account management table recorded in the storage device 60B of the server device 60 via the network I / F 20D and network 30.

[0086] As mentioned above, if a user attempts to access a dangerous website and then tries to log in from another client terminal, that login can be blocked. This helps to deter the same user from accessing dangerous websites again.

[0087] <Other Embodiments> The present invention can also be realized by supplying a program that implements one or more of the functions of the above-described embodiments to a system or device via a network or storage medium, and by having one or more processors in the computer of that system or device read and execute the program. It can also be realized by a circuit (for example, an ASIC) that implements one or more functions.

Claims

1. An information processing system, It has a client terminal device, information equipment, and a server device. The aforementioned client terminal device is A monitoring means for monitoring packets, A recording means that records client-specific information as the message header of an HTTP request in a packet monitored by the monitoring means, A transmission means that transmits a packet containing the message header of an HTTP request, on which client-specific information has been recorded by the recording means, to the information device. Equipped with, The server device is Receiving means for receiving the packets from the information device, An extraction means for extracting client-specific information recorded as the message header of the HTTP request from the packet received by the receiving means. An information processing system characterized by having the following features.

2. The information processing system according to claim 1, characterized in that the client-specific information is information that identifies a user.

3. The information processing system according to claim 1, characterized in that the client-specific information is a program name or a process name.

4. The information processing system according to claim 1, characterized in that the client-specific information is information indicating a client terminal device.

5. An information processing system, It has a client terminal device, information equipment, and a server device. The aforementioned client terminal device is A monitoring means for monitoring packets, A recording means that records information indicating a client terminal device or user along with information indicating a program in the packets monitored by the monitoring means, A transmission means that transmits a packet containing information indicating a program along with information indicating a client terminal device or user to the information device, recorded by the recording means, Equipped with, The server device is Receiving means for receiving the packet from the information device, An extraction means for extracting information indicating the client terminal device or user, along with information indicating the program, from the packet received by the receiving means. An information processing system characterized by having the following features.

6. The information processing system according to claim 5, characterized in that the information indicating the program is a program name or a process name.

7. The information processing system according to claim 5, characterized in that the server device has a determination means for determining whether or not a packet received by the receiving means is a request to a predetermined access destination.

8. The information processing system according to claim 7, characterized in that the determination means performs the determination using a list of predetermined access destinations.

9. An information processing system, It has a client terminal device, information equipment, and a server device. The aforementioned client terminal device is A monitoring means for monitoring packets, An addition means for adding client-specific information to packets monitored by the monitoring means, A transmission means that transmits a packet to the information device to which client-specific information has been added by the aforementioned additional means. Equipped with, The server device is Receiving means for receiving the packet from the information device, An extraction means for extracting client-specific information from packets received by the receiving means, A determination means for determining whether a packet received by the receiving means is a request to a predetermined access destination, An information processing system characterized by having the following features.

Images