Kurz gesagt: Ausgehende Verbindungen eines Servers prüfen Sie mit ss -tunap oder lsof -i, die jede Verbindung einem Prozess zuordnen. Normal sind Verbindungen zu Datenbank, Mailserver, Update-Servern und bekannten Schnittstellen. Verbindungen von PHP- oder Webserver-Prozessen zu unbekannten Zielen, ungewöhnliche Ports und dauerhafte Verbindungen ohne Anlass sind Warnsignale für Fernsteuerung oder Datenabfluss. Dauerhaft hilft eine Ausgangsfilterung, die nur benötigte Ziele erlaubt.
Warum der Blick nach draußen so viel verrät
Bei der Suche nach einem Einbruch schauen die meisten auf Dateien. Doch ein Angreifer will mit seinem Zugang etwas anfangen: Werkzeuge nachladen, Befehle empfangen, Daten hinausschaffen oder den Server für Spam oder Angriffe auf andere nutzen. All das braucht Verbindungen nach außen.
Ein Webserver baut von sich aus nur wenige Verbindungen auf, und die meisten davon sind vorhersehbar: Er fragt die Datenbank ab, übergibt Mails, ruft Zahlungs- oder Versandschnittstellen auf und holt Updates. Deshalb fallen fremde Verbindungen hier besonders auf. Laut den uns vorliegenden Berichten gehören ausgehende Verbindungen zu den allgemeinen Warnsignalen nach einem Einbruch; bestätigte Indicators of Compromise speziell für PHP2Shell gibt es nicht. Weitere Anzeichen fasst Bin ich schon kompromittiert? zusammen.
Ausgehende Verbindungen auflisten und Prozessen zuordnen
Die folgenden Befehle lesen nur. Führen Sie sie als root aus, sonst fehlen die Prozessangaben.
# Alle aufgebauten TCP-Verbindungen mit Prozess
ss -tnp state established
# TCP und UDP inklusive lauschender Dienste
ss -tunap
# Verbindungen je Programm und Benutzer, ohne Namensauflösung
lsof -i -n -P | grep -v LISTEN
# Nur Verbindungen von Prozessen der Webserver-Benutzer
lsof -i -n -P -u www-data 2>/dev/null
Achten Sie in der Ausgabe auf drei Spalten: den Prozess, die Zieladresse mit Port und den Benutzer. Eine Verbindung von php-fpm zur Datenbank auf Port 3306 ist normal. Eine Verbindung eines Programms mit unbekanntem Namen aus /tmp zu einer fremden Adresse auf einem ungewöhnlichen Port ist es nicht. Unter welchem Benutzer PHP läuft, hängt von Distribution und Panel ab.
Normal oder verdächtig? Eine Einordnung
| Beobachtung | Eher normal | Eher verdächtig |
|---|---|---|
| Ziel | eigene Datenbank, Mailserver, bekannte APIs, Update-Server | unbekannte Adressen ohne Bezug zur Anwendung |
| Prozess | php-fpm, Webserver, Mail- und Update-Dienste | unbekannte Programme, Prozesse aus /tmp oder /dev/shm |
| Port | 443, 3306, 5432, 587 | ungewöhnliche hohe Ports, IRC-typische Ports |
| Dauer | kurz, passend zu Anfragen | dauerhaft offen, auch nachts ohne Besucher |
| Menge | gering und gleichmäßig | plötzliche Spitzen im ausgehenden Datenvolumen |
| Mailverkehr | Versand über den vorgesehenen Mailserver | viele direkte Verbindungen auf Port 25 |
Viele Verbindungen auf Port 25 deuten auf Spam-Versand; dazu gibt es einen eigenen Beitrag, Der Server verschickt Spam.
Ein unbekanntes Ziel bewerten
Eine fremde Adresse in der Liste ist noch kein Beweis. Bevor Sie entscheiden, klären Sie, wohin die Verbindung führt und wer sie aufgebaut hat. Auch diese Schritte verändern nichts:
- Prozess bestimmen: PID aus
ssnehmen und mitls -l /proc/PID/exeund der Kommandozeile prüfen, welches Programm dahintersteht. - Ziel nachschlagen: Mit
dig -x <IP>den Namen und mitwhois <IP>den Netzbetreiber ermitteln. - Mit der Anwendung abgleichen: Fragen Sie Entwickler oder Dienstleister, ob Ihre Anwendung diesen Dienst nutzt.
- Verlauf prüfen: Firewall- und Netzwerkprotokolle zeigen, seit wann die Verbindung besteht und wie viele Daten geflossen sind.
- Ergebnisse sichern: Ausgaben mit Uhrzeit speichern, bevor Sie etwas beenden oder sperren.
Rechnen Sie mit mehrdeutigen Ergebnissen. Viele legitime Dienste laufen bei großen Cloud- und CDN-Anbietern, deren Adressen keinen Rückschluss auf den Kunden erlauben. Umgekehrt nutzen auch Angreifer gemietete Cloud-Server. Ein bekannter Netzbetreiber ist also weder Entwarnung noch Beweis; entscheidend ist, ob der Prozess und der Zweck zu Ihrer Anwendung passen.
Eine Momentaufnahme mit ss zeigt nur, was gerade offen ist. Kurze Verbindungen, die im Minutentakt aufgebaut werden, sehen Sie nur in Protokollen. Deshalb sind Firewall- oder Flow-Protokolle für die Frage nach einem Datenabfluss oft wichtiger als der Blick auf den Server selbst.
Haben Daten Ihren Server möglicherweise verlassen und sind personenbezogene Daten betroffen, kann eine Meldepflicht nach DSGVO in der Regel binnen 72 Stunden bestehen. Klären Sie das früh mit Ihrem Datenschutzbeauftragten; Hintergründe unter DSGVO-Meldepflicht in 72 Stunden. Dies ist keine Rechtsberatung.
DNS und Container nicht vergessen
Nicht jeder Datenabfluss braucht eine sichtbare Verbindung zu einer fremden Adresse. Namensauflösungen über DNS gehen an den Resolver Ihres Rechenzentrums und fallen in der Liste von ss kaum auf. Angreifer können Daten in lange, zufällig wirkende Subdomains verpacken und so über DNS-Anfragen hinausschaffen. Hinweise darauf liefern die Protokolle des Resolvers: ungewöhnlich viele Anfragen an dieselbe fremde Domain, sehr lange Namen oder Anfragen zu Zeiten, in denen niemand die Website nutzt.
Laufen Ihre Anwendungen in Containern, sieht der Host die Verbindungen der Container oft nur als Verkehr des Container-Netzes. Prüfen Sie dann in jedem Container einzeln, soweit die Werkzeuge dort vorhanden sind, oder werten Sie die Verbindungen auf Ebene des Hosts und der Firewall aus.
# Verbindungen innerhalb eines Containers (sofern ss im Image enthalten ist)
docker exec <container> ss -tnp 2>/dev/null
# Auf dem Host: vom Kernel verfolgte Verbindungen, falls conntrack installiert ist
sudo conntrack -L 2>/dev/null | head -50
Ausgehenden Verkehr dauerhaft begrenzen
Die wirksamste Vorbeugung ist eine Ausgangsfilterung: Der Server darf nur die Ziele erreichen, die er wirklich braucht, alles andere wird gesperrt und protokolliert. Für Angreifer wird es dadurch deutlich schwerer, Werkzeuge nachzuladen oder Daten abzuziehen, selbst wenn sie Code ausführen können.
Der Weg dahin beginnt mit einer Liste der benötigten Ziele, die Sie aus den oben gesammelten Verbindungen ableiten. Danach folgt eine Phase, in der gesperrte Verbindungen nur protokolliert werden, bevor die Sperre scharf geschaltet wird. Zahlungsdienste, Update-Server und Schnittstellen mit wechselnden Adressen brauchen dabei besondere Sorgfalt. Wie eine Firewall für Webserver insgesamt aufgebaut wird, beschreibt Firewall für Webserver: Nur nötige Ports öffnen.
Wie hilft PHP SOS konkret?
- Verbindungen prüfen: Wir ordnen alle aktiven Verbindungen Prozessen und Zwecken zu und bewerten unbekannte Ziele.
- Datenabfluss einschätzen: Wir werten Firewall- und Netzwerkprotokolle aus und klären, ob und wann Daten übertragen wurden.
- Ausgang begrenzen: Wir erarbeiten mit Ihnen eine Liste erlaubter Ziele und richten die Ausgangsfilterung schrittweise ein.
- Dauerhaft überwachen: Mit dem Security-Monitoring melden wir neue oder ungewöhnliche Verbindungen.
Häufige Fragen
Welche ausgehenden Verbindungen sind bei einem Webserver normal?
Typisch sind Verbindungen zur Datenbank, zum Mailserver, zu Zahlungs- und Versanddiensten, zu Update-Servern und zu bekannten Schnittstellen der Anwendung. Alles, was sich keinem dieser Zwecke zuordnen lässt, verdient einen genaueren Blick.
Wie sehe ich, welcher Prozess eine Verbindung aufgebaut hat?
Mit ss -tunap oder lsof -i -n -P als root. Beide zeigen zu jeder Verbindung die Prozess-ID und den Programmnamen. So erkennen Sie, ob die Verbindung von PHP, dem Webserver oder einem fremden Programm stammt.
Bedeutet eine unbekannte Verbindung, dass Daten abgeflossen sind?
Nicht zwingend. Sie ist aber ein Hinweis, der geklärt werden muss. Ob und welche Daten übertragen wurden, lässt sich oft nur mit Firewall- oder Netzwerkprotokollen beantworten. Sind personenbezogene Daten betroffen, können Meldepflichten bestehen.
Sollte ein Webserver ausgehende Verbindungen überhaupt dürfen?
Nur zu den Zielen, die er braucht. Eine Ausgangsfilterung, die alles andere sperrt, erschwert Angreifern das Nachladen von Werkzeugen und den Abfluss von Daten erheblich. Sie muss aber sorgfältig getestet werden.