Welcome to my technical blog and knowledge base!
Suggestions or feedback?
Contact me here or visit the project repository.
You can also subscribe via RSS.
This is a small series I wanted to start, where I write about my small threathunting setup and describe a little what I build and what I am doing with it.
In this part, I will describe the Network setup for my Environment, more about how I build the honeypots and the ELK Server I will describe in the follow up articles about threathunting.
Keep in mind this is for Education and fun, no serious stuff going on here.
The threat landscape is constantly evolving, with new attack vectors, tools, and tactics appearing almost daily.
And to keep my skills current with real-world threats, I built a home lab dedicated to threat hunting. This environment allows me to safely observe attacks and develop detection and defense methods. I deployed web and shell honeypots, and collect real threat data in a controlled setting.
It’s a practical, hands-on way to explore the behavior of adversaries and its a lot of fun!
For the hardware setup, I kept things lightweight and affordable by using Raspberry Pi devices and open-source tools. The honeypot is based on the well-known Cowrie SSH honeypot and the honeyhttpd HTTP honeypot . It runs on a Raspberry Pi 4 with 8GB of RAM, hosted inside a Docker 🐳 container. On the honeypot host, Filebeat is running to ingest the Cowrie logs into the ELK stack.
For the ELK stack, I used a Raspberry Pi 5 with 16GB of RAM, running Debian. The ELK services are also containerized using Docker. The stack is based on the DShield-SIEM project, which I customized to better fit my needs. I’ll dive deeper into those modifications and the ELK setup in a follow-up article.
The network topology is straightforward but deliberately segmented. The router is connected to a managed switch, which is responsible for handling VLAN separation. Both the honeypot and the ELK server are connected to this switch and are placed in an isolated VLAN (VLAN210). This VLAN is dedicated exclusively to threat hunting, ensuring that any potentially malicious traffic remains fully contained and cannot interfere with the rest of the home network.
My client system 💻 is the only machine allowed to connect from outside the VLAN to both the ELK server and the honeypot. This connection is strictly for maintenance and administrative purposes. The ELK server is allowed to access the internet, primarily to pull threat intelligence data from external sources and security feeds.
In contrast, the honeypot is completely blocked from internet access, with the exception of SSH and HTTP traffic going in and out of it. These are the only services deliberately exposed to simulate vulnerable endpoints. Communication between the honeypot and the ELK server is allowed for log ingestion and analysis. However, I intend to introduce stricter controls on this internal traffic in the future to further reduce the attack surface.
For the pf(1) configuration It was as always with UNIX fairly easy to get to work:
match in quick log on egress proto tcp from any to any port 22 flags S/SA rdr-to $honeypot port 2222
match in quick log on egress proto tcp from any to any port 443 flags S/SA rdr-to $honeypot port 4433This rule makes sure any incoming TCP connection attempt to port 22 (SSH) and port 443 (HTTPS) is immediately intercepted, logged, and transparently redirected to the $honeypot server listening on port 2222 or 4433 for HTTPS Traffic.
Here you can see my managed switch configuration. Port 5 (honeypot) and port 3 (ELK) is assigned to VLAN210, port 2 is the router it needs to talk into both networks and at port 1 is my workstation to access the theathunting environment.
Building and maintaining this lightweight honeypot and monitoring setup on Raspberry Pi devices has been an insightful experience. Here are some key takeaways:
Resource Efficiency: Raspberry Pis provide a surprisingly capable platform for running complex services like Cowrie honeypot and the ELK stack in Docker containers, keeping costs and power consumption low.
Network Segmentation Matters: Isolating the honeypot and ELK server in a dedicated VLAN (VLAN210) effectively contains malicious traffic, protecting the rest of the home network from potential threats.
Controlled Access Is Crucial: Restricting external access to only authorized clients and limiting the honeypot’s internet connectivity reduces the attack surface while still enabling useful data collection.
Logging and Data Collection: Using Filebeat to ship logs from the honeypot to the ELK stack provides real-time visibility into attacker behavior, which is essential for threat hunting and incident response.
Customization Pays Off: Adapting existing tools and SIEM projects (like DShield) to specific needs improves effectiveness and allows for tailored threat detection.
Future Improvements: There is always room to tighten internal communication rules and harden the setup further to minimize risk and improve operational security.
This project highlights the balance between practical constraints and security needs, demonstrating that even modest hardware can contribute significantly to threat intelligence and network defense.
I drew inspiration for this setup from the DShield SIEM project by SANS and would like to express my gratitude for their valuable work.
Next I had to build the ssh honeypot and the HTTP Honeypot, stay tuned for the follow up!
As someone who is passionate about security and has an interest in Unix operating systems, OpenBSD particularly captivates due to its dedication to security, stability, and simplicity. In comparison to other OSes, what sets OpenBSD apart? And how do these principles align with my journey through Zen meditation?
At first glance, OpenBSD and Zen may appear to be vastly disparate concepts - one being a potent operating system, while the other is a spiritual practice originating from ancient China. However, as I delved deeper into both realms, I uncovered some fascinating similarities.
In Zen, simplicity is key to achieving inner clarity and balance. By stripping away unnecessary complexity, OpenBSD aims to create a stable and secure foundation for users. Similarly, in meditation, simplicity helps to quiet the mind and focus on the present moment. This alignment between OpenBSD’s philosophy and Zen practices extends to their shared emphasis on mindfulness and deliberate decision-making, fostering an environment of security and tranquility in both realms.
Both OpenBSD and Zen underscore the significance of attending to detail. In software development, this entails meticulously crafting each line of code to guarantee stability and security. In Zen practice, it involves paying close attention to one’s breath, posture, and mental state to attain a state of mindfulness. By zeroing in on these details, both OpenBSD and Zen strive for perfection.
OpenBSD’s dedication to consistency is manifested in its codebase, where each code change undergoes a thorough code review process. Consistency holds equal importance in Zen practice, as it fosters a sense of routine and stability. By cultivating a consistent daily meditation practice, I have discovered that consistency is instrumental in making progress on my spiritual journey. OpenBSD’s emphasis on consistency mirrors the principles of Zen, emphasizing the value of diligence and discipline in both domains.
Finally, both OpenBSD and Zen acknowledge the elegance in imperfection. In software development, imperfections can often be rectified or lessened through meticulous design and testing. In Zen practice, imperfections are perceived as avenues for growth and self-awareness.
By acknowledging our imperfections, we can nurture humility and compassion. As I progress in my journey with OpenBSD and Zen, I am consistently struck by the ways in which these two seemingly unrelated realms intersect. By embracing simplicity, attention to detail, consistency, and the beauty of imperfection, both OpenBSD and Zen provide unique perspectives on the nature of software development and personal growth. Stay tuned for further insights from my exploration in the realm of security!
This post provides a brief walkthrough of how to deploy a lightweight, containerized SSH honeypot using Cowrie and Podman, with the goal of capturing and analyzing malicious activity as part of my threat hunting strategy.
Cowrie is an interactive SSH and Telnet honeypot designed to emulate a real system, capturing attacker behavior in a controlled environment. It allows defenders and researchers to observe malicious activity without exposing actual infrastructure.
Key capabilities of Cowrie include
Full session logging: Records all commands entered by the attacker, along with input/output streams and timing data. Sessions can be saved as plaintext or in formats suitable for replay.
Fake file system and shell environment: Emulates a basic Linux shell with a user-modifiable file system. Attackers can navigate directories, read/write fake files, or attempt to download/upload payloads.
Command emulation: Supports a large set of common Unix commands (`ls`, `cat`, `wget`, etc.), allowing attackers to interact naturally, as if on a real system. And can be extended with more commands
Credential logging: Captures usernames and passwords used in brute-force login attempts or interactive logins.
File download capture: Logs and optionally stores any files attackers attempt to retrieve via `wget`, `curl`, or similar tools.
JSON-formatted logging and integration’s: Outputs structured logs that are easy to parse and ingest into systems like ELK, Splunk, or custom analysis pipelines.
Cowrie is widely used in research, threat intelligence, and proactive defense efforts to gather Indicators of Compromise (IOCs) and understand attacker tactics,techniques, and procedures (TTPs).
Podman offers several advantages over Docker, particularly in terms of security and system integration. It supports rootless containers, allowing users to run containers without elevated privileges, which reduces the attack surface.
Podman is daemon-less, integrating more seamlessly with systemd and existing Linux workflows. Additionally, Podman is fully compatible with the Open Container Initiative (OCI) standards, ensuring interoperability and flexibility across container ecosystems.
Before I proceed with the cowrie setup, I made sure the following preconditions are met:
I am using a Raspberry Pi 4+ running Ubuntu
After installation, I made sure system is up to date:
sudo apt update && sudo apt upgrade -y# Ubuntu 20.10 and newer
sudo apt-get -y install podmanRun the Hello World Container.In this moment I did not had the cowrie user yet setup so I used my system user to test
podman run hello-world
Trying to pull docker.io/library/hello-world:latest...
...
Hello from Docker!
This message shows that your installation appears to be working correctly.tho sometimes the pulling fails like that then I had to put `docker.io` in front of the container name like:
podman run docker.io/hello-worldthen it would work for sure.
In my network setup for threathunting the honeypot requires VLAN tagging to
configured to reachable from the outside, VLAN210 is my restricted Network.
Therefore i needed to configure the vlan using nmcli so it’s persistent across reboots.
sudo nmcli con add type vlan con-name vlan210 dev mainif id 210 ip4 192.168.210.3/24 gw4 192.168.210.1
sudo nmcli con up vlan210con-name vlan210: Name of the new VLAN connection.dev mainif: Physical interface to tag.id 210: VLAN ID.ip4, gw4: Optional IP and gateway assignment.This will persist the configuration and activate the VLAN interface immediately. Next I moved on to Install the honeypot.
Running the Podman container under a dedicated system user with no login shell is a recommended security best practice. Reasons include:
Privilege Separation: Isolates the container from other system processes and users, limiting the potential impact of a compromise.
Reduced Attack Surface:
The user has no login shell (e.g., /usr/sbin/nologin), meaning it can’t be
used to log into the system interactively.
Auditing & Logging: Helps distinguish container activity in system logs and process lists, making monitoring easier.
Least Privilege Principle: The user has only the permissions necessary to run the container — nothing more.
1. Create the ‘cowrie’ user (no home directory, no login shell)
sudo useradd --system --no-create-home --shell /usr/sbin/nologin cowrie2. Create necessary directories and set ownership
sudo mkdir -p /opt/cowrie/etc
sudo mkdir -p /opt/cowrie/var
sudo mkdir -p /opt/cowrie/var/log/cowrie
sudo chown -R cowrie:cowrie /opt/cowrie3. As the cowrie user, pull the container image
sudo -u cowrie podman pull docker.io/cowrie/cowrie4. Copy default config file into persistent volume
sudo -u cowrie podman run --rm localhost/cowrie_honeypot:latest \
cat /cowrie/cowrie-git/etc/cowrie.cfg.dist > /opt/cowrie/etc/cowrie.cfgThe `cowrie.cfg` file is the main configuration for Cowrie, the SSH/Telnet honeypot we use. It uses INI-style syntax and is divided into sections. Each section begins with a header like [section_name].
📁 Key Sections & Settings
[ssh]
enabled = true
listen_port = 2222[honeypot]
Set honeypot host name and logpath properties:
hostname = cowrie-host
# Directory where to save log files in.
log_path = var/log/cowrieDefine login behavior:
auth_class = AuthRandom
auth_class_parameters = 1, 5, 10I use AuthRandom here which causes to allow access after “randint(2,5)” attempts. This means the threat actor will fail with some logins and some will be logged in immediately.
[output_jsonlog]
[output_jsonlog]
enabled = true
logfile = ${honeypot:log_path}/cowrie.json
epoch_timestamp = falseThis is the whole configuration needed to run the honeypot.
📌 Notes
Once I had created the dedicated system user (see earlier section), I
was able to run the Cowrie container with Podman using sudo -u and UID mapping.
sudo -u cowrie podman run -d --name cowrie \
--uidmap 0:999:1001 \
-v /opt/cowrie/etc:/cowrie/cowrie-git/etc:Z \
-v /opt/cowrie/var:/cowrie/cowrie-git/var:Z \
-p 2222:2222 \
cowrie/cowriesudo -u cowrie: Runs the Podman command as the unprivileged cowrie user.--uidmap 0:999:1001: Maps root (UID 0) inside the container to the cowrie UID on the host.-v /opt/cowrie/etc and /opt/cowrie/var: Mounts configuration and data volumes from the host with `:Z` to apply correct SELinux labels (optional on systems without SELinux).-p 2222:2222: Forwards port 2222 from host to container (Cowrie’s SSH honeypot port).cowrie/cowrie: The container image name (use latest or specific tag as needed).Container runs as non-root on the host:
Even if a process inside the container thinks it’s root, it’s actually limited to the unprivileged cowrie user outside the container.
Enhanced security:
If the container is compromised, the attacker only gets access as the cowrie user — not real root.
Avoids root-equivalent risks: Prevents privilege escalation or access to sensitive host files and devices.
View logs I think to know how to debug the container is important so we start first with the logs:
sudo -u cowrie podman logs -f cowrie
...snip...
[HoneyPotSSHTransport,14,10.0.2.100] Closing TTY Log: var/lib/cowrie/tty/e52d9c508c502347344d8c07ad91cbd6068afc75ff6292f062a09ca381c89e71 after 0.8 seconds
[cowrie.ssh.connection.CowrieSSHConnection#info] sending close 0
[cowrie.ssh.session.HoneyPotSSHSession#info] remote close
[HoneyPotSSHTransport,14,10.0.2.100] Got remote error, code 11 reason: b'disconnected by user'
[HoneyPotSSHTransport,14,10.0.2.100] avatar root logging out
[cowrie.ssh.transport.HoneyPotSSHTransport#info] connection lost
[HoneyPotSSHTransport,14,10.0.2.100] Connection lost after 2.8 seconds
...snip...Restart container If things go left just restart that thing:
sudo -u cowrie podman restart cowrieIn the logs you can see that cowrie is running and accepting SSH connections:
...snip...
[-] CowrieSSHFactory starting on 2222
[cowrie.ssh.factory.CowrieSSHFactory#info] Starting factory <cowrie.ssh.factory.CowrieSSHFactory object at 0x7fb66f26d0>
[-] Ready to accept SSH connections
...snip...When the log says “Ready to accept SSH connections” I tested if I could login:
ssh 192.168.210.3 -p 2222 -l root
root@192.168.210.3 password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@svr04:~# uname -a
Linux svr04 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux
root@svr04:~#Stop container Nothing special here:
sudo -u cowrie podman stop cowrieTo keep your Cowrie container running reliably and restart it if it stops, use a systemd service with restart policies. Please make sure to double check this part on your side as I am no systemd expert at all, for me this just worked.
Create `/etc/systemd/system/cowrie-container.service` with the following content: You can create the systemd file with the command:
sudo -u cowrie podman generate systemd --name cowrie --files --restart-policy=on-failureThe resulting file looks somewhat like this
# container-cowrie.service
# autogenerated by Podman 4.3.1
# Fri Sep 19 10:27:47 CEST 2025
[Unit]
Description=Podman container-cowrie.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/run/user/1001/containers
[Service]
User=cowrie
Group=cowrie
Restart=on-failure
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman start -a cowrie
ExecStop=/usr/bin/podman stop -t 10 cowrie
ExecStopPost=/usr/bin/podman stop -t 10 cowrie
Type=forking
[Install]
WantedBy=default.targetsudo systemctl daemon-reload
sudo systemctl enable --now cowrie-container.serviceTo detect if Cowrie stops accepting connections even if the container is still running, create a health check script running as cowrie:
Create `/usr/local/bin/check_cowrie.sh`:
#!/bin/bash
if ! nc -z localhost 2222; then
echo "Cowrie not responding, restarting container"
/usr/bin/podman restart cowrie
/usr/local/bin/pushover.sh "Cowrie was restarted!"
fiThis restarts the service and sends out a notification via pushover.
Make it executable:
sudo chmod +x /usr/local/bin/check_cowrie.sh
sudo chown cowrie:cowrie /usr/local/bin/check_cowrie.shCreate systemd service `/etc/systemd/system/check_cowrie.service`:
[Unit]
Description=Check Cowrie honeypot health
[Service]
User=cowrie
Group=cowrie
Type=oneshot
ExecStart=/usr/local/bin/check_cowrie.shCreate systemd timer `/etc/systemd/system/check_cowrie.timer`:
[Unit]
Description=Run Cowrie health check every minute
[Timer]
OnBootSec=1min
OnUnitActiveSec=1min
Unit=check_cowrie.service
[Install]
WantedBy=timers.targetEnable and start the timer:
sudo systemctl daemon-reload
sudo systemctl enable --now check_cowrie.timerThe `cowrie` user has no login shell (`/usr/sbin/no login`)
Running Cowrie isolated via Podman increases containment
All files are owned by `cowrie`, no root access required for normal operation
1. Add Elastic’s GPG key and repository
curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elastic.gpg
echo "deb [signed-by=/usr/share/keyrings/elastic.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | \
sudo tee /etc/apt/sources.list.d/elastic-8.x.list2. Update APT and install Filebeat
sudo apt install filebeat3. Edit Filebeat config
sudo mg /etc/filebeat/filebeat.ymlThe filebeat config is straight forward. You have to write a filebeat.input block which contains the path where the logfiles are you need to ingest. And at the end the log-destination (logstash) so that filebeat knows where to send the logs to:
filebeat.inputs:
- type: log
enabled: true
paths:
- /opt/cowrie/var/log/cowrie/cowrie.json
json.keys_under_root: true
json.add_error_key: true
fields:
source: cowrie
fields_under_root: true
output.logstash:
hosts: ["192.168.123.5:5044"]4. (Optional) Test Filebeat config
sudo filebeat test config
logstash: 192.168.210.5:5044...
connection...
parse host... OK
dns lookup... OK
addresses: 192.168.210.5
dial up... OK
TLS... WARN secure connection disabled
talk to server... OK5. Enable and start Filebeat
sudo systemctl enable filebeat
sudo systemctl daemon-reload
sudo systemctl start filebeat6. Check Filebeat status and logs
sudo systemctl status filebeat
sudo journalctl -u filebeat -f1. We deployed Cowrie like pros.
2. Logs? Sorted.
3. Everything’s persistent.
4. Setup is clean and modular.
5. It’s nerdy, useful, and kinda fun.
Next I build the HTTP Honeypot
Monitoring a router is something many people forget about, especially at home. But a router is the heart of the network — when it fails, everything fails.
OpenBSD already provides a strong foundation for reliability and security. By adding Monit (a lightweight monitoring tool) and using Pushover (simple mobile notifications), you can build a robust alerting and monitoring setup that works even on small hardware.
This article shows how to install, configure, and use Monit to watch essential router services and send push notifications with Pushover.
To follow this guide you need:
All configuration happens in /etc/monitrc.
Installing Monit on OpenBSD is simple:
pkg_add monitAfter installation, enable Monit so that it starts automatically:
echo "monit_flags=" >> /etc/rc.conf.local
rcctl enable monit
rcctl start monitMonit’s main configuration file is:
You must set permissions correctly, because Monit refuses unsafe files:
chmod 600 /etc/monitrcSystem monitoring runs every 45 seconds. The first check is delayed by 120 seconds to avoid overloading the system immediately after boot.
set daemon 45
with start delay 120Monit logs to syslog. `idfile` and `statefile` store Monit’s persistent state and identity across restarts.
set log syslog
set idfile /var/monit/id
set statefile /var/monit/stateLimits control buffer sizes and timeouts for program outputs, network I/O, and service start/stop/restart operations. This prevents Monit from hanging or processing excessive data.
set limits {
programOutput: 512 B,
sendExpectBuffer: 256 B,
fileContentBuffer: 512 B,
httpContentBuffer: 1 MB,
networkTimeout: 5 seconds
programTimeout: 300 seconds
stopTimeout: 30 seconds
startTimeout: 30 seconds
restartTimeout: 30 seconds
}Monit will send alerts via local email. Events are queued under `/var/monit/events` to prevent message loss during temporary network problems.
set mailserver localhost
set eventqueue
basedir /var/monit/events
slots 200
set mail-format { from: root@monit }
set alert root@localhost not on { instance, action }Simply comment out or delete all `set alert` entries:
# set alert root@localhost not on { instance, action }After this, Monit will not send any emails, but it will still monitor services.
Monit HTTP interface is on port 2812. Access is restricted to localhost, a local subnet (`192.168.X.0/24`), and an admin user with a password.
set httpd port 2812 and
allow localhost
allow 192.168.X.0/255.255.255.0
allow admin:foobarMonit will start all monitored services automatically on reboot.
set onreboot startThis monitors overall system health:
If thresholds are exceeded, it triggers `pushover.sh` for alerts.
check system $HOST
if loadavg (1min) per core > 2 for 5 cycles then exec /usr/local/bin/pushover.sh
if loadavg (5min) per core > 1.5 for 10 cycles then exec /usr/local/bin/pushover.sh
if cpu usage > 95% for 10 cycles then exec /usr/local/bin/pushover.sh
if memory usage > 75% then exec /usr/local/bin/pushover.sh
if swap usage > 25% then exec /usr/local/bin/pushover.sh
group system`/home` filesystem is monitored for:
Alerts are sent via `pushover.sh` if any threshold is exceeded.
check filesystem home_fs with path /dev/sd0k
start program = "/sbin/mount /home"
stop program = "/sbin/umount /home"
if space usage > 90% then exec /usr/local/bin/pushover.sh
if inode usage > 95% then exec /usr/local/bin/pushover.sh
if read rate > 8 MB/s for 20 cycles then exec /usr/local/bin/pushover.sh
if read rate > 800 operations/s for 15 cycles then exec /usr/local/bin/pushover.sh
if write rate > 8 MB/s for 20 cycles then exec /usr/local/bin/pushover.sh
if write rate > 800 operations/s for 15 cycles then exec /usr/local/bin/pushover.sh
if service time > 10 milliseconds for 3 times within 15 cycles then exec /usr/local/bin/pushover.sh
group systemRoot filesystem `/` has similar checks but shorter cycles since it’s critical to system stability.
check filesystem root_fs with path /dev/sd0a
start program = "/sbin/mount /"
stop program = "/sbin/umount /"
if space usage > 90% then exec /usr/local/bin/pushover.sh
if inode usage > 95% then exec /usr/local/bin/pushover.sh
if read rate > 8 MB/s for 5 cycles then exec /usr/local/bin/pushover.sh
if read rate > 800 operations/s for 5 cycles then exec /usr/local/bin/pushover.sh
if write rate > 8 MB/s for 5 cycles then exec /usr/local/bin/pushover.sh
if write rate > 800 operations/s for 5 cycles then exec /usr/local/bin/pushover.sh
if service time > 10 milliseconds for 3 times within 5 cycles then exec /usr/local/bin/pushover.sh
group systemMonit ensures secure permissions for `/root`. If permissions are wrong, monitoring for this directory is disabled to avoid false alarms.
check directory bin with path /root
if failed permission 700 then unmonitor
if failed uid 0 then unmonitor
if failed gid 0 then unmonitor
group systemA network host is ping-checked. Frequent failures trigger alerts. Dependencies on interfaces and services ensure checks only run when the network is up.
check host homeassistant with address 192.168.X.19
if failed ping then alert
if 5 restarts within 10 cycles then exec /usr/local/bin/pushover.sh
group network
depends on iface_in,dhcpd,unboundMonit watches network interface `pppoeX`:
check network iface_out with interface pppoeX
start program = "/bin/sh /etc/netstart pppoeX"
if link down then restart else exec /usr/local/bin/pushover.sh
if changed link then exec /usr/local/bin/pushover.sh
if saturation > 90% then exec /usr/local/bin/pushover.sh
if total uploaded > 5 GB in last hour then exec /usr/local/bin/pushover.sh
if 5 restarts within 10 cycles then exec /usr/local/bin/pushover.sh
group networkDNS resolver `unbound` is monitored by PID and port. Failures trigger a restart, repeated failures trigger alerts.
check process unbound with pidfile /var/unbound/unbound.pid
start program = "/usr/sbin/rcctl start unbound"
stop program = "/usr/sbin/rcctl stop unbound"
if failed port 53 for 3 cycles then restart
if 3 restarts within 10 cycles then exec /usr/local/bin/pushover.sh
group network
depends on dnscrypt_proxy,iface_out,iface_inDHCP server is monitored. Missing process triggers a restart. Alerts are sent if failures happen repeatedly.
check process dhcpd with matching /usr/sbin/dhcpd
start program = "/usr/sbin/rcctl start dhcpd"
stop program = "/usr/sbin/rcctl stop dhcpd"
if does not exist then restart
if 2 restarts within 10 cycles then exec /usr/local/bin/pushover.sh
group network
depends on iface_inNTP daemon ensures time synchronization. Missing process triggers restart; repeated issues generate alerts.
check process ntpd with matching /usr/sbin/ntpd
start program = "/usr/sbin/rcctl start ntpd"
stop program = "/usr/sbin/rcctl stop ntpd"
if does not exist then restart
if 5 restarts within 5 cycles then exec /usr/local/bin/pushover.sh
group network
depends on iface_outvnStat daemon monitors network traffic statistics. Monit restarts it if it stops and alerts on repeated failures.
check process vnstatd with matching /usr/local/sbin/vnstatd
start program = "/usr/sbin/rcctl start vnstatd"
stop program = "/usr/sbin/rcctl stop vnstatd"
if does not exist then restart
if 5 restarts within 15 cycles then exec /usr/local/bin/pushover.sh
group network
depends on iface_outPushover provides a simple HTTPS API for sending notifications to your phone.
Monit can call an external script. Create /usr/local/bin/pushover.sh:
#!/bin/sh
TOKEN="YOUR_PUSHOVER_API_TOKEN"
USER="YOUR_PUSHOVER_USER_KEY"
/usr/local/bin/curl -s \
-F "token=$TOKEN" \
-F "user=$USER" \
--form-string "message=[$MONIT_HOST] $MONIT_SERVICE - $MONIT_EVENT - $MONIT_DESCRIPTION" \
https://api.pushover.net/1/messages.jsonMake it executable:
chmod +x /usr/local/bin/pushover.shNow the checks which contain the “exec /usr/local/bin/pushover.sh” line will trigger pushover notifications:
check process vnstatd with matching /usr/local/sbin/vnstatd
start program = "/usr/sbin/rcctl start vnstatd"
stop program = "/usr/sbin/rcctl stop vnstatd"
if does not exist then restart
if 5 restarts within 15 cycles then exec /usr/local/bin/pushover.sh
group network
depends on iface_outMonit will automatically send the full text of the event to Pushover.
monit -t # syntax check
monit reload # reload configuration
monit summary # Show command line overview
monit status vnstatd # Show check statusUsing Monit together with Pushover is an excellent way to keep a close eye on an OpenBSD router. Monit is tiny, fast, and reliable — perfect for embedded hardware. Pushover provides instant alerts with almost no configuration or overhead.
For a home router or small business network, this combination gives you semi professional-grade monitoring with minimal effort.
If you’re running Elasticsearch on a single node — like a Raspberry Pi or small lab setup like I am —
you might notice some indices appear with a yellow health status.
This show article explains what that means and how to fix it, especially in resource-constrained, single-node environments.
In Elasticsearch:
green: All primary and replica shards are assigned and active.yellow: All primary shards are active, but at least one replica shard is unassigned.red: At least one primary shard is missing → critical!In single-node clusters, Elasticsearch cannot assign replica shards (because replicas must be on a different node). So any index with replicas will always be yellow unless:
number_of_replicas: 0)GET _cat/indices?v&health=yellowGET _cluster/allocation/explainGET _cat/shards/.monitoring-beats-7-2025.08.06?vExample output:
index shard prirep state docs store ip node
.monitoring-beats-7-2025.08.06 0 p STARTED 7790 5.9mb 127.0.0.1 mynode
.monitoring-beats-7-2025.08.06 0 r UNASSIGNED→ The r (replica) is unassigned → yellow status.
Set replicas to zero:
PUT .monitoring-beats-7-2025.08.06/_settings
{
"index" : {
"number_of_replicas" : 0
}
}This changes the index health from yellow to green.
If you want to automate the fix, use this (Kibana Dev Tools):
GET _cat/indices?health=yellow&format=jsonThen for each index in the result:
POST <your_index>/_settings
{
"index": {
"number_of_replicas": 0
}
}Disable replicas by default using an index template:
PUT _template/no-replica-default
{
"index_patterns": ["*"],
"settings": {
"number_of_replicas": 0
}
}> ⚠️ This applies to all future indices. Only do this in single-node environments.
Yellow indices aren’t dangerous by default — they just mean you’re missing redundancy. In small environments, it’s perfectly safe to run with zero replicas.
Just don’t forget to:
So I had this USB Disk attached to my OpenBSD Router used as storage, one saturday when I was walking by I noticed the weird clicking sounds from the disk. So I knew my time was running before the disc would fail.
Curiously, when I plugged the same drive into a Linux box, it was detected — and even showed a valid OpenBSD partition table. That gave me a glimmer of hope: maybe the hardware wasn’t completely dead yet.
So, for fun (and a little bit of stubborn curiosity), I decided to spend the weekend seeing how much I could rescue from it.
This post documents the process — part forensic experiment, part recovery attempt, and part “let’s see what happens if I do this.”
Before doing anything risky, I wanted to be sure I was imaging the right disk. The idea was to identify the OpenBSD partition and dump it to an image file.
lsblk -o NAME,SIZE,FSTYPE,TYPE,LABEL,UUIDThat gives a good overview — which disks are present, how large they are, and what filesystems they contain. Sure enough, my external USB drive showed up as `/dev/sda`.
sudo fdisk -l /dev/sdaExample output:
Disk /dev/sda: 931.5 GiB, 1000204883968 bytes, 1953525164 sectors
Disk model: External USB 3.0
Sector size: 512 bytes
Disklabel type: dos
Device Boot Start End Sectors Size Id Type
/dev/sda4 * 64 1953525163 1953525100 931.5G a6 OpenBSDPerfect. The OpenBSD partition was still there (`/dev/sda4`), and it even reported the correct size.
At this point, the goal was to make a bit-for-bit copy of that partition, compress it, and work on the image rather than risk further damage to the actual disk.
For imaging, I decided to use GNU ddrescue — it’s great for
flaky disks and can retry sectors intelligently.
On Fedora, installation was trivial:
sudo dnf install ddrescueI tried a fast, one-shot dump — not ideal for a failing disk, but I wanted to see if it would work at all:
sudo ddrescue -d -r3 /dev/sda4 - - | xz -T0 -c > openbsd_sda4.img.xzThat command streams data directly from the device, compresses it with xz, and writes the result.
It works — if the disk is healthy. Mine wasn’t, so it failed partway through.
So I switched to the safer, resumable method:
sudo ddrescue -d -r3 /dev/sda4 openbsd_sda4.img openbsd_sda4.log
xz -T0 openbsd_sda4.img
sha256sum openbsd_sda4.img > openbsd_sda4.img.sha256This time, ddrescue created a detailed log file so I could resume later if the system froze or the disk disconnected. It took most of the night, but eventually I had a clean (or mostly clean) image.
Explanation of parameters
-r3 retries each bad block 3 times-d enables direct disk I/Oxz -T0 uses all CPU cores for compressionAfter the dump, I verified the output:
ls -lh openbsd_sda4.img.xz
xz -t openbsd_sda4.img.xz # test integrity
sha256sum openbsd_sda4.img.xz > openbsd_sda4.img.xz.sha256Everything checked out — a ~450 GB compressed image file safely sitting on my main system.
Since the real disk was unstable, I wanted a safe way to experiment. So I created a copy of the image and simulated damage to practice recovery techniques.
sudo dd if=/dev/sda4 of=openbsd_sda4.img bs=4M status=progressTo emulate bad sectors:
dd if=/dev/zero of=openbsd_sda4.img bs=512 count=10 seek=1000 conv=notruncNow the image contained 10 intentionally corrupted sectors — perfect for testing.
ddrescue -d -r3 openbsd_sda4.img openbsd_sda4_recovered.img openbsd_sda4_recovery.logAnd just like that, I could practice recovery without touching the actual hardware again.
xz -T0 openbsd_sda4.imgIt’s amazing how much you can still do with raw disk images and a few classic Unix tools.
During the rescue, I learned (the hard way) that ddrescue can saturate I/O and make your system lag like crazy.
So I ended up using this combination for a gentler approach:
sudo ionice -c2 -n7 nice -n19 ddrescue -b 4096 -B 4096 /dev/sda4 openbsd_sda4.imgAnd, for long operations, running it inside tmux:
tmux new-session -s rescue
sudo ddrescue -d -r3 /dev/sda4 openbsd_sda4.img openbsd_sda4.log
# Detach with Ctrl-B DLater, I could simply:
tmux attach -t rescueThat setup saved me more than once when I accidentally closed an SSH session.
Once I had a full image, the plan was to:
unxz openbsd_sda4.img.xz)vnconfig under OpenBSDsoftraid volume using bioctlThat’s a topic for another weekend. But getting to this point already felt like a small victory.
What started as a “let’s see if I can still read this disk” experiment turned into a proper mini-forensics exercise. Even though the original USB drive was dying, I managed to preserve most of its data and learned a ton in the process.
Allover it was quite fun to do something forensics related on a OpenBSD target, I guess it is something you don’t come across everyday but when you do its good to be prepared I think.
Key takeaways:
ddrescue is your friend for unstable mediaNot a bad way to spend a weekend.
Depending on USB speed:
dd, ddrescue, xzfdisk, lsblk, sha256sumtmux, ionice, dstat, iotopIn an age where digital identities are easily faked and impersonation is just a few clicks away, I decided to take a step forward in securing mine. GPG (GNU Privacy Guard) provides a robust way to authenticate, encrypt, and sign digital content. In this post, I’ll walk you through how I:
To start, I made sure GPG was installed. Here’s how I did it on each of my systems:
On Ubuntu/Debian:
sudo apt update && sudo apt install gnupgOn Fedora 40:
sudo dnf install gnupg2On OpenBSD 7.6:
doas pkg_add gnupgCheck your installation:
gpg --versionI created a new key using:
gpg --full-generate-keyHere’s what I chose:
ed25519 (modern and compact) or RSA and RSA (widely compatible)After generating the key, I listed it and saved the fingerprint:
gpg --list-keys --fingerprint
gpg: "Trust-DB" wird überprüft
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: Tiefe: 0 gültig: 1 signiert: 0 Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u
gpg: nächste "Trust-DB"-Pflichtüberprüfung am 2026-08-04
[keyboxd]
---------
pub ed25519 2025-08-04 [SC] [verfällt: 2026-08-04]
A371 9309 4ED4 B0E6 AD2E 5022 D7D6 4842 8DBD 39FD
uid [ ultimativ ] Dirk.L (Dirk.L's official key) <polymathmonkey@keksmafia.org>I created subkeys for:
Then, I moved the subkeys to my YubiKey using GPG’s interactive editor:
gpg --edit-key Dirk.L
gpg> addkey <- once for signing, engryption, auth
gpg> keytocard
gpg> save⚠️ Be cautious: Once moved to the YubiKey, the subkey no longer exists on disk.
More guidance: YubiKey + GPG official instructions
I exported my key in ASCII format so others could import it easily:
gpg --export --armor you@example.com > publickey.ascI uploaded publickey.asc to my website and linked it like this:
<a href="/publickey.asc">🔑 Download my GPG public key</a>Additionally, I displayed my key’s fingerprint on the page so that people can verify its authenticity manually.
I configured email signing using my GPG key.
For Thunderbird (Linux, OpenBSD, Windows):
For Mutt / CLI mailers:
.muttrc to sign and/or encrypt automatically.Signing ensures message authenticity. If recipients have my key, they can encrypt replies.
To safely share personal certificates and private files, I signed and optionally encrypted them:
# Sign only (adds signature block)
gpg --sign --armor diploma.pdf
# Sign and encrypt with a password (no public key needed)
gpg --symmetric --armor --cipher-algo AES256 diploma.pdfThis way, the document is verifiably mine and only decryptable with the shared password.
The encrypted .asc files can be uploaded to the website, with instructions for downloading and decrypting.
Before moving entirely to the YubiKey, I backed up the master key offline:
gpg --export-secret-keys --armor > masterkey-backup.ascI stored it on an encrypted USB drive with either one:
Rolling out GPG was super easy. With my identity cryptographically verifiable, email signing in place, and secure document sharing live on my site, I now have a strong, decentralized identity system.