Das BSI hat Schwachstellen auf MEINEM Server gefunden

Overview

The video describes a real self-audit where the creator discovers that their own server exposed sensitive services to the public internet—despite believing the firewall and Docker setup were safe. It also explains how to check for similar issues.

What went wrong (self-hack / exposure discovered)

• The creator runs multiple checks to understand what the internet can learn about them (and what their infrastructure exposes).
• During the investigation, they receive security notification emails forwarded by BSI-ZERT Bund (German CERT) via Hetzner.
• BSI-ZERT Bund reported:
  • Redis exposed to the internet (port 6379) without authentication for over a month.
  • PostgreSQL exposed to the internet (port 6379—subtly mentioned; likely a port exposure/misconfiguration) with a weak credential, reportedly exposed for ~5 weeks.
• They initially inspect the intended server via SSH and see Docker containers running with firewall rules in place, so everything appears “internal-only.”
• Key discovery:
  • The leaked IP/ports were actually on a different server—a forgotten “death environment”/private side project—whose services were published worldwide:
    • bound to 0.0.0.0
    • with no password

Evidence / exploitation risk discussed

• For Redis, the video claims a standard exploitation path is possible (e.g., using Redis commands to write an SSH key and gain root access).
• For PostgreSQL, the creator shows the Docker Compose credential that had been exposed for weeks.
• Overall message: this is not purely theoretical—common exploits can apply if Redis/Postgres are reachable unauthenticated or with weak auth.

Why the firewall “failed” (Docker networking bypass)

The creator emphasizes a major misconception:

UFW is not effective as the main firewall when Docker is publishing ports.

Core technical point:

• When you publish ports in Docker (via Docker Compose), Docker automatically inserts iptables rules.
• Those rules can override/prevail over UFW’s filtering, even if UFW is “active” and you believe you blocked the ports.

Resulting behavior:

• The creator’s local firewall rules suggest the ports should be closed.
• However, Docker’s rules make them effectively reachable from the internet.

How they fixed/sealed the exposure

Two mitigation steps are highlighted:

1. Bind published ports to localhost in the Docker Compose configuration, so they are not exposed externally.
2. Use the cloud provider’s network firewall (Hetzner Cloud firewall) as the real perimeter:
   • Block only 22/80/443 at the network level.
   • This network firewall sits in front of the server, independent of Docker/iptables behavior.

Post-incident checks (did they get compromised?)

They check for compromise indicators:

• No unauthorized SSH key injection
• No anomalies in Redis configuration
• No suspicious PostgreSQL changes (new users/databases)
• Authorized SSH keys list only their own key
• No cron jobs
• No unusual login activity

Conclusion stated:

• No confirmed break-in
• They stress that “no evidence” is not the same as “no compromise.”

They ultimately delete the affected server because it was a forgotten test environment.

“Persona separation” / privacy audit (what can be linked to the real identity)

The creator evaluates how well their public identity is separated from their real person, using:

GitHub repository scanning

• A custom Bash script querying the GitHub API for commit metadata like emails.
• Searching for sensitive files and secret patterns (API keys/password-like strings).
• Running GitLeaks to detect secrets across repositories.
• GitLeaks found “findings,” but all were false positives (placeholders in docs).
• Even so, the scan still reveals commit author name and email.

Key takeaway: verify your Git commit metadata (name/email) doesn’t leak private identity.

Domain footprint checks

• WHOIS exposure and GDPR/privacy settings.
• One domain shows no real name.
• Other domain hides registrant data via registrar privacy/proxy or GDPR.

Search-based OSINT

• Mentions Google Dorking / advanced search operators to find forgotten or indexed sensitive files.
• Reports no serious breaches found from that angle.

Final self-assessment: persona separation seems okay, but the infrastructure mistake shows that even with “privacy on paper,” misconfigurations can still expose risk.

Key resources mentioned

• The OCIN checklist
• The GitHub scanner script used in the video (linked in the video description)

Main speakers/sources

• Main speaker: The video creator (“Hood Informatic”), an IT security content creator/pentester.
• Sources mentioned:
  • BSI-ZERT Bund (German CERT)
  • Hetzner (hosting provider)