# A Highly Interactive Honeypot-Based Approach to Network Threat Management
## 4 Implementation and Results Analysis of High Interactivity Honeypot System
### Implementation of Honeypot Central Node  
For the design and implementation of the central node, it must ensure its high level of fakery and self-protection. Although maintaining a high level of fakery is more of a characteristic of a honeypot, the central node also relies on a high level of fakery to ensure that it is not accidentally recognized and attacked by attackers. Due to the overall design architecture, once the central node is attacked, the entire honeypot system will be impacted. In order to achieve a high level of authenticity for the central node in a honeypot system, all external network connections must be strictly restricted. Only the communication interface and WEB management interface of the honeypot should be exposed, and there should be no other external connections. This approach will help to ensure that the central node appears as realistic as possible to potential attackers. Secondly, in order to prevent attackers from infiltrating the central node through the honeypot, the central node needs to deploy a protective system consisting of a firewall and intrusion detection system to achieve self-protection. The specific workflow is shown in Figure 7 below. In our implementation, strict restrictions are imposed on the content security policy at the backend to ensure secure interaction between the front end and back end. Only API access from a trustworthy front end is processed. All the honeypots are stored as tuple data in the central node, consisting of the honeypot IP address, a randomly generated unique key assigned to each honeypot, and other relevant information. This random key satisfies the characteristics of a universally unique identifier, ensuring uniqueness and reliability. This key is kept secret in the central node and there is no way for it to be disclosed after it is created. This key serves as the unique master key for communication between the central node and the corresponding honeypot. All communication traffic is encrypted using the session key generated by this master key in CBC mode AES encryption. To  
Figure 7: Central Node Interaction Model. facilitate critical interactions between the central node and honeypots, a distinct backend API is utilized. This API accepts encrypted data along with the honeypot IP address. The central node then maps the IP address to the corresponding universally unique identifier, decrypts the encrypted data with the matching session key utilizing the CBC mode AES decryption algorithm, and verifies the data's validity only if it conforms to specific JSON object properties. Any other format data or decryption failure is considered an abnormal interaction and triggers the corresponding exception handling module, rolling back any information saved in the process. The specific workflow is shown in Figure 8 below. After receiving a legitimate honeypot interaction, the central node invokes the core data cross-processing computation method, which is detailed in this paper. The newly obtained information is analyzed from multiple angles and stored in the database. The core data cross-processing method involves passing in the authenticated JSON data returned by each honeypot, which contains key-value pairs. A loop is used to iterate through the keys, and if a key corresponds to a value that is a JSON object, it is recursively iterated through. Once all the values are available, they are aggregated into a key-set. This is the pre-processing step for a copy of the honeypot incoming data. All incoming data must first be preprocessed as JSON objects. In this way, we obtain a collection consisting of a key table of keys of individual JSON objects. By performing different set operations on the elements  
Figure 8: Central node data flow model. in the set, the key table can be queried from a specific perspective, and the results obtained will have specific features. The results are the mapping of the whole dataset under this feature, which is saved in the database and bound to the feature value for the next query.