Gibt es ein fertiges Web-Tunnel-Gateway?

Welches MT Feature nutzt du da genau ? Die Bezeichnung "Web-Tunnel-Gateway" ist ja eher kryptisch und sagt nichts aus über das verwendete Verfahren oder was das genau sein soll.
Man kann darunter mit viel gutem Willen ein SSL VPN Gateway vermuten:
SSL-VPNs im Enterprise Umfeld
das einen VPN Tunnel über eine Website bzw. Website Access (mit Java) realisiert.
Da der MT das aber nicht kann wäre es mal interessant zu erfahren wie du das mit dem MT gelöst hast.
Mal ganz davon abgesehen was "Web-Tunnel-Gateway" IT technisch denn genau sein soll.

MT = Mikrotik

IP Adressen für die Port Weiterleitung ?? Du meinst die Weiterleitung auf interne IPs und damit die internen LAN IPs oder ?
Klingt wieder kryptisch.
Grundsätzlich kann man das ja mit jeder Firewall und jedem Router machen wenn man GUI oder CLI im Internet exponiert.
Du solltest dich aber mal ernsthaft fragen ob du sowas wirklich willst...??
Port Weiterleitung bedeutet das diese Daten von jederman "gesehen" werden und vollkommen ungeschützt transferiert werden.
Deine Gednaken zum Thema VPN sind doch da viel sinnvoller und zudem erreichst du damit genau das was du willst.
Über ein VPN bist du im lokalen LAN wie ein lokaler Client und hast auf alles Zugriff. Genau der tiefere Sinn von VPNs.
Das das dann auch noch datentechnisch sicher ist der 2te Pluspunkt !

Mit Port Forwarding machst du die Firewall löchrig und schaffst immer potenzielle Angriffsfläche für dein Netz, klar !
Machen kannst du es aber dennoch. Musst ja nur die Konfig Oberfläche aus dem Internet erreichbar machen. Was in sich auch schon wieder ein NoGo ist.
Machbar ist aber alles. Ob es sicher und sinnvoll ist, ist natürlich was ganz anderes. Weisst du aber alles sicher auch selber ohne immerwährende Predigten in einem Admin Forum

Moin,
Aqui, stefan will eo fach die firewallregel dynamisch anpassen, wenn sich der client über https authentifiziert hat.

İch würde da auf der firewall ein skript laufen lassen, daß bei erfolgreicher authentifizierung per bash-skript die filterregeln ergänzt. Wa fertiges wird es dafür wohl nicht geben.

lks

OK...verstanden. Also quasi simples Port Forwarding nur mit dem Unterschied das man die inbound Absender IP in einer ACL freigeben will.
Gut, billige Router können das nicht, denn die können nicht nach Absender IP filtern sondenr nehmen alles wenn nur der Port stimmt.
Ausnahme natürlich die OpenWRT oder DD-WRT Maschinen mit denen ist das möglich allerdings nicht so komfortabel in einer GUI.
Mit den üblichen kleinen Business Routern wie Cisco, Lancom Bintec und Co geht das natürlich problemlos.
Bei Cisco ist das eine simple Zeile in der ACL.
Das Problem ist aber das keiner dieser Router sowas wie ein Klicki Bunti GUI dafür hat das der User der das nutzen will quasi sich nach Authentisierung mit einem Mausklick seine Absender IP freischalten kann.
Mal abgesehen davon das User die nicht IT affin sind ohnehin Problem haben werden ihre öffentliche Absender IP, sofern diese dynamisch zugeteilt wurde, zu ermitteln.
Nicht auszumalen was passiert wenn jemand leichtfertig so ein Passwort weitergeben würde.
Die Frage der Sinnhaftigkeit bleibt also.
Fragt sich ob man da nicht mit einem simplen VPN und einer User bezogenen ACL nicht einfacher fährt ?!

Selbstverständlich gibt es das fix und fertig. Das kann jede Firewall, die Webbased Authentication sowie die Berücksichtigung derselben bei den Firewallregeln unterstützt (User aware). Ich würde erwarten, dass das jede aktuelle Firewall kann - per Definition jedenfalls jede UTM oder NGFW. Bei den USGs von Zyxel, Sonicwall und Fortinet ist dies jedenfalls kein Problem. Auch Cisco kann das: http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-ne ...
Das ist im Grunde nichts anderes, als ein Captive Portal - der Unterschied ist nur die Richtung des Traffics und dass die Freischaltung des Benutzers nicht anhand der MAC-Adresse, sondern anhand der Source-IP erfolgt.

Die Frage ist und bleibt allerdings, ob man einen auf der Frontfirewall laufenden Webservice im Web exponieren sollte. Die Antwort ist ganz klar: NEIN! Genau wie ein Webportal-basiertes SSL-VPN gehört diese Funktionalität auf ein dediziertes Gateway in der DMZ!

Die Nutzung von Schwachstellen in Webanwendungen oder Webservern zur Rechteausweitung ist eine der am häufigsten auftretenden Angriffsvarianten. So etwas will man nicht auf seiner Firewall laufen haben - erst recht nicht, wenn man sich vergegenwärtigt, dass bei vielen Herstellern der gleiche Webserver sowohl für die Firewallkonfiguration als auch für die webbasierte Authentifizierung und das Web-VPN zuständig ist. Findet ein Angreifer also eine Lücke im Web-VPN-Service, hat er oftmals schnell die gesamte Firewall unter Kontrolle!
Und glaubt nicht, dass solche Schwachstellen auf Firewalls nicht existieren, weil die Hersteller hierfür sensibilisiert sein müssten. Die coden oft genauso stümperhaft, wie ein Schülerpraktikant. Hier mal zwei "tolle" Beispiele aus dem Hause Zyxel:
https://www.redteam-pentesting.de/de/advisories/rt-sa-2011-003/-authenti ...
https://www.redteam-pentesting.de/de/advisories/rt-sa-2011-004/-client-s ...
Wie gesagt: nur ein (zugegeben sehr prägnantes) Beispiel, weil ich mich bei diesem Hersteller besonders gut auskenne und dies daher ad hoc zur Hand hatte.
Zu sagen, dass soetwas nur bei Billigheimern wie Zyxel passiert, wäre jedenfalls Augenwischerei. Ich kann mich z.B. an ähnliche Schwachstellen bei Juniper und Fortinet erinnern. Auch und gerade Cisco ist nicht fehlerfrei. Bei WebVPN macht Cisco ja immerhin schon vieles richtig, weil der Webserver für die Konfigurationoberfläche und WebVPN getrennte Prozesse sind. Aber selbst ein unpreviligierter WebVPN-Zugang kann in Kombination mit anderen Schwachstellen und Designfehlern schnell zum Problem werden. Siehe http://2014.ruxcon.org.au/assets/2014/slides/Breaking%20Bricks%20Ruxcon ...

Ich hoffe, es ist deutlich geworden, dass all die featureüberladenen UTM- und NG-Firewalls wie Astaro/Sophos usw. unbedarfte Admins in die Falle locken. Der Vertrieb sagt: wir können alles - und zwar in einer Box. Ich sage: mag sein - aber nutzen darf man es so nicht! Eine Front- oder Backfirewall darf keine Dienste im Internet bereitstellen - nicht nur keine Webserver, sondern z.B. auch keine IPSec- oder SSH-Dienste. All diese Dienste gehören auf dedizierte und in einer DMZ isolierte Spezial-Gateways, so dass ein Ausnutzen eventueller Schwachstellen nicht gleich zum Flächenbrand wird!

Ok. Genug in Rage geschrieben. Zurück zum Thema:

Grundsätzlich gilt: ein im Web angebotener Dienst muss möglichst sicher sein. Der Hersteller muss diesen sicher coden und Schwachstellen ggf. zeitnah fixen. Der Admin muss das System sicher konfigurieren/härten, regelmäßig patchen und vorallem monitoren. Zur sicheren Konfiguration gehört auch, dass der öffentlich erreichbare Dienst nur die unabdingbar erforderlichen Informationen speichert und minimierte Zugriffsrechte hat. --> von den "Kronjuweilen" trennen!
Es kann sinnvoll sein, die Angriffsfläche dadurch zu verkleinern, dass die Zugriffe von Extern auf bestimmte authentifizierte Benutzer und/oder Absender-IPs eingeschränkt wird. Wenn hierzu jedoch die Implementierung eines weiteren öffentlichen Dienstes erforderlich ist, muss man sich bewusst sein, dass auch dieser Schwachstellen haben kann und daher entsprechend "behandelt" werden muss. Und eine der dann zu befolgenden Grundlegeln lautet: Funktionstrennung. Keinesfalls darf man jedenfalls einen Webservice auf der Firewall im Internet exponieren!

Gruß
sk

P.S.
Statt einer (Web-)Authentifizierung könnte im vorliegenden Fall evtl. auch Portknocking eine Alternative sein. Das lässt sich z.B. mit einem Mikrotik problemlos implementieren: http://mum.mikrotik.com/presentations/US10/discher.pdf

Dann kannst du das auch per DynDNS der Clients lösen: Die Hostnamen in der pfSense als Alias definieren und dann die Firewall/NAT-Regel für den Alias erstellen. Das Auflösungsintervall (System>Advanced>Firewall/NAT) ist standardmäßig 5 Min. Wenn die Nutzer geduldig sind, reicht ihnen ein Update-Link ohne DynDNS-Client.

Grüße
Richard

Hi Stefan,

wenn du das Implementiert haben möchtest, sag Bescheid - mit 1h bekommen wir das leicht hin!


LG,
Stefan

Und das wäre jetzt dann einen normale Port Forwarding Regel die an eine inbound Firewall Regel gebunden ist wo dann manuell die entsprechenden Absender IPs eingetragen werden ?
OK, das kann man ja dann so machen ist aber etwas Handarbeit.
Weiterhin bleibt natürlich die Gefahr die mit Port Forwarding an sich einhergeht.

Aqui,

ja, im Prinzip:

Die Rule lege ich dynamisch via API an, nach erfolgreicher OTP Authentifizierung.

OTP=One Time Password ?
Da muss ich mal doof nachfragen: Brauchst du dafür externe Tools ? Normal geht das ja nicht mit dem MT und Bordmitteln nicht.
Verbirgt sich ein MT Skritpt dahinter ? Klingt auf alle Fälle interessant nur rätsel ich etwas rum wie das konkret technisch geht ?!

Hi aqui,

OTP = one time Passwort, korrekt!

Selbstverständlich, dafür braucht man einen Webserver, der dann auf den Mikrotik zugreifen darf (via API).

LG,
Stefan

Das ist dann etwas Sinnbefreit, mindestens Port 443 sollte schon erreichbar sein

Gibts da irgendwie ne Doku zu der MT API ??

http://wiki.mikrotik.com/wiki/Manual:API

Kann man aber bei Bedarf auch über einen einfachen SSH-Client und plink etc. pp abfackeln.

Gruß

Cool...wieder was gelernt
Muss ich glatt mal probieren mit SSH.
Gibts da auch irgendwie ne Sicherung ? Ohne wäre es ja fatal denn damit könnte man ja die Konfig vollständig manipulieren.

Geht natürlich per SSH nur mit Authentifizierung (user, pass) welches du mitschickst, wäre ja noch schöner

Unter Windows mit plink z.B. so
Geht natürlich bevorzugt auch mit Zertifikatauth ohne Passwörter.

Ich nehme mal an bei unixoiden OS ist das dann rein SSH statt plink, richtig ?
Danke für das Beispiel !

Korrekt. Machst du dann wie bei einer normalen SSH-Verbindung zwischen zwei Linux Kisten.

Auch wenn mein obiges Posting komplett ignoriert wurde, muss ich doch noch ein letztes Mal mahnend den Finger heben:

Meine aktive Mikrotik-Zeit ist lange her und vielleicht bin ich deshalb nicht mehr auf dem letzten Stand oder zumindest nicht tief genug im Thema, aber meines Wissens ist es in RouterOS nicht möglich, die Rechte eines MT-Users soweit einzuschränken, dass er nur eine ganz bestimmte Firewallregel setzen oder ändern kann. Deine Webanwendung oder zumindest der Prozess, der letztlich die Configänderungen in den MT schreibt, müsste m.E. die Zugangsdaten für einen User-Account auf dem MT haben, der über die Login-Policy "api" und die Config-Policy "write" verfügt. Außerdem muss natürlich die erforderliche Netzwerkkonnektivität gegeben sein.
Dies bedeutet: Das selbst gestrickte Authentifizierungsfrontend oder zumindest der dahinterliegende Prozess, der die gewünschten Config-Änderung in den MT schreiben soll, hat nahezu uneingeschränkte Rechte für Konfigurationsänderungen auf dem MT (bei fehlendem "policy" kann er z.B. keine Änderungen an der Userdatenbank vornehmen). Die Sicherheit dieses Systems steht und fällt also mit der Sicherheit und Fehlerfreiheit des Webfrontends/Änderungsprozesses!

Selbst wenn ich annehme, dass die obige Zeitangabe von einer Stunde sich nicht auf das schnelle Dahincoden in einer serverseitigen Skriptsprache bezieht, sondern rein auf die Implementierung einer durchdachten, auch unter Sicherheitsaspekten genau untersuchten und getestenten sowie in der Praxis bewährten Lösung bezieht, dann erscheint mir dies dennoch nur dann vertretbar, wenn der auf diese Weise angesteuerte Mikrotik-Router nicht gleichzeitig die bisherige Firewall substituiert, sondern innerhalb eines mehrstufigen Firewallkonzeptes lediglich für diesen speziellen Kommunikationskanal als dedizierte zusätzliche Ergänzung dient. Die von diesem Miktorik-Router ausgehenden Verbindungen müssen sämtlichst von einer davon unabhängigen Firewall reglementiert werden und im Falle nicht erwarteten Traffics muss das Monitoring ganz laut "Alarm" schreien.

Alles andere wäre meiner Meinung nach grob fahrlässig! Ein remote steuerbarer Mikrotik-Router unter fremder Kontrolle verkehrt nicht nur den hier avisierten Nutzen ins Gegenteil und verringert das angestrebte Schutzniveau beim TO, sondern kann auch als beachtliche Waffe gegenüber Dritten genutzt werden.

Bewährte Best Practices haben ihren Sinn und sollten nicht leichtfertig ignoriert werden, denn gut gemeint ist nicht immer auch gut gemacht und der Teufel ist immer ein Eichhörnchen!

Gruß
sk