Requirements: Phase 3 - ReplayProject/ReplayHoneypots GitHub Wiki

Task 1 - Config Generation Tool

  • 1.1 Given a NMAP scan and a related PCAP file, the system must generate a port response configuration (ports, protocols, payloads) that is ready for a honeypot's use.
    • 1.1.1 If input files are malformed, the system will notify the user and exit.
    • 1.1.2 The system will show the user the generated configs (in a human-readable form) to check their validity.
    • 1.1.3 (Constraint) This feature will be separate from the honeypots, and once prototyped, may be introduced as part of the frontend.

Honeypots (HP)

Task 2 - HP functionality

  • 2.2 At initial handshake with the Management System, the system must assign the honeypot the following data:
    • 2.2.1 a universally unique ID (UUID)
    • 2.2.2 creation timestamp
    • 2.2.3 certificate for later commands / configuration communications (TLS)
  • 2.3 The system must identify all logs & network interactions with its UUID.
  • 2.4 The system must support available "modules" being selected/deselected through configuration.
  • 2.5 The system will only require the configurations to support enabled modules.
  • (Stretch Goal 1) The system will include modules for a Telnet, SSH, SMTP, and RDP server.

Management Frontend

Task 3 - Local Authentication Rework

  • 3.1 The system must support database backed, local authentication.
    • 3.1.1 The system's local authentication must use sensible & standard methods for password hashing.
    • 3.1.2 The system's local authentication must use sensible & standard methods for all user data stored in the database.
    • 3.1.3 The system must support a central authentication method for the database (Fauxton), and the frontend.

Task 4 - Security Features, Authentication, Authorization

  • 4.1 The system must support HTTPS for the management frontend (This may also be used for configuration tunnel encryption)
  • 4.2 The system must integrate with SAML 2.0 (AZURE AD) authentication.
    • 4.2.1 The system must support both authentication methods after initial setup
    • 4.2.1 The system must support adding accounts as SAML 2.0 or local from the management frontend.
  • 4.3 The system must support the following account recovery options
    • 4.3.1 The system must support user-initiated password changes given they are authenticated on the frontend. (need password to change password)
    • 4.3.2 The system must support administrative password resets on a user account.
    • 4.3.3 The system must allow admins to choose if a user's reset password is a one time password (OTP) (Password expiry on next login)
  • 4.4 The system must implement a role based access control (RBAC) system that supports the following user types (authorization)
    • Admin
      • 4.4.1 Admins can create other users of each type
      • 4.4.2 Admins can promote other users to admin status
      • 4.4.3 Admins can reset other user's passwords (linked to 4.3.3)
      • 4.4.4 There must be at least 1 admin in the system
    • Editor
      • 4.4.4 More privileges than auditors, can change options for devices / groups.
      • 4.4.5 Editors cannot create other users.
    • Auditor
      • 4.4.6 Read-only access to the frontend & traffic data.
    • (Stretch Goal 2) Custom Roles with more granular rights & access controls
  • 4.5 The RBAC system must support access controls to:
    • 4.5.1 user accounts
    • 4.5.2 administrative logs
    • 4.5.3 traffic logs
    • 4.5.4 devices
    • 4.5.5 device groups
    • 4.5.6 RBAC controls for the devices & groups

Task 5 - New Functionality

  • 5.1 Device Grouping
    • 5.1.1 The system must support grouping devices dynamically from the frontend.
    • 5.1.2 The system must support locking/unlocking groups of devices as defined in the RBAC.
    • 5.1.3 The system must allow authorized roles to create new groups and modify "unlocked" groups.
    • 5.1.4 The system must allow for the "summary & details" views to only deal with data from a given device group.
    • 5.1.5 The system must have a dashboard to see and manage existing device groups, as well as the permissions associated with them.
  • 5.2 Health Metrics
    • 5.2.1 The system must report health metrics and device statuses to the management system. (EG. CPU usage, RAM usage, storage, heartbeat)
    • 5.2.2 The system musts allow for displaying supported health metrics on the frontend for each device & device groups.
    • 5.2.3 The system must support displaying supported health metrics for device groups.
    • 5.2.4 The system must support collecting and displaying device heartbeats.

Task 6 - Database & Configuration

  • 6.1 The system must keep a log of administrative actions taken in a partition of the database.

  • 6.2 The system must support having a redundant / collaborative management database.

  • 6.3 The system must pull honeypot configurations from device groups of the following types

    • 6.3.1 Management Groups - where does this device (UUID) report to
    • 6.3.2 Response Groups - what kind of responses do I give incoming traffic
    • 6.3.3 Allow Groups - what traffic (ports & IPs) do I ignore
    • 6.3.4 UUID "Groups" - device specific configuration

General Constraints

  • C1 Queries to the database & honeypots will work in a timely manner (operations that take a long times will be timestamped and cached, CouchDB calculated queries will be taken advantage of)
    • Basically: "Use available tech to increase performance"
  • C2 Each component of the system will be designed with large scale deployments in mind. (> 50 devices and multiple managed locations)
  • C3 When creating new users in the system, it will choose default passwords, and the admins will be responsible for communicating those to the users via side-channel. Next the user will log into the account with the default password to fully "complete the registration".
  • C4 Use the TRIO library to save resources and as an alternative to threading on the honeypot side of things.
  • C5 The codebase should be written in python3, nodejs, vuejs, and bash as this is what the system is already built and tested thus far with.
  • C5 Technology pivots will be discussed with sponsors, changing technology stacks now represents a huge technical debt at this phase in the project.