Rampart

Self-hosted security and reliability stack. TLS, intrusion detection, secret and vulnerability scanning, identity. Docker-first, pinned,...
Location hidden
•Created byProfile pictureDoctor Doom
1 joined
Profile picture
Doctor DoomProfile picture@doctordoompro·Oct 3

Scanning your own hosts, legally and usefully

Running Nuclei against your own infrastructure is one of the highest

return-per-minute things you can do.


nuclei -u https://your-host -severity high,critical


It runs community templates for known exposures - default credentials, exposed

admin panels, known CVEs in common software. Most of what it finds on a

self-hosted stack is something you forgot was reachable.


Two things worth being clear about:


Only scan what you own. Pointing these tools at third parties is both

ineffective and illegal. There is no version of this that ends well.


Findings are not all equal. A hundred low-severity results matter less than

one exposed admin panel. Triage by reachability, not by count.


What has Nuclei or Trivy actually caught for you? I am more interested in the

embarrassing finds than the impressive ones.

Profile picture
Doctor DoomProfile picture@doctordoompro·Oct 3

The secret you already committed

Most breaches are not clever. They are an API key in a repository.


If you have pushed code and ever had a key in it, assume it is compromised -

even if you deleted the file. Git history is forever, and scrapers watch

public repos continuously.


Check your own history:


gitleaks detect --source . -v


Anything it finds is already public if the repo is. Rotate the key first.

Cleaning the history afterwards is tidiness; rotation is the actual fix.


Then stop the next one with a pre-commit hook:


cat > .git/hooks/pre-commit <<'EOF'
#!/bin/sh
gitleaks protect --staged -v
EOF
chmod +x .git/hooks/pre-commit


A hook takes two minutes and has no downside. What is your setup for this?

Profile picture
Doctor DoomProfile picture@doctordoompro·Oct 3

What is actually exposed on your network?

Most people do not know. Not in a careless way - it is just that ports

get opened for one thing and never closed.


Worth doing once: list what is listening and what reaches the internet.


ss -tlnp


Then, from outside your network, scan your own public IP. Anything answering

that you did not intend is the whole problem.


The common finds:


  • a database on 5432 or 3306, meant for localhost

  • an admin panel on a high port with no auth

  • a service that was behind a proxy once and now is not


The fix is usually not a firewall rule. It is putting everything behind one

reverse proxy and only exposing 80 and 443.


What did you find the first time you actually looked?