A WEB honeypot background management system and method based on Docker

Abstract

The present invention discloses a WEB honeypot background management system and method based on Docker. The management system comprises a user login unit, a container creation unit, a container management unit, a user management unit and a log collection unit. The method adopts an automation concept to complete most of the processes of honeypot deployment, that is, when deploying the honeypot, the administrator and the user only need to input the files configured by themselves at the front end and click the corresponding button, and the back end can automatically execute the corresponding operation process: decompress the package → execute the docker command in the folder to form a docker image → when starting the honeypot, the back end executes the corresponding docker command to realize that the honeypot is mapped out on a port to lure hackers.

Description

Technical Field

[0001] The present invention relates to the technical field of network data security, and in particular to a WEB honeypot background management system based on Docker. Background Art

[0002] In the era of network informatization, network security issues are becoming increasingly serious. Traditional passive defense technology is inadequate in the face of increasingly severe and complex dangers. The introduction of active defense technology is intended to make up for some of the corresponding shortcomings. Honeypot technology, as a typical representative of active defense technology, publishes pre-designed false business information to attract attackers to attack the deployed network traps, so that attackers spend a lot of time and energy on the false target system, thereby delaying the attack on the real target, and ultimately effectively protecting the real target system.

[0003] Honeypot technology has developed rapidly in recent years, and various types of honeypots have gradually been formed. According to the degree of interaction, they can be divided into low-interaction, medium-interaction and high-interaction honeypots of different levels. According to the purpose of the honeypot, they can be divided into WEB business honeypots, SSH application honeypots, and host-type honeypots. Honeypots can be as small as a word document-sized honeymark or as large as a distributed honey farm that supports traffic monitoring and forwarding.

[0004] At present, most honeypot systems use a single template to generate honeypot applications. The honeypot style is fixed and single, with low interactivity, and it is easy for attackers to identify it as a honeypot page. Some honeypots are physical honeypots, which require expensive hardware support when deployed, and professional support is required for operation and maintenance. More often, honeypot deployment is just to confuse external attackers, and they will not take the initiative to use honeypot access traces to take corresponding measures against attackers. Since this application can realize the one-click deployment function of the honeypot, the administrator does not need to enter the backend server to use the sh command to deploy the honeypot, which greatly reduces the workload of the administrator. Therefore, the administrator can easily configure multiple honeypot style options for users through various docker images in the front-end interface, which is convenient for management. Users can deploy their own honeypots according to the images configured by the administrator in the visual interface, or they can configure their own honeypots like the administrator, but the administrator has absolute management rights over the user's honeypot to prevent users from maliciously configuring honeypots.

[0005] In summary, the existing honeypot system still has some shortcomings in actual use and there is room for improvement. Summary of the invention

[0006] The purpose of the present invention is to provide a WEB honeypot background management system and method based on Docker, so as to solve the above-mentioned problems existing in the prior art.

[0007] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0008] A Docker-based WEB honeypot background management system, including a user login unit, a container creation unit, a container management unit, a user management unit and a log collection unit;

[0009] The user login unit is used to confirm the identity information of the login person, find the corresponding login person information in the database, and grant the user's operation authority (including the operation of hiding the highest authority from ordinary users) according to the preset identity information of the person (administrator or ordinary user);

[0010] The container creation unit is used to create a specified honeypot container in the system according to the user's operation instruction after the user logs in;

[0011] The container management unit is used to perform corresponding operations in the honeypot container created in the system according to the user's operation instructions after the user logs in;

[0012] The user management unit is used to manage user information in the database according to the user's operation authority after the user logs in;

[0013] The log collection unit is used to store the operation status log and the access log of the honeypot container during the operation of the system, so as to generate a corresponding log report.

[0014] Preferably, the user's operating authority includes administrator authority and common user authority. If the user has administrator authority, the user has authority to enter the user management unit, and the user management unit is directly loaded after logging in to perform corresponding user management operations. If the user has common user authority, the user has authority to create and manage honeypot containers, and the container creation unit and / or container management unit is loaded after logging in to the system to perform corresponding container creation operations and / or container management operations.

[0015] Preferably, the ordinary user loads the container management unit after logging into the system and performs corresponding container management operations, specifically including:

[0016] Ordinary users can view the information of the honeypot containers running in the current system, including the container ID, name, URL, status and corresponding operation buttons. Users can start, pause and delete the honeypot containers according to actual operation needs. The success or failure of the corresponding operation will be fed back through a pop-up window.

[0017] Preferably, the ordinary user loads the container creation unit after logging into the system and performs corresponding container creation operations, specifically including: the ordinary user can create a honeypot container according to the deployment needs to protect the website originally deployed by the user, that is, deploy the honeypot content into a web page that is the same as the own website or deploy it into an administrator backend web page, including the following steps:

[0018] 1) The user searches for an image with a web environment (with PHP7.0 and Apache) in the Docker image station, and writes its name at the beginning of the Dockerfile file (in the form of FROM image name); a homepage (index.html, a file pre-edited in HTML language) like the administrator login interface is copied to the Apache display directory (path: \var\www\html) in the Dockerfile file using the COPY function to implement the deployment of this honeypot. The format is: COPYindex.html\var\www\html. You can also replace index.html with a folder. It is worth noting that the folder and Dockerfile need to be placed in the same folder and packaged into a compressed file package.

[0019] 2) Upload the Dockerfile compressed file package to the container creation unit. The compressed package is transferred to the upload directory of the server and decompressed. Set the basic information of the container and click the create button to create the container. The process executed by the backend is: go to the folder where the decompression is completed, and according to the image name set by the front end (docker uses the image name as the keyword), use the docker build name. (Note: this command is followed by a space and an English period symbol) command to create a docker image with the corresponding name of the compressed package (excluding the .zip suffix). The image is downloaded according to the "FROM image name" in the Dockerfile file;

[0020] 3) The background unzips the compressed file according to the uploaded compressed file package and the basic information of the container set by the front end. According to the Dockerfile command, this command is the docker up command. According to the mapping port set by the front end, the port mapping option in the docker command is used to map the 80 port exposed by the honeypot to an idle port on the host, and the container is automatically deployed.

[0021] Preferably, the basic container information in step 2) includes the container name and port information of internal and external mappings.

[0022] Preferably, the user login unit obtains different front-end echoes according to the content of the account and password input. For example, if the verification code is not entered, if an incorrect account and password are entered, "account and password are incorrect" will be echoed; if the correct account and password are entered, "verification code is incorrect" will be echoed; at the same time, verifying the account and password requires calling the database for verification, and the workload is slightly more than the server resources consumed by only judging the verification code first.

[0023] Determining whether the user has logged in successfully includes the following steps:

[0024] First, determine whether the verification code entered by the user is correct. If it is incorrect, a pop-up window will pop up to prompt that the verification code is wrong, and the login interface will be directly exited; if the verification code is correct, it will directly jump to the account login interface to verify the account and password;

[0025] Enter the account number and password, and the user login unit determines whether the user's account number and the corresponding password are correct. When the account number and password are correct, the user authority is directly determined and the user is redirected to the corresponding operation interface; otherwise, a pop-up window prompts that the user name or password is incorrect and the user logs out of the login interface.

[0026] Preferably, the log collection unit records the operation status log during the system operation process, including the success or failure information of all user logins, container creation, container management and user management processes, stores all operation status logs in the database, and writes True or False in the corresponding success or failure fields for distinction.

[0027] Preferably, the log collection unit records the honeypot container access log during the system operation process, specifically including: screening the log of the honeypot container, filtering out the access log of the honeypot container, counting the number of IP addresses of the request sources, and sorting them, comparing the number of IP addresses and the access frequency and parameter content of the same IP address, and if an abnormality is found, determining that the access is an attack, and forming an attack log report, so that the user can take corresponding disposal measures according to the attack behavior.

[0028] More preferably, the abnormality includes that the account and password in the passed parameter content have a certain pattern, then it is determined to be a behavior of cracking the account and password, and the incoming GET request contains access to admin, but the discovery of this abnormality can only be analyzed and verified manually.

[0029] Another object of the present invention is to provide a WEB honeypot background management method based on Docker, comprising the following steps:

[0030] S1, the user selects a role through the login unit to log in to the honeypot background management system, and determines the user role authority. If it is an administrator role, the management interface including the user management unit is loaded, and step S2 is performed. Otherwise, if it is a common user role, the honeypot management unit is loaded, and step S3 is performed;

[0031] S2, the management user checks the existing user information in the current database, and performs addition, deletion, modification and query operations on the user information as needed. The success or failure of the corresponding operation will be fed back through a pop-up window, and then proceed to step S5;

[0032] S3, ordinary users view the information of the honeypot container running in the current system, including the container ID, name, URL, status information and corresponding operation buttons. Users can start, pause and delete the honeypot container according to actual operation needs. The success or failure of the corresponding operation will be fed back through a pop-up window, and then proceed to step S4;

[0033] S4, ordinary users can create a new honeypot container according to the needs of deployment and operation, and proceed to step S5;

[0034] S5: Administrator users can view the system's operation logs, analyze the system's operating status, and repair fault points. Ordinary users can view the container's access logs, obtain the attacker's attack behavior and source IP based on the access log report, and take corresponding disposal measures.

[0035] Preferably, creating a new honeypot container in step S4 specifically includes:

[0036] S41, the user first uploads the custom Dockerfile compressed file package;

[0037] S42, the user enters the container name, the port information of the internal and external mappings, and then clicks the Create button;

[0038] S43, the backend first decompresses the compressed package according to the information submitted by the frontend, and automatically deploys the container according to the Dockerfile command.

[0039] The beneficial effects of the present invention are:

[0040] The present invention discloses a WEB honeypot background management system and method based on Docker, which adopts the automation concept to complete most of the processes of honeypot deployment, that is, when deploying the honeypot, the administrator and the user only need to input the configured files at the front end and click the corresponding button, and the back end can automatically execute the corresponding operation process: decompress the package → execute the docker command in the folder to form a docker image → when starting the honeypot, the back end executes the corresponding docker command to realize that the honeypot is mapped out on a port to lure hackers.

[0041] This method reduces the professional ability requirements for network administrators; it can capture attack methods and attacker information so that administrators can take measures; it adopts a customized honeypot design with a high degree of simulation and good interactive performance, which is not easy to be identified by attackers; it designs a log recording module, which records the access of each IP address to the honeypot. The recorded content is the request header sent by the user, which is more specific. It also records the operation records of the system users on the system. Administrators can use this module to determine whether the user has any illegal operations, which is used to analyze the system operation status. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is the overall framework diagram of the WEB honeypot background management system based on Docker provided in Example 1;

[0043] Figure 2 It is a flow chart of the WEB honeypot background management method based on Docker provided in Example 2; DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings. It should be understood that the specific implementation methods described herein are only used to explain the present invention and are not used to limit the present invention.

[0045] Example 1

[0046] This embodiment provides a WEB honeypot background management system based on Docker. Figure 1 As shown, it includes a user login unit, a container creation unit, a container management unit, a user management unit and a log collection unit;

[0047] The user login unit is used to confirm the identity information of the login person, find the corresponding login person information in the database, and grant the user operation authority according to the preset identity information of the person (administrator or ordinary user);

[0048] The container creation unit is used to create a specified honeypot container in the system according to the user's operation instruction after the user logs in;

[0049] The container management unit is used to perform corresponding operations in the honeypot container created in the system according to the user's operation instructions after the user logs in;

[0050] The user management unit is used to manage user information in the database according to the user's operation authority after the user logs in;

[0051] The log collection unit is used to store the operation status log and the access log of the honeypot container during the operation of the system, so as to generate a corresponding log report.

[0052] The user's operating permissions include administrator permissions and common user permissions. If the user has administrator permissions, he / she has permissions to enter the user management unit, and directly loads the user management unit after logging in to perform corresponding user management operations. If the user has common user permissions, he / she has permissions to create and manage honeypot containers, and loads the container creation unit and / or container management unit after logging in to the system to perform corresponding container creation operations and / or container management operations, and also includes operations that can hide the highest permissions from common users.

[0053] In this embodiment, the ordinary user loads the container management unit after logging into the system and performs corresponding container management operations, specifically including:

[0054] Ordinary users can view the information of the honeypot containers running in the current system, including the container ID, name, URL, status and corresponding operation buttons. Users can start, pause and delete the honeypot containers according to actual operation needs. The success or failure of the corresponding operation will be fed back through a pop-up window.

[0055] After logging into the system, the ordinary user loads the container creation unit and performs corresponding container creation operations, specifically including: ordinary users can create honeypot containers according to deployment needs to protect the website originally deployed by the user, that is, deploy the honeypot content into a web page that is the same as their own website or deploy it into an administrator backend web page, including the following steps:

[0056] 1) The user searches for an image with a web environment (with PHP7.0 and Apache) in the Docker image station, and writes its name at the beginning of the Dockerfile file (in the form of FROM image name); a homepage (index.html, a file pre-edited in HTML language) like the administrator login interface is copied to the Apache display directory (path: \var\www\html) in the Dockerfile file using the COPY function to implement the deployment of this honeypot. The format is: COPYindex.html\var\www\html. You can also replace index.html with a folder. It is worth noting that the folder and Dockerfile need to be placed in the same folder and packaged into a compressed file package.

[0057] 2) Upload the Dockerfile compressed file package to the container creation unit. The compressed package is transferred to the upload directory of the server and decompressed. Set the basic information of the container, including the container name and the port information of the internal and external mappings. Click the Create button to create the container. The process executed by the backend is: go to the folder where the decompression is completed, and according to the image name set by the front end (docker uses the image name as the keyword), use the docker build name. (Note: this command is followed by a space and an English period symbol) command to create a docker image with the corresponding name of the compressed package (excluding the .zip suffix). The image is downloaded according to the "FROM image name" in the Dockerfile file;

[0058] 3) The background unzips the compressed file according to the uploaded compressed file package and the basic information of the container set by the front end. According to the Dockerfile command, this command is the docker up command. According to the mapping port set by the front end, the port mapping option in the docker command is used to map the 80 port exposed by the honeypot to an idle port on the host, and the container is automatically deployed.

[0059] The user login unit obtains different front-end echoes according to the content of the account and password input. For example, if the verification code is not entered, if the wrong account and password are entered, "Account and password are wrong" will be echoed; if the correct account and password are entered, "Verification code is wrong" will be echoed; at the same time, the verification of the account and password requires calling the database for verification, and the workload is slightly more than the server resources consumed by only judging the verification code first.

[0060] Determining whether the user has logged in successfully includes the following steps:

[0061] First, determine whether the verification code entered by the user is correct. If it is incorrect, a pop-up window will pop up to prompt that the verification code is wrong, and the login interface will be directly exited; if the verification code is correct, it will directly jump to the account login interface to verify the account and password;

[0062] Enter the account number and password, and the user login unit determines whether the user's account number and the corresponding password are correct. When the account number and password are correct, the user authority is directly determined and the user is redirected to the corresponding operation interface; otherwise, a pop-up window prompts that the user name or password is incorrect and the user logs out of the login interface.

[0063] The log collection unit in this embodiment records the operation status log during the system operation process, including the success or failure information of all user logins, container creation, container management and user management processes, stores all operation status logs in the database, and writes True or False in the corresponding success or failure field for distinction.

[0064] The log collection unit in this embodiment records the honeypot container access log during the system operation process, specifically including: screening the log of the honeypot container, filtering out the access log of the honeypot container, counting the number of IP addresses of the request source, and sorting them, comparing the number of IP addresses and the access frequency and parameter content of the same IP address, and if an abnormality is found, determining that the access is an attack, and forming an attack log report, so that the user can take corresponding disposal measures according to the attack behavior.

[0065] More preferably, the abnormality includes that the account and password in the passed parameter content have a certain pattern, then it is determined to be a behavior of cracking the account and password, and the incoming GET request contains access to admin, but the discovery of this abnormality can only be analyzed and verified manually.

[0066] Example 2

[0067] This embodiment provides a WEB honeypot background management method based on Docker. Figure 2 As shown, the following steps are included:

[0068] S1, the user selects a role through the login unit to log in to the honeypot background management system, and determines the user role authority. If it is an administrator role, the management interface including the user management unit is loaded, and step S2 is performed. Otherwise, if it is a common user role, the honeypot management unit is loaded, and step S3 is performed;

[0069] S2, the management user checks the existing user information in the current database, and performs addition, deletion, modification and query operations on the user information as needed. The success or failure of the corresponding operation will be fed back through a pop-up window, and then proceed to step S5;

[0070] S3, ordinary users view the information of the honeypot container running in the current system, including the container ID, name, URL, status information and corresponding operation buttons. Users can start, pause and delete the honeypot container according to actual operation needs. The success or failure of the corresponding operation will be fed back through a pop-up window, and then proceed to step S4;

[0071] S4, ordinary users can create a new honeypot container according to the needs of deployment and operation, and proceed to step S5;

[0072] S41, the user first uploads the custom Dockerfile compressed file package;

[0073] S42, the user enters the container name, the port information of the internal and external mappings, and then clicks the Create button;

[0074] S43, the backend first decompresses the compressed package according to the information submitted by the frontend, and automatically deploys the container according to the Dockerfile command.

[0075] S5: Administrator users can view the system's operation logs, analyze the system's operating status, and repair fault points. Ordinary users can view the container's access logs, obtain the attacker's attack behavior and source IP based on the access log report, and take corresponding disposal measures.

[0076] By adopting the above technical solution disclosed in the present invention, the following beneficial effects are obtained:

[0077] The present invention discloses a WEB honeypot background management system and method based on Docker, which adopts the automation concept to complete most of the processes of honeypot deployment, that is, when deploying the honeypot, the administrator and the user only need to input the configured files at the front end and click the corresponding button, and the back end can automatically execute the corresponding operation process: decompress the package → execute the docker command in the folder to form a docker image → when starting the honeypot, the back end executes the corresponding docker command to realize that the honeypot is mapped out on a port to lure hackers.

[0078] This method reduces the professional ability requirements for network administrators; it can capture attack methods and attacker information so that administrators can take measures; it adopts a customized honeypot design with a high degree of simulation and good interactive performance, which is not easy to be identified by attackers; it designs a log recording module, which records the access of each IP address to the honeypot. The recorded content is the request header sent by the user, which is more specific. It also records the operation records of the system users on the system. Administrators can use this module to determine whether the user has any illegal operations, which is used to analyze the system operation status.

[0079] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be considered as the scope of protection of the present invention.

Claims

1. A WEB honeypot background management system based on Docker, characterized in that: It includes a user login unit, a container creation unit, a container management unit, a user management unit and a log collection unit; The user login unit is used to confirm the identity information of the login person, find the corresponding login person information in the database, and grant the user operation authority according to the preset identity information of the person; The container creation unit is used to create a specified honeypot container in the system according to the user's operation instruction after the user logs in; The container management unit is used to perform corresponding operations in the honeypot container created in the system according to the user's operation instructions after the user logs in; The user management unit is used to manage user information in the database according to the user's operation authority after the user logs in; The log collection unit is used to store the operation status log and the access log of the honeypot container during the operation of the system, so as to generate a corresponding log report; the operation authority of the user includes administrator authority and ordinary user authority. If the user has administrator authority, he has the authority to enter the user management unit, and directly loads the user management unit after logging in to perform corresponding user management operations; If it is a common user, then the user has the permission to create and manage honeypot containers. After logging into the system, the user loads the container creation unit and / or container management unit and performs corresponding container creation operations and / or container management operations. After logging into the system, ordinary users load the container creation unit and perform corresponding container creation operations, including: ordinary users can create honeypot containers according to deployment needs to protect the website originally deployed by the user, that is, deploy the honeypot content into a web page like their own website or deploy it into an administrator backend web page, including the following steps: 1) Find an image with a web environment in the Docker image site and write its name at the beginning of the Dockerfile file; use the COPY function in the Dockerfile file to copy index.php to the Apache display directory when deploying this honeypot; or replace index.html with a folder and package the folder and Dockerfile into a compressed file package; 2) Upload the compressed file package to the container creation unit. The compressed file package is transferred to the upload directory of the server and decompressed. Set the basic information of the container and click the create button to create the container. The process executed by the backend is: go to the folder where the decompression is completed, and use the docker build name. command to create a docker image with the corresponding name of the compressed package according to the image name set by the front end. The image is downloaded according to the "FROM image name" in the Dockerfile file; 3) The background unzips the compressed file according to the uploaded compressed file package and the basic information of the container set by the front end. According to the Dockerfile command, this command is the docker up command. According to the mapping port set by the front end, the port mapping option in the docker command is used to map the 80 port exposed by the honeypot to an idle port on the host, and the container is automatically deployed.

2. According to the Docker-based WEB honeypot background management system of claim 1, it is characterized in that: After logging into the system, the ordinary user loads the container management unit and performs corresponding container management operations, including: Ordinary users can view the information of the honeypot containers running in the current system, including the container ID, name, URL, status and corresponding operation buttons. Users can start, pause and delete the honeypot containers according to actual operation needs. The success or failure of the corresponding operation will be fed back through a pop-up window.

3. The Docker-based WEB honeypot background management system according to claim 1 is characterized in that: The basic container information in step 2) includes the container name and the port information of the internal and external mappings.

4. The Docker-based WEB honeypot background management system according to claim 1 is characterized in that: The user login unit obtains different front-end echoes according to the contents of the account and password input, and determines whether the user has successfully logged in, including the following steps: First, determine whether the verification code entered by the user is correct. If it is incorrect, a pop-up window will pop up to prompt that the verification code is wrong, and the login interface will be directly exited; if the verification code is correct, it will directly jump to the account login interface to verify the account and password; Enter the account number and password, and the user login unit determines whether the user's account number and the corresponding password are correct. When the account number and password are correct, the user authority is directly determined and the user is redirected to the corresponding operation interface; otherwise, a pop-up window prompts that the user name or password is incorrect and the user logs out of the login interface.

5. The Docker-based WEB honeypot background management system according to claim 1 is characterized in that: The log collection unit records the operation status log during the system operation process, including the success or failure information of all user logins, container creation, container management and user management processes, stores all operation status logs in the database, and writes True or False in the corresponding success or failure fields for distinction.

6. The Docker-based WEB honeypot background management system according to claim 1, characterized in that: The log collection unit records the honeypot container access log during the system operation process, specifically including: screening the log of the honeypot container, filtering out the access log of the honeypot container, counting the number of IP addresses of the request source, and sorting them, comparing the number of IP addresses and the access frequency and parameter content of the same IP address, and if an abnormality is found, determining that the access is an attack, and forming an attack log report, so that the user can take corresponding disposal measures according to the attack behavior.

7. A WEB honeypot background management method based on Docker, characterized in that: The Docker-based WEB honeypot background management system described in any one of claims 1 to 6 is implemented, comprising the following steps: S1, the user selects a role through the login unit to log in to the honeypot background management system, and determines the user role authority. If it is an administrator role, the management interface including the user management unit is loaded, and step S2 is performed. Otherwise, if it is a common user role, the honeypot management unit is loaded, and step S3 is performed; S2, the administrator user checks the existing user information in the current database, and performs addition, deletion, modification and query operations on the user information as needed. The success or failure of the corresponding operation will be fed back through a pop-up window, and then proceed to step S5; S3, ordinary users view the information of the honeypot container running in the current system, including the container ID, name, URL, status information and corresponding operation buttons. Users can start, pause and delete the honeypot container according to actual operation needs. The success or failure of the corresponding operation will be fed back through a pop-up window, and then proceed to step S4; S4, ordinary users can create a new honeypot container according to the needs of deployment and operation, and proceed to step S5; S5: Administrator users can view the system's operation logs, analyze the system's operating status, and repair fault points. Ordinary users can view the container's access logs, obtain the attacker's attack behavior and source IP based on the access log report, and take corresponding disposal measures.

8. The Docker-based WEB honeypot background management method according to claim 7, characterized in that: Creating a new honeypot container in step S4 specifically includes: S41, the user first uploads the custom Dockerfile compressed file package; S42, the user enters the container name, the port information of the internal and external mappings, and then clicks the Create button; S43, the backend first decompresses the compressed package according to the information submitted by the frontend, and automatically deploys the container according to the Dockerfile command.

Images