11
Rate my firewall rules
Hallo wieder,
das Netzwerk sieht momentan so aus:
Ziel ist es den Pi, welcher einen Service im Internet anbietet vom Netzwerk der Fritzbox abzuschotten (wobei der Pi trotzdem internetzugang haben soll).
Interressant wird das dadurch, dass die Netzwerkstruktur genau wie oben sein soll (das warum ist ausführlich in meinem ersten Thread dargestellt und soll diesen Thread nicht zumüllen), insbesondere ist mir bewusst, dass eine DMZ hier geeigneter wäre.
Wäre jemand bereit mir hier einen sanity-check zu geben? Falls ich irgendetwas völlig vergesse / falsch denke...
Der MikroTik ist hier als Router mit seinem eigenem Netz 192.168.88.0/24 konfiguriert. ether2-ether4 gehören zur Bridge "localbridge". ether5 gehört zu keiner Bridge. Die Fritzbox ist nicht der DNS Resolver für den pi (so kann ich die Fritzbox mit der Firewall völlig unerreichbar für den pi machen). Die Adressliste "not_in_internet" enthält die typischen private-gerouteten Netzwerke. Der MT ist dabei nur über ether5 wartbar (siehe firewallregeln) (und explizit nicht aus dem Internet an ether1 oder vom pi an ether2).
Die Filter Regeln als Überblick-screenshot:
Die genauen Filter (und NAT) Regeln:
Erreiche ich meine Zielsetzung so?
LG
Duck
EDIT:Meine Ping-tests und webinterface-erreichbarkeitstests z.B. der Fritzbox ergeben, dass sich alles so verhält wie gewünscht (soweit ich das bemerken kann). Also dass der Pi keine Verbindungen zu Geräten im Fritzbox-Netz aufbauen kann.
das Netzwerk sieht momentan so aus:
Ziel ist es den Pi, welcher einen Service im Internet anbietet vom Netzwerk der Fritzbox abzuschotten (wobei der Pi trotzdem internetzugang haben soll).
Interressant wird das dadurch, dass die Netzwerkstruktur genau wie oben sein soll (das warum ist ausführlich in meinem ersten Thread dargestellt und soll diesen Thread nicht zumüllen), insbesondere ist mir bewusst, dass eine DMZ hier geeigneter wäre.
Wäre jemand bereit mir hier einen sanity-check zu geben? Falls ich irgendetwas völlig vergesse / falsch denke...
Der MikroTik ist hier als Router mit seinem eigenem Netz 192.168.88.0/24 konfiguriert. ether2-ether4 gehören zur Bridge "localbridge". ether5 gehört zu keiner Bridge. Die Fritzbox ist nicht der DNS Resolver für den pi (so kann ich die Fritzbox mit der Firewall völlig unerreichbar für den pi machen). Die Adressliste "not_in_internet" enthält die typischen private-gerouteten Netzwerke. Der MT ist dabei nur über ether5 wartbar (siehe firewallregeln) (und explizit nicht aus dem Internet an ether1 oder vom pi an ether2).
Die Filter Regeln als Überblick-screenshot:
Die genauen Filter (und NAT) Regeln:
/ip firewall filter
add action=drop chain=input comment=\
"drop all connections to router from not-ethernet 5" in-interface=!ether5
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=forward comment=\
"accept established,related connections" connection-state=\
established,related
add action=drop chain=forward comment="drop invalid" connection-state=invalid
add action=accept chain=forward comment=\
"accept dst-natted (port forwarded) from ether1 from internet" \
connection-nat-state=dstnat in-interface=ether1 src-address-list=\
!not_in_internet
add action=accept chain=forward comment=\
"accept connections from local to internet (but not to private ip's)" \
dst-address-list=!not_in_internet in-interface=localbridge
add action=drop chain=forward comment="drop else"
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
add action=dst-nat chain=dstnat dst-port=22 in-interface=ether1 protocol=\
tcp to-addresses=192.168.88.254 to-ports=22Erreiche ich meine Zielsetzung so?
LG
Duck
EDIT:Meine Ping-tests und webinterface-erreichbarkeitstests z.B. der Fritzbox ergeben, dass sich alles so verhält wie gewünscht (soweit ich das bemerken kann). Also dass der Pi keine Verbindungen zu Geräten im Fritzbox-Netz aufbauen kann.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2437660702
Url: https://administrator.de/contentid/2437660702
Printed on: May 6, 2024 at 16:05 o'clock
11 Comments
Latest comment
Achte auch darauf Service und Infrastruktur Broad- und Multicasts des MT wie LLDP, CDP usw. und die WinBox Mac Discovery am Port 2 zu deaktivieren ! Der Pi sollte nicht nur keine Verbindungen zur FB initiieren können sondern auch zum MT !
https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
Als Check immer ein tcpdump auf dem Pi ausführen und checken ob der MT auch wirklich stumm ist (sudo apt install tcpdump)
https://danielmiessler.com/study/tcpdump/
https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
Als Check immer ein tcpdump auf dem Pi ausführen und checken ob der MT auch wirklich stumm ist (sudo apt install tcpdump)
https://danielmiessler.com/study/tcpdump/
Danke für den Hinweis auf das Tutorial!
Bin das Tutorial durchgegangen.
tcpdump liefert nach dem deaktivieren von RSTP nur noch ARP-Meldungen zwischen Pi und MT unbeantwortete ICMP6 requests, sowie ntp anfragen vom pi. Vom restlichen Netzwerk keine Spur
Aber selbst wenn man die von dir genannten Protokolle aktiv lässt, sollte die Firewall-Regel ja trotzdem jeglichen Traffic vom Pi droppen.
LG
Duck
Bin das Tutorial durchgegangen.
tcpdump liefert nach dem deaktivieren von RSTP nur noch ARP-Meldungen zwischen Pi und MT unbeantwortete ICMP6 requests, sowie ntp anfragen vom pi. Vom restlichen Netzwerk keine Spur
Aber selbst wenn man die von dir genannten Protokolle aktiv lässt, sollte die Firewall-Regel ja trotzdem jeglichen Traffic vom Pi droppen.
LG
Duck
Hallo,
Ein blick mit einen Wireshark in deinen Fritz Netzwerk (oder das LOG der Fritte selbst) sagt es dir.
Gruß,
Peter
Ein blick mit einen Wireshark in deinen Fritz Netzwerk (oder das LOG der Fritte selbst) sagt es dir.
Gruß,
Peter
Hi Duck,
das sieht für mich sehr gut aus!
Bei den Input-Regeln würde ich noch straffen. Auch Ether5 muss ja nicht alles auf dem MT können. Wahrscheinlich willst Du da nur SSH, HTTPS oder Winbox. Im MT dann auch die Dienste abschalten, die nicht benötigt werden. Wenn Du Bobs Behausung jedoch als safe ansiehst, musst Du da nicht übertreiben. Geht ja nur um Zugriff von intern. Da hat er den Pi ja ohnehin physisch im Zugriff.
Auch die Forward (Portforwarding-Rule) könntest Du noch straffen, weil ja nicht das gesamte local lan des MT sondern nur konkret der Pi erreicht werden muss. Und das auch nur auf Port22. Ist aber wohl nur Kosmetik, denn die Portweiterleitung berücksichtigt dies ja.
Das !not... versteht auch nur ein Mathematiker
. Auch da würde ich vielleicht noch straffen, denn der Pi muss ja definitiv nicht das gesamte Internet abgrasen sondern braucht nur seine Updates. Ob Ports schließen aber heute noch ein großer Schutz ist, sei mal dahin gestellt. Ich würde es machen. Wenn das Notebook im Supportfall mehr Internet braucht, mach für Ether5 eben noch eine Extra-Rule. Die kannst Du evtl. auch noch an das Gerät binden, damit sich bei Bob nicht einer einschleicht und den Port missbraucht.
Fasttrack fehlt auch, in dem Setup aber wohl auch nicht wichtig.
Fazit: Mir fallen nur kaum relevante Anpassungen ein. Top und Respekt!
Viele Grüße, commodity
das sieht für mich sehr gut aus!
Bei den Input-Regeln würde ich noch straffen. Auch Ether5 muss ja nicht alles auf dem MT können. Wahrscheinlich willst Du da nur SSH, HTTPS oder Winbox. Im MT dann auch die Dienste abschalten, die nicht benötigt werden. Wenn Du Bobs Behausung jedoch als safe ansiehst, musst Du da nicht übertreiben. Geht ja nur um Zugriff von intern. Da hat er den Pi ja ohnehin physisch im Zugriff.
Auch die Forward (Portforwarding-Rule) könntest Du noch straffen, weil ja nicht das gesamte local lan des MT sondern nur konkret der Pi erreicht werden muss. Und das auch nur auf Port22. Ist aber wohl nur Kosmetik, denn die Portweiterleitung berücksichtigt dies ja.
Das !not... versteht auch nur ein Mathematiker
. Auch da würde ich vielleicht noch straffen, denn der Pi muss ja definitiv nicht das gesamte Internet abgrasen sondern braucht nur seine Updates. Ob Ports schließen aber heute noch ein großer Schutz ist, sei mal dahin gestellt. Ich würde es machen. Wenn das Notebook im Supportfall mehr Internet braucht, mach für Ether5 eben noch eine Extra-Rule. Die kannst Du evtl. auch noch an das Gerät binden, damit sich bei Bob nicht einer einschleicht und den Port missbraucht.Fasttrack fehlt auch, in dem Setup aber wohl auch nicht wichtig.
Fazit: Mir fallen nur kaum relevante Anpassungen ein. Top und Respekt!
Viele Grüße, commodity
sollte die Firewall-Regel ja trotzdem jeglichen Traffic vom Pi droppen.
Der Traffic kommt ja nicht vom Pi sondern vom MT und in den Infrastruktur Broadcasts steht quasi die Konfig deines Netzwerk Segments und des Ports die Angreifer dann auf dem Silbertablett bekommen. Deshalb macht es immer Sinn diese in einem öffentlichen Segment zu deaktivieren. Egal ob man vom Pi Zugang hat oder nicht. RSTP hättest du anlassen können, denn das ist Spanning Tree und sichert den Port eher gegen Loops. Da ist es nicht so gut das zu deaktivieren. Stört aber auch nicht sofern der Pi da dort das einzige Endgerät ist.
Zum Rest hat Kollege @commodity schon alles gesagt.
@aqui RSTP hab ich vor deaktiviert um nicht so einen Spam beim tcpdump zu haben, und da das Netzwerk an diesem Ende keinen Loop haben wird, hab ichs gleich deaktiviert gelassen :D
@Pjordorf
Ich habe mal in Wireshark reingeschaut und nichts vom pi erkannt. Allerdings ist dieser ja momentan auch von keinem Angreifer motiviert das zu tun. Kannst du "Log der fritzbox" etwas spezifizieren. Meinst du einfach die momentan angemeldeten Geräte? Denn ansonsten finde ich nichts wirklich hilfreiches in der GUI der fritte.
@commodity Meinst du bezüglich ports schließen in folgender regel
LG
Duck
@Pjordorf
Ich habe mal in Wireshark reingeschaut und nichts vom pi erkannt. Allerdings ist dieser ja momentan auch von keinem Angreifer motiviert das zu tun. Kannst du "Log der fritzbox" etwas spezifizieren. Meinst du einfach die momentan angemeldeten Geräte? Denn ansonsten finde ich nichts wirklich hilfreiches in der GUI der fritte.
@commodity Meinst du bezüglich ports schließen in folgender regel
add action=accept chain=forward comment=\
"accept connections from local to internet (but not to private ip's)" \
dst-address-list=!not_in_internet in-interface=localbridge
noch zusätzlich sourceport = ... hinzuzufügen? Oder meintest du mit straffen nur whitelisten von updateserver-ip's (statt blacklisten der privaten)?"accept connections from local to internet (but not to private ip's)" \
dst-address-list=!not_in_internet in-interface=localbridge
LG
Duck
Hallo,
Gruß,
Peter
Zitat von @duckduck:
Ich habe mal in Wireshark reingeschaut und nichts vom pi erkannt. Allerdings ist dieser ja momentan auch von keinem Angreifer motiviert das zu tun. Kannst du "Log der fritzbox" etwas spezifizieren. Meinst du einfach die momentan angemeldeten Geräte? Denn ansonsten finde ich nichts wirklich hilfreiches in der GUI der fritte.
Auf http://service.avm.de/help/de/FRITZ-Box-7590/015/hilfe_support etwas runter Scrollen und dort unter Paketmitschnitt erstellen weiterlesen Ich habe mal in Wireshark reingeschaut und nichts vom pi erkannt. Allerdings ist dieser ja momentan auch von keinem Angreifer motiviert das zu tun. Kannst du "Log der fritzbox" etwas spezifizieren. Meinst du einfach die momentan angemeldeten Geräte? Denn ansonsten finde ich nichts wirklich hilfreiches in der GUI der fritte.
Gruß,
Peter
hab ich vor deaktiviert um nicht so einen Spam beim tcpdump zu haben
Überflüssig, denn dafür hat tcpdump Filter die das ausfiltern können:https://stackoverflow.com/questions/67591617/tcpdump-filter-out-arp-and- ...
Gewusst wie !
Zitat von @duckduck:
Meinst du bezüglich ports schließen ... noch zusätzlich sourceport = ... hinzuzufügen? Oder meintest du mit straffen nur whitelisten von updateserver-ip's (statt blacklisten der privaten)?
Weder noch. Ich meinte Destination-Ports ausfiltern. Also nur die zulassen, die der Pi auch ansteuert (Wahrscheinlich nur 433).Meinst du bezüglich ports schließen ... noch zusätzlich sourceport = ... hinzuzufügen? Oder meintest du mit straffen nur whitelisten von updateserver-ip's (statt blacklisten der privaten)?
Viele Grüße, commodity
1Zitat von @aqui:
Überflüssig, denn dafür hat tcpdump Filter die das ausfiltern können:
https://stackoverflow.com/questions/67591617/tcpdump-filter-out-arp-and- ...
Gewusst wie !
10 stunden testen könnten mir 5 minuten dokumentationslesen sparen! ;)Überflüssig, denn dafür hat tcpdump Filter die das ausfiltern können:
https://stackoverflow.com/questions/67591617/tcpdump-filter-out-arp-and- ...
Gewusst wie !
Zitat von @commodity:
Weder noch. Ich meinte Destination-Ports ausfiltern. Also nur die zulassen, die der Pi auch ansteuert (Wahrscheinlich nur 433).
Danke fürs klarstellen.Weder noch. Ich meinte Destination-Ports ausfiltern. Also nur die zulassen, die der Pi auch ansteuert (Wahrscheinlich nur 433).
Zitat von @Pjordorf:
Auf http://service.avm.de/help/de/FRITZ-Box-7590/015/hilfe_support etwas runter Scrollen und dort unter Paketmitschnitt erstellen weiterlesen
Habs gefunden, da muss man erstmal auf die Idee kommen draufzuklicken!Auf http://service.avm.de/help/de/FRITZ-Box-7590/015/hilfe_support etwas runter Scrollen und dort unter Paketmitschnitt erstellen weiterlesen
Großes Danke an alle für die vielen suggestion! Ich denke der MT ist nun bereit für seinen Einsatz.
LG
Duck
Wie immer gerne!
Viele Grüße, commodity
Viele Grüße, commodity
