CN110691097A

CN110691097A - Industrial honey pot system based on hpfeeds protocol and working method thereof

Info

Publication number: CN110691097A
Application number: CN201910992216.3A
Authority: CN
Inventors: 石爱业; 陈武
Original assignee: Hohai University HHU
Current assignee: Hohai University HHU
Priority date: 2019-10-18
Filing date: 2019-10-18
Publication date: 2020-01-14

Abstract

The invention discloses an industrial honeypot control system based on an hpfeeds protocol, which comprises a data capture module and a data remote transmission module, wherein the data remote transmission module receives a response sent by the data capture module, and the data capture module comprises session management, protocol interaction, template configuration and log record; the data remote transmission module comprises a remote client, a remote server and a remote database, wherein the remote database is used for storing identity information, the remote server calls the remote database information to verify the remote client, and the remote client sends and receives the information of the remote server. The invention also discloses a working method of the industrial control honeypot based on the hpfeeds protocol. The industrial control honeypot system based on the hpfeeds protocol and the working method thereof can record and store attack information, restrain attack activities of an attacker and realize active defense.

Description

Industrial honey pot system based on hpfeeds protocol and working method thereof

Technical Field

The invention particularly relates to an industrial control honeypot system based on an hpfeeds protocol and a working method thereof, belonging to the technical field of industrial control safety.

Background

With the continuous integration of informatization and industrialization, more and more industrial control systems are accessed to the internet. In addition, the networked wave tide also integrates the innovative technologies such as an embedded technology and a wireless technology into the industrial control system, thereby expanding the development space of the industrial control system and bringing new development opportunities. Meanwhile, the method also brings unprecedented safety problems to the industrial control system.

The traditional security protection technologies include firewalls, intrusion detection and the like, and belong to passive defense technologies. In a network, the games of the attacking and defending parties are seriously asymmetric, and the passive defense cannot effectively cope with the attack. First, the location of the attacking and defending parties is different. The defense system is generally exposed in the network in public, while the attacker acts in the dark. Secondly, the work load of the attacking and defending parties is different. The attacker only needs to find one vulnerability of the system to attack the system, and the defender needs to protect the system comprehensively. Finally, even if the system prevents the attack, the attack activity of the attacker is not restricted, and the attacker can continue to attack other systems.

Today's industrial honeypot solutions can be broadly classified as simulating PLCs, using real PLC equipment that contains typical vulnerabilities. Analog PLCs are also classified into business simulation and protocol simulation. The honeypot projects of companies such as Cisco, digital bonds, trend technology and the like are mainly used for simulating industrial control business and realizing the service of simulating PLC. And the high demasa Naruoka, Charles Scott and the like simulate the industrial control service to realize PLC simulation. Particularly, Chunhui Zhao simulates PLC from two aspects of man-machine interface and protocol simulation, and Robert Jaromin is based on VMware, and Robert M.Jaromin realizes simulating PLC based on Gumstix single-chip microcomputer. The protocol simulation aspect is mainly that Feng Xiao simulates a high-interaction honeypot based on an S7comm protocol, and Stephan Lau simulates the high-interaction honeypot of an S7-300PLC by modifying a TCP/IP stack.

In general, in the industrial control honeypot scheme in the prior art, the real PLC honeypot scheme is rarely used, and the simulation PLC is the mainstream scheme for honeypot implementation, but mainly focuses on the aspect of service simulation, protocol simulation is less, and most of the protocol simulation schemes cannot ensure data security.

Disclosure of Invention

The invention aims to solve the technical problems of overcoming the asymmetry of the attack and defense game in the prior art and overcoming the defects of the traditional safety protection technology, and provides an industrial honey pot control system based on the hpfeeds protocol and a working method thereof, wherein the system can record and store attack information, restrain the attack activity of an attacker and realize active defense.

In order to solve the technical problems, the technical scheme adopted by the invention is as follows:

the system comprises a data capture module and a data remote transmission module, wherein the data remote transmission module receives a response sent by the data capture module, the data capture module comprises session management, protocol interaction, template configuration and log record, the protocol interaction is used for capturing attack data from two aspects of an attack IP and a protocol message by virtue of a Modbus protocol and an S7comm protocol, the session management establishes a session example for each attack event and is used for distinguishing each attack event and storing the attack events by using an event queue, the log record is used for recording the attack IP, a request message and response information generated according to the request, and the template configuration is used for configuring simulated equipment information and different protocol return information; the data remote transmission module comprises a remote client, a remote server and a remote database, wherein the remote database is used for storing identity information, the remote server calls remote database information to verify the remote client, and the remote client sends and receives the information of the remote server.

A working method of an industrial control honey pot based on an hpfeeds protocol comprises the following steps:

s1: the protocol interaction adopts Modbus and S7comm protocols to start monitoring on the 102 port and the 502 port;

s2: when an attacker utilizes a scanning tool to connect and detect the ports, the corresponding ports monitor the connection request and capture an attack IP, if the attack is the initial attack of the attacker, session management establishes a session for marking the whole session process, and if not, the process directly enters S3;

s3: the protocol interaction captures a detection request of an attacker to the industrial control equipment, the protocol server analyzes the message content and generates a corresponding response according to the analysis content, wherein if the analysis request is related to the equipment information, the template configuration is used for scheduling a template and generating an equipment information response;

s4: logging, adding the captured request and the generated response into an event queue;

s5: storing identity information in a remote database, wherein the identity information comprises a user name, a password, and subscription and release channels;

s6: the remote server side calls remote database information to carry out identity verification on the remote client side;

s7: the remote client publisher sends information to the remote server, and the remote client subscriber receives the information of the remote server.

The Modbus protocol in S1 specifically includes the following steps:

s11: the Modbus server obtains a request ADU, and extracts an MBAP message header of the request ADU;

s12: judging whether the MBAP message header meets the requirements, namely whether the protocol type is equal to 0 and the length field is equal to the number of bytes of the data behind the MBAP message header, if not, directly discarding the data and waiting for receiving again;

s13: if the requirement of the MBAP message is met, extracting functional codes and data fields in the request PDU;

s14: judging the abnormality according to the functional code and the data field;

s15: and if no abnormity exists, the Modbus server generates a normal response message and sends the response to the client.

S14 specifically includes the following steps:

s141: judging whether the request function code is valid, wherein the request function code comprises whether the function code is in a normal function code range or not and whether the Modbus server has the function code or not;

s142: judging whether the request quantity is effective or not;

s143: judging whether the initial address and the final address are valid;

s144: and judging whether the request is effectively finished, if one step is invalid, directly returning a corresponding exception code, and then generating an exception response according to the exception code and the function code.

The S7comm protocol in S1 specifically includes the following steps:

s16: s7, the comm server starts a monitoring program and waits for a request of connecting a 102 port;

s17: after receiving the data, carrying out protocol first check: checking the validity of a TPKT header and a COTP message, wherein the TPKT header checks whether the content comprises a packet length field of the whole packet byte number, a version field of the packet byte number is 3 and a reserved field of the packet byte number is 0; the COTP message checks whether the content comprises a len field with the length from type to payload field and whether the type is 0xe0, namely the request connection type; if the verification is successful, the server sends a COTP connection confirmation packet, and if the connection is successful, the COTP connection is established;

s18: and S7, the comm server receives the data again and carries out second protocol check: firstly, judging whether a COTP packet is a functional packet, namely whether a type field is 0xf0, if so, determining that a trailer field of the current COTP packet is an S7 protocol message; then, judging whether the S7type field is 0x01, namely whether the field is a request PDU, and whether the code subfield in the paramters field is 0xf0, namely whether the field is an S7 connection request, if the field is an S7 connection request packet, returning to an S7 connection response, and if the connection is successful, establishing an S7 connection;

s19: after all connections are established successfully, the communication can be circulated, but each time the received data is checked for a third time, mainly to check whether the type field of the COTP packet is 0xf0, and if not, the procedure returns to the beginning to wait for the connection request again.

S6 specifically includes the following steps:

s61: the remote server side starts and initializes the connection with the remote database, opens a monitoring service port and monitors the connection from the remote client side;

s62: after inputting correct user information, the remote client creates an hpfeeds object according to the information and establishes connection with the remote server;

s63: the remote server monitors a connection request from the remote client, generates a random number rand in real time according to the request, and immediately sends an INFO type message including the random number, the server name and other information to the remote client;

s64: after receiving the INFO type message, the remote client extracts the random number rand in the message, and combines the random number rand with the secret of the user through a hash digest algorithm to obtain rhash;

s65: the remote client sends AUTH type information to the remote server, wherein the AUTH type information comprises information such as a user name, a hash value and the like, and the information is used for verifying the identity of a user;

s66: after receiving the AUTH type message at the remote service end, the remote service end extracts the rhash therein;

s67: and the remote server side takes out the user information from the remote database according to the user name, and performs the same hash summarization algorithm on the previously generated rand and the secret of the user to finally obtain the akhash, if the akhash is equal to the rhash, the authentication is successful, otherwise, the remote server side is disconnected from the remote client side and returns to the state waiting for connection again.

S7 specifically includes the following steps:

s71: after the user identity authentication is successful, the remote service end is in a waiting receiving state.

S72: a subscriber sends a SUB type message to a remote server, wherein the message comprises a subscriber user name and a subscription channel;

s73: after receiving the SUB type message, the remote server checks whether the current user name is the user name in the previous authentication stage, and judges whether the current message is the SUB type or the PUB type, if so, the server extracts the subscription channel information, and corresponds the subscription channel to the subscriber, and if so, the server extracts the release channel c and the release data payload;

s74: after the identity of the publisher is successfully verified, a PUB type message is sent to a remote server, wherein the PUB type message comprises a publisher user name, a publishing channel and publishing data;

s75: after the remote server receives the request, the message is judged to be of a PUB type, after the publisher sends the data, the publisher continues to wait for receiving the data of the server, if the server does not send an error message to the publisher, the publisher directly closes the connection with the server, otherwise, the publisher is caused to be abnormal;

s76: the remote server checks whether the subscription channel is the same as the release channel, if so, the PUB type message is recombined and sent to the remote client subscriber, otherwise, the request is waited again;

s77: after a remote client subscriber receives published data sent by a remote server, acquiring a message type and the published data, and judging whether the message is of an ERR type or a PUB type: and if the PUB type is adopted, the remote client subscriber stores the data sent by the remote server, keeps the connection with the remote server and continues to receive the data, otherwise, the connection with the remote server is disconnected.

The invention has the beneficial effects that: the industrial control honeypot system based on the hpfeeds protocol and the working method thereof realize the simulation of the Modbus protocol and the S7comm protocol, integrate the hpfeeds protocol, are used for realizing the safe storage of data, solve the defects that the traditional passive defense cannot defend unknown attacks and the like, and can ensure the data safety.

Drawings

FIG. 1 is a schematic diagram of the structural industrial honey pot functional module of the present invention;

FIG. 2 is a schematic diagram of the operation of the structural data capture module of the present invention;

FIG. 3 is a schematic diagram illustrating a Modbus protocol analysis in the structured data capture module according to the present invention;

FIG. 4 is a schematic diagram illustrating the S7comm protocol analysis in the structural data capture module according to the present invention;

FIG. 5 is a schematic diagram of a structural data remote transfer module according to the present invention;

FIG. 6 is a schematic diagram of the structural data remote transport module authentication phase of the present invention;

FIG. 7 is a diagram illustrating a normal publish/subscribe phase of a structured data remote transport module according to the present invention;

FIG. 8 is a schematic diagram of the structural honeypot response process of the present invention.

Detailed Description

The present invention is further described with reference to the accompanying drawings, and the following examples are only for clearly illustrating the technical solutions of the present invention, and should not be taken as limiting the scope of the present invention.

Through the data opened by Censys in the last two years, the number of Modbus and S7comm protocol devices is found to increase rapidly. Therefore, the invention respectively realizes the simulation of the Modbus protocol and the S7comm protocol, integrates the hpfeeds protocol and is used for realizing the safe storage of data.

The main working principle of the invention is as follows: when an attacker uses a scanning tool to initiate a detection behavior on the honeypot, the honeypot data capture module monitors the connection of the corresponding port, selects a Modbus server or an S7comm server according to the port to analyze the detection request, and generates response information according to the analysis result. Then, the honeypot records the analyzed information and the responded information in a local mode and a remote mode, wherein the attack data is recorded by using a local database in the local mode, and the attack data is issued by using a data remote transmission module in the remote mode. And finally, the attack data is transferred by the remote server and reaches the data remote transmission module subscriber, and the specific technical scheme is as follows.

As shown in FIG. 1, the system for industrial control of honeypots based on the hpfeeds protocol comprises a data capture module and a data remote transmission module. The data capturing module comprises four parts of session management, protocol interaction, template configuration, log recording and the like. And protocol interaction, which is mainly used for capturing attack data of the Modbus and the S7comm protocol from two aspects of an attack IP and a protocol message. And session management, namely creating a session instance for each attack event, distinguishing each attack event, and storing the attack events by using an event queue. And the log recording function is used for recording information such as an attack IP, a request message, a response generated according to the request and the like. And (4) template configuration, namely configuring simulation equipment information and return information of different protocols. In addition, the data remote transmission module comprises a remote client, a remote server and a remote database, and mainly utilizes an hpfeeds protocol to remotely store attack data so as to realize real-time transmission and sharing of the data.

As shown in fig. 2, the data capture module of the present invention has the following steps:

step 1: the protocol interaction portion of the data capture module initiates snooping of the 102 port, 502 port.

Step 2: when an attacker utilizes a scanning tool to connect and detect the ports, the corresponding ports monitor the connection request and capture the attack IP. If the attack is the initial attack of the attacker, session management establishes a session for marking the whole session process. If not, directly entering the step 3.

And step 3: the protocol interaction captures the detection request of an attacker to the industrial control equipment, and the protocol server analyzes the message content and generates a corresponding response according to the analysis content. And if the analysis request is related to the equipment information, scheduling the template and generating an equipment information response.

And 4, step 4: logging, adding the captured request and the generated response to an event queue.

As shown in fig. 3, the diagram is a Modbus protocol analysis module in the data capture module, and Modbus communication is implemented by Modbus frame messages including MBAP message headers and PDUs, that is, requests ADUs. The MBAP message header is a message header which is specially used for identifying a Modbus application data unit on a TCP/IP. The PDU consists of two parts, a function code and data, and the function code determines the main function of the message.

Step 1: and the Modbus server acquires the request ADU and extracts the MBAP message header of the request ADU.

Step 2: and judging whether the MBAP message header meets the requirement, namely whether the protocol type is equal to 0 and whether the length field is equal to the number of bytes of data behind the protocol type. And if the MBAP message requirement is not met, directly discarding the data and waiting for receiving again.

And step 3: and if the request accords with the MBAP message requirement, extracting the functional code and the data field in the request PDU.

And 4, step 4: and judging the abnormity according to the function code and the data field. The abnormality determination is mainly divided into four steps, and the specific content is as follows.

Step 4.1: and judging whether the request function code is valid, wherein the request function code comprises whether the function code is in a normal function code range, whether the Modbus server has the function code and the like.

Step 4.2: it is determined whether the number of requests is valid.

Step 4.3: it is determined whether the start address and the final address are valid.

Step 4.4: and judging whether the request is effectively finished. And as long as one step is invalid, directly returning the corresponding exception code, and then generating an exception response according to the exception code and the function code.

And 5: and if no abnormity exists, the Modbus server generates a normal response message and sends the response to the client.

As shown in fig. 4, the S7comm protocol parsing module in the data capture module. The straight line with an arrow in the figure has both a solid line and a dotted line, and the dotted line portion represents the server reception client connection process, and the solid line portion represents the server verification data process. And if errors occur in the process of verifying the data, recording the errors and waiting for connection again. The data capturing module S7comm protocol analyzing module of the invention has the following implementation steps:

step 1: the S7comm server starts a monitor program and waits for a request for connecting the 102 port.

Step 2: after receiving data, carrying out protocol first check, and mainly checking validity of a TPKT header and a COTP message. The TPKT header checks whether the contents include a packet length field as the number of bytes of the entire packet, a version field as 3, and a reserved field as 0. The COTP message checks whether the content includes a len field as a type-to-payload field length, and whether the type is 0xe0, i.e., a request connection type. If the check is successful, the server sends a COTP connection acknowledgement packet (type 0xd 0). If the connection is successful, a COTP connection will be established.

And step 3: and S7, the comm server receives the data again and carries out second protocol check. First, it is determined whether the COTP packet is a function packet, i.e., whether the type field is 0xf 0. If the current COTP packet is a COTP functional packet, the trailer field of the current COTP packet is the S7 protocol message. Next, it is determined whether the S7type field is 0x01, i.e., a request PDU, and the code subfield in the paramters field is 0xf0, i.e., an S7 connection request. If the connection request packet is the S7 connection request packet, an S7 connection response is returned. If the connection is successful, a connection will be established S7.

And 4, step 4: after all connections are established successfully, the communication can be cycled. But each time the data is received, a third check is made, mainly to see if the COTP packet type field is 0xf 0. If not, returning to the beginning of the program and waiting for the connection request again.

As shown in fig. 5, the remote clients are divided into two types, namely a publisher and a subscriber, and the honeypot host serves as the publisher of the remote client and is responsible for transmitting the captured data. The data remote transmission module is realized in two stages, including an identity verification stage and a normal publishing/subscribing stage. User authentication, whether a publisher or a subscriber, is a necessary process for each user. The subscriber and publisher identity verification phases are the same, while the normal publish/subscribe phase is different. Therefore, the authentication phase is the authentication between the remote server and the remote client, and the normal publish/subscribe phase is the publish/subscribe activity between the remote server, the subscriber and the publisher. In the following process, the default server is a remote server, and the client is a remote client.

As shown in fig. 6 and 7, the data remote transmission module of the present invention has the following steps:

step 1: identity information is stored in an identity database, and comprises a user name, a password, and channels for subscription and release.

Step 2: and the data remote transmission module is realized in the authentication stage.

Step 2.1: the server side starts and initializes the connection with the identity database, opens a monitoring service port and monitors the connection from the client side.

Step 2.2: after inputting correct user information, the client creates an hpfeeds object according to the information and establishes connection with the server.

Step 2.3: the server monitors a connection request from the client, generates a random number rand in real time according to the request, and immediately sends an INFO type message to the client, wherein the information mainly comprises the random number, the name of the server and the like.

Step 2.4: after the client receives the INFO type message, the client extracts the random number rand in the message, and combines the random number rand with the secret of the user through a hash digest algorithm to obtain rhash.

Step 2.5: the client sends an AUTH type message to the server, mainly comprising information such as a user name, a hash value and the like, wherein the AUTH type message is used for verifying the identity of the user.

Step 2.6: after the server receives the AUTH type message, the server extracts the rhash therein.

Step 2.7: the server side takes out the user information from the database according to the user name, and performs the same hash digest algorithm on the previously generated rand and the secret of the user to finally obtain the akhash. If the akhash is equal to the rhash, the authentication is successful, otherwise, the server side is disconnected from the client side and returns to the state of waiting for connection again.

And step 3: the normal subscription/publication phase is implemented. The following process, whether it is a client or a server, is performed after the authentication phase is successful, and the client is divided into a subscriber and a publisher at this phase.

Step 3.1: after the user identity authentication is successful, the server side is in a waiting receiving state.

Step 3.2: the subscriber sends a SUB type message to the server, and the message mainly comprises a subscriber user name and a subscription channel.

Step 3.3: after the server receives the SUB type message, the server checks whether the current user name is the user name in the previous authentication stage, and judges whether the current message is the SUB type or the PUB type. If the message is the SUB type message, the server side extracts the subscription channel information and corresponds the subscription channel with the subscriber. And if the PUB type message is generated, the server side extracts the publishing channel c and the publishing data payload.

Step 3.4: and when the identity of the publisher is successfully verified, sending a PUB type message to the server, wherein the PUB type message mainly comprises a publisher user name, a publication channel and publication data.

Step 3.5: after the server receives the request, the message is concluded to be of the PUB type. After the data is sent by the publisher, the publisher also continues to wait for receiving the server data. If the server side does not send error messages to the publisher, the publisher directly closes the connection with the server side, otherwise, the publisher is caused to be abnormal.

Step 3.6: the server checks whether the subscription channel is the same as the publishing channel. If the channels are the same, the PUB type messages are recombined and sent to the subscriber, otherwise, the request is waited again.

Step 3.7: after the subscriber receives the published data sent by the server, the message type and the published data are obtained, and whether the message is of an ERR type or a PUB type is judged. And if the PUB type is adopted, the subscriber stores the data sent by the server, keeps the connection with the server and continues to receive the data, otherwise, the connection with the server is disconnected.

As shown in FIG. 8, the honeypot response process of the present invention is implemented as follows: the honeypot response process is carried out around the honeypot main program, and all the modules are matched with each other to finish the honeypot capture attack work. When the main program of the honeypot finds the connection detection activity, a session is generated. Session management adds sessions to the event queue and provides an interface for different protocol services to get packets. The honeypot main program calls different protocol services according to different ports, each protocol service has a thread pool, and when a corresponding call is inquired, a thread is created to process the call. The response processing processes the data sent by the protocol interaction and returns the processed data to the protocol interaction part. Both session management and response processing log the attack behavior.

The above description is only of the preferred embodiments of the present invention, and it should be noted that: it will be apparent to those skilled in the art that various modifications and adaptations can be made without departing from the principles of the invention and these are intended to be within the scope of the invention.

Claims

1. The utility model provides a system of industry control honeypot based on hpfeeds agreement which characterized in that: the system comprises a data capturing module and a data remote transmission module, wherein the data remote transmission module receives a response sent by the data capturing module, the data capturing module comprises session management, protocol interaction, template configuration and log records, the protocol interaction is used for capturing attack data from two aspects of an attack IP and a protocol message by a Modbus protocol and an S7comm protocol, the session management establishes a session example for each attack event and is used for distinguishing each attack event and storing the attack events by using an event queue, the log records are used for recording the attack IP, a request message and response information generated according to a request, and the template configuration is used for configuring simulation equipment information and different protocol return information; the data remote transmission module comprises a remote client, a remote server and a remote database, wherein the remote database is used for storing identity information, the remote server calls remote database information to verify the remote client, and the remote client sends and receives the information of the remote server.

2. A working method of an industrial control honey pot based on an hpfeeds protocol is characterized in that: the method comprises the following steps:

3. The working method of the industrial control honeypot based on the hpfeeds protocol as claimed in claim 2, characterized in that: the Modbus protocol in S1 specifically includes the following steps:

4. The working method of the industrial control honeypot based on the hpfeeds protocol as claimed in claim 3, characterized in that: s14 specifically includes the following steps:

s142: judging whether the request quantity is effective or not;

s143: judging whether the initial address and the final address are valid;

5. The working method of the industrial control honeypot based on the hpfeeds protocol as claimed in claim 2, characterized in that: the S7comm protocol in S1 specifically includes the following steps:

6. The working method of the industrial control honeypot based on the hpfeeds protocol as claimed in claim 2, characterized in that: s6 specifically includes the following steps:

7. The working method of the industrial control honeypot based on the hpfeeds protocol as claimed in claim 2, characterized in that: s7 specifically includes the following steps: