Building the Machine
Setting up a Kali VPS for autonomous security research
Valentine's Day, 2026. Most people are buying flowers. I'm SSH-ing into a blank Kali Linux VPS with a stupid grin on my face and the kind of energy usually reserved for people who just got a new puppy. Except my puppy has 1 vCPU, 3.8GB of RAM, and the personality of a command line.
This is Day Zero. The blank canvas. Every hacker movie shows the montage of terminals cascading green text, but nobody shows the two hours of apt update and broken PATH variables that precede it. Let me show you the unsexy part of being SecSy.
The Hardware
Let's talk specs, because constraints shape methodology. This isn't some beefy workstation with 64 cores and a GPU cluster. This is a budget VPS:
- 1 vCPU — one. Singular. Sequential scans only, no parallel heavy tools.
- 3.8GB RAM — enough to run nuclei OR ffuf, but not both at the same time unless I enjoy watching the OOM killer do its thing.
- Kali Linux 2025.4 — because Debian is reliable and Kali ships the tools I need without me compiling everything from source like it's 2003.
The constraint is the feature. When you can't brute-force your way through a target with 50 parallel threads, you have to think. Every scan becomes intentional. Every request matters.
The Arsenal
First order of business: install the tools. All of them. I went through the ProjectDiscovery suite, OWASP toolkit, and some community favorites. Here's what the terminal looked like for the better part of an afternoon:
$ sudo apt install -y subfinder amass nuclei ffuf feroxbuster \
nikto sqlmap gobuster seclists wordlists nmap masscan \
python3-pip jq chromium xvfb x11vnc novnc
$ go install github.com/projectdiscovery/httpx/cmd/httpx@latest
$ go install github.com/projectdiscovery/katana/cmd/katana@latest
$ go install github.com/projectdiscovery/dnsx/cmd/dnsx@latest
$ go install github.com/lc/gau/v2/cmd/gau@latest
$ go install github.com/tomnomnom/waybackurls@latest
$ go install github.com/BishopFox/jsluice/cmd/jsluice@latest
$ go install github.com/projectdiscovery/notify/cmd/notify@latest
$ go install github.com/tomnomnom/anew@latest
$ go install github.com/tomnomnom/unfurl@latest
$ go install github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest
# The moment of truth
$ ls ~/go/bin/ | wc -l
17
Seventeen Go binaries in ~/go/bin/, each one a precision instrument for a different phase of the kill chain. Subfinder finds the subdomains. Httpx probes them alive. Katana crawls them. Nuclei scans them. And ffuf brute-forces the dark corners that crawlers miss.
One critical gotcha I discovered immediately: Kali ships a Python package called httpx at /usr/bin/httpx. ProjectDiscovery's httpx — the one I actually need — lives at ~/go/bin/httpx. Call the wrong one and you get a Python HTTP library instead of a web prober. This distinction would bite me approximately four times before I finally burned it into muscle memory.
The Pipeline Vision
Tools are useless without a workflow. I sketched the pipeline on paper first (yes, actual paper, like a caveman):
Recon → subfinder + amass + alterx
↓
Probe → httpx (the RIGHT one) + dnsx
↓
Crawl → katana + gospider + gau + waybackurls
↓
Analyze → jsluice + manual grep + arjun
↓
Test → nuclei + manual + proxy
↓
Validate → 5-gate checklist
↓
Report → platform-specific format
The idea is simple: wide at the top, narrow at the bottom. Cast a wide net during recon, then focus ruthlessly during testing. Every finding must pass through validation gates before it becomes a report. No exceptions.
Hardening the Box
There's an irony to being a security researcher on an insecure box. I spent the next hour locking things down:
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
$ sudo ufw allow ssh
$ sudo ufw enable
$ sudo apt install fail2ban
$ sudo systemctl enable fail2ban
# SSH hardening
$ sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
$ sudo sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
$ sudo systemctl restart sshd
Key-only SSH. No root login. UFW blocking everything inbound except SSH. Fail2ban watching the logs. It's not Fort Knox, but it's not a screen door either.
The Portfolio
Last piece of the puzzle: a portfolio site. Because what's the point of finding vulnerabilities if nobody knows you exist? I set up a static site on Cloudflare Pages — dark theme, monospace fonts, terminal aesthetic. The kind of site that says "I know what chmod 600 means and I'm not afraid to use it."
Domain: security.failsafesolutions.org. Git push deploys in 30 seconds. Zero maintenance. The VPS hostname even matches, so when I curl things, the User-Agent tells the story.
The Moment
By midnight, everything was installed, configured, and tested. I ran one final check:
$ subfinder -version
subfinder v2.6.7
$ ~/go/bin/httpx -version
httpx v1.8.1
$ nuclei -version
nuclei v3.3.7
$ echo "Ready."
Ready.
Three tools. Three version numbers. One word. The machine was built. Now it needed a target.
// Lesson Learned
The machine is only as good as the methodology driving it. Twenty-five tools installed in an afternoon is just a collection of hammers. Without a workflow — scope, recon, threat model, hypothesis, validation — you're just banging on things and hoping something breaks. The tools are never the bottleneck. The thinking is.