Listening Ports auf einem Cloud-Mac prüfen und absichern

Nach mehreren Build-Durchläufen auf einem entfernten Mac können Entwicklungswerkzeuge, Debug-Server, Paketmanager und temporäre Skripte weiterhin Ports abhören. Entscheidend ist nicht die bloße Anzahl offener Ports, sondern ob sich drei Fragen beantworten lassen: Welcher Prozess lauscht, an welche Adresse ist er gebunden und wird er nach einem Neustart erneut gestartet? Mit den integrierten macOS-Werkzeugen lässt sich zunächst ein reproduzierbarer, rein lesender Prüfablauf aufbauen und anschließend die Angriffsfläche schrittweise verkleinern.

Baseline der Listening Ports erstellen

Erfassen Sie den TCP- und UDP-Status, wenn der Knoten nicht ausgelastet ist und keine temporären Debug-Aufgaben laufen. -nP verhindert die Namensauflösung und die Umwandlung von Portnummern in Dienstnamen. Dadurch eignet sich die Ausgabe besser zum Speichern und Vergleichen.

mkdir -p "$HOME/audit/network"
stamp="$(date -u +%Y%m%dT%H%M%SZ)"

sudo lsof -nP -iTCP -sTCP:LISTEN \
  > "$HOME/audit/network/tcp-$stamp.txt"

sudo lsof -nP -iUDP \
  > "$HOME/audit/network/udp-$stamp.txt"

netstat -anv -p tcp \
  > "$HOME/audit/network/netstat-tcp-$stamp.txt"

Betrachten Sie nicht nur die Portnummer. COMMAND, PID, USER und NAME müssen gemeinsam bewertet werden: Ein bekannter Entwicklungsserver unter einem normalen Benutzerkonto hat eine völlig andere Priorität als ein unbekannter Prozess, der als root ausgeführt wird.

LISTEN bedeutet nicht automatisch, dass ein Dienst von außen erreichbar ist. Das Endergebnis hängt von der Listening-Adresse, der Host-Firewall und der Netzwerkrichtlinie des Knotens ab. Eine Wildcard-Adresse zeigt jedoch, dass der Prozess seinen Empfangsbereich aktiv erweitert hat, und sollte daher zuerst nachvollzogen werden.

Ports zu Prozessen und Startobjekten zurückverfolgen

Nachdem Sie die PID ermittelt haben, prüfen Sie mit ps den vollständigen Befehl, den übergeordneten Prozess und die bisherige Laufzeit. Kontrollieren Sie anschließend, ob der Prozess von einem persistenten Startobjekt stammt.

pid=1234
ps -p "$pid" -o pid,ppid,user,lstart,command
sudo lsof -nP -p "$pid"

launchctl print "gui/$(id -u)" > "$HOME/audit/network/launch-gui.txt"
sudo launchctl print system > "$HOME/audit/network/launch-system.txt"

find "$HOME/Library/LaunchAgents" \
  /Library/LaunchAgents \
  /Library/LaunchDaemons \
  -maxdepth 1 -name '*.plist' -print 2>/dev/null

Untersuchen Sie verdächtige plist-Dateien mit plutil -p 文件路径 und achten Sie auf Program, ProgramArguments, RunAtLoad und KeepAlive. Wurde ein Prozess nur vorübergehend von einem Build-Skript gestartet, sollte er nach Abschluss der Aufgabe beendet werden. Erzwingt KeepAlive dagegen fortlaufende Neustarts, lässt sich das Problem nicht allein mit kill beheben.

Maßnahmenregister anlegen

Dokumentieren Sie für jeden nicht zum System gehörenden Listener mindestens den Zweck des Dienstes, die verantwortliche Person, die Startmethode, die gebundene Adresse und den Grund für seine Beibehaltung. Lässt sich ein Prozess nicht zuordnen, stoppen Sie zunächst die zugehörige Aufgabe und sichern Sie Befehlszeile, Protokollpfad und plist-Inhalt. Löschen Sie Dateien nicht sofort, da sonst wichtiger Untersuchungskontext verloren geht.

Zuerst die Bindungsadresse ändern, nicht den Port sperren

Wird ein Entwicklungsdienst ausschließlich vom aktuellen Benutzer benötigt, besteht die direkteste Korrektur darin, ihn an die Loopback-Adresse zu binden. Selbst wenn sich Firewall-Regeln ändern, akzeptiert der Prozess dann keine Verbindungen über andere Schnittstellen.

python3 -m http.server 8080 --bind 127.0.0.1

HOST=127.0.0.1 PORT=8080 ./run-development-server

Für den Zugriff vom eigenen Computer stellen Sie den Einstieg über eine lokale SSH-Portweiterleitung bereit:

ssh -N \
  -L 127.0.0.1:9000:127.0.0.1:8080 \
  "$REMOTE_USER@$REMOTE_HOST"

Rufen Sie anschließend lokal 127.0.0.1:9000 auf. Prüfen Sie zugleich, dass der entfernte Dienst weiterhin ausschließlich auf 127.0.0.1:8080 lauscht und nicht wegen unwirksamer Startparameter auf *:8080 zurückgefallen ist.

Die Einschränkung der Bindungsadresse lässt sich meist leichter überprüfen als eine neue Blockierungsregel und beeinträchtigt seltener die Remote-Verwaltung. Die Firewall bildet eine zweite Kontrollebene und ersetzt keine korrekte Listening-Konfiguration des Dienstes.

Beide Firewall-Ebenen nur lesend prüfen

Die macOS-Anwendungsfirewall und pf haben unterschiedliche Schwerpunkte. Lesen Sie bei einer Prüfung zunächst nur den aktuellen Zustand aus und überschreiben Sie in einer Remote-Sitzung keine Regeln.

sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps

sudo pfctl -s info
sudo pfctl -sr
sudo pfctl -sn

Anhand der Liste der Anwendungsfirewall lässt sich feststellen, welche Programme eingehende Verbindungen annehmen dürfen. Die pf-Ausgabe zeigt dagegen Filter- und NAT-Regeln. Wenn Sie Auffälligkeiten feststellen, speichern Sie zuerst die vollständige Ausgabe und klären Sie anschließend, ob die Regeln aus der Systemkonfiguration, einem Betriebsprozess oder einem temporären Experiment stammen.

Das größte Risiko bei Remote-Änderungen an pf ist nicht ein Syntaxfehler, sondern das gleichzeitige Blockieren der aktuellen Verwaltungsverbindung. Solange kein zweiter, überprüfter Zugriffsweg verfügbar ist, sollte es bei einer rein lesenden Kontrolle bleiben. Falls eine Änderung notwendig ist, sichern Sie zuerst die Regeln, legen Sie den Rollback-Befehl eindeutig fest und prüfen Sie in einer weiteren Sitzung fortlaufend, ob die Konsole erreichbar bleibt.

Erneut auftretende Ports mit Differenzprüfungen erkennen

Eine einmalige Bereinigung berücksichtigt keine späteren Werkzeug-Upgrades, Änderungen an Build-Skripten oder neuen Startobjekte. Speichern Sie nach Abschluss der Umgebungseinrichtung eine freigegebene Baseline und erfassen Sie den Zustand nach jeder größeren Änderung erneut.

latest_tcp="$(ls -t "$HOME"/audit/network/tcp-*.txt | head -n 1)"
diff -u "$HOME/audit/network/tcp-approved.txt" "$latest_tcp"

latest_udp="$(ls -t "$HOME"/audit/network/udp-*.txt | head -n 1)"
diff -u "$HOME/audit/network/udp-approved.txt" "$latest_udp"

Wenn der Vergleich neue Einträge zeigt, prüfen Sie diese in einer festen Reihenfolge: Ordnen Sie den Prozess zu, kontrollieren Sie die Listening-Adresse und die Startquelle und entscheiden Sie, ob Remote-Zugriff erforderlich ist. Erst danach wird festgelegt, ob der Dienst beibehalten, auf eine lokale Bindung umgestellt oder deaktiviert wird. Brechen Sie die Nachverfolgung nicht ab, sobald eine Portnummer in eine statische Positivliste aufgenommen wurde, denn derselbe Port kann später von einem anderen Programm übernommen werden.

Auf den dedizierten physischen Knoten von OwnAMac eignet sich dieser Ablauf ebenfalls für Build-Agenten, Vorschau-Server, Prozesse für Test-Callbacks und temporäre Dateidienste. Bewahren Sie anschließend die ursprünglichen Snapshots, die dokumentierten Maßnahmen und die Ergebnisse der Nachprüfung auf. Bei der nächsten Änderung der Umgebung können Sie dann mit den Abweichungen beginnen, statt den aktuellen Zustand erneut erraten zu müssen.

Häufig gestellte Fragen