Attack observation apparatus and attack observation method

The present invention relates to an attack observation apparatus being a simulation environment where a malicious program such as malware created by an attacker is run, the simulation environment being built for observing the behavior and attack scheme of the malicious program.The attack observation apparatus includes a low-interactive simulation environment to execute on a terminal a predetermined response to communication coming from the malware, a high-interactive simulation environment to execute a response to the communication coming from the malware with using a virtual machine which simulates the terminal, and a communication management part to monitor an execution state of the low-interactive simulation environment with respect to the communication coming from the malware and switch the communication coming from the malware to the high-interactive simulation environment depending on the execution state of the low-interactive simulation environment.

TECHNICAL FIELD

The present invention relates to an attack observation apparatus being a simulation environment where a malicious program such as malware created by an attacker is run, the simulation environment being built for observing the behavior and attack scheme of the malicious program.

BACKGROUND ART

Conventionally, in a simulation network system where a malicious program such as malware created by an attacker is run, the malicious network system being built for observing the behavior and attack scheme of the malicious program, a scheme (to be referred to as simulation environment hereinafter) of simulating a terminal or server which functions in the network system is known. For example, a scheme as described in Patent Literature 1 is known. According to this scheme, simulation is performed by a simulation program which receives communication data as input transmitted from a malware-infected terminal, determines response data in accordance with the contents of the communication data, and sends back the response data. Such a simulation environment will be called a low-interactive honeypot (an example of a low-interactive simulation environment) hereinafter.

A scheme as described in Patent Literature 2 and Non-Patent Literature 1 is also known. According to this scheme, a virtual machine is operated in a virtualized environment that uses a commercially available product, and this virtualized environment is used as a simulation environment. Such a simulation environment will be referred to as a high-interactive honeypot (an example of a high-interactive simulation environment) hereinafter.

CITATION LIST

Patent Literature

Non-Patent Literature 1: Takahiro Kasama et al, “Malware Sandbox Analysis System with Accumulated Server Responses Collected by Dummy Clients”, International Processing Society of Japan, anti Malware engineering Workshop 2009 (MWS2009) A7-2, (October 2009).

SUMMARY OF INVENTION

Technical Problem

In a low-interactive honeypot, each simulated terminal and each server return a response to the contents of a received communication packet, in accordance with a method predetermined by a program. Since it is only necessary to return the determined response to the packet transmitted from malware, advantageous can be obtained that the processing load is small and that large numbers of terminals and servers can be simulated simultaneously. However, a problem exists that when a packet with contents (for example, an unknown attack) that cannot be processed by the program is received, the terminals and servers cannot respond in the same manner as when an actual packet is received. Another problem also arises that in face of an attack accompanying malware infection, it is impossible to run the malware in the simulation environment.

Meanwhile, a high-interactive honeypot can cope with the above-mentioned issue of unknown attack and malware infection. However, a simulation environment that uses high-interactive honeypots requires resources (a CPU, a memory, an HHD, and so on) equivalent to the actual resources for simulating one terminal or one server. When, for example, the entire business system is to be simulated, a large number of terminals and a large number of servers must be prepared.

As described above, in the prior art, a large-scale system cannot be simulated elaborately.

The present invention has been made to solve the above problems, and has as its object to implement an attack observation apparatus capable of elaborate simulation with a few computer resources even in a large-scale network system such as a business system.

Solution to Problem

In order to solve the problems described above, an attack observation apparatus according to the present invention is an attack observation apparatus being an environment where malware is run and an attack of the malware is observed, and includes: a low-interactive simulation environment to execute on a terminal a predetermined response to communication coming from the malware; a high-interactive simulation environment to execute a response to the communication coming from the malware with using a virtual machine which simulates the terminal; and a communication management part to monitor an execution state of the low-interactive simulation environment with respect to the communication coming from the malware and switch the communication coming from the malware to the high-interactive simulation environment depending on the execution state of the low-interactive simulation environment.

Advantageous Effects of Invention

According to the present invention, communication is processed initially by a low-interactive honeypot. Communication is switched to a low-interactive honeypot only where necessary, so that use of the high-interactive honeypot can be reduced. Hence, an effect can be obtained that an attack observation apparatus simulating a large-scale system can be implemented with a few computer resources.

DESCRIPTION OF EMBODIMENTS

FIG. 1is a configuration diagram illustrating a configuration example of an attack observation apparatus according to Embodiment 1.

Referring toFIG. 1, a honeypot system101being an attack observation apparatus is constituted of a high-interactive honeypot part103being a high-interactive simulation environment, a low-interactive honeypot part106being a low-interactive simulation environment, a terminal state transition scenario execution part107, a terminal state management part108, a terminal state accumulation part109, a terminal state transition scenario accumulation part110, a communication management part112, a honeypot execution state management part115being an execution state management part, and a high-interactive honeypot execution command accumulation part116being an execution command accumulation part. The high-interactive honeypot part103and the low-interactive honeypot part106will be collectively called the honeypot hereinafter.

The high-interactive honeypot part103houses virtual machines104serving as high-interactive honeypots and a virtual machine execution environment105which executes the virtual machines104. The low-interactive honeypot part106operates as a low-interactive honeypot. The terminal state transition scenario execution part107instructs to the terminal state management part108a state change of a file and the like occurring spontaneously in each terminal simulated in the honeypot system101. The terminal state management part108acquires and/or changes the state of the file and the like in each terminal in accordance with a command from the terminal state transition scenario execution part107or low-interactive honeypot part106. The terminal state transition scenario accumulation part110accumulates a terminal state transition scenario indicating a scenario for the state transition of each terminal. The communication management part112relays and/or manages communication between honeypots, or between the honeypots and an external network102. The honeypot execution state management part115manages honeypot execution state data indicating the present execution state of the honeypots. The high-interactive honeypot execution command accumulation part116accumulates a high-interactive honeypot execution command definition table that defines a command and so on started when the terminal state transition scenario is reproduced on the high-interactive honeypot part103. The communication management part112is connected to the virtual machines104via a network111and connected to the low-interactive honeypot part106via a network113. The communication management part112is also connected to the external network102via a network114.

FIG. 2is a diagram describing configurations of the communication management part112and network111in detail.

Referring toFIG. 2, the communication management part112is constituted of a packet reception part207which receives a packet to the communication management part112, a packet transmission part208for transmitting the packet from the communication management part112, an ARP (Address Resolution Protocol) response part209which returns a spoofed response to an ARP, a gateway part210which relays communication, and a communication restoring data accumulation part211accumulating data necessary for reconstructing a pre-transition communication state on a post-transition simulated terminal in execution state transition of the simulated terminal. The communication management part112is connected to the low-interactive honeypot part106via a network113and connected to the outside of the honeypot system via a network114.

InFIG. 2, the network111ofFIG. 1is constituted of a virtual switch205in the high-interactive honeypot part103, VLANs (Virtual Local Area Networks)203to204built between respective virtual machines201to202and the virtual switch205, and a network206which trunk-connects the virtual switch205and the communication management part112.

FIG. 3is a diagram describing a configuration of a low-interactive honeypot part106in detail.

Referring toFIG. 3, the low-interactive honeypot part106is provided with a communication processing program execution part301and a communication processing program accumulation part302. The communication processing program execution part301executes a communication processing program which processes common communication protocols such as TCP/IP (Transmission Control Protocol/Internet Protocol) and TLS (Transport Layer Security), and application layer communication. The communication processing program accumulation part302stores at least one communication processing program303. Each communication processing program303is identifiable by its program name.

FIG. 4is a diagram illustrating an example of honeypot execution state data stored in the honeypot execution state management part115.

Referring toFIG. 4, the honeypot execution state data is constituted of a terminal ID401, a communication processing program name402, a file system name403an IP address404, an execution state405, and a VLAN ID406.

FIG. 5is a diagram illustrating an example of the terminal state transition scenario stored in the terminal state transition scenario accumulation part110.

Referring toFIG. 5, the terminal state transition scenario is constituted of a scenario execution time501, a terminal ID502indicating the ID of a simulated terminal for which a scenario is to be carried out, and a command503which is to be carried out for causing a state transition.

FIG. 6is a diagram illustrating an example of the high-interactive honeypot execution command definition table stored in the high-interactive honeypot execution command accumulation part116.

Referring toFIG. 6, the high-interactive honeypot execution command definition table is constituted of a command name601, a terminal ID602of a terminal for which a command is to be carried out, a started program603started when carrying out a command, and a user ID604of a user having a user privilege for carrying out an operation. As indicated by605, it is possible to specify for the started program603a variable ($1 in the case ofFIG. 6) that looks up an argument given to the command of the started program603.

FIG. 7is a diagram illustrating a configuration example of the terminal state accumulation part109.

Referring toFIG. 7, virtual machine images701to702of the respective simulated terminals are housed in the terminal state accumulation part109. A virtual machine image stores as a file the image of the file system of a corresponding simulated terminal. This method of storing the image of a file system, as a file can be implemented easily by, for example, reading the sectors in the HDD sequentially and storing them in a file, as with a dd command of a basic OS, for example.

The operation of the attack observation apparatus according to Embodiment 1 will be described.

First, the outline of the overall operation will be described. A terminal simulated in the honeypot system101according to Embodiment 1 transitions between two execution states, namely, a low-interactive honeypot state and a high-interactive honeypot state.

When communication addressed to a target terminal to be simulated in this system occurs, the communication management part112relays communication data to the low-interactive honeypot part106or to the virtual machines104in the high-interactive honeypot part103depending on the execution state of the target terminal.

The low-interactive honeypot part106returns a response to the transmitted communication data in accordance with the communication processing program303. If the communication processing program303determines that switching to a high-interactive honeypot is necessary because, for example, communication for which a processing method is not defined has arrived, then a virtual machine that simulates the address terminal is booted in the high-interactive honeypot part103, and the execution state of the addressed terminal transitions to the high-interactive honeypot state. Subsequent communication is transferred to the virtual machine by the communication management part112.

The terminal state transition scenario execution part107carries out the spontaneous state change in each simulated terminal in accordance with the scenario by operating the terminal state management part108. A spontaneous state change signifies a state change occurring irrespective of the communication to the simulated terminal, that is, a file change. The purpose of the spontaneous state change is to make the state look as if an authorized user were acting on the simulated terminal.

The operation in detail of each part of the attack observation apparatus will now be described. To begin with, the operation of the communication management part112will be described with referring toFIG. 8.

FIG. 8is a sequence diagram illustrating communication the communication management part112carries out with other terminals and a process executed in the communication management part112.

Referring toFIG. 8, first, when a terminal1(801) is to communicate with a simulated terminal (having an IP address of IP2), the terminal1transmits a connection request to IP2(803) as a destination. The connection request is received by the packet reception part207of the communication management part112and supplied to the gateway part210. The gateway part210establishes the connection with the sender. Honeypot execution state data (FIG. 4) in the honeypot execution state management part115is searched for with using the destination IP address as a key. When it is confirmed that the terminal1is a simulated terminal, the communication management part112sends a connection request, and the connection is established (804). Namely, connection from a terminal to another terminal is terminated by the gateway part210in the communication management part112, providing two connections. Not only a TCP but also a session such as a TLS (Transport Layer Security), which is built by a higher-level protocol is terminated by the communication management part112.

After that, the terminal1(801) and a low-interactive honeypot (802) communicate with each other as the communication is being relayed by the communication management part112(805to815). The communication management part112, while relaying the communication, monitors the communication state change of the application layer of the communication it relays, and stores in the communication restoring data accumulation part211the communication of when a state transition occurs.

For example, suppose that the communication illustrated inFIG. 8relays an application layer which that causes a state transition as indicated by the state transition diagram illustrated inFIG. 9.

FIG. 9is a diagram illustrating an example of a state transition of a communication protocol.

In the case of the state transition ofFIG. 9, it is seen that at the time a log-in (904) communication occurs, the communication state transitions from connection complete (903) to log-in complete (905). Therefore, after log-in is successful at808, log-in data is stored in the communication restoring data accumulation part211at809. A command relayed after the log-in will not be stored in the communication restoring data accumulation part211because this command corresponds to transition of906inFIG. 9and does not cause a state transition.

Subsequently, communication with a command #n is transferred to the low-interactive honeypot802at815, and after that a switching request816for a honeypot is sent from the low-interactive honeypot802. Then, the communication management part112changes the execution state of the simulated terminal in the honeypot execution state data (FIG. 4) in the honeypot execution state management part115to the high-interactive honeypot state (817). The communication management part112boots a new virtual machine in the high-interactive honeypot part103and connects the high-interactive honeypot part103to a virtual switch with using a VLAN independent of the other virtual machines (819).

After that, the communication management part112connects to the booted virtual machine (820). In order to restore the communication state to the state of communication that has been carried out between the low-interactive honeypot802and the terminal1(801) until immediately recently, the communication management part112transmits a log-in request (821) with using the log-in data which has been stored in the communication restoring data accumulation part211, and receives a log-in response (822). Note that communication state restoration of821to822is to restore the communication state of immediately before switching the honeypot and accordingly does not deal with a command #1to a command “n−1 as a restoration target. Then, the communication management part112transmits a command #n (823) that has been transmitted to the low-interactive honeypot802the last time, and transfers (825) a command #n result (824) being a response to the command #n (823), to the terminal1(801).

A proxy server and the like are known as examples of an apparatus arranged between two terminals, for building separate connections to the two terminals respectively and transferring data between the two connections in this manner. Embodiment 1 is different from such a known embodiment in the following respect. Namely, the communication management part112in Embodiment 1 spoofs an IP address so that none of the two terminals can identify the communication management part112as being a communication party. This operation is implemented when, at the start of communication with each simulated terminal, the ARP response part209of the communication management part112returns the MAC (Media Access Control) address of the communication management part112for an ARP (Address Resolution Protocol) request from the communication terminal to broadcast the MAC address of the communication party.

In Embodiment 1, the packet transmission part208of the communication management part112must determine on which network a packet should be supplied. For this purpose, the packet transmission part208looks up the honeypot execution state data stored in the honeypot execution state management part115to check the execution state of a simulated terminal corresponding to the destination IP. If the execution state is low-interactive, the packet transmission part208transmits the packet onto a network (113in the case ofFIG. 2) connected to the low-interactive honeypot802. If the execution state is high-interactive, the packet transmission part208acquires a VLAN ID of the VLAN to which the simulated terminal is connected. The packet transmission part208stores the VLAN ID in an L2frame (tag VLAN) as a tag and transmits the packet, so that the packet arrives at the corresponding VLAN.

The operation of the low-interactive honeypot802will be described with referring toFIG. 10.

FIG. 10is a flowchart illustrating an operation flow of the low-interactive honeypot802.

First, in step S101, the low-interactive honeypot802waits for a packet to arrive.

Then, in step S102, when a packet arrives at the low-interactive honeypot802, the low-interactive honeypot802acquires a destination IP.

Then, in step S103, the low-interactive honeypot802searches for honeypot execution state data stored in the honeypot execution state management part115with using the acquired destination IP as a key, and acquires a terminal ID and a communication processing program name which are registered in the honeypot execution state data.

Then, in step S104, the low-interactive honeypot802executes the communication processing program303by giving the acquired terminal ID to the communication processing program303as a parameter.

The process in the communication processing program303changes when seen in detail depending on the protocol simulated by the communication processing program303, and flows as illustrated by the flowchart ofFIG. 11.

FIG. 11is a flowchart illustrating an operation flow in the communication processing program303.

First, in step S201, the communication processing program303receives the data of the arriving packet, from the communication processing program execution part301.

Then, in step S202, the communication processing program303analyzes the received data and determines whether a response should be returned, the process should be ended, or switching to a high-interactive honeypot should be made

Then, in step S203, if the result of the data analysis by the communication processing program303in step S202indicates that switching to a high-interactive honeypot is needed, the flow branches to step S204and “switching request” is set in the execution result. The program ends.

Then, in step S205, if it is determined to end the process based on the result of the data analysis by the communication processing program303in step S202, the flow branches to step S206and “end” is set in the execution result. The program ends. If the result of the data analysis in step S202indicates that a response should be returned, the flow branches to step S207.

Then, in step S207, the communication processing program303checks whether or not look-up or change of the terminal state is necessary in creating a response to the received data. Such a need arises when, for example, the contents of some file in the simulated terminal need be stored in the response, or when the received data is a command requesting change of some file. If it is determined that look-up or change of the terminal state is necessary, the flow branches to step S208. The communication processing program303calls the terminal state management part108with using the terminal ID and command as a parameter, and carries out necessary look-up or change.

Finally, in step S209, the communication processing program303creates response data and transmits the response data to the communication management part112. The transmitted data is transferred to a destination terminal via the gateway part210of the communication management part112. After that, the communication processing program303returns to step S201and waits for the next data to arrive.

When the communication processing program ends, the process returns to step S105ofFIG. 10.

In step S105, the low-interactive honeypot802checks the execution result of the communication processing program. If the execution result indicates “switching request”, the flow branches to step S106and the low-interactive honeypot802notifies the communication management part112of a honeypot switching request. After that, the low-interactive honeypot802returns to step S101.

The operation of the terminal state management part108will be described with referring toFIG. 12.

FIG. 12is a flowchart illustrating an operation flow of the terminal state management part108.

First, in step S301, the terminal state management part108receives the terminal ID and the command.

Then, in step S302, the terminal state management part108acquires a file system name stored in the honeypot execution state management part115with using the received terminal ID as a key.

Then, in step S303, based on the acquired file system name, the terminal state management part108selects a function for executing a command given on a virtual machine image where the file system is stored. Such a function can be created by using a technique applied to a command such as mount command of the basic OS, which renders a file operable as a virtual file system.

In Embodiment 1, the function is implemented in the terminal state management part108as a function. It is also possible to divide the function into modules and switch a module to be loaded, with referring to the file system name.

An example of a command executable by the communication management part112in Embodiment 1 will be described.

FIG. 13is a diagram illustrating examples of the command that can be executed by the communication management part112.

As illustrated inFIG. 13, some command requires a parameter such as a file name being the operation target. In that case, a command name and a required parameter make up one complete command. Note that the command executable by the communication management part112is not limited to the examples illustrated inFIG. 13.

Finally, in step S304, the terminal state management part108returns the processing result obtained by executing the function, to the caller. The process ends.

The process of the terminal state transition scenario execution part107will be described with referring toFIG. 14.

FIG. 14is a flowchart illustrating an operation flow of the terminal state transition scenario execution part107.

First, in step S401, when booting the system, the terminal state transition scenario execution part107loads the terminal state transition scenario from the terminal state transition scenario accumulation part110. The terminal state transition scenario is formed in a table format including, as elements, the execution time501, the terminal ID502, and the command503, as inFIG. 5.

Then, in step S402, the terminal state transition scenario execution part107acquires the present time.

Then, in step S403, the terminal state transition scenario execution part107checks if the terminal state transition scenario includes a scenario to be executed describing the execution time501coinciding with the time acquired in step S402. If such a scenario does not exist, the flow returns to step S402.

Then, in step S404, the terminal state transition scenario execution part107acquires the terminal ID502and command503of the scenario concerned.

Then, in step S405, the terminal state transition scenario execution part107searches the execution state management part115with using the acquired terminal ID as a key, and acquires the execution state of the terminal having the ID concerned.

Then, in step S406, the terminal state transition scenario execution part107checks if the execution state of the simulated terminal indicated by the acquired terminal ID shows a high-interactive honeypot. If the execution state shows a high-interactive honeypot, the flow branches to step S407.

Then, in step S407, the terminal state transition scenario execution part107searches the high-interactive honeypot execution command definition table (FIG. 6) stored in the high-interactive honeypot execution command accumulation part116with using the command name and terminal ID as a key, and acquires the started program603and the user ID604that correspond to an operation. The name of the program started on the virtual machine, and an argument which is given at start-up are described in the started program603. InFIG. 6, a portion $1 expresses a variable indicating the first value of parameters included in the command. The acquired started program603is started on the virtual machine concerned, under the privilege of the acquired user ID. Such start-up of a program in the virtual machine is a function provided by an existing product of the virtual machine execution environment as well and is easy to implement.

Finally, in step S408, the terminal state transition scenario execution part107supplies the terminal ID and the command acquired from the scenario to the terminal state management part108. The flow returns to step S402.

As described above, in the invention of Embodiment 1, the communication management part112switches the transfer destination honeypot. The communication is initially processed by a low-interactive honeypot. The transfer destination honeypot is switched to a high-interactive honeypot only where necessary, so that use of the high-interactive honeypot can be suppressed. This provides an effect that an attack observation apparatus which simulates a large-scale system can be implemented with a few computer resources.

Regarding the terminal state stored in the terminal state accumulation part109, the image file of the virtual machine is employed, and the image file is operated by the terminal state management part108. As a result, the execution state of the low-interactive honeypot and the execution state of the high-interactive honeypot can be synchronized.

The protocol state transition of the application layer is traced by the communication management part112. Data necessary for state restoration is accumulated. When switching the honeypot, communication for communication state restoration is performed. As a result, honeypot switching can be carried out without causing communication state inconsistency and so on.

Since the communication is terminated in the communication management part112, honeypot switching can be carried out even with communication using a protocol such as TCP or TLS.

The communication management part112returns an ARP response to an ARP request for all simulated terminal IPs. Furthermore, the virtual machines are connected to different VLANs and are booted. This can guarantee that all communications pass by way of the communication management part112.

The terminal state is changed in accordance with the terminal state transition scenario. Therefore, it is possible to reproduce a state showing as if the user was actually conducting business within the simulated terminal.

When having the high-interactive honeypot carry out state transition according to the terminal state transition scenario, a process is started in the virtual machine. This further enables camouflaging a user conducting business.

In Embodiment 1 described above, the communication management part112transfers communication to the low-interactive honeypot and the high-interactive honeypot. In Embodiment 2, a case will be described where the low-interactive honeypot is operated by the gateway part210of the communication management part112.

FIG. 15is a diagram illustrating an example of a system configuration of a periphery of a communication management part112according to Embodiment 2.

Comparison ofFIG. 15withFIG. 2shows that the low-interactive honeypot part106is no longer used. Instead, a gateway part cum low-interactive honeypot part1501replaces the gateway part210.

An operation of the gateway part cum low-interactive honeypot part1501in Embodiment 2 will be described. Upon reception of communication from a terminal, the gateway part cum low-interactive honeypot part1501processes the communication by a low-interactive honeypot part while storing communication restoring data in the same manner as the gateway part210of Embodiment 1 does. This process can be implemented easily by inputting the data to a communication processing program303disclosed in Embodiment 1, instead of transferring communication on the gateway part210of Embodiment 1. When the communication processing program303returns a honeypot switching request, a high-interactive honeypot is booted and the communication state is restored in accordance with the same method as that in Embodiment 1. Subsequently, the communication is transferred to the high-interactive honeypot which has started the communication, in the same manner as in Embodiment 1.

As described above, in the invention of Embodiment 2, since the process of the low-interactive honeypot is carried out on the communication management part112, overhead of transferring communication to the low-interactive honeypot is eliminated, providing an effect of reducing response delay of communication.

In Embodiments 1 and 2 described above, the virtual machines in the high-interactive honeypot part103are connected to different VLANs respectively. In Embodiment 3, a case will be described where the same effect is obtained without using VLANs but by setting ARP caches of the respective virtual machines on the communication management part112.

FIG. 16is a diagram illustrating an example of a system configuration of a periphery of a communication management part112according to Embodiment 3. Comparison ofFIG. 16withFIG. 2shows that virtual machines201and202and the communication management part112are connected to the same LAN. A configuration being the ARP response part209in the communication management part112of Embodiment 1 is replaced by an ARP cache setting part1601.

An operation of the communication management part112in Embodiment 3 will be described. In Embodiment 3, the communication management part112periodically transmits an ARP response packet to each virtual machine in operation, the ARP response packet indicating that a MAC address corresponding to the IPs of all simulated terminals is the MAC address assigned to the interface of the communication management part112connected to a network206.

FIG. 17is a diagram illustrating an example of the ARP response packet.

As illustrated inFIG. 17, in the packet, the MAC address of the communication management part112is used as the MAC address (1701) for each virtual machine IP (1702). Therefore, even when the communication party is an adjacent virtual machine, each virtual machine does not transmit communication directly to the adjacent virtual machine but transmits the packet to the communication management part112.

As described above, in the invention of Embodiment 3, an ARP response being spoofed is transmitted to each virtual machine. Thereby, the individual virtual machines need not be separated apart by VLANs, providing an effect of simplifying the system configuration.

The scheme disclosed in Embodiment 3 can be applied not only to Embodiment 1 but also to Embodiment 2 similarly, as a matter of course.

In Embodiments 1 to 3 described above, all pieces of data necessary for communication state restoration are stored in the communication management part112. In case of communication state restoration, the communication management part112communicates with a booted virtual machine. In Embodiment 4, a case will be described where a low-interactive honeypot is used for communication state restoration of an application layer.

FIG. 18is a diagram illustrating an example of a system configuration of a periphery of a communication management part112according to Embodiment 4.

Comparison ofFIG. 18withFIG. 2of Embodiment 1 shows that the communication restoring data accumulation part211is no longer used. An application layer restoring communication transfer part1801is added which transfers to a virtual machine communication sent from a low-interactive honeypot for restoring the application layer communication state.

FIG. 19is a diagram illustrating an example of a configuration of a low-interactive honeypot part106of an attack observation apparatus according to Embodiment 4.

Comparison ofFIG. 19withFIG. 3illustrating the configuration of the low-interactive honeypot part106of Embodiment 1 shows that an application layer communication restoring data accumulation part1901for accumulating data for restoring application layer communication and a communication state restoring program accumulation part1902for accumulating a restoration program1903for restoring communication of the application layer are added.

An operation of the attack observation apparatus according to Embodiment 4 will be described. In Embodiment 4, the low-interactive honeypot part106operates in a manner illustrated inFIG. 20.

FIG. 20is a flowchart illustrating an operation flow of the low-interactive honeypot part106according to Embodiment 4.

The flowchart ofFIG. 20is the same as that in Embodiment 1 until step S506.

After a honeypot switching request is executed in step S506, a communication restoration program is acquired in step S507. Using this program, the communication state of the application layer is restored in step S508.

In order to accumulate data necessary for restoring the communication state of the application layer in step S508, a communication processing program in Embodiment 4 operates as indicated by the flowchart illustrated inFIG. 21.

FIG. 21is a flowchart illustrating an operation flow of the communication processing program according to Embodiment 4.

The flowchart ofFIG. 21is equivalent to the flowchart indicated in Embodiment 1 but additionally includes step S607and step S608. More specifically, a process is added so that necessary data is stored when it is determined in the communication processing program that data need be stored for communication state restoration (for example, when a log-in request on an application layer protocol is received inFIG. 8of Embodiment 1).

Upon reception of a honeypot switching request, the communication management part112boots the virtual machine in the same manner as in Embodiment 1, and restores low-level layer communication (for example, TCP, TLS session, and so on). After that, communication restoring application layer data being transmitted from a communication restoration program in a low-interactive honeypot is transferred to a virtual machine on the restored communication connection. Likewise, a response from the virtual machine is transferred to the communication restoration program. This communication is executed until the communication restoration program ends. Then, communication restoration ends.

As described above, in the invention of Embodiment 4, the communication management part112covers as far as to the restoration of a protocol of an application layer such as TCP or TLS, which is not higher than the application layer. The communication state restoration of the application layer is executed by a communication restoration program on the low-interactive honeypot. This provides an effect that the communication management part112will not be influenced by a change in a protocol of the application layer. Apparently, Embodiment 4 is operable on the communication management part112, as has been described in Embodiment 2.

In Embodiments 1 to 4 described above, switching to a high-interactive honeypot takes place in response to a request from a low-interactive honeypot. In Embodiment 5, a case will be described where an intrusion detection system (IDS) is installed in a low-interactive honeypot, or on a network that connects a low-interactive honeypot and the communication management part112to each other, and where honeypot switching is effected under the condition that the IDS has detected an attack.

FIG. 22is a diagram illustrating an example of a system configuration of a periphery of a communication management part112according to Embodiment 5.

Referring toFIG. 22, an IDS2201monitors communication to a low-interactive honeypot. When an attack is detected, the attack is notified to the communication management part112, and switching to a high-interactive honeypot is executed. Switching of the honeypot and communication state restoration after switching are the same as those in Embodiments 1 to 4.

As has been described above, in the invention of Embodiment 5, honeypot switching is effected under the condition that the IDS has detected an attack. Therefore, honeypot switching can be carried out exhaustively, not only when undefined communication arrives but also in response to attacks as a whole which are detectable by an IDS, thus providing an effect that a large-scale system can be simulated more elaborately.

REFERENCE SIGNS LIST

101: honeypot system (attack observation apparatus);102: external network;103: high-interactive honeypot part;104: virtual machines;105: virtual machine execution environment;106: low-interactive honeypot part;107: terminal state transition scenario execution part;108: terminal state management part;109: terminal state accumulation part;110: terminal state transition scenario accumulation part;112: communication management part;115: honeypot execution state management part;116: high-interactive honeypot execution command accumulation part;201to202: virtual machine;205: virtual switch;207: packet reception part;208: packet transmission part;209: ARP response part;210: gateway part;211: communication restoring data accumulation part;301: communication processing program execution part;302: communication processing program accumulation part;303: communication processing program;701to702: virtual machine image;1501: gateway part cum low-interactive honeypot part;1601: ARP cache setting part;1801: application layer restoring communication transfer part;1901: application layer communication restoring data accumulation part;1902: communication state restoring program accumulation part;1903: restoration program;2201: IDS