JP7147601B2 - Inspection method and inspection system - Google Patents

Description

The present invention relates to an inspection method and an inspection system.

In recent years, along with the term "Internet of Things (IoT)," various things are equipped with communication functions and connected to networks. Attempts have been made to collect data from these IoT devices and utilize the collected data to provide services that have never existed before and services with higher value.

Techniques related to network security are also known (for example, Patent Literature 1 and Patent Literature 2).

Japanese Unexamined Patent Application Publication No. 2010-11206 JP-A-2005-193590

An IoT device may be infected with a virus or the like and attack other devices. For example, if the IoT device has sufficient functions, it is possible to take countermeasures against such threats by installing security software on the IoT device. However, among IoT devices, there are devices for which countermeasures such as installation of security countermeasure software cannot be taken. Therefore, it is desired to provide a further technology that can check whether IoT devices are conducting unauthorized communication.

In one aspect, an object of the present invention is to check whether a device is executing unauthorized communication.

In the inspection method according to one aspect of the present invention, the server sets the packet filter to discard the positive acknowledgment addressed to the device to be inspected, and the timing at which the packet filter discards the positive acknowledgment addressed to the device to be inspected a first number of packets representing the number of packets sent by the device under test and a second number of packets representing the number of packets transmitted to the server by the device under test based on and inspecting the device under inspection for unauthorized communication according to whether the number of packets of and the number of packets of the second match within a predetermined error range.

It is possible to check whether the device is executing unauthorized communication.

1 illustrates an exemplary IoT system; FIG. 1 is a diagram illustrating an IoT system according to an embodiment; FIG. It is a figure which illustrates the block configuration of the server which concerns on embodiment. FIG. 7 is a diagram illustrating an operation flow of inspection processing for unauthorized communication of an IoT device to be inspected according to the embodiment; It is a figure which illustrates the traffic information acquisition process which concerns on embodiment. FIG. 4 illustrates counting information collected by a packet counting device; FIG. 4 illustrates an inquiry in the SNMP protocol; FIG. 2 illustrates an object containing information about the number of packets provided in an exemplary SNMP protocol; FIG. 5 is a diagram illustrating analysis information collected by a packet analysis unit; FIG. 4 is a diagram illustrating packet analysis processing executed by a packet analysis unit; FIG. 4 illustrates packets on paths and buffers; FIG. 2 is a diagram for explaining communication control by TCP between a device on the transmission side and a device on the reception side; FIG. 7 is a diagram illustrating an operation flow of traffic information acquisition processing during communication according to the embodiment; FIG. 10 is a diagram illustrating discarding of a connection request according to the embodiment; FIG. FIG. 11 is a diagram illustrating the arrangement of packet analysis units according to another embodiment; FIG. 4 is a diagram illustrating differences in packet transmission procedures according to TCP versions; FIG. 10 is a diagram illustrating execution timings of collecting traffic information in the second version of TCP according to Modification 1; FIG. 11 is a diagram illustrating an operation flow of traffic information acquisition processing during communication according to Modification 1; FIG. 11 is a diagram illustrating execution timings of collecting traffic information according to Modification 2; FIG. 11 is a diagram further illustrating execution timings for collecting traffic information according to Modification 2; FIG. 12 is a diagram illustrating an operation flow of traffic information acquisition processing during communication according to Modification 2; FIG. 11 is a diagram illustrating execution timings of collecting traffic information according to Modification 3; FIG. 12 is a diagram illustrating an operation flow of traffic information acquisition processing during communication according to Modification 3; It is a figure which illustrates the hardware constitutions of the computer for implement|achieving the server or packet analysis part which concerns on embodiment.

Several embodiments of the present invention will be described in detail below with reference to the drawings. In addition, the same code|symbol is attached|subjected to the element which corresponds in several drawings.

FIG. 1 is a diagram illustrating an exemplary IoT system 100. As shown in FIG. FIG. 1 shows another network 105 formed by a server 102 and a plurality of IoT devices 101 under an IT network 150 within an organization. A server 102 and a plurality of IoT devices 101 form an IoT system 100 . The IoT device 101 may be, for example, various devices that collect information and transmit the collected information to the server 102 . For example, if the IoT device 101 is a sensor such as a thermometer or a hygrometer, the IoT device 101 may periodically provide information such as measured temperature and humidity to the server 102 . Also, for example, if the IoT device 101 is a microcomputer mounted on an electrical appliance such as an air conditioner controller, information regarding operations input to the electrical appliance may be provided to the server 102 . The server 102 may use the information collected from the IoT device 101, for example, to provide various services to terminals connected to the IT network 150 within the organization.

Here, the IoT device 101 may be infected with a virus or the like and attack other devices. For example, if the IoT device 101 has sufficient functions, countermeasures against such threats can be taken by installing security software.

However, the IoT devices 101 include devices for which measures such as installation of security software cannot be taken. For example, some of the IoT devices 101 operate on their own operating system (OS: Operating System), some operate on an outdated OS, and some do not have an OS in the first place, and security software cannot be installed. There is Therefore, it is desired to provide a further technique capable of detecting unauthorized communication of IoT devices.

Here, the IoT device 101 is often used, for example, to keep sending data to a specific host such as the server 102 in FIG. be done. In such a case, if the IoT device 101, which is set to communicate only with a specific host, communicates with a device other than the host, the IoT device 101 may be conducting unauthorized communication. It is possible to determine that it is high.

Therefore, in the embodiments described below, for example, it is checked whether the number of packets transmitted by the IoT device 101 and the number of packets arriving from the IoT device 101 to the host match within a predetermined error range. is communicating with a device other than the host. The predetermined error range can be set to an allowable error range, such as 1% to 2%, by investigating the frequency of packet losses occurring in the IoT system in advance. Then, for example, if the number of packets transmitted by the IoT device 101 and the number of packets delivered from the IoT device 101 to the host are significantly different beyond a predetermined error range, the IoT device 101 may perform unauthorized communication with devices other than the host. It can be estimated that there is a high possibility that In other words, for example, when the IoT device 101 is conducting unauthorized communication, the number of packets transmitted by the IoT device 101 increases by the number of unauthorized communications. On the other hand, since these packets of unauthorized communication do not reach the host, there is no change in the number of packets sent from the IoT device 101 to the host, and the number of packets sent by the IoT device 101 is greater than the number of packets sent from the IoT device 101 to the host. It will be more than the number of packets that arrive. Further, for example, if the number of packets transmitted by the IoT device 101 and the number of packets delivered from the IoT device 101 to the host match within a predetermined error range, the IoT device 101 can communicate with devices other than the host. It can be assumed that they did not. Embodiments will be described in more detail below.

FIG. 2 is a diagram illustrating an IoT system 200 according to an embodiment. The IoT system 200 includes, for example, an IoT device 101, a server 202, a packet counting device 211, a hub (HUB) 212, and a packet analysis unit 213. Note that, in one embodiment, the inspection system 250 that inspects unauthorized communication of the IoT device 101 may include the server 202 , the packet counting device 211 , the hub (HUB) 212 and the packet analysis unit 213 . Here, it is assumed that the IoT device 101 is set to communicate only with the server 202 when operating normally. The server 202 may, for example, collect various measurement data from the IoT device 101 and use the measurement data to provide various services to other devices connected to the IT network 150 . For example, the server 202 may not have a packet routing function, and packets transmitted by the IoT device 101 may not flow to the IT network 150 beyond the server 202 .

The packet counting device 211 may be, for example, a switch compatible with SNMP (Simple Network Management Protocol), and in one example, may be an intelligent switch. Packet counting device 211 may be referred to as a packet counting switch in one embodiment. The packet counting device 211, for example, counts input packets for each port and outputs the packets to the destination port. The IoT device 101 may be connected to a specific port of the packet counting device 211, for example. Therefore, the number of packets counted by the packet counting device 211 for the port to which the IoT device 101 is connected can be used as the number of packets transmitted by the IoT device 101 connected to that port.

The packet analysis unit 213 may be, for example, a protocol analyzer. A protocol analyzer is, for example, a device or program that analyzes data flowing between networks and data devices. The packet analysis unit 213 may, for example, count input packets for each source address indicating the source of the packet. Note that, for example, a MAC address or an IP address can be used as the source address.

Hub 212 may be, for example, a repeater hub. The repeater hub, for example, transmits received packets to all connected terminals. Therefore, in FIG. 2, all packets addressed to the server 202 input from the packet counting device 211 are also sent to the packet analysis section 213 by the repeater hub. The packet analysis unit 213 can count the number of packets transmitted from the IoT device 101 to be inspected to the server 202 by analyzing the source address of the packet.

Therefore, the server 202 can obtain, for example, from the packet counting device 211 the first number of packets representing the number of packets transmitted by the IoT device 101 to be inspected. Also, the server 202 can acquire from the packet analysis unit 213 a second number of packets representing the number of packets transmitted to the server 202 by the IoT device 101 to be inspected. After that, the server 202 can determine whether or not the IoT device 101 to be inspected is conducting unauthorized communication, for example, by comparing the first number of packets and the second number of packets. In the embodiments described below, a first packet count representing the number of packets transmitted by the IoT device 101 to be inspected and a second packet count representing the number of packets transmitted by the IoT device 101 to be inspected to the server 202 is sometimes called traffic information.

FIG. 3 is a diagram illustrating a block configuration of the server 202 according to the embodiment. Server 202 includes, for example, control unit 301 , storage unit 302 , and communication unit 303 . The control unit 301 operates, for example, as an OS 350, a setting unit 311, an acquisition unit 312, an inspection unit 313, and the like. The storage unit 302 of the server 202 may store information such as programs and data, for example. In one embodiment, the storage unit 302 of the server 202 stores, for example, analysis information 900 described below. Details of these units and details of information stored in the storage unit 302 will be described later.

FIG. 4 is a diagram illustrating an operation flow of inspection processing for unauthorized communication by the IoT device 101 to be inspected according to the embodiment. The control unit 301 of the server 202 may start the inspection process of FIG. 4, for example, when an instruction to execute the inspection process of unauthorized communication is input.

In step 401 (hereinafter, the step is written as "S", for example, written as S401), the control unit 301 selects the IoT device 101 to inspect for unauthorized communication. For example, the control unit 301 may receive selection of the IoT device 101 from the user, and select the IoT device 101 selected by the user as an inspection target.

In S402, the control unit 301 determines whether or not communication is being performed with the IoT device 101 to be inspected. If not communicating with the IoT device 101 to be inspected (NO in S402), the flow proceeds to S403. In S403, the control unit 301 collects traffic information by executing traffic information collection processing, which will be described later with reference to FIG. 5, and the flow proceeds to S405. Note that the traffic information is, for example, information used to check whether the IoT device 101 is executing unauthorized communication, as described above. In one example, the traffic information may include a first packet count representing the number of packets transmitted by the IoT device 101 and a second packet count representing the number of packets transmitted from the IoT device 101 to the host.

Also, in S402, if the connection with the IoT device 101 to be inspected has been established and communication is in progress (YES in S402), the flow proceeds to S404. In S404, the control unit 301 collects traffic information by executing traffic information collection processing during communication, which will be described later with reference to FIG. 13, and the flow proceeds to S405.

In S405, for example, based on the collected traffic information, the control unit 301 inspects whether the IoT device 101 to be inspected is conducting unauthorized communication, and this operation flow ends. For example, assume that the first number of packets representing the number of packets transmitted by the IoT device 101 and the second number of packets representing the number of packets transmitted from the IoT device 101 to the host match within a predetermined error range. . In this case, the control unit 301 may determine that the IoT device 101 is not conducting unauthorized communication. On the other hand, for example, suppose that the first number of packets and the second number of packets differ by exceeding a predetermined error range (for example, the first number of packets representing the number of packets transmitted by the IoT device 101 is more than a predetermined value). In this case, the control unit 301 may determine that the IoT device 101 is conducting unauthorized communication.

(traffic information collection processing)
Next, the traffic information collection processing executed in S403 of FIG. 4 will be described. FIG. 5 is a diagram illustrating traffic information acquisition processing according to the embodiment. For example, when proceeding to S403 of FIG. 4, the control unit 301 may start the operation flow of FIG.

In S501, for example, the control unit 301 acquires the number of packets of the port connected to the IoT device 101 to be inspected from the packet counting device 211 as the first number of packets. Note that, in one embodiment, the control unit 301 may acquire the number of packets of the port to which the IoT device 101 to be inspected is connected, as described in FIGS. 6 to 8 below.

FIG. 6 is a diagram illustrating counting information 600 collected by the packet counting device 211. As shown in FIG. For example, when a packet is input, the packet counting device 211 registers the packet number of the packet in the counting information 600 in association with the information of the port through which the packet was input. In one example, the packet counting device 211 may record the cumulative input packet information from the startup in the counting information 600 . Also, the packet counting device 211 may be, for example, an intelligent switch, and communicates with the outside using the SNMP protocol.

FIG. 7 is a diagram illustrating an inquiry in the SNMP protocol. The packet counting device 211 may have a storage device 701 such as a memory, for example, and count information 600 is stored in the storage device 701 . Then, the server 202 sends an inquiry to the packet counting device 211 by designating an object identifier (OID) and a port number ("x" in FIG. 7) together with, for example, a GET command. Thereby, the server 202 can receive back the object identifier and the corresponding value from the packet counting device 211, for example.

FIG. 8 shows an object containing information about the number of packets provided in an exemplary SNMP protocol. The control unit 301 of the server 202, for example, makes an inquiry to the packet counting device 211 five times and acquires the values of the five objects shown in FIG. You can get the number of packets sent. For example, the control unit 301 sums "ifInUcastPkts" and "ifInNUcastPkts" to obtain the sum of received packets of the specified port. Also, the control unit 301 obtains the total value of error packets input to the port by summing up three of "ifInDiscards", "ifInErrors", and "ifInUnknownProtos". Then, the control unit 301 may acquire the number of packets transmitted by the IoT device 101 via the port of the packet counting device 211 by subtracting the total value of error packets from the total value of received packets.

Subsequently, in S502, the control unit 301 acquires the number of packets transmitted from the IoT device 101 to be inspected to the server 202 as the second number of packets from the packet analysis unit 213, and the operation flow ends. Flow proceeds to S405. In one embodiment, the control unit 301 may acquire the number of packets transmitted from the IoT device 101 to be inspected to the server 202 as described in FIGS. 9 and 10 below.

FIG. 9 is a diagram illustrating analysis information 900 collected by the packet analysis unit 213. As shown in FIG. For example, when a packet is input, the packet analysis unit 213 analyzes the source address indicating the source of the packet, counts the number of packets input in units of source address, and registers the count in the analysis information 900 . In one example, the packet analysis unit 213 may count the number of packets input cumulatively from the start. The packet analysis unit 213 may be, for example, a protocol analyzer. For example, in response to an inquiry from the server 202, the packet analysis unit 213 reads the number of packets transmitted by the IoT device 101 to be inspected to the server 202 from the analysis information 900 using the source address specified in the inquiry, you can reply.

FIG. 10 is a diagram illustrating packet analysis processing executed by the packet analysis unit 213. As shown in FIG. For example, the packet analysis unit 213 may start the operation flow of FIG. 10 when activated.

In S1001, the control unit 301 determines whether or not a packet has been received. If no packet has been received (NO in S1001), the flow repeats the processing of S1001. On the other hand, if a packet has been received in S1001 (YES in S1001), the flow advances to S1002.

In S<b>1002 , the control unit 301 determines whether the received packet is an inquiry about the number of packets from the server 202 . If it is not an inquiry about the number of packets from the server 202 (NO in S1002), the flow advances to S1004. On the other hand, if the inquiry is for the number of packets from the server 202 (YES in S1002), the flow advances to S1003.

In S<b>1003 , the control unit 301 reads the number of packets from the entry of the analysis information 900 whose source address is the IoT device 101 to be inspected, which is specified by, for example, the MAC address or IP address in the inquiry, and returns it to the server 202 .

In S1004, the control unit 301 analyzes the source address of the received packet, adds 1 to the number of packets in the entry of the analysis information 900 corresponding to the source address, counts the number of packets for each source address, and the flow proceeds to S1001. return.

According to the operation flow of FIG. 10, the number of packets transmitted to the server is registered in the analysis information 900 for each source address. 10, the control unit 301 of the server 202 counts the number of packets transmitted from the IoT device 101 to be inspected to the server 202 in response to the inquiry from the server 202 transmitted in S502. A second number of packets to represent can be obtained.

(Traffic information collection processing during communication)
Next, traffic information acquisition processing during communication executed by the control unit 301 in S404 will be described.

For example, when executing the inspection of the IoT device 101 to be inspected, the IoT device 101 to be inspected may establish a communication connection with the server 202 . Here, for example, if the IoT device 101 to be inspected has not established a communication connection with the server 202, the packets addressed to the server 202 sent by the IoT device 101 to be inspected in the past have already been delivered to the delivery destination. is in a state of being Therefore, the server 202 uses the traffic information of the IoT device 101 to be inspected obtained from the packet counting device 211 and the packet analysis unit 213 to determine whether the IoT device 101 to be inspected is conducting unauthorized communication. It is possible to determine whether

However, for example, when the server 202 inspects the IoT device 101 to be inspected, if the IoT device 101 to be inspected has established a communication connection with the server 202, the IoT device 101 to be inspected sends a packet to the server 202. is sending In this case, for example, as shown in FIG. 11, there may be undelivered packets on the communication path or in the buffers of the packet counter 211 and the packet analysis unit 213 . Even if the number of packets is acquired from the packet counting device 211 and the packet analysis unit 213 at such timing, the number may differ due to undelivered packets. Moreover, if the timing of acquiring the number of packets between the packet counting device 211 and the packet analysis unit 213 does not match in the first place, the number of packets will differ even if the IoT device 101 to be inspected is operating normally. put away. For example, when obtaining the number of packets, if the last packets counted by the packet counting device 211 and the packet analysis unit 213 are the same, the numbers of packets are compared to inspect the IoT device 101 to be inspected. can be done. However, if, for example, the last packets counted by the packet counting device 211 and the packet analysis unit 213 are packets transmitted at significantly different timings in the IoT device 101 to be inspected, comparing the numbers of packets does not make sense. A certain judgment cannot be executed. If there is a discrepancy in the number of packets due to reasons other than such unauthorized communication of the IoT device 101, the IoT device 101 to be inspected cannot be inspected even if the number of packets is collected.

As one method for reducing such discrepancies in the number of packets caused by factors other than unauthorized communication of the IoT device 101, it is possible to temporarily stop the transmission of packets by the IoT device 101 to be inspected when the number of packets is obtained. Conceivable. By stopping packet transmission by the IoT device 101 to be inspected, for example, it becomes possible to collect traffic information after waiting for the completion of delivery of undelivered packets existing on the route or buffer. Also, if the delivery of all packets sent by the IoT device 101 is completed, the number of packets whose collection timing matches can be acquired from the packet counting device 211 and the packet analysis unit 213 .

However, among the IoT devices 101, almost no control interface from the outside is prepared, and for example, there are some IoT devices 101 that cannot be controlled such as stopping transmission of packets. Therefore, in the embodiment, transmission of packets from the IoT device 101 is stopped using a communication control mechanism based on TCP (Transmission Control Protocol). For example, in the embodiment, when a packet is received from the IoT device 101 to be inspected, the control unit 301 of the server 102 discards an ACK (positive acknowledgment) for that packet. By discarding the ACK, the IoT device 101 to be inspected enters a state of waiting for ACK, and the transmission of packets from the IoT device 101 to be inspected is temporarily stopped. As a result, even when the IoT device 101 to be inspected is communicating with the server 202, traffic information can be collected and the IoT device 101 to be inspected can be inspected. Collection of traffic information in a state where the IoT device 101 to be inspected has established a communication connection with the server 202 will be described in more detail below.

FIG. 12 is a diagram for explaining communication control by TCP between a device on the transmitting side and a device on the receiving side. Note that the device on the transmission side may be the IoT device 101, for example. Also, the receiving device may be, for example, the server 202 .

FIG. 12(a) illustrates the flow of packet transmission by TCP. As shown in FIG. 12(a), it is assumed that the transmitting device transmits a packet to the receiving device ((1) in FIG. 12(a)). Note that TCP employs a method called window control for packet transmission. In window control, multiple packets of the window size are sent consecutively without acknowledgment by ACK, and only one ACK is returned for those multiple packets. In the following description, a group of packets corresponding to the window size that are continuously transmitted is regarded as one box, and an expression such as, for example, transmitting one box of packets may be used.

When the device on the receiving side receives one box of packets sent by the device on the sending side, the device on the receiving side returns an ACK corresponding to the received packet ((2) in FIG. 12(a)). When the ACK is received, the device on the transmitting side makes adjustments such as increasing the window size ((3) in FIG. 12(a)), and transmits the next box of packets with the adjusted window size (FIG. 12 ( a) (4)). Here, if ACK is not returned from the device on the receiving side, the device on the transmitting side enters a state of waiting for reception of ACK.

FIG. 12(b) is a diagram exemplifying the state of waiting for ACK reception of the device on the transmitting side. As shown in FIG. 12(b), it is assumed that the device on the transmitting side has transmitted packets for one box ((1) in FIG. 12(b)). When the device on the receiving side receives packets for one box, the device on the receiving side returns an ACK corresponding to the received packet, but assumes that this ACK is discarded ((2) in FIG. 12(b)). . In this case, the device on the transmitting side waits for ACK reception. The state of waiting for reception of ACK continues from the transmission of the packet in (1) until a predetermined waiting time set in the retransmission timer elapses and times out. When the retransmission timer times out ((3) in FIG. 12(b)), the device on the transmitting side makes adjustments such as reducing the window size, for example ((4) in FIG. 12(b)). Then, the device on the transmitting side resends packets for one box with the adjusted window size ((5) in FIG. 12(b)), and the resent packets arrive at the device on the receiving side ((5) in FIG. 12(b)). (6)).

In this case, after transmitting the packet in (1), the device on the transmitting side stops transmitting the packet until it retransmits the packet in (5). Therefore, the server 202 can collect traffic information with reduced measurement errors during this period in which packet transmission is stopped.

As described above, the device on the receiving side discards the ACK and stops the transmission of packets from the device on the transmitting side. It is possible to create a state in which the delivery of data has been completed and execute the acquisition of traffic information.

Note that, in the example of FIG. 12, the packet transmission of the device on the transmitting side is stopped according to TCP communication control. Therefore, for example, if communication is performed using TCP, the packet transmission of the IoT device 101 can be stopped even if the IoT device 101 does not have an external control interface for receiving packet transmission stop or the like.

Also, for example, ACK discarding can be executed by setting a packet filter such as a firewall of the device on the receiving side to discard ACKs or TCP packets addressed to the IoT device 101 to be inspected from the own device. can be done. By using a packet filter, for example, ACK or TCP packets can be discarded without modifying the OS 350 or the like.

Next, the operation flow of the traffic information acquisition process during communication using the discarding of ACK described above will be described. FIG. 13 is a diagram illustrating an operation flow of traffic information acquisition processing during communication executed by the control unit 301 in S404. For example, when proceeding to S404 of FIG. 4, the control unit 301 may start the operation flow of FIG.

In S<b>1301 , the control unit 301 sets the packet filter to discard ACK or TCP packets addressed to the IoT device 101 to be inspected from its own device.

In S1302, the control unit 301 waits until the TCP ACK is discarded. Once the ACK is discarded, flow proceeds to S1303.

The subsequent processes of S1303 and S1304 may correspond to the processes of S501 and S502 of FIG. 5, and the control unit 301 may acquire traffic information by executing processes similar to those of S501 and S502.

In S1305, the control unit cancels the packet filter set in S1301, the operation flow ends, and the flow proceeds to S405.

As described above, according to the embodiment, by collecting the traffic information of the IoT device 101 to be inspected, unauthorized communication by the IoT device 101 can be detected. Therefore, for example, even an IoT device 101 having only simple functions in which security countermeasure software cannot be installed can be inspected as to whether or not unauthorized communication is being performed.

Further, according to the above-described embodiment, when the IoT device 101 is communicating with the server 202, the packet transmission from the IoT device 101 is temporarily stopped by discarding the TCP ACK. As a result, the number of packets transmitted by the IoT device 101 and the number of packets transmitted from the corresponding IoT device 101 to the server 202 can be acquired while suppressing measurement errors. Therefore, even when the IoT device 101 is communicating with the server 202, it can be determined with high accuracy whether or not the IoT device 101 to be inspected is conducting unauthorized communication.

In the operation flow of FIG. 4 described above, when the server 202 is not communicating with the IoT device 101 to be inspected (NO in S402), the operation flow of FIG. 5 is executed to collect traffic information. ing. However, a connection request may be received from the IoT device 101 to be inspected while traffic information is being collected in the operation flow of FIG. In this case, by discarding the ACK for the connection request, it is possible to collect traffic information while suppressing measurement errors.

FIG. 14 is a diagram illustrating discarding of a connection request according to the embodiment. FIG. 14A is a diagram illustrating establishment of a TCP connection. In TCP, for example, as shown in FIG. 14(a), a connection is established by a 3-way handshake. At this time, as shown in FIG. 14(b), by discarding the ACK for the connection request and then restarting the collection of traffic information, the measurement error caused by the connection with the IoT device 101 can be reduced. Traffic information can be collected.

For example, when the control unit 301 receives a connection request from the IoT device 101 to be inspected during execution of the operation flow of FIG. 5, it stops the operation flow of FIG. 5 and executes the operation flow of FIG. 13 instead. may discard the ACK for the connection request and collect the traffic information.

Also, in order to count the number of packets flowing into the server 202, the above embodiment describes an example in which the hub 212 and the packet analysis unit 213 are implemented as hardware as shown in FIG. However, embodiments are not so limited. For example, as shown in FIG. 15, the packet analysis unit 213 can be implemented as an application running on the server 202. FIG. In this case, for example, by setting the kernel of the OS 350 of the server 202 so that the network interface operates in promiscuous mode, the packet analysis unit 213 can acquire packet information.

(Modified example of traffic information collection)
Next, a further modified example of acquisition of traffic information when the IoT device 101 is communicating with the server 202 will be described.

TCP has different packet transmission procedures depending on the version. FIG. 16 is a diagram illustrating differences in packet transmission procedures according to TCP versions. FIG. 16 exemplifies the packet transmission procedure of the first version represented by Tahoe, Reno, etc., and the second version represented by NewReno, BIC, CUBIC, etc., for example.

As shown in FIG. 16(a), in the first version, the transmitting device receives an ACK corresponding to the transmitted packet from the receiving device after transmitting one box of packets corresponding to the window size. Do not send the next box packet until In this case, after the device on the receiving side discards one ACK for the received packet of one box, the device on the transmitting side does not transmit the packet of the next box until retransmission is started. Therefore, in the first version, the receiving device may start acquiring traffic information when it discards one ACK.

On the other hand, as shown in FIG. 16(b), in the second version, the transmitting device receives an ACK for the one box of packets transmitted from the receiving device after transmitting one box of packets. Send the next box packet before. After that, the device on the transmitting side waits until it receives ACK for the previously transmitted packet of one box, and does not transmit the packet of the next box. In this case, the device on the receiving side receives the packet of the next box even after discarding one ACK for the box of the first received packet. Therefore, in the second version, after discarding one ACK, the device on the receiving side receives the packet in the next box sent by the device on the transmitting side, and then starts acquiring traffic information. . Modification 1 of acquisition of traffic information in the second version of TCP will be described below.

(Modification 1)
FIG. 17 is a diagram illustrating execution timings for collecting traffic information in the second version of TCP according to Modification 1. In FIG. First, the device on the transmitting side transmits one box of packets corresponding to the window size to the device on the receiving side ((1) in FIG. 17). The device on the receiving side turns on the packet filter when collecting traffic information. Therefore, the device on the receiving side issues an ACK when it receives a packet from the device on the transmitting side, but the ACK is discarded by the packet filter ((2) in FIG. 17). Also, in the second version of TCP, the device on the transmitting side transmits the box of the next packet without waiting for ACK for the packet transmitted in (1) ((3) in FIG. 17). When the device on the transmitting side transmits the next packet box, it enters an ACK waiting state and stops packet transmission. Therefore, the device on the receiving side can start acquiring traffic information when it receives the packet transmitted in (3) ((4) in FIG. 17). In one example, the device on the receiving side transmits an ACK for the packet transmitted in (3), and starts collecting traffic information at the timing when the ACK is discarded by the packet filter ((5) in FIG. 17). good. After that, when the collection of traffic information is completed, the device on the receiving side turns off the packet filter and stops discarding ACKs ((6) in FIG. 17).

Also, the device on the transmitting side waits to receive an ACK for the packet transmitted in (1), but when the retransmission timer times out after the predetermined waiting time has passed since the packet was transmitted ((7 in FIG. 17) )) and resend the packet ((8) in FIG. 17).

As exemplified above, even in the second version of TCP, by discarding the ACK, it is possible to collect traffic information in a state in which the packet transmitted by the device on the transmitting side to the server 202 has been delivered. .

FIG. 18 is a diagram illustrating an operational flow of traffic information acquisition processing during communication executed by the control unit 301 in Modification 1 in S404 of FIG. The processes of S1801 and S1803 to S1805 correspond to the processes of S1301 and S1303 to S1305 of FIG. However, in the process of FIG. 18, the control unit 301 waits until two consecutive ACKs are discarded in S1802. As a result, even with the second version of TCP, it is possible to collect traffic information while suppressing measurement errors.

(Modification 2)
In Modification 1 described above, the control unit 301 of the device on the receiving side discards the second ACK in (5) of FIG. 17 and then starts collecting traffic information. Here, it is desirable that the collection of traffic information be completed before the device on the transmitting side times out waiting for ACK reception and retransmits the packet. However, in reality, the traffic information may not be collected in time due to the communication environment and the like. In this case, the time available for collecting traffic information can be extended by utilizing the TCP property of reducing the window size when retransmitting packets. Therefore, in Modified Example 2, an example will be described in which the time available for collecting traffic information is extended by starting the collection of traffic information after discarding three consecutive ACKs in the device on the receiving side.

FIG. 19 is a diagram illustrating execution timings for collecting traffic information according to Modification 2. In FIG. From (1) to (3) in FIG. 19, the processing may be executed in the same manner as in FIG. In (4), the device on the receiving side transmits an ACK when it receives a packet from the device on the transmitting side, but the ACK is discarded by the packet filter ((5) in FIG. 19). The device on the transmitting side is waiting for ACK, but when the timeout time for waiting for ACK elapses ((6) in FIG. 19), it retransmits the packet ((7) in FIG. 19). Then, in Modification 2, the device on the receiving side starts acquiring traffic information at the timing when the ACK of the retransmitted packet is discarded ((8) in FIG. 19).

In this case, the retransmission timer starts counting from the retransmission of the packet in (7), and in TCP, when the packet is retransmitted, the time until the retransmission timer waits for ACK is extended until timeout. The waiting time of the timer is also extended. Also, for example, after a timeout, the window size is reduced, and the device on the transmitting side transmits one packet and waits for its ACK. Therefore, the time required to transmit packets for one box is also shortened. As a result, in modification 2, a longer time than in modification 1 can be secured for obtaining traffic information.

Furthermore, in TCP, the time until timeout of the retransmission timer waiting for ACK is extended each time a packet is repeatedly retransmitted. For example, the timeout period may have an initial value of 3 seconds and may be extended by 3 seconds for each retransmission. In this case, as shown in FIG. 20, the waiting time of the retransmission timer is extended by 3 seconds each time an ACK for a packet retransmitted due to timeout is discarded.

Note that an upper limit is set for each OS 350, for example, for the wait time of the retransmission timer. For example, in Windows (registered trademark), the upper limit of waiting time is set to 21 seconds, and in Linux (registered trademark), the upper limit of waiting time is set to 381 seconds. If the latency limit is exceeded, the connection will be disconnected, so in embodiments, the number of ACKs to be discarded can be set so that the latency is less than or equal to the latency limit and suitable for obtaining traffic information. . For example, in the first version of TCP in FIG. 16(a), the waiting time can be estimated by "the number of discarded ACKs×3 seconds". In addition, in the second version of TCP in FIG. 16(b), after the ACK is discarded first, the ACK of the packet of the next box that is transmitted without waiting for the ACK is incremented by 1 to discard the ACK. The waiting time can be estimated by (the number of discarded ACKs - 1) x 3 seconds.

FIG. 21 is a diagram illustrating an operational flow of traffic information acquisition processing during communication executed by the control unit 301 in Modification 2 in S404 of FIG. The processing from S2101 and from S2103 to S2105 corresponds to the processing from S1301 and from S1303 to S1305 in FIG. . However, in the process of FIG. 21, the control unit 301 waits until ACKs are discarded consecutively a predetermined number of times in S2102. The predetermined number of times is, for example, the number of times ACKs are discarded consecutively, and may be three times or more. , the number of times to discard the ACK may be set.

As described above with reference to FIGS. 19 to 21, by repeatedly discarding ACKs, the ACK waiting time can be lengthened. Therefore, even when it takes time to collect traffic information, sufficient time is secured. be able to.

(Modification 3)
In Modified Example 2, the number of packets for one box is reduced by using the TCP property that the window size is reduced after the retransmission timer times out, and the time until the packets for one box reach the device on the receiving side. is shortened. As a result, it is possible to secure a longer time available for collecting traffic information. However, in this case, there is a waiting time until the retransmission timer times out in the device on the transmitting side. Therefore, in Modification 3, an example will be described in which the window size of the transmission-side device is reduced by transmitting a modified ACK to the transmission-side device. This makes it possible to start collecting traffic information without having to wait until the retransmission timer times out.

In TCP, it is possible to reduce the window size of the device on the transmitting side depending on the type of ACK. For example, in TCP, the ACK has a flag indicating that the receive buffer is full, and if this flag is ON, the device on the sending side reduces the window size. Therefore, in Modification 3, the device on the receiving side transmits to the device on the transmitting side an ACK that has been falsified so as to set a flag indicating that the reception buffer is full, thereby reducing the window size of the device on the transmitting side. Let

FIG. 22 is a diagram illustrating execution timings for collecting traffic information according to Modification 3. In FIG. When collecting traffic information, when a device on the transmitting side transmits a packet ((1) in FIG. 22), the device on the receiving side sets a flag indicating that the receive buffer is full for that packet. ((2) in FIG. 22). After that, the device on the receiving side sets the packet filter to ON ((3) in FIG. 22), and thereafter, when the device on the transmitting side transmits packets ((4) in FIG. 22), ACK indicating that it has been received is discarded ((5) in FIG. 22).

Further, when the device on the transmitting side receives the tampered ACK, it reduces the window size ((6) in FIG. 22), and thereafter transmits packets one by one and waits for the ACK ((7) in FIG. 22). . Therefore, the device on the receiving side can start collecting traffic information after discarding the ACK for the packet in (8). In this case, the receiving device may complete the collection of traffic information before the retransmission timer for the packet transmitted in (7) times out in the transmitting device. After completing the collection of traffic information, the device on the receiving side turns off the packet filter ((9) in FIG. 22). Then, when the retransmission timer times out, the device on the transmission side retransmits the packet ((10) in FIG. 22).

As described above, in Modification 3, it is possible to collect traffic information by reducing the window size of the device on the transmission side without waiting for timeout of the device on the transmission side. For example, in modification 3, it is not necessary to wait for the timeout of (6) in FIG. 19 of modification 2. FIG.

Note that in Modification 3, the device on the receiving side returns a falsified ACK to the device on the transmitting side. As an example of a technique for returning a falsified ACK to a device on the transmitting side, it is conceivable to modify the OS 350 that generates an ACK in the device on the receiving side so as to return a falsified ACK upon receiving a request from an application. be done. In another example, it is conceivable to set the OS 350 to send the entire packet received by a specific interface to the application, bypass the processing of the OS 350, and process the TCP packet on the application. In this case, since the application returns a tampered ACK, the process of modification 3 can be executed without modifying the OS 350 .

FIG. 23 is a diagram illustrating an operational flow of traffic information acquisition processing during communication executed by the control unit 301 in Modification 3 in S404 of FIG. In the process of FIG. 23, the control unit 301 transmits the ACK falsified in S2301 to the IoT device. For example, the control unit 301 can generate a falsified ACK by falsifying the ACK so as to set a flag indicating that the receive buffer is full. After transmitting the tampered ACK, in S2302, the control unit 301 sets the packet filter so as to discard the ACK or TCP packet addressed to the IoT device 101 to be inspected from its own device. Then, in S2303, the control unit 301 waits until two consecutive ACKs are discarded. The subsequent processing from S2304 to S2306 corresponds to the processing from S1303 to S1305 in FIG. 13, respectively, and the control unit 301 may execute the same processing as from S1303 to S1305. Note that in the third modification, as in the second modification, the ACK may be discarded three times or more in order to secure a waiting time suitable for acquiring traffic information.

According to Modifications 1 to 3 described above, even if the TCP version is the second version, or even if it takes time to collect traffic information, traffic information can be collected while suppressing measurement errors. , the IoT device 101 can be inspected.

In the above-described embodiment, for example, the control unit 301 of the server 202 operates as the setting unit 311 in the processes of S1301, S1801, S2101, and S2302. Further, for example, in the processes of S501, S502, S1303, S1304, S1803, S1804, S2103, S2104, S2304, and S2305, the control unit 301 of the server 202 operates as the acquisition unit 312. For example, in the process of S<b>405 , the control unit 301 of the server 202 operates as the inspection unit 313 .

Although the embodiment has been exemplified above, the embodiment is not limited to this. For example, the operational flow described above is an example, and embodiments are not limited thereto. Where possible, the operation flow may be executed by changing the order of the processes, may include additional processes, or may omit some of the processes. For example, the processes of S501 and S502, the processes of S1303 and S1304, the processes of S1803 and S1804, the processes of S2103 and S2104, and the processes of S2304 and S2305 described above may be executed in a different order.

Further, for example, in the above-described modified examples 1 to 3, examples are described in which the collection of traffic information is started at the timing when the ACK is discarded. However, embodiments are not so limited. For example, in another embodiment, the control unit 301 may determine the start timing of traffic information collection based on the timing of discarding the ACK. For example, in Modification 1 described above, after discarding the first ACK, the control unit 301 may start collecting traffic information at the timing of receiving packets for the window size. Alternatively, the control unit 301 may start collecting traffic information when a predetermined time has passed after discarding the first ACK. In this case, the predetermined time is set to a length, for example, according to the round-trip time (RTT: Round-Trip Time) to complete the reception of the packet of the next box transmitted by the device on the transmitting side. good.

FIG. 24 is a diagram illustrating the hardware configuration of a computer 2400 for implementing the server 202 or packet analysis unit 213 according to the embodiment. A hardware configuration for realizing the server 202 or the packet analysis unit 213 of FIG. 24 includes, for example, a processor 2401, a memory 2402, a storage device 2403, a reader 2404, and a communication interface 2406. Note that the processor 2401, memory 2402, storage device 2403, reading device 2404, and communication interface 2406 are connected to each other via a bus 2408, for example.

The processor 2401 may be, for example, a single processor, multiple processors, or multiple cores. The processor 2401 provides a part or all of the functions of the control unit 301 or the packet analysis unit 213 described above by executing, for example, a program describing the procedure of the operation flow described above using the memory 2402 . For example, the processor 2401 of the server 202 operates as the setting unit 311 , the acquisition unit 312 and the inspection unit 313 by reading and executing programs stored in the storage device 2403 . Also, the processor 2401 may operate as the packet analysis unit 213 by reading and executing a program stored in the storage device 2403, for example.

Memory 2402 is, for example, a semiconductor memory and may include a RAM area and a ROM area. The storage device 2403 is, for example, a hard disk, a semiconductor memory such as a flash memory, or an external storage device. Note that RAM is an abbreviation for Random Access Memory. Also, ROM is an abbreviation for Read Only Memory.

Reader 2404 accesses removable storage medium 2405 according to instructions from processor 2401 . The removable storage medium 2405 is, for example, a semiconductor device (USB memory, etc.), a medium in which information is input/output by magnetic action (magnetic disk, etc.), a medium in which information is input/output by optical action (CD-ROM, DVD, etc.). Note that USB is an abbreviation for Universal Serial Bus. CD is an abbreviation for Compact Disc. DVD is an abbreviation for Digital Versatile Disk.

Note that the storage unit 302 described above may include a memory 2402, a storage device 2403, and a removable storage medium 2405, for example. For example, analysis information 900 may be stored in the storage device 2403 of the server 202 or the storage device 2403 of the packet analysis unit 213 .

Communication interface 2406 transmits and receives data via the network according to instructions from processor 2401 . The communication interface 2406 is, for example, an example of the communication unit 303 described above.

Each program according to the embodiment is provided to the server 202 and the packet analysis unit 213 in the following form, for example.
(1) Pre-installed in the storage device 2403 .
(2) provided by removable storage medium 2405;
(3) provided by a server such as a program server;

Note that the hardware configuration of the computer 2400 for realizing the server 202 and the packet analysis unit 213 described with reference to FIG. 24 is an example, and the embodiment is not limited to this. For example, some or all of the functions of the functional units described above may be implemented as hardware such as FPGA and SoC. Note that FPGA is an abbreviation for Field Programmable Gate Array. SoC is an abbreviation for System-on-a-chip.

Several embodiments are described above. However, it should be understood that the embodiments are not limited to the embodiments described above, but encompass various variations and alternatives of the embodiments described above. For example, it will be appreciated that various embodiments can be embodied with varying elements without departing from the spirit and scope thereof. Also, it will be understood that various embodiments can be implemented by appropriately combining a plurality of constituent elements disclosed in the above-described embodiments. Furthermore, various embodiments can be implemented by deleting or replacing some components from all the components shown in the embodiments, or by adding some components to the components shown in the embodiments. It will be understood by those skilled in the art that

100 IoT system 101 IoT device 102 Server 105 Network 150 IT network 200 IoT system 202 Server 211 Packet counting device 212 Hub 213 Packet analysis unit 250 Inspection system 301 Control unit 302 Storage unit 303 Communication unit 311 Setting unit 312 Acquisition unit 313 Inspection unit 2400 computer 2401 processor 2402 memory 2403 storage device 2404 reader 2405 removable storage medium 2406 communication interface 2408 bus

Claims (6)

A testing method performed by a server, the server comprising:
configure the packet filter to discard positive acknowledgments destined for the device under test;
a first packet count representing the number of packets transmitted by the device under test based on the timing at which the packet filter discards a positive acknowledgment addressed to the device under test; and a second packet count representing the number of packets sent to
Inspecting unauthorized communication of the device to be inspected depending on whether the first number of packets and the second number of packets match within a predetermined error range;
inspection method, including 2. The packet filter according to claim 1, wherein the timing at which said packet filter discards positive acknowledgments addressed to said device to be inspected is the timing at which said packet filter discards two consecutive positive acknowledgments addressed to said device to be inspected. inspection method. The timing at which the packet filter discards the positive acknowledgment addressed to the device to be inspected is the timing at which the packet filter discards the positive acknowledgment addressed to the device to be inspected for a predetermined number of times of three or more consecutive times. Item 1. The inspection method according to Item 1. The server discards positive acknowledgments destined for the device under test after returning to the device under test a positive acknowledgment tampered with to flag a receive buffer full. 2. The inspection method according to claim 1, wherein said packet filter is set. The device under test is connected to a port of a switch,
the server obtains from the switch the number of packets input to the port of the switch to which the device to be inspected is connected as the first number of packets;
The inspection method according to any one of claims 1 to 4, further comprising: An inspection system including a server and a packet counting device,
The packet counting device counts the number of input packets for each port and outputs the packets to a destination port;
The server is
a setting unit configured to configure a packet filter to discard positive acknowledgments addressed to the device under test;
a first number of packets representing the number of packets input to a port to which the device under test is connected, based on the timing at which the packet filter discards the positive acknowledgment addressed to the device under test; an acquisition unit that acquires from a device and acquires a second number of packets representing the number of packets that the device to be inspected has transmitted to a server;
an inspection unit that inspects unauthorized communication of the device to be inspected depending on whether the first number of packets and the second number of packets match within a predetermined error range,
inspection system.

Images