Ich habe ein sekundäres Netzwerk von meinem ER605-Router, das dazu dient, das angeschlossene Gerät, einen Raspberry Pi, zu isolieren. Ich verwende es, um eingehende Dateien aus zweifelhaften Quellen (wie den ständig von Malware befallenen Computern meiner Schwiegereltern) unter Quarantäne zu stellen und zu scannen. Ich muss auf den Pi zugreifen und gescannte Dateien in mein primäres Netzwerk exfiltrieren können. Ich plane, VNC für den Zugriff zu verwenden und freigegebene Dateien über eine SMB-Freigabe direkt auf meinem QNAP NAS abzulegen.
ACL-Regel 5 blockiert die Kommunikation vom Quarantänenetzwerk zu meinem primären Netzwerk. Um VNC von meinem primären Netzwerk zu meinem Quarantäne-Pi zu bekommen, habe ich zunächst Regel 4 hinzugefügt, was jedoch nicht ausreichte (Online-Leser wiesen darauf hin, dass ich eine ACL für Rückmeldungen benötige). Also habe ich eine Version von Regel 3 hinzugefügt, die auf den VNC-Dienst verwies, was jedoch immer noch nicht funktionierte. Aus einer Laune heraus habe ich versucht, die VNC_duplex-Dienstdefinition zu erstellen, die Quell- und Zielport austauscht, und Regel Nr. 3 von VNC-Dienst in VNC-Duplex geändert, und voilà, VNC hat funktioniert!
Ich bin ziemlich froh, dass das funktioniert, aber ich bin mir nicht sicher, warum oder ob es sicher ist. Habe ich das richtig verstanden, dass ACL-Regel 3 es einem bösartigen Skript erlaubt, eine Nachricht von jedem Port auf dem Raspberry Pi an Port 5900 auf jedem Gerät in meinem primären Netzwerk zu senden? Wie ist das semantisch zu verstehen und könnte es sicherer gemacht werden?
Mein Netzwerk und VLANS:
Ich habe auch einige IP-Bereiche eingerichtet, um Bereiche meines Netzwerks zu beschreiben, die ich segmentieren/zu denen ich Zugriff gewähren möchte:
Meine Leistungsarten (die letzten vier werden von mir individuell eingegeben):
Und schließlich meine ACL:
Antwort1
Online-Lektüre deutete darauf hin, dass ich eine ACL für Rückmeldungen benötige), also fügte ich eine Version von Regel 3 hinzu, die auf den VNC-Dienst verwies, und das schlug immer noch fehl. Aus einer Laune heraus versuchte ich, die VNC_duplex-Dienstdefinition zu erstellen, die Quell- und Zielport tauscht, und Regel Nr. 3 von VNC-Dienst in VNC-Duplex zu ändern, und voilà, VNC funktionierte!
Wenn der Pi Antworten an Ihren Computer sendet,der Pi ist die Quelle.
Die „Rücksendungspakete“ haben nicht nur die IP-Adresse des Pi als „Quell-IP“, sondern auch die entsprechende Portnummer.auf der Pi-Seiteals „Quell-Port“.
Connection: 192.168.0.PC:54321 <--> 192.168.2.10:5900
Packets from PC: src = 192.168.0.PC:54321, dst = 192.168.2.10:5900
Packets from Pi: src = 192.168.2.10:5900, dst = 192.168.0.PC:54321
Alle ursprünglichen Dienstvorlagen in Ihrer Firewall sind nur für die „Vorwärts“-Richtung definiert. Die „VNC“-Vorlage beispielsweise stimmt mit 5900 als Zielport überein – was, wie erläutert, nur auf Pakete zutrifft, deren Ziel der VNC-Server ist, nicht jedoch auf die „Rückgabe“-Pakete.
Habe ich das richtig verstanden, dass ACL-Regel 3 es einem bösartigen Skript erlaubt, eine Nachricht von jedem Port auf dem Raspberry Pi an Port 5900 auf jedem Gerät in meinem primären Netzwerk zu senden?
Nein. Es ermöglicht das Gegenteil: Es ermöglicht einem Skript, eine Nachricht zu sendenvon Port 5900auf dem Raspberry Pizu jedem Hafenin Ihrem primären Netzwerk. (Die „Quelle“ in „Quellport = 5900“wirklich bedeutetdie Quelle der Pakete.)
Da der Quellport einer Verbindungdürfenbeliebig gewählt werden (falls gewünscht), das heißt das primäre Netzwerk steht jedem offen, derweißüber die Existenz dieser Ausnahme; alles, was sie tun müssen, ist, das Betriebssystem zu bitten, eine Verbindung an den lokalen Port 5900 zu binden. (Aber andererseits, da der Quellport normalerweise zufällig ausgewählt wird und der Bereich weit hinter 5900 beginnt, kann jeder, dernichtWer von dieser Ausnahme weiß, wird sie wahrscheinlich nicht zufällig entdecken.)
Wie ist das semantisch zu verstehen?
"Quelle" bedeutet eigentlich die Quelle des IndividuumsPaket, nicht der gesamten Verbindung. (Tatsächlich könnte man den Port fast als Teil der „Transportschicht“-Adresse des Pakets betrachten, und in mehreren anderen Nicht-IP-Protokollen war er tatsächlich buchstäblich Teil der Adresse.)
Jeder Port ist mit einem bestimmten Endpunkt verknüpft, genauso wie jede IP-Adresse mit einem bestimmten Endpunkt verknüpft ist. Wenn Sie eine Verbindung zum Pi herstellen, erwarten Sie nicht, dass ein „Rückgabe“-Paket vom Pi immer noch die IP-Adresse des Pi als „Ziel“ anzeigt, und dasselbe gilt für die Portnummern.
und könnte es sicherer gemacht werden?
Der übliche Ansatz besteht darin, solche reflexiven ACLs vollständig zu vermeiden und eineStaatsbürgerlichFirewall. Die meisten Router sind in der Lage, aktive Verbindungen („Zustände“ oder „Flows“) zu verfolgen – siemüssentun Sie dies, wenn sie ein typisches 1:viele-NAT implementieren – und der Firewall-Filter möglicherweise eine spezielle Regel hat, die alle Pakete zulässt, die einer „hergestellten“ Verbindung entsprechen (wie in iptables/nftables), oder solche Pakete implizit zulässt (wie in pf).
Es scheint, dass der ER603 Unterstützung für Stateful ACLs erhalten hatin Firmware 2.1(Die Leute scheinen jedoch zu sagen, dass es nicht funktioniert.)
Wenn dumussWenn Sie zustandslose ACLs verwenden, besteht der alternative Ansatz darin, nur "Rücksendungen" von Paketen zuzulassen, die dieTCP-Kennzeichen „ACK“gesetzt. Das erste Paket einer TCP-Verbindungniemalshat dieses Flag gesetzt, während dies bei allen anderen Paketen der Fall ist; es reicht eine einzige Regel, die TCP-ACK-Pakete auf jedem Port zulässt.
Natürlich funktioniert dieser Ansatz nur für TCP – bei UDP können Sie ohne Statusverfolgung nicht viel tun, außer zu hoffen, dass niemand das Loch entdeckt, das Ihre reflexive ACL verursacht.
Sie sollten auch eine andere Regel haben, die ICMP-Rücksendungspakete zulässt (z. B. Echo Reply und die verschiedenen ICMP-Fehlermeldungen –mindestens„Fragmentierung erforderlich“ muss zugelassen werden, vorzugsweise sollten jedoch auch andere Fehler wie „Nicht erreichbar“ zugelassen werden.