Einige Links auf dieser Seite sind Affiliate-Links: bei einer Anmeldung darüber erhält diese Seite eine Provision, für Sie ohne Mehrkosten. Preise und Empfehlungen bleiben davon unberührt.

Jemand drückt Ihnen das Root-Passwort einer Maschine in die Hand, die seit Jahren läuft. Sie bedient echte Seiten, niemand weiß mehr genau, wie sie aufgesetzt wurde, und die Person, die sie aufgesetzt hat, ist weg.

Die Versuchung ist, gleich das große Ding anzugehen: neu aufbauen, migrieren, containerisieren. Machen Sie zuerst das kleine Ding. Eine Stunde, fünf Fragen, und Sie wissen, ob die Maschine ein Ärgernis ist oder ein Notfall.

Das ist das Audit, das wir letzte Woche auf genau so einer Box gefahren haben, mit dem, was dabei tatsächlich zum Vorschein kam. Jeder Befund unten ist real, und keiner davon war von außen sichtbar.

1. Was lauscht, und was glaubt die Firewall?

Diese beiden Antworten gehören immer verglichen, nie getrennt gelesen. Die erste ist die Wahrheit über die Maschine, die zweite ist das, was irgendwann einmal beabsichtigt war.

ss -tlnp                     # jeder lauschende TCP-Socket, mit Prozess
iptables -L INPUT -n --line-numbers

Unser Fund, und das ist der eine, den man sich aus diesem Artikel mitnehmen sollte: Die Firewall hatte eine sorgfältige Allowlist für den Admin-Panel-Port, drei vertrauenswürdige Subnetze, geschrieben von jemandem, der wusste, was er tat. Vier Zeilen darüber saß ein pauschales ACCEPT für denselben Port aus 0.0.0.0/0, später hinzugefügt.

iptables wertet der Reihe nach aus und stoppt beim ersten Treffer. Die Allowlist hatte seit dem Moment, in dem diese Zeile hinzugefügt wurde, niemals weniger als jeden erlaubt. Der Admin-Login stand seit Jahren offen im Internet, hinter einer Regel, die auf den ersten Blick wie eine Einschränkung aussah.

Lesen Sie Ihre Regeln von oben nach unten, mit Zeilennummern, und fragen Sie sich, was zuerst greift. Eine Regelliste ist ein Programm, keine Menge.

2. Wer benutzt das tatsächlich, was Sie gerade schließen wollen?

Die nützlichste Gewohnheit des gesamten Audits. Bevor Sie einen Zugangsweg schließen, lesen Sie dessen Access-Log und zählen Sie die echten Nutzer.

# Top-Zugriffe auf einen Pfad, letzte 10k Zeilen
grep -h 'phpmyadmin' /var/log/nginx/*access* | awk '{print $1}' \
  | sort | uniq -c | sort -rn | head

Zwei unserer Befunde kamen direkt daraus:

  • Ein phpMyAdmin aus dem Jahr 2017, aus dem Internet erreichbar, auf einem Webserver, dessen PHP keine Upstream-Patches mehr bekam. Das Log zeigte 201 Requests von einer Adresse und 38 von einer anderen, beides Scanner, die eine Wortliste durchgingen. Keine einzige menschliche Sitzung im gesamten Zeitfenster.
  • proftpd lief, im Klartext, ohne TLS. xferlog war seit Juni leer. Die einzigen Verbindungen waren anonymous-Login-Versuche aus einem Botnet.

Beides war in Minuten geschlossen, ohne Risiko, irgendjemandes Arbeitsablauf zu zerstören, weil die Logs bewiesen, dass es keinen Arbeitsablauf gab. Hätten die Logs tägliche Sitzungen von einer Büro-IP gezeigt, wäre die Antwort eine Allowlist und ein Gespräch gewesen, keine Abschaltung.

Die Regel: Schließen Sie niemals einen Dienst, weil Sie glauben, dass niemand ihn nutzt. Schließen Sie ihn, weil Sie es belegen können. Beides fühlt sich gleich an, bis die Buchhaltung anruft.

3. Sich nicht selbst aussperren

Alles in diesem Abschnitt ist Firewall-Arbeit auf einer Maschine, die Sie nur durch genau diese Firewall erreichen. Zwei Vorsichtsmaßnahmen, beide billig.

Richten Sie einen Auto-Revert ein, bevor Sie irgendetwas scharf schalten. Ein Timer, der das bekannt-gute Regelwerk nach zehn Minuten wiederherstellt, den Sie von Hand abbrechen, sobald Sie bestätigt haben, dass Sie noch hereinkommen:

iptables-save > /root/iptables.good
echo 'iptables-restore < /root/iptables.good' | at now + 10 minutes

Wenden Sie Ihre Änderung an, öffnen Sie eine brandneue SSH-Sitzung von anderswo, und brechen Sie den Job erst dann mit atrm ab. Ein Test in der Sitzung, die Sie schon offen haben, beweist nichts: Eine bestehende Verbindung überlebt Regeln, die neue blockieren.

Dann machen Sie es reboot-fest, ein eigener Schritt, und der, den man am ehesten vergisst:

service iptables save          # oder: netfilter-persistent save
systemctl is-enabled iptables

Unsere Maschine rebootete nach einem wöchentlichen Zeitplan, von dem wir nichts wussten. Die Härtung war danach noch da, weil die Regeln gesichert waren, und wir wussten es, weil wir nach dem Reboot nachgeprüft haben, statt es einfach anzunehmen.

4. Was erneuert sich selbst, und was sieht nur so aus?

Der stille Killer. Auf dieser Box lief die TLS-Erneuerung als Job innerhalb eines Control Panels, dessen Lizenz zwei Monate zuvor abgelaufen war. Der Erneuerungs-Cron starb mit der Lizenz. Vier Seiten scheiterten bereits seit fünf Tagen am TLS-Handshake, bevor das Audit es fand, und sieben weitere waren so geplant, dass sie innerhalb von drei Wochen abliefen.

# jeder geplante Job auf der Box, in einem Durchgang
crontab -l; ls -l /etc/cron.*/ /etc/cron.d/; systemctl list-timers --all

Lesen Sie alles, auch die auskommentierten Zeilen, denn sie zeigen, was früher lief. Und achten Sie auf Duplikate: Wir haben einen Erneuerungs-Cron deaktiviert und erst im zweiten Durchgang einen zweiten gefunden, denselben Job, andere Uhrzeit, vier Zeilen weiter unten.

Die Erneuerung zurückzuholen ist selbst auf einer End-of-Life-Distribution eine kurze Aufgabe - wir haben es aufgeschrieben in acme.sh auf einem Server, auf dem sich certbot nicht installieren lässt.

5. Was ist installiert, das niemand benutzt?

Legacy-Boxen sammeln Laufzeitumgebungen an. Unsere hatte elf separate PHP-Builds, zurückreichend bis 5.2. Die interessante Frage ist nicht, was installiert ist, sondern was tatsächlich verdrahtet ist:

grep -rhoE 'php[0-9]+' /etc/nginx/conf.d/*.conf /etc/httpd/conf.d/*.conf \
  | sort | uniq -c | sort -rn

Acht Seiten liefen auf 7.4, drei auf 8.0, und jeder ältere Build war toter Ballast. Dieser eine Befehl änderte den gesamten Migrationsplan: Eine Maschine, die aussieht, als bräuchte sie eine Hosting-Plattform mit PHP-5.2-Support, braucht tatsächlich 7.4 und 8.x, also so gut wie alles Moderne.

Ein Audit geht nicht nur darum, was man schließt. Es geht auch darum, zu entdecken, dass der beängstigende Teil der Arbeit gar nicht existiert.

Was eine Stunde gebracht hat

Vier Befunde auf einer Maschine: eine Allowlist, die jeden durchließ, ein neun Jahre altes Admin-Tool, offen für Scanner, ein FTP-Daemon, der niemandem diente, und eine Zertifikatserneuerung, die seit zwei Monaten tot war, mit vier Seiten, die schon ausgefallen waren.

Nichts davon brauchte einen Neuaufbau. Nichts davon brauchte ein Wartungsfenster. Drei der vier wurden in derselben Stunde behoben, und der vierte - die Distribution selbst, die am Ende ihres Lebenszyklus ist - ist der eine ehrliche Befund, den man nicht patchen kann, und genau deshalb gehört er in den Migrationsplan statt in die Arbeit von heute.

Wenn das Audit Sie auf die Suche nach einer Ersatzmaschine schickt: Wir haben die Optionen mit Live-Preisen verglichen in Bester VPS für Self-Hosting 2026, und vier Jahre bei einem Anbieter aufgeschrieben in unserem Hetzner-Cloud-Test.