3
Port forwarding zu Reverse Proxy absichern (Mikrotik)
Hallo zusammen,
Ich möchte für zwei mobile Geräte den gesicherten Zugriff auf einen internen webservice zu Hause übers Internet ermöglichen. Ein VPN Tunnel scheidet leider aus, da die Geräte bereits via VPN über die Firma ins Netz gehen.
Folgenden Aufbau habe ich bei mir realisiert und mich würde eure Meinung dazu interessieren:
Die relevanten Firewall regeln habe ich folgendermaßen konfiguriert:
Der Reverse Proxy is im VLAN A der einzige host und so eingestellt, dass nur via mTLS authentifizierte Anfragen angenommen werden. Zugriff wird über das dstnat und die erste Firewallregel erlaubt.
Ist der Client authentifiziert wird der Request vom reverse proxy ins VLAN B an den Webservice weitergeleitet, bei dem noch mal User und Password fällig werden. Dazu der zweite Firewall Eintrag.
Beide Vlans sind der gleichen Bridge zugewiesen.
Meine Frage wäre primär, ob das eine vernünftige / sichere Architektur ist, ob ich etwas übersehen habe und wie ich das eventuell weiter absichern kann.
Ich dachte z.B. daran die Bandbreite / Verbindungen der eingehenden Request zu beschränken. In die Queue Thematik habe ich mich allerdings noch nicht eingelesen, habe aber auch in den Firewall regeln was zu Limits gesehen.
Eventuell könnte ich auch einen anderen Port statt dem 443 verwenden.
Und die Frage fürs nächste Osterwochenende wäre, wie das ganze äquivalent mit IPv6 umgesetzt werden kann. Zur Zeit (nach dem Update auf ROS 7.2...) hat der Reverse Proxy eine sich ständig ändernde globale Adresse und ich hab noch keine Ahnung wie ich die Firewall entsprechend konfiguriert bekomme.
Jedenfalls Danke für eure Zeit, Feedback und Ideen!
Ich möchte für zwei mobile Geräte den gesicherten Zugriff auf einen internen webservice zu Hause übers Internet ermöglichen. Ein VPN Tunnel scheidet leider aus, da die Geräte bereits via VPN über die Firma ins Netz gehen.
Folgenden Aufbau habe ich bei mir realisiert und mich würde eure Meinung dazu interessieren:
Client mit Client Zertifikat (eigene CA) -> Subdomain mit CNAME Eintrag auf Mikrotik DynDNS service -> RB4011 -> Traefik Reverse Proxy (vlan A) -> Webservice (vlan B)Die relevanten Firewall regeln habe ich folgendermaßen konfiguriert:
/ip firewall filter
add action=accept chain=forward comment="WAN -> Proxy" connection-nat-state=dstnat dst-address=10.8.0.8 dst-port=443 \
in-interface=pppoe-1 log=yes log-prefix="WAN -> Proxy" out-interface="VLAN_A - Ingress" protocol=tcp
add action=accept chain=forward comment="Proxy -> Webservice" dst-address=10.10.0.127 dst-port=8443 in-interface="VLAN_8" \
out-interface="VLAN_B" protocol=tcp src-address=10.8.0.8
add action=drop chain=forward comment="drop all"
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="443 -> Proxy" disabled=yes dst-port=443 in-interface=pppoe-1 log=yes log-prefix=\
"Proxy forwarding" protocol=tcp to-addresses=10.8.0.8 to-ports=443 Der Reverse Proxy is im VLAN A der einzige host und so eingestellt, dass nur via mTLS authentifizierte Anfragen angenommen werden. Zugriff wird über das dstnat und die erste Firewallregel erlaubt.
Ist der Client authentifiziert wird der Request vom reverse proxy ins VLAN B an den Webservice weitergeleitet, bei dem noch mal User und Password fällig werden. Dazu der zweite Firewall Eintrag.
Beide Vlans sind der gleichen Bridge zugewiesen.
Meine Frage wäre primär, ob das eine vernünftige / sichere Architektur ist, ob ich etwas übersehen habe und wie ich das eventuell weiter absichern kann.
Ich dachte z.B. daran die Bandbreite / Verbindungen der eingehenden Request zu beschränken. In die Queue Thematik habe ich mich allerdings noch nicht eingelesen, habe aber auch in den Firewall regeln was zu Limits gesehen.
Eventuell könnte ich auch einen anderen Port statt dem 443 verwenden.
Und die Frage fürs nächste Osterwochenende wäre, wie das ganze äquivalent mit IPv6 umgesetzt werden kann. Zur Zeit (nach dem Update auf ROS 7.2...) hat der Reverse Proxy eine sich ständig ändernde globale Adresse und ich hab noch keine Ahnung wie ich die Firewall entsprechend konfiguriert bekomme.
Jedenfalls Danke für eure Zeit, Feedback und Ideen!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2539730372
Url: https://administrator.de/forum/port-forwarding-zu-reverse-proxy-absichern-mikrotik-2539730372.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
3 Kommentare
Neuester Kommentar
Hallo.
Sieht so weit ok aus. Man könnte noch die Firmen-IP-Adresse whitelisten.
Warum denn das? Will man nicht höchste Verfügbarkeit?
Das ist Security through Obscurity also Unfug.
Mit IPv6? Genau so?
Hol dir ne statische IP-Adresse? Oder mit DynDNS?
Gruss.
Sieht so weit ok aus. Man könnte noch die Firmen-IP-Adresse whitelisten.
Ich dachte z.B. daran die Bandbreite / Verbindungen der eingehenden Request zu beschränken.
Warum denn das? Will man nicht höchste Verfügbarkeit?
Eventuell könnte ich auch einen anderen Port statt dem 443 verwenden.
Das ist Security through Obscurity also Unfug.
Mit IPv6? Genau so?
Hol dir ne statische IP-Adresse? Oder mit DynDNS?
Gruss.
Firmen-IP-Adresse whitelisten
Gute Idee, das lässt sich leicht machen.
Warum denn das? [Bandbreite einschränken] Will man nicht höchste Verfügbarkeit?
Nicht unbedingt. Der Webservice dahinter braucht nicht viel. Eventuell kann so einer DoS Attacke auf den gesamten Anschluss vorgebeugt werden? Wenn von außen der offenen Port geflutet wird wäre nicht gleich die ganze Leitung dicht. Oder ist das Käse?
Security through Obscurity
Klar, verstecken kann ich den Port nicht, aber evtl. fällt er bei Scans auf die Standard Ports raus. Nach dem Motto: Lass deinen Geldbeutel nicht sichtbar im verschlossenen Auto liegen
Nicht unbedingt. Der Webservice dahinter braucht nicht viel. Eventuell kann so einer DoS Attacke auf den gesamten Anschluss vorgebeugt werden? Wenn von außen der offenen Port geflutet wird wäre nicht gleich die ganze Leitung dicht.
Nein, ein DoS-Angriff kann nicht durch QoS (Beschränkung der Bandbreite) verhindert werden. Dabei ist es Wurst, ob der Port offen ist oder nicht. Das Paket muss trotzdem vom Netzwerkstack des Kernels verarbeitet werden. Du würdest mit einer Bandbreitenbeschränkung bzw. mit einem Ratelimiting nur dich selbst beschränken.
Es sei denn du DoS dich mit der gewhitelisteten Firmen-IP-Adresse selber. Aber warum sollte man sich das antun?
Ich würde bei meinem ISP nach einer "Lösung" fragen. Volumenbasierte DoS-Angriffe werden am besten auf Netzwerkebene mitigiert und nicht auf dem Server.
Aber wie schlimm wäre es denn, wenn du für einige Stunden nicht mehr auf deine Daten zugreifen könntest? Warum sollte jemand ausgerechnet dich DoSen? Eher unwahrscheinlich.
Dein Denkansatz macht zu einem gewissen Grad durchaus Sinn, wenn man die Firmen-IP nicht auf eine Whitelist setzt. Deswegen würde ich die Firmen-IP-Adresse auf eine Whitelist setzen. Dann muss man sich nicht mehr selbst beschränken.
Aber bei einem Botnetz, welches aus tausenden von Zombies besteht, ist die Leitung schnell mal gesättigt, trotz Bandbreitenlimitierung usw. Dann hätten wir wieder die Kondition Denial of Service.
Gruss.
