Requirements: Phase 2 - ReplayProject/ReplayHoneypots GitHub Wiki
The purpose of this project is to complete the following 3 major tasks:
- Add features to the existing honeypots
- Create an automated configuration and deployment tool
- Create a centralized honeypot management to report various metrics for statistical analysis
1.1 The system shall be dynamically configurable with an Nmap scan and set of payloads
- 1.1.1 The system shall extract open port numbers from an Nmap scan file
- 1.1.2 The system’s port signature shall bear no differences from the mimicked host when scanned with Nmap
- 1.1.3 The system shall return preconfigured payloads when interacting with mimicked services
1.2 Each honeypot shall have the following configuration options:
- 1.2.1 The system shall allow a user to open a port
- 1.2.2 The system shall allow a user to close a port
- 1.2.3 The system shall allow logging to be toggled for each open port
- 1.2.4 The system shall allow logging to be toggled for each supported protocol
- 1.2.5 The system shall allow configuration for the IP address of a honeypot
- 1.2.6 The system shall allow configuration for the MAC address of a honeypot
- 1.2.7 The system shall allow configuration for the hostname of a honeypot
- 1.2.8 The system shall allow configuration of payloads to be sent after successful connection on each open port
- 1.2.9 The system shall allow configuration of payloads to be sent after successful connection for each supported transport protocol
- 1.2.10 The system shall allow for local log collection and retention settings (e.g. whitelisting and local storage)
1.3 Each honeypot shall detect and log network traffic.
- 1.3.1 These logs include the following data: Hostname, Timestamp, Source and Destination port, Protocol, Source and destination IP, Source and Destination MAC, Type of Connection (e.g. TCP, UDP, ICMP)
- 1.3.2 The system shall detect & log when any connection is attempted on an open port
- 1.3.3 The system shall detect & log when any connection is attempted on a closed port
- 1.3.4 The system shall allow the exclusion of unnecessary logs through the “whitelisting” of specific IPs and ports
1.4 Each honeypot shall send logged data to a central management server. These logs contain the following data: Hostname, Timestamp, Source and Destination port, Protocol, Source and destination IP, Source and Destination MAC, Type of Connection (e.g. 2-way Handshake only)
2.1 The deployment system shall allow various setup options:
- 2.1.1 The deployment system shall allow the user to add a host
- 2.1.2 The deployment system shall allow the user to remove a host
- 2.1.3 The deployment system shall allow the user to connect to the host and change configuration files
2.2 The deployment system shall allow various installation options:
- 2.2.1 The deployment system shall allow the user to install a honeypot to a host previously specified by the user
- 2.2.2 The deployment system shall allow the user to uninstall a honeypot to a host previously specified by the user
- 2.2.3 The deployment system shall allow the user to reinstall a honeypot to a host previously specified by the user
2.3 The deployment system shall allow the user honeypot status options:
- 2.3.1 The deployment system shall allow the user to retrieve the status of a honeypot.
- 2.3.2 The deployment system shall allow the user to start a honeypot
- 2.3.2 The deployment system shall allow the user to stop a honeypot
2.4 The deployment system shall copy and set up the project’s repository on the specified host
- 2.4.1 The deployment system shall configure a virtual environment for the honeypot’s code
- 2.4.2 The deployment system shall install all required libraries and check/setup needed privileges for the codebase to run successfully
- 2.4.3 The deployment system shall generate configuration files for the specific device it is deploying a honeypot on
- 2.4.4 The deployment system shall setup ssh keys so that the management system may access the honeypot at a later time
2.5 The deployment system shall alert the user when honeypot setup is finished and allow the user to review the output of the setup process. This output will include success states, error states and partial completion. {x}
3.1 The frontend GUI shall display an overview of deployed Honeypots.
- 3.1.1 The frontend GUI shall display the number of logs for each honeypot
- 3.1.2 The frontend GUI shall display the most frequently logged IP addresses and port numbers
- 3.1.3 The frontend GUI shall display the most frequently logged traffic type
3.2 Honeypot logs shall be centrally collected and made accessible through the frontend GUI.
- 3.2.1 The frontend GUI shall provide an interface to make logs available for collection by an external Security Information and Event Management (SIEM).
- 3.2.2 The frontend GUI shall provide an interface to query logs for manual analysis
3.3 The frontend GUI shall display alerts based on collected logs
- 3.3.1 Alerts shall be available for collection by an external SIEM
- 3.3.2 The system shall record nmap port scans and alert users
- 3.3.3 The system shall record configuration changes and alert users
- 3.3.4 The system shall record honeypot startup and alert users
- 3.3.5 The system shall record honeypot shutdown and alert users
Overall Stretch Goals (IDed by general relation to other requirements)
- SG#1: Each honeypot shall be able to be dynamically assigned an IP address when starting.
- SG#2: The honeypot system shall engage in commonly used encrypted protocols that Nmap supports, such as TLS.
- SG#3: A user shall be able to execute more than one honeypot in parallel using different physical or virtual network interfaces (Unable to test but should work)
- SG#4: The honeypot system should be able to register with Microsoft Active Directory to assist with credential management and team access. (Possible to integrate with Passport.js with minimal effort)
Non-Functional Requirements
- NFR1: This system shall be able to deploy honeypots on a variety of hardware such as (but not limited to) Virtual Machines, Raspberry Pis, or physical servers
- NFR2: The system shall utilize no more than 10% of CPU capacity. This is to allow multiple honeypots to be deployed on the same host.
- NFR3: The Honeypot’s management interface shall be hidden from adversaries’ scans. More concretely, the administrative traffic of the system can be routed over a specific network interface through the system’s configuration options.
Constraints With this project we are operating under two main constraints.
- C1: The individual honeypot codebase shall be implemented in the Python 3 programming language.
- C2: Honeypots shall be configured with two network interfaces in mind: an internal-facing one to communicate with a management server and an external-facing one which will be open to all network activity.
We decided the best way to approach the implementation of this system was to break our requirements into end-to-end flows between the user and the other parts of our system.
Flow 1: TCP/UDP on closed port --> Activity is logged on honeypot --> Logs are sent to management system
Flow 2: User requests configuration changes for honeypot --> Honeypot is changed --> Responds to the management system
Flow 3: User requests a honeypot to be deployed --> Management system connects to host --> Honeypot is installed --> Responds to the management system
Flow 4: User requests metrics of deployed honeypot --> Honeypot responds to management system
Flow 5: Honeypot experiences error/attack --> Logs the error/attack --> Reports to Management system with alert
Here are 4 of these flows diagrammed out
The rogue agent performs a port scan of one of our honeypots. The honeypot that is being scanned logs this activity. These logs are sent to the management system. The user of the management system can then view these logs.
The end user wants to make configuration changes to a currently deployed honeypot. The user specifies the configuration options that they wish to change. These options are sent to the honeypot. The honeypot attempts to make these configuration changes and then responds to the management system with its status.
The end user requests a honeypot to be deployed. They select the desired deployment options and press deploy. The management system connects to a host and sets up the environment to deploy the desired honeypot. As part of this setup, the honeypot is registered with the management system and can be viewed through the web interface. The honeypot reports its status back to the end user once it has been fully deployed.
The user opens the web interface of the management system. The user requests to view metrics of a specific honeypot. These metrics are retrieved from the honeypot and displayed to the user.
A rogue agent attacks a currently deployed honeypot. The honeypot logs this attack and stores the log locally. The honeypot sends this log to the management system and alerts the user of a current attack.
A currently deployed honeypot stops unexpectedly. The honeypot logs this error locally and sends its to the management system. The user is then alerted of the current issues.