Skip to content

Honeypots

Jump to bottom
Toby Lin edited this page Oct 11, 2020 · 11 revisions

Honeypots

Objective

Create isolated environments for cyber attackers to interact with while limiting their capabilities to cause unwanted effects

Expectations

The environment should be:

  • Isolated from the Proxmox Host's filesystem
  • contained as not to overwhelm the Proxmox Host's resources
  • Safeguarded from many kinds of network attacks (DOS)

Resources

Terminology

Honeypots go through a series of stages as shown below:
Screen Shot 2019-07-29 at 11 29 09 PM

  • Initial State (aka. Clean State)
    • No attackers have previously successfully logged into the honeypot.
    • Honey, if any, is placed
  • Compromised State (aka. Contaminated State)
    • This happens on the very first successful login by an attacker into the honeypot. Any subsequent logins by the same attacker or different attackers does not change the honeypot state.
    • All files inside the honeypot are to no longer be trusted. For this honeypot project, files to be analyzed should be sent over to an isolated container with no network access inside the Proxmox Sandbox VM. Never open/run any files inside the honeypot on a host OS (e.g. Proxmox Host OS, Proxmox Sandbox VM Host OS).
  • End of Life:
    • This happens when a recycling script has determined that the honeypot should be taken offline and recycled.
  • Recycling:
    • Procedure to bring the honeypot back to its initial state.

Container Specifications

Container OS Template

To download OS templates, look at the Container Management section in the Proxmox 5.4 wiki. We recommend using Ubuntu 16.04 and at the time of this writing, the latest release of Ubuntu 16.04 is ubuntu-16.04-standard_16.04.5-1_amd64.tar.gz.

Container Limitations

The following limitations must be placed on each container:

  • SWAP (Virtual memory): 0

The following limitations must be placed on each container; however, you are free to set your own limits as long as it does not overwhelm the Proxmox Host:

  • RAM: 512MB (Recommended)
  • CPU Time: 0.5 (Recommended)
  • CPU Cores: 1 (Recommended)

Container Networking

If you're trying to send traffic through the host via a NAT bridge, you should do the following:

The IP address of each container must be within the following private IP range: 172.20.0.0/16

  • Note that IP address 172.20.0.1 is used by the bridge on the Proxmox Host

The container's gateway must be the IP address of the bridge on the Proxmox Host as to route all of the containers' traffic not destined to 172.20.0.0/16 via the Proxmox Host

Using NAT is likely required for a MITM setup as you need to additionally route your network traffic.

If you are trying to connect the container to the honeynet, you should use your assigned public IP address.

Direct to public address should only be used if you do not expect to have additional routing configuration, just a simple container directly on the internet.

DNS

You may use any DNS server

  • Cloudflare's privacy oriented DNS servers: 1.1.1.1 and 1.0.0.1
  • Google's Public DNS servers: 8.8.8.8 and 8.8.4.4
  • UMD's DNS servers: 128.8.74.3 and 128.8.76.3

If required, the DNS search domain should be umd.edu

Container SSH Server

View the SSH wiki page

Clone this wiki locally