JP7617239B2 - Information Processing System - Google Patents

Description

The present invention relates to an information processing system .

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 combat this, countermeasures have been taken to prevent damage caused by malware by making a list of destination information (URLs, IP addresses, etc.) for 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.

Therefore, one technique for identifying the source of network communications is to refer to the MAC address in an Ethernet (registered trademark) frame. However, because MAC addresses are information that can only be transmitted within the same segment, it is assumed that there are no other network devices between the source client and the network device performing the identification. However, in the case of a typical network configuration within a company or government agency, there are various external devices such as routers and firewalls along the network. Therefore, in such an environment, the source of network communications 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 communications on an external device, but this makes management cumbersome.

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.

JP 2004-240559 A

However, in Prior Art Document 1, the location where the URL is analyzed is a web server, which is beyond the control of the user or administrator, and therefore cannot be applied to communications outside of the user'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 terminal that is the source of communications.

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 information indicating a client terminal device to a packet monitored by the monitoring means;
a transmitting means for transmitting the packet added by the adding means to the information device,
The server device includes:
receiving means for receiving the packet from the information device;
and an extracting means for extracting information indicating the client terminal device from the packet received by the receiving means.

According to the present invention, the terminal that is the source of communication can be easily identified.

FIG. 1 is a system configuration diagram showing an example of the configuration of an information processing system. 4 is a flowchart showing a process of the client terminal device 10. 13 is a flowchart showing a process of the server device 20. FIG. 13 illustrates an example of a packet. 13 is a flowchart showing a process of the server device 20. FIG. 11 is a diagram showing an example of an operation history. 13 is a flowchart showing a process of the server device 20. FIG. 13 is a diagram illustrating an example of an operation history. 13 is a flowchart showing a process of the server device 20. FIG. 11 is a diagram showing an example of an operation history. 13 is a flowchart showing a process of the server device 20. FIG. 1 is a system configuration diagram showing an example of the configuration of an information processing system. FIG. 11 is a sequence diagram showing login restrictions. FIG. 13 illustrates an example of an account management table.

[First embodiment]
<System configuration diagram>
First, the information processing system configuration 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 multiple client terminal devices 10 and information devices 50. There may be multiple server devices 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 devices capable of executing each process described below as being performed by an information processing device such as a PC or a mobile terminal device.

<Client Terminal Device>
In the client terminal device 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 operation of the OS or the user. This storage device 10B stores computer programs and data for causing the arithmetic unit 10C to execute various processes, which will be described later as being performed by the OS and this device. These computer programs include a client program 10F and a browser 10G.

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 as an operation history in the storage device 10B, 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).

Figure 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 URL of the request (access destination URL), etc. are recorded. For example, record 601 indicates that a communication request was made to the access destination URL "http://aaa.com" from a PC named "PC-A" in which a user named "userA" was logged in on the date "2019/08/10" at "14:00:00". Note that the information recorded is not limited to this.

Computer programs and data stored in storage device 10B are loaded into the RAM of memory 10E as appropriate under the control of computing device 10C, and are processed by computing device 10C. The OS may be, for example, Windows (registered trademark), MacOS, Linux (registered trademark), iOS, Android, etc.

The storage device 10B is a hard disk drive (HDD) or a solid state drive (SSD), and stores the OS as well as the client program 10F that runs 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 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 calculation device 10C. The I/O device 10A also functions as a user interface (UI) for displaying information.

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 computing 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.

<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 unit 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.

In the server device 20, the computing device 20C is a microprocessor (CPU). The computing device 20C starts the OS stored in the storage device 20B in accordance with a boot program such as the BIOS stored in the ROM of the memory 20E. Then, the computing 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 (such as a web server) on the Internet that is the destination.

The storage device 20B is a HDD, SSD, or the like, and stores the 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.

The server program 20F divides the request packets received from multiple 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. It can also store and manage the operation history of the client terminal devices 10 sent from the client terminal devices 10 connected via the network 30 in the storage device 20B, and can also send commands such as patch application commands, virus scan commands, and quarantine commands to the client terminal devices 10.

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.

In addition, in FIG. 1, the server device 20 and the client terminal device 10 are both installed inside the LAN, but the server device 20 may be installed on the Internet 40 as long as it can be connected to the client terminal device 10 via the network 30.

<Information devices>
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 an Ethernet (registered trademark) frame packet 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.

<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 unit 10C monitors the transmission of a packet (e.g., a request packet) by a program (e.g., a browser 10G) in the client terminal device 10 (step S201).

The computing device 10C determines whether any program has attempted to transmit a packet to another information processing device (e.g., a web server) (step S202). If it is determined that a packet transmission has been attempted (YES in step S202), the computing device 10C temporarily suspends the transmission of the packet (step S203).

Next, the computing device 10C records client-specific information indicating information about the client terminal device 10 as a unique header in the HTTP request message in the packet to be sent (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 sent the packet (such as the name of the program that made the request, the process name, etc.).

Figure 4 shows an example of a message header of an HTTP request in a packet edited by the computing 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, 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 of identifying the program name that sent the request packet and the destination URL is a publicly known technique (for example, JP 2012-185799 A), so a description thereof will be omitted.

After recording the client-specific information in the message header of the HTTP request in the packet, the computing device 10C transmits the packet whose transmission was temporarily suspended in step S203 (step S205). Note that in the above explanation, 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.

<Server Device Processing>
3 is a flowchart showing the process of the server device 20. In the following description, the server device 20 is described as a proxy server, but is not limited to this.

In the configuration of FIG. 1, a packet sent 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).

The computing device 20C attempts to extract information specific to the sender client from all received packets. Specifically, the following process is performed for all received packets. The computing device 20C divides the message header data of the HTTP request in the packet into header name units (step S302). It determines whether any header added by the client program 10F (computing device 10C) of the client terminal device 10 is present among the divided headers (step S303). The determination is made using a table stored in advance in the storage device 20B to determine whether the header name is a unique one added by the client program 10F (computing device 10C). The table stores information specific to the client program 10F, such as "ADDHEADER" as shown in FIG. 4.

If the relevant header is present, the character string recorded in the 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 communications to dangerous destinations to prevent damage caused by malware, measures can also be taken against malware remaining on the client side.

A more detailed explanation will be given using Figure 4. For example, when server program 20F receives a packet as shown in Figure 4, it first divides it into header name units. Since the header contains an "ADDHEADER" header added by client program 10F, the character string "TestPCNAME.test.co;iexplore.exe" is obtained and divided by semicolons. 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".

The header name and 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.

As mentioned above, the location where packets are analyzed (for example, the location where the source of the communication is identified) is not located 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.

[Second embodiment]
By identifying the source client of the packet, for example, the following effects can be obtained. When the client terminal device adds the "computer name" and the "requested program name" as client-specific information and a server device (e.g., a proxy server) receives a packet whose destination URL is a dangerous website, 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 process after the server device identifies the source client and program of the packet. Note that most of the operations of this embodiment are common to the operations of the first embodiment, so only operations that differ from the first embodiment will be described here, and common operations will be omitted.

Figure 5 is a flowchart showing the processing of the server device 20. The computing device 20C judges whether the received packet is a request to a dangerous website (step S501). The judgment of whether the packet is for access to a dangerous website is made by comparing "Host" and other information contained 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 processing ends. In the above explanation, 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 (not shown) connected to the network 30 (for example, a UTM). In that case, step S501 is omitted.

The computing device 20C determines whether the identified program is a web browser (step S502). The determination of whether the program is a web browser is based on 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 assumed that the program jumped from a dangerous URL included in the phishing email, for example. If the program is determined to be a web browser (YES in step S502), the computing device 20C changes the email settings of the client (step S503). For example, in order to prevent the phishing email from being delivered, the computing device 20C checks the destination from which the phishing email was sent from the operation history of the client identified in step S502, and sets the client to not receive emails from that destination. The email settings may be stored in the server device 20, the client terminal device 10, or a mail server (not shown).

The server program 20F judges whether the identified program is a general application (step S504). The judgment of whether it is a general application is made based on the program information indicating the general application pre-stored in the storage device 20B. If it 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 it is judged to be a general application (YES in step S504), the calculation device 20C applies a patch program that fixes the vulnerability to the client terminal device 10 (step S505). Note that the general application and the acquisition destination (download server) of the patch program may be associated and stored in the storage device 20B in advance, and the corresponding acquisition destination may be accessed to acquire the patch program, and the patch program may be applied to the client terminal device 10. Also, the patch program may be associated with the general application and pre-stored in the storage device 20B.

If the computing device 20C determines that the identified program is not a general application (NO in step S504), it sends 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 within the client terminal device 10, isolating it from the network, and preventing the infection from spreading are necessary. Note that the predetermined programs used as the judgment criteria in steps S502 and S504, such as a web browser and a general application, are merely examples and are not limited to these.

As mentioned above, by adding client-specific information (client information), it is possible to understand the situation on the client terminal device side, which cannot be determined from normal packets alone, and to take appropriate measures immediately.

[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.

Referring to the operation history in FIG. 6, record 602 records that on date "2019/11/18" and time "11:00:00", user name "userC" accessed the URL "http://aaa.com" on PC name "PC-C". If it turns out that "http://aaa.com" is a dangerous website, it will be necessary to first take measures such as running a virus scan on "PC-C" that accessed the URL "http://aaa.com", or prohibiting access to the URL.

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. Furthermore, the determination of whether the URL in question is dangerous or not is made after an investigation by an antivirus vendor, so this 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 on PCs that accessed the URL in question before it was determined to be dangerous.

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 the explanation of these processing steps is omitted.

First, in step S501, the computing device 20C determines that a URL (e.g., "http://aaa.com") that a client terminal device 10 (e.g., "PC-C") is attempting to access is dangerous. The computing device 20C then refers to the operation history recorded in all client terminal devices 10 stored in the storage device 20B (step S701). Next, the computing device 20C determines whether the operation history contains any access to the URL determined to be dangerous from any client other than the client terminal device 10 (e.g., "PC-C") that sent the packet detected in step S501 (step S702).

Referring to the operation history in Figure 6, record 601 shows that the URL "http://aaa.com" was accessed by a PC named "PC-A" on the date "2019/08/10" and time "14:00:00".

If the computing device 20C does not confirm access by another client terminal device 10 (NO in step S702), it does nothing and proceeds to step S502. If access is confirmed (YES in step S702), the computing device 20C sends a virus scan or quarantine command to the client terminal device 10 (e.g., "PC-A") (step S703).

For example, in the case of the operation history of Figure 6, since access to the URL "http://aaa.com" by "PC-A" was confirmed, the computing device 20C issues a command to "PC-A" to perform a virus scan, etc.

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.

[Fourth embodiment]
In this embodiment, a process for detecting and dealing with damage from a website even when the local time is changed in the client terminal device 10 will be described.

In the third embodiment, the computing device 20C refers to the operation history to perform processing to determine whether a dangerous URL has been accessed from another client terminal device 10 in the past. 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.

The problems mentioned above can be prevented by prohibiting changes to the local time itself, but this would also hinder time changes for non-malicious purposes such as program testing, reducing convenience, so banning time changes entirely is not appropriate. For this reason, 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.

Therefore, when the local time of the client terminal device 10 is changed, the computing device 10C stores the time difference before and after the change, and records this difference (offset) in the operation history. An example of recording the time difference (offset) in the operation history is shown in Figure 8.

Figure 8 is a diagram showing 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 of "+48:00", which indicates that the local time has been shifted back 48 hours.

Figure 9 is a flowchart showing the processing of the server device 20. Note that in the flowchart of Figure 9, the same processing steps as those shown in Figure 5 are given the same step numbers, and the explanation of these processing steps is omitted.

In step S501, it is assumed that the URL "http://aaa.com" accessed by the PC named "PC-C" on date "2019/11/18" at time "11:00:00" is determined by the computing device 20C to be a dangerous website. The computing device 20C refers to the operation history recorded in all client terminal devices 10 stored in the storage device 20B to determine whether the same URL "http://aaa.com" was previously accessed by another client terminal device 10 (step S901).

The calculation device 20C recalculates the time using the offset value (step S902). For example, record 801 in FIG. 8 contains an operation history in which "PC-A" accessed "http://aaa.com" on date "2019/11/19" at 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".

The computing device 20C applies the time recalculated in step S902 and determines whether there is a history of accessing the URL "http://aaa.com" in the past (step S903). For example, record 801 in FIG. 8 confirms that "http://aaa.com" was accessed on "PC-A" on the date "2019/11/17" and time "14:00:00" recalculated in step S902.

If the computing device 20C does not confirm access by another client terminal device 10 (NO in step S903), it does nothing and proceeds to step S502. If access is confirmed (YES in step S903), the computing device 20C sends a virus scan or quarantine command to the client terminal device 10 (e.g., "PC-A") (step S904).

For example, in the case of the operation history of FIG. 8, since access to the URL "http://aaa.com" by "PC-A" was confirmed, the computing device 20C issues a command to "PC-A" to perform a virus scan or the like. Therefore, measures can be taken, such as issuing a virus scan command to "PC-A" as well.

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.

[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.

In the third and fourth embodiments, the computing device 20C refers to the operation history to perform processing to determine whether a dangerous website has been accessed from another client terminal device 10 in the past. 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 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 sent the packet (the program that made the communication request) is recorded in the operation history.

Figure 10 shows an example of an operation history with a hash value added. 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 the operation history shown in Figure 8, the hash value of the program that made the 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 the operation history.

Record 1001 records the hash value "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).

Figure 11 is a flowchart showing the processing of the server device 20. In the following, as an example, the explanation will be given assuming that the operation history shown in Figure 10 is recorded.

First, in step S501, it is assumed that the computing device 20C has determined that the 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".

Then, the computing device 20C refers to the operation history recorded in all client terminal devices 10 stored in the storage device 20B (step S1101).

Next, the computing device 20C acquires the hash value of the program ("AAAAAA...") that was 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 that has the same hash value as the previously acquired hash value (step S1102).

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..." corresponds to two records in the operation history, records 1001 and 1002.

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 determined that the same malware has already infiltrated PC names "PC-A" and "PC-C", the computing device 20C sends a virus scan or quarantine command to these client terminal devices 10 (step S1103).

As mentioned above, by using hash values, it is possible to discover client terminal devices that contain lurking malware without accessing dangerous URLs, and to take action against those client terminal devices.

[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 website.

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 who used that client terminal device 10 uses another client terminal device 10, there is a possibility that he or she will attempt to connect to a similarly dangerous website.

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 accessing a dangerous website, and can use the identified user account to restrict logins to the client terminal device 10 by the same user.

Figure 12 is a system configuration diagram showing an example of the configuration of an information processing system. In addition to the configuration of the information processing system shown in Figure 1, the information processing system shown in Figure 12 includes a server device 60 and multiple client terminal devices 11. As most of the server device 60 is common to the server management device 20, a description will be omitted below and only the different parts will be described. Note that most of the operation of this embodiment is common to the operations of the first to fifth embodiments, so only the operations that differ from the first to fifth embodiments will be described here and the common operations will be omitted.

The server device 60 stores a login management program 60F that manages the logins of all client terminal devices 10 present within the network 30. The login management program 60F and the server program 20F may be configured to be implemented on the same server device.

The storage device 60B also records an account management table in which the user accounts (account names) of all client terminal devices 10 present within 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. The login management program 60F, which manages logins, is loaded into the RAM of the memory 60E as appropriate under the control of the computing device 60C, and becomes the subject of processing by the computing device 60C.

In addition, in this embodiment, when logging in to a 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 computing device 10C of the client device 10 detects that a user has attempted to log in (step S1301).

The computing 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 sent.

The computing device 60C that receives the inquiry compares the loaded user account with the user account included in the inquiry based on the account management table stored in the memory device 60B, and determines whether login is possible (step 1303).

The computing device 60C returns a response indicating the result of the determination (login permission or denial) to the client terminal device 10 that originated the inquiry (step S1304).

The computing device 10C of the client terminal device 10 allows or denies the login based on the received judgment result. For example, as shown in FIG. 14, login from user A is allowed, and login from user B is denied.

Let us assume that a user accesses a dangerous website (assuming that a YES determination is made in step S501 in FIG. 5). As described above, in this embodiment, the computing device 10C adds the logged-in user account to the request packet, so the computing device 20C can identify the user account that made the request. The computing device 20C then 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.

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. This makes it possible to prevent the same user from accessing dangerous websites.

<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 (10)

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 information indicating a client terminal device to a packet monitored by the monitoring means;
a transmitting means for transmitting the packet added by the adding means to the information device,
The server device includes:
receiving means for receiving the packet from the information device;
and an extracting means for extracting information indicating the client terminal device from the packet received by the receiving means. 2. The information processing system according to claim 1, wherein the information indicative of the client terminal device is a computer name. 3. The information processing system according to claim 1, wherein said server device comprises a first determination means for determining whether or not the packet received by said receiving means is a request for a predetermined access destination. 4. The information processing system according to claim 3, wherein the first determination means makes the determination using a list in which predetermined access destinations are recorded. 5. The information processing system according to claim 1, wherein the server device is a proxy server. 6. The information processing system according to claim 1, wherein the information device is a router, a firewall, or a UTM. the adding means further adds, to the packet, information indicating a program that has transmitted the packet;
The server device includes:
7. The information processing system according to claim 3 , further comprising a second determination unit that determines whether the information indicating the program is information indicating a predetermined program . 8. The information processing system according to claim 7, wherein the information indicating the program is a program name or a process name. The adding means further adds information indicating a user to the packet;
An information processing system as described in any one of claims 1 to 8, characterized in that the extraction means extracts information indicating the user from the packet and records it in a table in which the information indicating the user corresponds to information regarding restrictions on logging in to the client terminal device. 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:
10. The information processing system according to claim 9 , wherein a restriction on logging in to the client terminal device is determined based on the received information indicating a user of the client terminal device, based on the table.

Images