KR102112587B1 - Packet monitoring device and packet monitoring method for communication packet - Google Patents

Abstract

A packet monitoring method according to an embodiment of the present invention includes receiving a communication packet transmitted and received between a server and a control device, a history table including control information of communication packets received before a received communication packet, and a received communication packet And determining whether the received communication packet is abnormal based on the control information of and performing a security operation according to the determination result.

Description

Packet monitoring device and packet monitoring method for communication packets {PACKET MONITORING DEVICE AND PACKET MONITORING METHOD FOR COMMUNICATION PACKET}

The present invention relates to a control system, and more particularly, to a packet monitoring apparatus and a packet monitoring method for communication packets.

The control system is a system for efficiently monitoring and managing remote systems, and is used in the operation of major national infrastructure such as power, gas, water and sewage, and transportation. The use environment of the control system is changing from the use of a closed communication network or a dedicated OS to the use of an open communication network and a general purpose OS. While this change increases the convenience of the control system, it has a two-sided nature that exposes security vulnerabilities. In particular, as private control system protocol standards are gradually released as international standards, the possibility and risk of cyber infringement on control systems are gradually increasing.

Among the above-described control system protocols, the DNP 3.0 protocol is widely used in control systems and is a protocol established as an industry standard used in fields such as electricity, oil, and gas. However, the DNP3 protocol that does not consider security aspects has various attack risks such as spoofing and modification of a general network. In other words, the DNP (Distributed Network Protocol) 3.0 protocol is being established as a general protocol standard for the control system, but there is a problem in that a simple attack is possible using a weak security aspect. That is, since the DNP 3.0 protocol can be attacked with simple packet manipulation, there is a possibility that a new type of attack may occur.

Digital Bond has released 16 vulnerabilities that apply these general network vulnerabilities to the DNP3 protocol, and the disclosed intrusion detection rules are in the form of Snort's intrusion detection rules to 11 major security companies such as Cisco, 3com / Tipping Point, and Symantec. Provided and used. However, since there are many unknown techniques for the attack pattern on the power grid, it is required to construct a monitoring system through behavior-based or abnormal behavior learning by improving the existing traffic-based traffic monitoring system. In conclusion, in order to protect the stable provision of services between control systems from activities that interfere with the safe operation of the main infrastructure due to intentional or unintentional actions, security techniques appropriate to the control system protocol are required.

An object of the present invention is to provide a packet monitoring apparatus for efficiently detecting abnormal communication packets on a distributed network protocol and a packet monitoring method for communication packets.

A packet monitoring method for a communication packet transmitted and received between a server and a control device according to an embodiment of the present invention includes receiving a communication packet transmitted and received between the server and the control device; Determining whether the received communication packet is abnormal based on a history table including control information of communication packets received before the received communication packet and control information of the received communication packet; And performing a security operation according to the determination result, wherein the control information includes a function code field of application protocol control information of the communication packet, a sequence bit of the application protocol control information, a source field of a link header, and the link. It includes a target field of a header, a start bit of a transport header, and an end bit of the transport header.

As an embodiment, the server and the control device exchange and transmit the communication packet based on Distributed Network Protocol 3.0 (DNP 3.0).

As an embodiment, determining whether the received communication packet is abnormal may include classifying the received communication packet into any one of the first to fifth types of abnormal communication packets when the received communication packet is an abnormal communication packet. Steps.

As an embodiment, the first type of abnormal communication packet indicates an abnormal communication packet that cannot occur between the server and the control device, and the second type of abnormal communication packet is used for normal communication between the server and the control device. Refers to a violated abnormal communication packet, the third type of abnormal communication packet refers to an abnormal communication packet that is retransmitted to a communication packet that has been transmitted and received between the server and the control device, and the fourth type of abnormal communication packet is the An abnormal communication packet that violates a normal order bit between a server and the control device, and the fifth type of abnormal communication packet indicates an abnormal communication packet that causes abnormal message interpolation between the server and the control device.

As an embodiment, the step of classifying the received communication packet into any one of the first to fifth types of abnormal communication packets may include a source field of the link header of the received communication packet and a function code field of the application protocol control information. And classifying the received communication packet into the abnormal communication packet of the first type based on the received communication packet.

As an embodiment, the step of classifying the received communication packet into the first type of abnormal communication packet may include the source field of the link header of the received communication packet pointing to the server, and the function code field responding or random If the value corresponding to the response or the source field of the link header of the received communication packet points to the control device, and the function code field has a value corresponding to the request, the received communication packet is And classifying it as a first type of abnormal communication packet.

As an embodiment, the step of classifying the received communication packet into any one of the first to fifth types of abnormal communication packets is based on sequence bits and received time of the previously received communication packets included in the history table. And classifying the received communication packet into the abnormal communication packet of the second type.

As an embodiment, classifying the received communication packet into the second type of abnormal communication packet may include communication having the same order bit as the received communication packet among the previously received communication packets included in the history table. And when the packet is received before a predetermined time, classifying the received communication packet as the abnormal communication packet of the second type.

As an embodiment, the step of classifying the received communication packet into any one of the first to fifth types of abnormal communication packets may include whether or not transmission / reception of communication packets corresponding to the received communication packet among the previously received communication packets is completed. And classifying the received communication packet into the abnormal communication packet of the third type.

As an embodiment, the step of classifying the received communication packet into any of the first to fifth types of abnormal communication packets is the same as the received communication packet among the previously received communication packets based on the history table. And when the transmission / reception of the communication packet having the sequence bit is completed, classifying the received communication packet as the abnormal communication packet of the third type.

As an embodiment, the step of classifying the received communication packet into any one of the first to fifth types of abnormal communication packets may include receiving the received communication packets based on order bits of the previously received communication packets included in the history table. And classifying the communication packet into the abnormal communication packet of the fourth type.

As an embodiment, classifying the received communication packet into the abnormal communication packet of the fourth type is based on the order bits of the previously received communication packets in which the order bit of the received communication packet is included in the history table. In the case of different from the order bits according to the distributed network protocol 3.0, it includes classifying the order bits of the received communication packet into the fourth type of abnormal communication packets.

As an embodiment, the step of classifying the received communication packet into any one of the first to fifth types of abnormal communication packets may include starting bits and ending bits of the link header of the previously received communication packets included in the history table. And classifying the received communication packet into the fifth type of abnormal communication packet based on bits.

As an embodiment, the step of classifying the received communication packet into the abnormal communication packet of the fifth type may include the start bit before the communication packet with the end bit '1' transmitted from the control device to the server is received. When the communication packet with a '1' is received, classifying the received communication packet into the abnormal communication packet of the fifth type.

A packet monitoring apparatus according to another embodiment of the present invention includes a distributed network protocol physical layer that receives a communication packet transmitted and received between a server and a control device, and releases the received communication packet to generate control information and a message; A communication packet analysis module that manages the control information of the received communication packet; The history table for storing control information of the received communication packet and control information of a communication packet received earlier than the received communication packet; And an abnormal packet detection and classification module for determining whether the received communication packet is an abnormal communication packet based on control information of the previously received communication packet and control information of the received communication packet stored in the history table. And a control module performing a security operation according to a result of the determination of the abnormal packet detection and classification module, wherein the control information includes a function code field of application protocol control information of the communication packet, an order bit of the application protocol control information, It includes the source field of the link header, the target field of the link header, the start bit of the transport header, and the end bit of the transport header.

As an embodiment, the server and the control device transmit and receive the communication packet based on Distributed Network Protocol 3.0 (DNP 3.0; Distributed Network Protocol 3.0).

As an embodiment, the distributed network protocol physical layer may include a DNP 3.0 data link layer that extracts the link header from the received communication packet; A DNP 3.0 transport layer that extracts the transport header from the received communication packet; And a DNP 3.0 application layer that extracts the application protocol control information from the received communication packet.

As an embodiment, the server and the control device communicate with each other through a communication line based on the TCP / IP protocol, and the distributed network protocol physical layer extracts an Ethernet header, an IP header, and a TCP header from the received communication packet. The communication protocol layer is further included.

As an embodiment, the abnormal packet detection and classification module may first to fifth receive the received communication packet based on control information of the previously received communication packet and control information of the received communication packet stored in the history table. It is classified as one of the types of abnormal communication packets.

As an embodiment, the abnormal communication packet of the first type indicates a communication packet that cannot occur between the server and the control device, and the abnormal communication packet of the second type is in violation of normal communication between the server and the control device. Refers to a communication packet, and the abnormal communication packet of the third type indicates a retransmission communication packet for a communication packet that has been transmitted and received between the server and the control device, and the abnormal communication packet of the fourth type is the server and the control A packet monitoring device indicating communication packets that violate a normal sequence bit between devices, and the fifth type of abnormal communication packets indicating communication packets that cause abnormal message interpolation between the server and the control device.

According to the present invention, the packet monitoring apparatus can effectively detect abnormal communication packets and classify the types thereof by analyzing control information of communication packets based on the distributed network protocol 3.0. In addition, the packet monitoring device provides secure reliability and availability of services through rapid discovery and response to security threats in the control system based on the classified type.

Accordingly, a packet monitoring apparatus having improved reliability and a packet monitoring method for communication packets are provided.

1 is a block diagram showing a control system according to an embodiment of the present invention.
FIG. 2 is a block diagram showing in detail the server, control device, and packet monitoring device of FIG. 1.
3 is a block diagram showing in detail the physical layer of the DPN 3.0 protocol of FIG. 2.
FIG. 4 is a diagram for describing a data structure in each layer of FIG. 3.
5 is a diagram showing in detail the data fragment of FIG. 4.
FIG. 6 is a diagram showing in detail the data segment of FIG. 4.
7 is a diagram showing in detail the data frame of FIG. 4.
8 and 9 are diagrams showing communication between the server and the control device of FIG. 2.
FIG. 10 is a block diagram showing the packet monitoring device of FIG. 2 in detail.
11 is a flow chart showing the operation of the packet monitoring apparatus of FIG. 10.
12 is a flowchart illustrating another operation of the packet monitoring apparatus of FIG. 10.
13 to 17 are diagrams for describing first to fifth types of abnormal packets, respectively.

Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings in order to describe in detail that a person skilled in the art to which the present invention pertains can easily implement the technical spirit of the present invention. .

1 is a block diagram showing a control system according to an embodiment of the present invention. Referring to FIG. 1, the control system 100 includes servers 110, 110a, 110b, control devices 120, 120a, 120b, sensors, and a packet monitoring device 130. For example, the control system 100 may be a closed control system used in a system requiring safety or security, such as power, gas, water and sewage, and transportation.

The servers 110, 110a and 110b may serve as a server of the control system 100. For example, the servers 110, 110a, 110b can control the control devices 120, 120a, 120b. For example, the servers 110, 110a, and 110b may communicate with the control devices 120, 120a, and 120b through a communication line CL or gateway GW, respectively. For example, the server 110 and the control device 120 may communicate through a communication line CL. The server 110a and the control device 120b may communicate through a communication line CL and a gateway CW. For example, the servers 110, 110a, and 110b may include a control server device such as a Human Machine Interface (HMI), a SCADA server, and the like.

The control devices 120, 120a, and 120b may communicate with the server devices 110, 110a, and 110b through a communication line CL or a gateway GW. The control devices 120, 120a, and 120b control a plurality of sensors under the control of the servers 110, 110a, and 110b, or receive information detected from the plurality of sensors. 110, 110a, 110b). Illustratively, the control devices 120, 120a, 120b may include field control devices such as PLC, IED, RTU, or outstation devices.

For example, the communication line CL may be a communication line according to a predetermined communication protocol. That is, when the server and the control device communicate through the communication line CL, the server and the control device can each send and receive communication packets defined according to a predetermined communication protocol. For example, the communication line CL may be a communication line on the TCP / IP protocol. In this case, the server 110 and the control device 120 can send and receive communication packets defined by the TCP / IP protocol.

The packet monitoring device 130 may monitor communication packets transmitted and received through the communication line CL between the servers 110, 110a, and 110b and the control devices 120, 120a, and 120b. For example, the packet monitoring device 130 may receive a communication packet branched through the mirroring port MP provided on the communication line CL, and manage code information of the received communication packet. The packet monitoring device 130 determines whether the received communication packet is an abnormal communication packet (or abnormal traffic) based on the managed code information and the received communication packet, and if the received communication packet is an abnormal communication packet, the received communication Anomaly types of packets can be classified.

FIG. 2 is a block diagram showing in detail the server, control device, and packet monitoring device of FIG. 1. Hereinafter, for the sake of brevity, embodiments of the present invention will be described based on the packet monitoring device 130 that monitors communication packets transmitted and received between the server 110 and the control device 120. At this time, it is assumed that the server 110 is a master device and the control device 120 is a slave device. In addition, it is assumed that the server 110 and the control device 120 exchange information according to the Distributed Network Protocol (DNP) 3.0 protocol, and send and receive communication packets through a communication line CL according to the TCP / IP protocol. That is, the server 110 and the control device 120 send and receive communication packets defined by the TCP / IP protocol, and the communication packets include data units defined by the DNP 3.0 protocol.

However, the technical idea of the present invention is not limited to the above-described assumptions, and the servers 110, 110a, 110b and the control devices 120, 120a, 120b can exchange and send communication packets, respectively. The monitoring device 130 may monitor communication packets transmitted and received between the servers 110, 110a, and 110b and the control devices 120, 120a, and 120b. Further, the servers 110, 110a, 110b and the control devices 120, 120a, and 120b may perform serial communication through a serial communication line (dotted line in FIG. 1) through the gateway GW. In this case, the servers 110, 110a, 110b and the control devices 120, 120a, 120b can exchange data units defined by the DNP 3.0 protocol through a serial communication line (dotted line in FIG. 1).

1 and 2, the control system 100 includes a server 110, a control device 120, and a packet monitoring device 130.

Each of the server 110 and the control device 120 may transmit and receive communication packets through a communication line CL. Each of the server 110, the control device 120, and the packet monitoring device 130 includes physical layers 111, 121, and 131 according to the DNP 3.0 protocol. The physical layer 111, 121, and 131 according to the DNP 3.0 protocol performs an operation of converting a message to be transmitted into a communication packet in a format defined by the DNP 3.0 protocol or inversely converting a received communication packet into a message.

For example, when the communication line CL is a communication line according to the TCP / IP protocol, each of the physical layers 111, 121, and 131 may further include a physical layer according to the TCP / IP protocol. That is, the physical layers 111, 121, and 131 may convert a message to be transmitted into a format defined by the DNP 3.0 protocol, and convert it into a communication packet in a format defined by the TCP / IP protocol. For example, when the communication line CL is a serial communication line, a physical layer according to the TCP / IP protocol may be omitted.

For example, the server 110 may be a master device, and the control device 120 may be a slave device. That is, the server 110 transmits a request (RQ) to the control device 120, and the control device 120 responds to the request (RQ) from the server 110 to send a response (RP) to the server 110 Can transmit. Alternatively, the control device 120 may transmit an arbitrary response (URP) to the server 110. The above-described request (RQ), response (RP), and random response (URP) are provided in a format defined by the DNP 3.0 protocol and may be included in a communication packet defined by the TCP / IP protocol.

3 is a block diagram showing in detail the physical layer of the DPN 3.0 protocol of FIG. 2. For example, the physical layer 111 of the server 110 is described with reference to FIG. 3, but the physical layers 121 and 131 of the control device 120 and the packet monitoring device 130 are also shown in FIG. 3. It may have the same hierarchical structure as the physical layer.

2 and 3, the physical layer 111 of the server 110 includes a DNP 3.0 application layer 111a, a DNP 3.0 transport layer 111b, a DNP 3.0 data link layer 111c, and a communication protocol layer ( 111d).

The DNP 3.0 application layer 111a may standardize the message by adding control information to the message to be transmitted from the server 110. For example, the message standardized in the DNP 3.0 application layer 111a is called an Application Protocol Data Unit (APDU) or a DNP 3.0 Fragment (DNP3 Fragment). Hereinafter, the message standardized in the DNP 3.0 application layer 111a is referred to as a data fragment (DNP 3.0 Fragment).

The DNP 3.0 transport layer 111b divides a piece of data into predetermined units and adds a transmission header to each of the divided units. Units processed in the DNP 3.0 transport layer 111b are called a Transport Protocol Data Unit (TPDU) or a DNP 3.0 segment (DNP3 Segment). Hereinafter, data operated in the DNP 3.0 transport layer 111b is referred to as a data segment (DNP 3.0 Segment).

The DNP 3.0 data link layer 111c adds a link header to each of the data segments. The data segments processed in the DNP 3.0 data link layer 111c are called Link Protocol Data Unit (LPDU) or DNP 3.0 Frame (DNP 3.0 Frame). Hereinafter, data segments processed in the DNP 3.0 data link layer 113 are referred to as data frames (DNP 3.0 Frames).

The communication protocol layer 111d may process data frames according to the protocol of the communication line CL. Illustratively, when the communication line CL is based on the TCP / IP protocol, the communication protocol layer 111d includes a transport layer, a network layer, and a link / physical layer, and data frames according to the TCP / IP protocol. It can be processed.

The processed data frames are transmitted as a communication packet to the control device 120 and the packet monitoring device 130 through the communication line CL.

Exemplarily, when the server 110 receives a communication packet (ie, a response (RP) or an arbitrary response (URP)) from the control device 120, each layer of the server 110 is in the reverse order of the above-described order. The message can be extracted by releasing the communication packet.

FIG. 4 is a diagram for describing a data structure in each layer of FIG. 3. Illustratively, the data structure when a 600-byte message M1 is transmitted from the server 110 is illustrated in FIG. 4. However, the scope of the present invention is not limited to this, and the size of the message may be variously changed, and according to the standard in each layer, the message may be further divided or data units may be further generated.

Referring to FIGS. 3 and 4, the message M1 may include first to 600th data D001 to D600. The size of each of the first to 600th data D001 to D600 is 1-bytes. The DNP 3.0 application layer 111a may convert a message into an application service data unit (ASDU). The DNP 3.0 application layer 111 may generate a data fragment (FRAG) by adding application protocol control information (APCI) to the application service data unit. That is, the data fragment FRAG includes application protocol control information (APCI) and first to 600th data D001 to D600. Illustratively, a data fragment (FRAG) is an Application Protocol Data Unit (APDU). For example, the application protocol control information (APCI) may include various information about a message.

Illustratively, the maximum size of a data fragment (FRAG) defined by the DNP 3.0 protocol may be limited to 2048-bytes. The size of the application protocol control information (APCI) may be 2-byte. In this case, when the message exceeds 2046-bytes, the DNP 3.0 application layer 111a divides the message into 2046 bytes, and adds application protocol control information (APCI) to each of the divided messages to pieces of data. You can create them. For example, the size of the application protocol control information (APCI) may vary depending on the type of message.

The DNP 3.0 transport layer 111b divides the data fragment (FRAG) into predetermined units, and adds first to third transmission headers (TH1 to TH3) to each of the divided data fragments to form the first to third data segments. Fields (SEG1 to SEG3) can be generated. For example, the maximum size of a data segment defined by the DNP 3.0 protocol can be limited to 250-bytes. The size of each of the first to third transmission headers TH1 to TH3 may be 4-byte. The DNP 3.0 transport layer 111b adds the first transport header TH1 to the application protocol control information (APCI) of the data fragment FRAG and the first to 247 data D001 to D247, and thus the first data segment SEG1 ). Similarly, the DNP 3.0 transport layer 111b generates the second data segment SEG2 based on the 248th to 496th data D248 to D496 and the second transmission header TH2, and the 4th to 600th data ( D497 to D600) and the third transmission header TH3 may generate a third data segment SEG3. For example, the first to third data segments SEG1 to SEG3 may be Transport Protocol Data Units (TPDUs).

Next, the DNP 3.0 data link layer 111c adds the first to third link headers LH1 to LH3 to each of the first to third data segments SEG1 to SEG3 to thereby form the first to third data frames. Fields (FR1 to FR3) can be produced. For example, each of the first to third data frames FR1 to FR3 may include a 10-byte link header, a 250-byte data segment, and a 32-byte cyclic redundancy check code (CRC code). have.

The communication protocol layer 111d generates communication packets by adding information based on the communication protocol of the communication line CL to the first to third data frames FR1 to FR3. For example, when the communication protocol of the communication line CL is TCP / IP, the communication line protocol layer 114 transmits information such as an Ethernet header, an IP header, and a TCP header to the first to third data frames FR1 to FR3) In addition to each, a communication packet is generated. The generated communication packet is transmitted to the control device 120 through the communication line CL.

Exemplarily, the unit and packet structures of each layer illustrated in FIG. 4 are exemplary, and the scope of the present invention is not limited thereto. The number of units in each layer may vary depending on the type of message, the size, and the maximum size of the units in each layer.

In addition, the control device 120 may perform communication based on the same hierarchical structure as the hierarchical structure illustrated in FIG. 4. Also, the packet monitoring device 130 may release the received communication packet based on the same hierarchical structure as the hierarchical structure shown in FIG. 4.

5 is a diagram showing in detail the data fragment of FIG. 4. Referring to FIG. 5, the data fragment FRAG includes application protocol control information (APCI) and a message M1 (or application service data unit (ASDU)). The application protocol control information (APCI) includes control information of the message M1. For example, the application protocol control information (APCI) includes an application control field (Application Control), a function code field (Function Code), and an internal command field (Internal Indications).

The application control field (Application Control) includes a start bit (FIR_A), an end bit (FIN_B), a cone bit (CON), a random response bit (UNS), and a sequence bit (SEQ_A). The start bit FIR_A is the seventh bit B7 of the application control field (Application Control) and indicates whether the current data piece is the first data piece. For example, if the start bit (FIR_A) is set to '1', the current data fragment is the first data fragment.

The end bit (FIN_A) is the sixth bit (B6) of the application control field, and indicates whether the current data fragment (FRAG) is the last data fragment. For example, if the end bit (FIN_A) is set to '1', the data fragment (FRAG) is the last data fragment.

The cone bit CON is the fifth bit B5 of the application control field. When the cone bit (CON) is set to '1', a device that has received a communication packet (that is, a communication packet with the cone bit (CON) '1') must return an application layer acknowledgment message. For example, in the case of the request message of the server 110, the cone bit CON is not set. For example, in the case of an unsolicited response (URP) of the control device 120, the cone bit CON is set to '1'. Exemplarily, when the CON bit is set in the response RP of a multi-slice form (that is, when the message size is larger than the maximum size of the data piece), the last data piece (ie, the end bit (FIN_A) is '1' Is set to (optional). For example, the response of the control device 120 that does not have an event for the request (RQ) of the server 110 may not be set the cone bit (CON).

The random response bit (UNS) is the fourth bit (B4) of the application control field (Application Control), and indicates whether the current data fragment (FRAG) is a random response (URP). For example, when the random response bit UNS is set to '1', the data fragment FRAG is a random response transmitted from the control device 120.

The sequence bit (SEQ_A) includes the first to fourth bits (B1 to B4) of the application control field, and indicates an identification number for identification of a message to be transmitted and received. For example, the response RP of the control device 120 to the request RQ from the server 110 has the same order bit (SEQ_A) as the request RQ. For example, the order bit (SEQ_A) of the request (RQ) of the server 110 increases by '1' except for retransmission. For example, the sequence bit (SEQ_A) of the request (RQ) of the server 110 and the sequence bit (SEQ_A) of the response (RP) of the control device 120 are managed independently of each other. For example, the order bits managed in communication between the server 110 and the control device 120 and the order bits managed in communication between the server 110 and the other control device 120 are managed independently of each other.

The function code field indicates the type of data fragment (FRAG). That is, the function code field (Function Code) includes information on whether the data fragment (FRAG) is a request (RQ), a response (RP), or an acknowledgment (CF). Exemplarily, the function code field includes 1-byte information. When the data fragment (FRAG) is the confirmation (CF), the confirmation function code field (Function Code) has a value of 0x00. When the data fragment FRAG is a request RQ, the verification function code field has a value between 0x01 and 0x82. When the data fragment FRAG is the response RP, the acknowledgment function code field has a value between 0x83 and 0xFF.

The internal instruction field (Internal Indication) may be omitted depending on the type of data fragment (FRAG). For example, if the data fragment (FRAG) is a request (RQ), the internal instruction field (Internal Indication) is omitted.

FIG. 6 is a diagram showing in detail the data segment of FIG. 4. Illustratively, referring to FIG. 6, the first data segment SEG1 is described, but the scope of the present invention is not limited thereto, and the second and third data segments SEG2, SEG3 or other data segments In addition, it may have a data structure similar to the first data segment (SEG1) of FIG.

Referring to FIG. 6, the first data segment SEG1 may include a portion of the first transport header TH1 and a data fragment FRAG. For example, a portion of the data fragment FRAG has a size of 249-bytes and may include application protocol control information (ACPI) and first to 247 data (D001 to D247).

The first transmission header TH1 has a size of 1-byte, and includes a start bit (FIR_T), an end bit (FIN_T), and a sequence bit (SEQ_T). The start bit (FIG_T) is the seventh bit (B7) of the first transmission header TH1, and indicates that the current data segment is the first data segment. For example, when the start bit FIR_T is set to '1', the first data segment SEG1 is the first data segment.

The end bit FIN_T is the eighth bit B8 of the first transmission header TH1, and indicates that the current data segment is the last data segment. For example, when the end bit FIN_T is set to '1', the first data segment SEG1 is the last data segment.

The sequence bit (SEQ_T) includes the first to sixth bits B1 to B6 of the first transmission header TH1, and indicates an identification number of the current data segment. For example, the sequence bit (SEQ_T) of the data segment in which the start bit (FIR_T) is set to '1' has a value between 0 and 63 regardless of the previous data segment.

7 is a diagram showing in detail the data frame of FIG. 4. Exemplarily, referring to FIG. 7, the first data frame FR1 is described, but the scope of the present invention is not limited thereto. The second and third data frames FR2 and FR3 and other data frames may also have a data structure similar to the first data frame FR1 of FIG. 7.

Referring to FIG. 7, the first data frame FR1 includes a first link header LH1, a first data segment SEG1, and a cyclic redundancy check code CRC. The first link header LH1 includes start fields (START), length fields (Length), control fields (Control), target fields (Destination), source fields (Source), and cyclic redundancy check code fields (CRC). Includes.

The start fields (START) each have a size of 1-byte, and have values of 0x05 and 0x64. The length field (Length) contains information about the length of the entire data frame, and has a size of 1-byte. The control field (Control) has a size of 1-byte and includes information for control in the DNP 3.0 data link layer 111c.

The target field (Destination) has a size of 2-byte, and includes information on a target device to which the first data frame FR1 is to be transmitted. The source field (Source) has a size of 2-byte and includes information on a device transmitting the first data frame (FR1).

For example, the target device and the source device may be identified through the target field (Destination) and the source field (Source). For example, the target device and the source device may be identified through the IP address of the TCP / IP protocol, but when a plurality of logical devices are connected to one IP, or when performing serial communication, the target field described above The target device and the source device may be identified based on the (Destination) and the source field (Source).

As an example, with reference to FIGS. 4 to 7, the data format of the server 110 communicating based on the DNP 3.0 protocol has been described. However, the scope of the present invention is not limited thereto, and the control device 120 may also communicate based on the above-described data format, and the packet monitoring device 130 may also receive received communication packets based on the above-described data format. Can be monitored.

8 and 9 are diagrams showing communication between the server and the control device of FIG. 2. Illustratively, illustratively, communication packets described with reference to FIGS. 8 and 9 (eg, request (RQ), response (RP), random response (URP), etc.) are defined by the DNP 3.0 protocol. Communication packets. That is, the communication packets described with reference to FIGS. 8 and 9 may include data frames FR described with reference to FIGS. 4 to 7.

2 and 8, as shown in the first section of FIG. 8, in step S11, the server 110 transmits a request (RQ) to the control device 120. In step S12, the control device 120 transmits a response RP to the server 110 in response to the request RQ. In step S13, the server 110 may transmit an optional confirmation (OCF) to the control device 110 in response to the response RP. One communication (that is, response and confirmation according to one request) is completed by communication packets transmitted and received in steps S11 to S13. For example, the request (RQ) of step S11, the response (RP) of step S12, and the optional confirmation (OCF) of step S13 may have the same sequence bit (SEQ_A) or sequence bits of consecutive values.

Next, as shown in the second section of FIG. 8, in step S14, the server 110 may transmit a request with no response (RQNR) to the control device 120. The control device 120 may not transmit a response in response to a request for no response (NRQ). For example, the request (NRQ) of step S14 is set to the cone bit (CON) is '0', and accordingly, the control device 120 does not need to transmit a communication packet having a function code of 0x00 to the server 110 do.

Next, as shown in the third section of FIG. 8, in step S15, the control device 120 may transmit an arbitrary response (URP) to the server 110. In step S16, the server 110 transmits an acknowledgment (CF) to the control device 120 in response to the random response (URP). For example, in the random response (URP) of step S15, the cone bit CON is set to '1', and the server 110 responds thereto to confirm that the function code has a value of 0x00 (CF). To the control device 120.

Next, referring to FIGS. 2 and 9, as shown in the first section of FIG. 9, in step S21, the server 110 may transmit a response RQ to the control device 120. Thereafter, if a response RP is not received from the control device 120 for a predetermined time (ie, after a response timeout has elapsed), in step S22, the server 110 responds to the retransmission ( RRQ) may be retransmitted to the control device 120. For example, the response (RP) of step S21 and the retransmitted (RRQ) of step S22 may have the same order bit (SEQ_A) as each other. Exemplarily, the predetermined time (ie, response timeout) may be a time defined by the DNP 3.0 protocol.

Similarly, as shown in the second section of FIG. 9, in step S23, the control device 120 may transmit an arbitrary response (URP) to the server 110. After this, the confirmation CF may not be received from the server 110 for a predetermined time. In this case, in step S24, the control device 120 may retransmit a random response (RURP). For example, the random response (URP) of step S23 and the random response (RURP) retransmitted in step S24 have the same order bit (SEQ_A) as each other.

For example, a retransmission operation may not be performed on some of the requests transmitted from the server 110. Exemplarily, requests that are not retransmitted are DIRECT_OPERATE (0x05), DIRECT) OPERATE_NR (0x06), DELAY_MEASURE (0x17), RECORD_CURRENT_TIME (0x18), WRITE (0x02) with an Absolute Time object, g50v1, with a Last Recored Time object, It may include a function code such as g50v3.

FIG. 10 is a block diagram showing the packet monitoring device of FIG. 2 in detail. 2 and 10, the packet monitoring device 130 includes a DNP 3.0 protocol layer 131, a packet analysis module 132, a history table 133, an abnormal packet detection and classification module 134, and a control module (135). Illustratively, a module may be implemented as a software or hardware device. For example, the software-type module is implemented in the form of program instructions, program codes, data, tables, and the like, and may be stored in a separate storage medium. The module in the form of a hard war can be implemented with devices such as a processor, a core, MEMS, electrical and electronic circuits, and passive elements. For example, the modules illustrated in FIG. 10 may be implemented in software, hardware, or a combination thereof.

The DNP 3.0 protocol layer 131 may be the same as the physical layer described with reference to FIGS. 3 to 4. The DNP 3.0 protocol layer 131 may receive communication packets transmitted and received between the server 110 and the control device 120 and release the received communication packets. Illustratively, since the DNP 3.0 protocol layer 131 and its hierarchical structure have been described with reference to FIGS. 3 to 7, detailed description thereof is omitted.

The packet analysis module 132 may analyze and manage control information from communication packets released by the DNP 3.0 protocol layer 131. For example, the packet analysis module 132 receives the received communication packet time, the type of communication packet, the target field of the communication packet, the end field of the communication packet, the start bit of the communication packet, the end bit of the communication packet, communication Information such as packet order bits can be managed as the history table 133. The history table 133 may manage control information of communication packets.

The abnormal packet detection and classification module 134 may detect an abnormal packet among received communication packets and classify the abnormal type of the detected abnormal packet. For example, the abnormal packet detection and classification module 134 may determine whether the received communication packet is an abnormal packet based on the control information and history table 133 of the received communication packet. For example, the abnormal packet detection and classification module 134 may classify the detected abnormal packet into one of the first to fifth abnormal types based on the communication characteristics of the DNP 3.0 protocol.

The control module 135 may perform a separate security operation according to the abnormal packet detection and classification result of the abnormal packet detection and classification module 134. For example, deletion of communication packets received according to the abnormal type classification result of the abnormal packet detection and classification module 134, communication cancellation of the server 110 and the control device 120, deletion of previously received communication packets, etc. The same security operation can be performed.

As described above, according to an embodiment of the present invention, the packet monitoring device 130 manages control information of previously received communication packets as a history table, and controls the control information and history table 133 of the received communication packets. By comparing and analyzing, it is possible to classify whether the received communication packet is an abnormal packet and an abnormal type. That is, the packet monitoring device 130 can detect various attack patterns on the control system 100 by classifying the abnormal type of the abnormal packet by analyzing the control information of the received communication packet based on the communication characteristics of the DNP 3.0 protocol. have. Accordingly, a packet monitoring apparatus having improved reliability and a packet monitoring method for communication packets are provided.

11 is a flow chart showing the operation of the packet monitoring apparatus of FIG. 10. 10 and 11, in step S110, the packet monitoring apparatus 110 receives a communication packet (that is, DNP 3.0 packet). For example, the packet monitoring apparatus 110 may receive a communication packet including a DNP 3.0 packet.

In step S120, the packet monitoring apparatus 110 may analyze control information of the received communication packet (that is, DNP 3.0 packet). For example, the communication packet includes application protocol control information (APCI), a transport header (TH), and a link header (LH). The DNP 3.0 protocol physical layer 131 may extract application protocol control information (APCI), transport header (TH), and link header (LH) from the communication packet. The packet analysis module 132 may analyze the extracted application protocol control information (APCI), transport header (TH), and link header (LH).

In step S130, the packet monitoring apparatus 110 may manage the control information of the communication packet as a history table.

12 is a flowchart illustrating another operation of the packet monitoring apparatus of FIG. 10. 10 and 12, in step S210, the packet monitoring apparatus 120 may receive a communication packet. Exemplarily, the communication packet may include a DNP 3.0 packet.

In step S220, the packet monitoring apparatus 120 may analyze control information of the received communication packet.

In step S230, the packet monitoring apparatus 120 may determine whether the received communication packet is an abnormal packet based on the analyzed control information and history table. For example, the packet monitoring apparatus 120 may compare the target field, source field, and function code field of the received communication packet to determine whether the received communication packet is an abnormal packet. Alternatively, the packet monitoring apparatus 120 may determine whether the received communication packet is an abnormal packet by comparing the order bit of the received communication packet and the order bit included in the history table. In addition, the packet monitoring apparatus 120 may determine whether the received communication packet is an abnormal packet based on the control information and history table of the received communication packet. Illustratively, with reference to FIGS. 13 to 17, features of the abnormal packet and a detection method of the abnormal packet are described in more detail.

In step S240, the packet monitoring apparatus 120 may determine whether the communication packet is an abnormal packet.

According to the determination result, if the received communication packet is an abnormal packet, in step S250, the packet monitoring apparatus 120 may classify the abnormal type of the received communication packet.

In step S260, the packet monitoring apparatus 120 may perform a security operation according to the classified abnormal type.

According to the above-described embodiment of the present invention, the packet monitoring device 120 manages control information of communication packets transmitted and received between the server 110 and the control device 120 as a history table, and abnormal communication based on the history table It can detect packets and classify abnormal types. Therefore, since it is possible to detect abnormal traffic for various attack patterns, a packet monitoring apparatus having improved reliability and a packet monitoring method for communication packets are provided.

13 to 17 are diagrams for describing first to fifth types of abnormal packets, respectively. Hereinafter, with reference to FIGS. 13 to 17, abnormal types of abnormal communication packets according to an embodiment of the present invention are described. Also, with reference to FIGS. 13 to 17, a detection method of abnormal types is described. For example, it is assumed in FIG. 13 to FIG. 17 that a communication packet of a step indicated by a broken line is an abnormal communication packet, and a communication packet of a step indicated by a dotted line is a communication packet that is not transmitted or received. In addition, the packet monitoring device 130 receives communication packets transmitted and received in each step of FIGS. 13 to 17, analyzes control information of the received communication packets, and manages them as a history table 133. The packet monitoring device 130 analyzes the history table 133 and control information of communication packets to detect abnormal communication packets, and classifies the abnormal types. However, the scope of the present invention is not limited thereto.

Referring first to FIGS. 2, 10, and 13, as shown in the first section of FIG. 13, in step S1010, the server 110 transmits a request (RQ) to the control device 120. In step S1020, the control device 120 transmits a response (RP) to the server 110. In step S1030, the server 110 transmits an optional confirmation (OCF) to the control device 120.

Thereafter, in step S1040, the server 110 may transmit a response (RP) or a random response (URP) to the control device 120. The packet monitoring device 130 detects that the response (RP) or the random response (URP) of step S1040 is the first type of abnormal communication packet based on the control information of the response (RP) or random response (URP) of step S1040. Can be. Illustratively, the first type of abnormal communication packet refers to an abnormal communication packet that cannot occur in communication between the server 110 and the control device 120.

For example, in DNP 3.0 protocol communication, the server 110, which is a master device, cannot transmit a response (RP) or an arbitrary response (URP) to the control device 120. The source field (Source) of the application protocol control information (ACPI) of the response (RP) or the random response (URP) of step S1040 includes information of the server 110, and the target field (Destination) of the control device 120 Information, and the function code field (Function Code) includes a value corresponding to the response (ie, a value between 0x33 and 0xFF). That is, the packet monitoring apparatus 130 may detect that the received communication packet (that is, the communication packet of step S1040) is the first type of abnormal communication packet by analyzing the above-described application protocol control information (ACPI).

Next, as shown in the second section of FIG. 13, in step S1050, the control device 120 transmits an arbitrary response (URP) to the server 110. In step S1060, the server 110 transmits a confirmation (CF) to the control device 120.

Thereafter, in step S1070, the control device 120 may transmit a request (RQ) to the server 110. The packet monitoring apparatus 130 may detect that the request RQ of step S1070 is an abnormal communication packet of the first type based on the control information of the request RQ of step S1070. Illustratively, the first type of abnormal communication packet refers to an abnormal communication packet that cannot occur in communication between the server 110 and the control device 120.

For example, in DNP 3.0 protocol communication, the control device 120, which is a slave device, cannot transmit a request (RQ) to the server 110. The source field (Source) of the link header (LH) of the request in step S1070 includes information of the control device 120, the target field (Destination) of the link header (LH) includes information of the server 110, The function code field of the application protocol control information (ACPI) includes a value corresponding to the request (ie, a value between 0x01 and 0x32). That is, the packet monitoring apparatus 130 may detect that the received communication packet (that is, the communication packet of step S1070) is the first type of abnormal communication packet by analyzing the above-described application protocol control information (ACPI).

For example, the packet monitoring device 130 may manage control information of communication packets to be transmitted and received as a history table 133, and accordingly, may detect abnormal communication packets of the first type described above. For example, the packet monitoring device 130 may control the IP or address of the server 110 included in the TCP / IP layer of the communication packet instead of the source field and the destination field of the link header LH. The abnormal packet of the first type described above may be detected based on the IP or address of the device 120.

Next, referring to FIGS. 2, 10, and 14, as shown in the first section of FIG. 14, in step S1110, the server 110 may transmit a request (RQ) to the control device 120. have. Thereafter, in step S1120, the server 110 may transmit a request (RQ). For example, it is assumed that there is no communication packet transmitted between the server 110 and the control device 120 between steps S1110 and S1120. That is, in step S1120, the server 110 does not receive a response RP having the same sequence bit (SEQ_A) as the request (RQ) in step S1110 from the control device 120, and requests the control device 120 ( RQ).

The packet monitoring device 130 may detect that the retransmitted request (RQ) of step S1120 is a second type of abnormal communication packet. Illustratively, the second type of abnormal communication packet refers to a communication packet in a form in violation of the completion of normal communication packet transmission / reception in DNP 3.0 protocol communication.

For example, the packet monitoring device 130 is in the order of the source field (Source), the target field (Destination), and application protocol control information (ACPI) in the link header (LH) of the requests (RQ) in steps S1110 and S1120. Bit (SEQ_A) can be managed. The packet monitoring device 130 may detect that a response RP having a sequence bit equal to the sequence bit (SEQ_A) of the request RQ of step S1110 is not transmitted from the control device 120 to the server 110. have. This can be detected based on the order bit (SEQ_A) of the communication packet. That is, the packet monitoring device 130 may detect that the request (RQ) of step S1120 is a second type of abnormal packet.

Next, as shown in the second section of Figure 14, in step S1130, despite the request (RQ) is not received from the server 110, the control device 120 responds to the server 110 (RP ). The packet monitoring device 130 may detect that the response RP of step S1130 is a second type of abnormal packet. This can be detected by searching for a request corresponding to the response (RP) of step S1130 among the previously received communication packets in the history table. That is, when the response (RP) in step S1130 is a normal packet, a request (RQ) having the same order bit (SEQ_A) as the response (RP) in step S1130 and having a corresponding target field and source field exists in the history table. will be. When the corresponding request (RQ) is up, the packet monitoring device 130 may detect that the response (RP) of step S1130 is an abnormal communication packet of the second type.

As illustrated in the third section of FIG. 14, in step S1140, the control device 120 may transmit an arbitrary response (URP) to the server 110. In step S1150, the control device 120 may transmit an arbitrary response (URP) to the server 110. For example, as in the first section of FIG. 14, it is assumed that there are no communication packets transmitted between the server 110 and the control device 120 between steps S1140 and S1150. That is, in step S1140, the control device 120 does not receive an acknowledgment (CF) having the same order bit (SEQ_A) as the random response (URP) of step S1140 from the server 110, and random response to the server 110 (URP).

The packet monitoring device 130 may detect that the retransmitted request (RQ) in step S1150 is a second type of abnormal communication packet. Illustratively, the second type of abnormal communication packet refers to a communication packet in a form in violation of the completion of normal communication packet transmission / reception in DNP 3.0 protocol communication.

For example, the packet monitoring device 130 may order the source field (Source), target field (Destination), and application protocol control information (ACPI) of the link header (LH) of the random response (URP) of steps S1140 and S1150. Bit (SEQ_A) and random response bit (UNS) can be managed. The packet monitoring device 130 detects that the confirmation CF having the same sequence bit as the sequence bit (SEQ_A) of the random transmission (URP) in step S1140 has not been transmitted from the server 110 to the control device 120. Can be. For example, since the acknowledgment (CF) for the random response (URP) is set to '1', the acknowledgment (CF) from the server 110 to the control device 120 is based on this. It may be detected that it has not been transmitted. That is, the packet monitoring device 130 may detect that the random response (URP) of step S1150 is the second type of abnormal packet.

For example, the packet monitoring device 130 may further improve the identification and classification accuracy by additionally analyzing a function code field (APCI) of application protocol control information (APCI) of communication packets transmitted and received in each step of FIG. 14. Can be.

For example, the request (RQ) in step S1120 or the random response (URP) in step S1150 may not be communication packets that are retransmitted after a threshold time. That is, as described with reference to FIG. 9, after a request RQ or a random response (URP) is transmitted, a response (RP) or confirmation (CF) is received for a predetermined time (ie, timeout time) It may not be. In this case, in DNP 3.0 protocol communication, a request (RQ) or a random response (URP) is retransmitted. However, after the request (RQ) of step S1120 or the random response (URP) of step S1150 in FIG. 14 is transmitted after the request (RQ) of step S1110 or the random response (URP) of step S1150 is transmitted, before a predetermined time elapses These are transmitted communication packets. That is, the request (RQ) in step S1120 or the random response (URP) in step S1150 in FIG. 14 may be a communication packet in a form in violation of the completion of normal communication packet transmission / reception in normal DNP 3.0 protocol communication. The packet monitoring device 130 manages the transmission / reception time of transmitted and received communication packets, so that a request (RQ) in step S1120 or a random response (URP) in step S1150 is transmitted before a predetermined time after the previous communication packet is transmitted. It is possible to determine whether the request (RQ) in step S1120 or a random response (URP) in step S1150 is an abnormal communication packet of the second type.

Next, referring to FIGS. 2, 10, and 15, as shown in the first section of FIG. 15, in step S1210, the server 110 transmits a request (RQ) to the control device 120. . In step S1220, the control device 120 transmits a response (RP) to the server 110. In step S1230, the server 110 transmits an optional confirmation (OCF) to the control device 120.

Thereafter, in step S1240, the server 110 may retransmit the request RRQ to the control device 120. The packet monitoring device 130 may detect that the request (RRQ) of step S1240 is a third type of abnormal packet. Illustratively, the third type of abnormal communication packet indicates a retransmission communication packet for a communication packet for which transmission and reception is completed.

For example, the packet monitoring device 130 analyzes the control information of the request (RQ) of step S1210, the response (RP) of step S1220, and the selective confirmation (OCF) of step S1230 based on the history table 133 In step S1210 to step S1230, it is possible to determine that transmission / reception of communication packets transmitted and received is completed (that is, transmission and reception of communication packets for one request is completed). Based on this, the packet monitoring device 130 may perform the operation in step S1240. It is possible to detect that the retransmission request (RRQ) is a third type of abnormal packet. That is, since the retransmission request (RRQ) in step S1230 is a retransmission request (RRQ) having the same order bit (SEQ_A) as the communication packet for which transmission and reception is completed, the packet monitoring apparatus 130 can detect it as a third type of abnormal packet. have.

Next, as shown in the second section of FIG. 15, in step S1250, the server 110 may transmit a request (RQ) to the control device 120. For example, the request (RQ) of step S1250 may be a request that does not require retransmission and response. The packet monitoring device 130 analyzes the function code field of the application protocol control field (ACPI) of the request RQ of step S1250, so that the request RQ of step S1250 is a request that does not require retransmission and response Can be confirmed. Exemplarily, a request that does not require retransmission and response may be requests having a function code field described with reference to FIG. 8.

Thereafter, in step S1260, the server 110 may retransmit the request RRQ to the control device 120. The retransmission request (RRQ) in step S1260 may be a retransmission request for the request (RQ) in step S1250. However, if the request (RQ) of step S1250 is a request that does not require retransmission and response, the retransmission request (RRQ) of step S1260 will be a third type of abnormal packet. Based on the history table and the control information of the retransmission request (RRQ) of step S1260, the packet monitoring device 130 may detect that the third type is an abnormal packet of the retransmission request (RRQ) of step S1260.

Next, as shown in the third section of FIG. 15, in step S1270, the control device 120 may transmit an arbitrary response (URP) to the server 110. In step S1280, the server 110 may transmit a confirmation (CF) to the control device 120. Thereafter, in step S1290, the control device 120 may retransmit a random response (RURP) to the server 110. The packet monitoring device 130 may detect that the retransmission random response (RURP) of step S1280 is a third type of abnormal packet.

For example, the packet monitoring device 130 analyzes the control information of the random response (URP) of step S1270 and the confirmation (CF) of step S1280 based on the history table 133 to communicate transmitted and received in steps S1270 and S1280. It can be determined that the transmission / reception of packets is completed (that is, transmission / reception of a communication packet for one request is completed), and based on this, the packet monitoring apparatus 130 has a retransmission random response (RURP) in step S1290. It can detect that it is a type of abnormal packet. That is, since the retransmission random response (RURP) of step S1290 is a retransmission random response (RURP) having the same order bit (SEQ_A) as the communication packet for which transmission and reception is completed, the packet monitoring apparatus 130 detects it as a third type of abnormal packet can do.

For example, the packet monitoring device 130 may detect additional types of abnormal packets by further analyzing additional information (eg, a function code field or separate identification data).

Next, referring to FIGS. 2, 10, and 16, as shown in the first section of FIG. 16, in step S1310, the server 110 may transmit a request (RQ) to the control device 120 have. At this time, the order bit (SEQ_A) of the request (RQ) may have a value of 'N'. Thereafter, in step S1320, the control device 120 may transmit a response (RP) to the server 110. At this time, the response RP may have a value of 'N + i' in the sequence bit (SEQ_A) of the last response RP (that is, the end bit FIN is set to '1'). For example, 'i' indicates a value greater than 1 by the number of data fragments (FRAG) of the response (RP). In step S1330, the server 110 may transmit an optional confirmation (OCF) to the control device 120.

Thereafter, in step S1340, the server 110 may transmit a request (RQ) to the control device 120. For example, in DNP 3.0 protocol communication, the order bit of a normal request will have a value greater than 1 by the order bit of the last response. That is, if the request (RQ) of step S1340 is a normal request (RQ), it will have a sequence bit of 'N + i + 1'. However, when the request RQ of step S1340 does not have a sequence bit of 'N + i + 1', the request RQ of step S1340 is a fourth type of abnormal communication packet. The packet monitoring device 130 analyzes the information of the history table 133 and the control information of the request (RQ) of step S1340 (for example, the order bit (SEQ_A)) so that the request (RQ) of step S1340 is the fourth type It can detect that it is an abnormal packet. Illustratively, the fourth type of abnormal communication packet indicates a communication packet that violates a normal order bit in DNP 3.0 protocol communication.

Next, as shown in the second section of FIG. 16, in step S1350, the server 110 may transmit a request (RQ) to the control device 120. At this time, the request (RQ) is a request for which no response is required, and may have a sequence bit (SEQ_A) of 'N'. In step S1360, the server 110 may transmit a request (RQ) to the control device 120. At this time, as described above, when the sequence bit (SEQ_A) of the request (RQ) in step S1260 is not 'N + 1', the request (RQ) in step S1260 is a fourth type of abnormal communication packet. The packet monitoring apparatus 130 analyzes the information of the history table 133 and the control information of the request (RQ) of step S1360 (for example, the order bit (SEQ_A)), so that the request (RQ) of step S1360 is the fourth type It can detect that it is an abnormal packet.

Next, as shown in the third section of FIG. 16, as shown in the second section of FIG. 16, in step S1370, the control device 120 may transmit an arbitrary response (URP) to the server 110. have. At this time, the sequence bit (SEQ_A) of the random response (URP) may have a value of 'N'. In step S1380, the server 110 may transmit a confirmation (CF) to the control device 120. In step S1390, the control device 120 may transmit an arbitrary response (URP) to the server 110. At this time, if the random response (URP) of step S1390 is a normal communication packet in DNP 3.0 protocol communication, the value of the order bit (ie, N) of the last random response (ie, random response (URP) of step S1270) is 1 It will have the value of an order bit as large as that. However, if the random response (URP) of step S1390 does not have the value of the order bit as described above, the random response (URP) of step S1390 will be a fourth type of abnormal communication packet. The packet monitoring device 130 analyzes the information of the history table 133 and the control information of the random response (URP) of step S1390 (for example, the order bit (SEQ_A)) to provide a random response (URP) of step S1390. It can detect 4 types of abnormal packets.

Finally, referring to FIGS. 2, 10, and 17, in step S1410, the control device 120 may transmit a response RP to the server 110. Exemplarily, the response RP may include multiple data segments. That is, the response RQ includes a plurality of data segments, and the control device 120 may sequentially transmit the plurality of data segments to the server 110. At this time, the start bit FIR of the transmission header TH of the first data segment is set to '1', and the end bit FIN of the transmission header TH of the last data segment is set to '1'. .

In step S1420, the control device 120 may transmit a response (RP) to the server 110. At this time, before all of the response (RP) of step S1410 (that is, multiple data segments) are received, the start bit (FIR) of the transmission header TH of the response (RP) of step S1420 may be '1'. . In this case, the response RP of step S1420 may be a fifth type of abnormal communication packet. Illustratively, the fifth type of abnormal communication packet refers to a communication packet that causes abnormal message interpolation in DNP 3.0 protocol communication.

The packet monitoring apparatus 130 may detect whether the response RP of step S1420 is a fifth type of abnormal communication packet by analyzing the history table 133 and the transmission header TH of the response RP of step S1420. For example, in the case of a normal communication packet in multi-data segment transmission, after a communication packet with a start bit (FIR) of '1' is received from the control device 120 to the server 110, the end bit (FIN) is A communication packet of '1' is received from the control device 120 to the server 110. However, before a communication packet with an end bit (FIN) of '1' is received from the control device 120 to the server 110, a communication packet with a start bit (FIR) of '1' from the control device 120 When received by the server 110, the previously received data segments are removed from the server 110, thereby causing damage to data reliability.

The packet monitoring apparatus 130 may detect whether the response RP of step S1420 is a fifth type of abnormal communication packet by analyzing the history table 133 and the transmission header TH of the response RP of step S1420. The packet monitoring device 130 may remove an abnormal communication packet according to a detection result to prevent the removal of a previously transmitted / received data packet.

Exemplarily, a method of detecting a type of an abnormal communication packet transmitted and received between the server 110 and the control device 120 has been described with reference to FIGS. 13 to 17, but the scope of the present invention is not limited thereto. For example, the abnormal communication packet may be transmitted and received by a separate hacking device other than the server 110 and the control device 120. The packet monitoring device 130 is disposed on the communication line CL to receive communication packets transmitted and received by the above-described hacking device, and can detect and classify abnormal communication packets.

According to the above-described embodiments of the present invention, the packet monitoring device 130 may analyze control information of communication packets transmitted and received between the server 110 and the control device 120 and manage them as a history table 133. . The packet monitoring device 130 may analyze the history table 133 and control information of the received communication packet to detect an abnormal communication packet and classify the abnormal type. That is, the packet monitoring apparatus 130 according to an embodiment of the present invention provides an efficient and fast abnormal traffic detection technique than the general count method. Accordingly, a stable and reliable communication service between control systems is provided. In addition, the abnormal traffic detection method of the packet monitoring apparatus 130 according to an embodiment of the present invention efficiently detects various types of abnormal traffic that may occur on the DNP 3.0 control protocol through minimal packet analysis.

In the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the above-described embodiments, but should be determined not only by the following claims, but also by the claims and equivalents of the present invention.

100: control system
110: server
120: control device
130: packet monitoring device
131: DNP 3.0 protocol physical layer
132: packet analysis module
133: history table
134: abnormal packet detection and classification module
135: control module
ASDU: Application Service Data Unit
FRAG: data fragment
APDU: Application Protocol Data Unit
APCI: Application protocol control information
SEG: Data segment
TPDU: Transmission Protocol Data Unit
TH: transport header
FR: Data frame
LPDU: Link Protocol Data Unit

Claims (20)

In the packet monitoring method for the communication packet transmitted and received between the server and the control device,
Receiving a communication packet transmitted and received between the server and the control device;
Determining whether the received communication packet is abnormal based on a history table including control information of communication packets received earlier than the received communication packet and control information of the received communication packet; And
And performing a security operation according to the determination result,
The control information includes the function code field of the application protocol control information of the communication packet, the order bit of the application protocol control information, the source field of the link header, the target field of the link header, the start bit of the transport header, and the transport header. Contains an end bit,
The server and the control device exchange and transmit the communication packets based on Distributed Network Protocol 3.0 (DNP 3.0),
The step of determining whether the received communication packet is abnormal includes classifying the received communication packet into any one of the first to fifth types of abnormal communication packets when the received communication packet is an abnormal communication packet. ,
The abnormal communication packet of the first type indicates an abnormal communication packet that cannot occur between the server and the control device,
The second type of abnormal communication packet indicates an abnormal communication packet that is in violation of normal communication between the server and the control device,
The abnormal communication packet of the third type indicates an abnormal communication packet that is retransmitted with respect to the communication packet that has been transmitted and received between the server and the control device,
The fourth type of abnormal communication packet indicates an abnormal communication packet that violates a normal sequence bit between the server and the control device,
The fifth type of abnormal communication packet is a packet monitoring method indicating an abnormal communication packet that causes an abnormal message interpolation between the server and the control device. delete delete delete According to claim 1,
Classifying the received communication packet into any one of the first to fifth types of abnormal communication packets,
And classifying the received communication packet into the first type of abnormal communication packet based on a source code field of the link header of the received communication packet and a function code field of the application protocol control information. The method of claim 5,
Classifying the received communication packet into the abnormal communication packet of the first type,
The source field of the link header of the received communication packet points to the server, the function code field has a value corresponding to a response or a random response, or the source field of the link header of the received communication packet And pointing to the control device and classifying the received communication packet into the abnormal communication packet of the first type when the function code field has a value corresponding to the request. According to claim 1,
Classifying the received communication packet into any one of the first to fifth types of abnormal communication packets,
And classifying the received communication packet into the second type of abnormal communication packet based on sequence bits and received time of the previously received communication packets included in the history table. The method of claim 7,
Classifying the received communication packet into the abnormal communication packet of the second type,
If a communication packet having the same order bit as the received communication packet among the previously received communication packets included in the history table is received before a predetermined time, the received communication packet is abnormal in the second type. Packet monitoring method comprising the step of classifying the communication packet. According to claim 1,
Classifying the received communication packet into any one of the first to fifth types of abnormal communication packets,
And classifying the received communication packet into the abnormal communication packet of the third type according to whether transmission / reception of communication packets corresponding to the received communication packet among the previously received communication packets is completed. The method of claim 9,
Classifying the received communication packet into any one of the first to fifth types of abnormal communication packets,
When transmission / reception of a communication packet having the same order bit as the received communication packet among the previously received communication packets is completed based on the history table, the received communication packet is classified as the abnormal communication packet of the third type. Packet monitoring method comprising the step of. According to claim 1,
Classifying the received communication packet into any one of the first to fifth types of abnormal communication packets,
And classifying the received communication packet into the fourth type of abnormal communication packet based on order bits of the previously received communication packets included in the history table. The method of claim 11,
The step of classifying the received communication packet into the abnormal communication packet of the fourth type,
If the order bit of the received communication packet is different from the order bit according to the distributed network protocol 3.0 based on the order bits of the previously received communication packets included in the history table, the order bit of the received communication packet is And classifying the fourth type of abnormal communication packet. According to claim 1,
Classifying the received communication packet into any one of the first to fifth types of abnormal communication packets,
And classifying the received communication packet into the fifth type of abnormal communication packet based on start bits and end bits of a link header of the previously received communication packets included in the history table. . The method of claim 13,
Classifying the received communication packet into the abnormal communication packet of the fifth type,
When the communication packet with the start bit '1' is received before the communication packet with the end bit '1' transmitted from the control device to the server, the received communication packet is the fifth type. Packet monitoring method comprising the step of classifying as an abnormal communication packet. A distributed network protocol physical layer that receives communication packets transmitted and received between a server and a control device, and releases the received communication packets to generate control information and messages;
A communication packet analysis module that manages the control information of the received communication packet;
A history table for storing control information of the received communication packet and control information of a communication packet received earlier than the received communication packet; And
An abnormal packet detection and classification module for determining whether the received communication packet is an abnormal communication packet based on the control information of the previously received communication packet and the control information of the received communication packet stored in the history table; And
A control module for performing a security operation according to the result of the abnormal packet detection and classification module determination,
The control information includes a function code field of the application protocol control information of the communication packet, an order bit of the application protocol control information, a source field of a link header, a target field of the link header, a start bit of the transport header, and the transport header. Contains an end bit,
The server and the control device transmit and receive the communication packet based on Distributed Network Protocol 3.0 (DNP 3.0; Distributed Network Protocol 3.0),
The distributed network protocol physical layer
A DNP 3.0 data link layer extracting the link header from the received communication packet;
A DNP 3.0 transport layer that extracts the transport header from the received communication packet; And
And a DNP 3.0 application layer that extracts the application protocol control information from the received communication packet. delete delete The method of claim 15,
The server and the control device communicate with each other through a communication line based on the TCP / IP protocol,
The distributed network protocol physical layer further includes a communication protocol layer that extracts an Ethernet header, an IP header, and a TCP header from the received communication packet. The method of claim 15,
The abnormal packet detection and classification module may use the first to fifth types of abnormal communication of the received communication packet based on control information of the previously received communication packet and control information of the received communication packet stored in the history table. Packet monitoring device to classify any one of the packets. The method of claim 19,
The first type of abnormal communication packet refers to a communication packet that cannot occur between the server and the control device, and the second type of abnormal communication packet refers to a communication packet that violates normal communication between the server and the control device. The third type of abnormal communication packet indicates a retransmission communication packet for a communication packet that has been transmitted and received between the server and the control device, and the fourth type of abnormal communication packet is normal between the server and the control device. A packet monitoring device indicating a communication packet that violates a sequence bit, and the fifth type of abnormal communication packet indicates a communication packet that causes abnormal message interpolation between the server and the control device.

Images