55 connections hit the honeypot on 2026-08-19, from 24 unique IP(s).

Top source IPs

27.79.3.95 — 11 connections
116.110.152.194 — 6 connections
76.32.83.132 — 2 connections
193.242.162.244 — 2 connections
102.213.49.90 — 2 connections

Auto-generated from the Cowrie session logs. Updates automatically while the day is still in progress.

Next goal: stop serving this off a bare IP and get it behind a real domain with real HTTPS.

Free domain

Used DuckDNS for a free subdomain. First attempt at pointing it went into the wrong field entirely — DuckDNS splits IPv4 and IPv6 into separate boxes, and the server's IP ended up typed into the IPv6 one by mistake. Fixed by moving it to the right field.

Elastic IP first

Before pointing a domain at anything, allocated an Elastic IP and associated it with the instance, so the address wouldn't shift on a stop/start. Associating it changed the public IP immediately — and broke the site's styling, because Bludit had the old IP baked into its site config as the base URL. Every CSS and JS request was still trying to load from an address that no longer pointed here.

sudo sed -i 's/OLD_IP/NEW_IP/g' bl-content/databases/site.php

Certbot

Amazon Linux doesn't ship certbot in its repos, so it went in through a Python venv instead:

sudo dnf install -y python3 augeas-libs
sudo python3 -m venv /opt/certbot/
sudo /opt/certbot/bin/pip install --upgrade pip
sudo /opt/certbot/bin/pip install certbot certbot-nginx
sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot

First run failed — certbot couldn't find a matching nginx server block, because nginx.conf still had server_name _;, a wildcard that doesn't match a real domain name. Swapped it for the actual domain, reloaded nginx, then re-ran the install step and the cert deployed cleanly.

The mixed-content trap, again

Switching to https:// broke styling a second time, same root cause as the IP change: the site's base URL was still saved as http://, so the browser blocked every asset as insecure mixed content. One more sed against site.php, this time swapping the scheme, fixed it for good.

What I actually learned

Whatever stores your site's base URL will bite you twice — once when the IP changes, once when the scheme does. Elastic IP before DNS, DNS before certs, in that order, saves a redo. And server_name _; is a real value, not a placeholder — certbot takes it literally.

A reference dump of every command from the honeypot and domain/HTTPS posts — no narrative, just the commands, grouped by post.

From: Building my first honeypot on AWS

sudo sed -i '/^#Port 22$/a Port 22\nPort 2222' /etc/ssh/sshd_config
sudo systemctl restart sshd
sudo sed -i '/^Port 22$/d' /etc/ssh/sshd_config
sudo systemctl restart sshd
sudo useradd -m -s /bin/bash cowrie
sudo passwd -l cowrie
sudo dnf install -y git python3.11 python3-pip python3-devel openssl-devel libffi-devel gcc gcc-c++ make
sudo su - cowrie
git clone https://github.com/cowrie/cowrie
cd cowrie
python3.11 -m venv cowrie-env
source cowrie-env/bin/activate
pip install -r requirements.txt
pip install -e .
cp src/cowrie/data/etc/cowrie.cfg.dist etc/cowrie.cfg
sed -i 's/listen_endpoints = tcp:2222:interface=0.0.0.0/listen_endpoints = tcp:2223:interface=0.0.0.0/' etc/cowrie.cfg
cowrie start
sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2223

From: Getting a real domain and real HTTPS

sudo sed -i 's/OLD_IP/NEW_IP/g' bl-content/databases/site.php
sudo dnf install -y python3 augeas-libs
sudo python3 -m venv /opt/certbot/
sudo /opt/certbot/bin/pip install --upgrade pip
sudo /opt/certbot/bin/pip install certbot certbot-nginx
sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot
sudo certbot --nginx -d DOMAIN
sudo certbot install --cert-name DOMAIN
sudo sed -i 's/http:\/\/DOMAIN/https:\/\/DOMAIN/g' bl-content/databases/site.php

Automating the blog

sudo dnf install -y cronie
sudo systemctl enable --now crond
echo '*/15 * * * * root /usr/bin/python3 /usr/local/bin/honeypot_blog.py >> /var/log/honeypot_blog.log 2>&1' | sudo tee /etc/cron.d/honeypot-blog