%20in%20der%20Firewall.png)
Ich habe mich für einen Whitelist-Ansatz entschieden, um meine Umgebung zu sichern (d. h., alle eingehenden/ausgehenden Verbindungen werden standardmäßig blockiert, sofern nicht anders angegeben).
Ich muss einige Windows-Apps (nicht alle) wie Powershell, cmd, Remotedesktop in der Firewall auf die Whitelist setzen. Das einfache Hinzufügen von cmd.exe, MSTSC.exe usw. reicht jedoch nicht aus. Ich bin sicher, dass diese Apps für die Netzwerkverbindung bestimmte Abhängigkeiten von anderen Apps haben, aber ich weiß nicht, welche das sind.
Das einfache Whitelisting von OpenSSH-Dateien von System32 beispielsweise gewährt keinen Zugriff auf SSH in PowerShell. Ich erhalte beim erhöhten Zugriff die Fehlermeldung „Zugriff verweigert“ (das Deaktivieren der Firewall behebt das Problem, daher sollte es durch die entsprechenden Firewall-Regeln behoben werden).
Das Öffnen von Ports ist keine Option, da durch das Öffnen eines Ports auch andere Apps, die ich nicht mag, Zugriff auf diese Ports hätten. Ich möchte beispielsweise curl auf cmd ausführen, aber ich möchte nicht, dass andere Apps Zugriff auf Port 443 haben.
Darüber hinaus ist das Erstellen einer Blacklist keine Option, da die Anzahl der Apps, die ich blockieren muss, die der drei benötigten Apps bei weitem übersteigt.
Antwort1
Windows 11: System32/svchost.exe in der Firewall zulassen, dann klappt alles.
PS: Hier sind einige Beobachtungen zu svchost.
Interessanterweise verliert Windows nach dem Blockieren dieser Datei nach einigen Minuten seine Internetfunktionalität. Ich wollte wissen, warum, also blockierte ich alles außer dieser Datei und bemerkte, dass sie viele verschlüsselte Pakete an Microsoft und einige unbekannte IPs sendet, obwohl ich Telemetrie, Windows Update usw. in der Registrierung deaktiviert habe. Nach dem Blockieren von svchost versucht Windows erneut, diese Pakete zu senden, doch nach einigen erfolglosen Minuten wird die gesamte Internetverbindung getrennt.
Das ist interessant, denn es scheint, dass einige Anwendungen wie Firefox einige Minuten lang ohne svhost funktionieren, sodass sie svhost wahrscheinlich nicht(?) benötigen, um auf das Internet zuzugreifen (im Gegensatz zu Powershell, das seine Funktionalität sofort nach dem Blockieren von svhost verliert), aber Windows entscheidet sich trotzdem, das Internet vollständig abzuschalten. Dies könnte auch damit zusammenhängenBlockiert die Windows-Firewall die Windows-Telemetrie vollständig?auch, da beide Beobachtungen zum Firewall-Verhalten falsch sind. Windows-IPs sind in der Firewall nicht fest codiert (wenn das der Fall wäre, hätten wir nach dem Blockieren von allem, einschließlich svhost, immer noch TLS-Pakete sehen können, aber das ist nicht der Fall.), und wir können Windows auch nicht daran hindern, diese Pakete zu senden, indem wir alles blockieren, da svhost dennoch in der Firewall auf die Whitelist gesetzt werden sollte.