Risiken der Outgoing Policy am Beispiel einer Video-Überwachungsanlage

Vor Kurzem wurden wir auf einen Fall aufmerksam, der wieder einmal verdeutlicht, warum die Outgoing Policy nicht verwendet werden sollte. In diesem Artikel beschreiben wir das beim Kunden vorliegende Setup, das aufgetretene Problem sowie entsprechende Lösungsansätze und Empfehlungen.

Setup:

• Video-Kamera im Trusted Network
• Video-Kamera per SNAT vom Internet direkt erreichbar
• Outgoing Policy vorhanden (Traffic von Any-Trusted nach Any-External, tcp(0)/udp(0) bzw. any erlaubt)
• DNS-Paketfilter-Policy von Any-Trusted nach Any-External

aufgetretenes Problem:

• die Firewall ging alle 10 Minuten für ein paar Sekunden offline

Nach einer kurzen Suche stellte sich heraus:

• auf dem internen Interface ist viel zu viel Traffic (hunderte GB innerhalb weniger Stunden)

Eine Analyse des Netzwer-Traffics mit Wireshark zeigt:

• beim Kunden war die gesamte Überwachungsanlage gehackt worden
• diese Anlage war über das Internet via Portforward direkt erreichbar (Kunde wurde bereits damals über das Risiko aufgeklärt)
• im Trace kann man von der internen IP (die Cam) nach extern tausende von Anfragen sehen, welche alle 10 Minuten abgefeuert wurden (Die Kamera wurde Teil eines Bot-Netzwerkes, das für typischer DDoS Angriffe verwendet wurde)
• weiterhin war extrem viele Traffic auf Port 53 mit SSL-Protokoll zu sehen.

Dadurch ist auf der Firewall vermutlich alle 10 Minuten die Session Table vollgelaufen und die Firewall war (kurz) überlastet und nicht erreichbar. Laut Firewall Logs und Wireshark wurden von dem internen Gerät über 350 GB Daten über verschiedene UDP / TCP Ports (z.B. OpenVPN Traffic über DNS Port 53/UDP) u.a. nach China erzeugt/versendet. Der Hersteller hat gegenüber dem Kunden wohl zugegeben, dass die letzten paar Tage wohl alle Anlagen ihrer Kunden gehackt wurden und diese doch sofort vom Netzwerk getrennt trennen sollen…

Nachdem der Kunde die Anlage vom Netz genommen ist auch das eigentliche Problem (Firewall steigt alle 10 Minuten aus) verschwunden.

Dieses reale Beispiel bestätigt unsere Empfehlungen, die wir immer und immer wieder aussprechen, die aber oft aufgrund “erhöhter Aufwand” und “ach was, das ist übertrieben” abgelehnt werden:

• die Default Outgoing Policy abschalten
• nur benötigte Ports/Protokolle nach extern zulassen
• die DNS-Policy einschränken und nur die internen DNS-Server mit dem Internet auf Port 53 kommunizieren lassen
  (WatchGuard bietet zum DNS-Schutz mehrere Möglichkeiten an. Zum einen gibt es DNSWatch und zum anderen kann für den DNS-Traffic eine DNS-Proxy-Policy verwenden, die explizit nur das DNS-Protokoll auf Port 53 erlaubt (und damit z.B. OpenVPN auf Port 53 verhindert))
• grundsätzlich IoT-Geräten (wie Kameras, Alarmanlagen, Steuerungen) keinen Zugriff aus dem/auf das Internet (Any) erlauben
  (‘From: Any’ ist eingehend immer eine schlechte Idee)
  (WatchGuard bietet verschiedene Möglichkeiten der Zugriffssteuerung an, u.a. Access Portal, verschiedene VPN-Technologien oder anmeldegestützte Zugriffe auf Portforwards (Zugriff wird erst nach Anmeldung an der Firewall erlaubt)
  
  

Weitere Informationen über die verschiedenen VPN-Technologien und Home Office Anbindungen finden Sie unserem Artikel WatchGuard Lösungen für Home Office Anbindung.

Grundsätzlich sollten derartige Systeme (Überwachungskameras etc.) wann immer möglich in ein eigenes Netzwerk (VLAN/DMZ/…).