Reverse proxy mit OTP

WernerH

WernerH

Member
Hallo zusammen,

nachdem ich nun schon fast den ganzen Tag und die halbe gestrige Nacht gegoogelt und verschieden Dinge mit Apache und Nginx ausprobiert habe, aber nichts so funktioniert, wie ich es mir eigentlich wünsche, hab' ich gedacht ich frag mal hier nach ob von euch vielleicht einer Idee oder noch besser, auch ein paar Links dazu hat.

Also, worum gehts?

Nun, ich monitore meine Server mit Icinga2 und es geht um den Zugriff auf IcingaWeb2 übers Internet. IcingaWeb2 ist nur User/Pw geschützt, ich würde aber gerne 2FA dafür implementieren. Bei den Icinga2 Developern gab's dazu letztes Jahr im April schon eine Diskussion, aber eine Einigung oder Anpassung des Webinterfaces kann ich bisher nicht erkennen.

Also hab' ich mir gedacht, ich schalte einen Reverse Proxy dazwischen. Im Moment ist das bei mir ein Apache, ich kann aber auch auf nginx wechseln, wenn das, was ich möchte, damit einfacher geht.

Ich möchte, dass sich der Benutzer, wenn er über den Reverse Proxy auf IncingaWeb2 zugreift, zunächst mit dem Token aus der Google Authenticator App am Reverse Proxy authentifizieren muss und dann zum IcingaWeb2-Server weitergeleitet wird. Was ich gefunden habe sind nur Lösungen, die zunächst im Proxy User/Pw abfragen, dann den Code der Google Authenticator App abfrageb und danach die Weiterleitung an den IcingaWeb2-Server ausführen. Dort muss ich mich dann aber nochmal mit User/Pw anmelden und das ist mir einmal zu viel.

Ich suche als eine Lösung für einen Reverse Proxy, der (ohne vorherige Abfrage von User/Pw) direkt meinen Token aus der Google Authenticator App abfragt und mich danach sofort weiterleitet.

Habt Ihr vielleicht 'ne Idee, wie ich das hinbekomme oder ob es dafür bereits irgendwelche Lösungen gibt?

Grüße

Werner
 
Die drei Lösungen die mir spontan einfallen wären:

a) Cloud-Lösung mit niedrigem Aufwand
Anbieter wie Cloudflare bieten neben klassischem CDN/Intrusion-protection auch Access-Control an. Bei Cloudflare heisst das Teams und kann je nach Anforderungen bis 50 User kostenfrei benutzt werden.

b) Auth-Request Server
Nginx kann über eine externe URL Anfragen validieren.
Möglich wären zb:

- OAuth:
Dein Login kann entweder über OAuth-Login der Applikation oder durch den Nginx Reverse-Proxy abgesichert werden
Beispiel: https://developer.okta.com/blog/2018/08/28/nginx-auth-request

- Radius Provider

- Direkte TOTP-Implementierung (Beispiel)
github.com

GitHub - newhouseb/simpleotp: Simple (T)OTP Server for Nginx Auth

Simple (T)OTP Server for Nginx Auth. Contribute to newhouseb/simpleotp development by creating an account on GitHub.
github.com github.com
 
nur für einen Service evtl. ein wenig oversized - aber ein Blick Richtung API-Gateways könnte da auch passen:
z.B. https://docs.gravitee.io/apim/3.x/apim_policies_oauth2.html

Wenn's nur um's Absichern von Icinga geht und nur um eine minimale Anzahl User würde ich aber eher auf ein Client-SSL-Zert. setzen als da das große Fass aufzumachen, vor allem wenn es von Icinga nicht direkt supported wird...
 
Hallo zusammen,

zunächst einmal vielen Dank an @d4f und @marce für eure beiden Antworten - damit habt ihr mir schon mal ein gutes Stück weiter geholfen!

Nachdem ich es möglichst einfach halten möchte werde ich es zunächt einmal mit der von @d4f unter b) - Direkte TOTP-Implementierung (Beispiel) skizzierten Lösung versuchen. Ich denke, das ist genau das was ich suche bzw. haben möchte.

Bevor ich meine Frage hier im Forum gestellt habe, hatte ich mir auch schon überlegt, einen oauth2-proxy aufzusetzen und den die Authentifizierung machen zu lassen. Das Problem ist nur, dass ich nichts an Doku dazu gefunden haben, wie ich den oauth2-proxy zur Zusammenarbeit mit dem Token aus der Google Authenticator App (also OTP) überreden kann bzw. ob das im oauth2-proxy überhaupt implementiert ist. Grundsätzlich findet man schon einiges an Doku für die Zusammenarbeit mit dem Google Authenticator, aber die geht davon das, dass man (s)einen Google-Account für die Authentifizierung verwenden möchte und genau das möchte ich ja eben nicht. Ein Beispiel dazu findet sich z.B. hier.

Für den Webindianer gibt's auch eine Authentifizierung mit OTP, aber erst nach der Authentifizierung mit User/Pw. Beispiele dazu gibt's hier und hier. Aber das ist ja genau das, was ich eben nicht möchte!

Also, ich probier das o.g. Beispiel jetzt mal aus und wenn's nicht funktionieren sollte rühr ich mich nochmal.
 
Hallo Werner, hallo zusammen,

ich bin im Forum auf den Thread hier bzgl. otp-Implementierung auf dem nginx gestoßen.
Ich bastele zwar ein wenig mit dem nginx rum, allerdings eher rudimentär als Reverse Proxy für meine internen Dienste.
Daher tu ich mich noch etwas schwer, den Einstieg in Module wie auth2 o.ä. hinzubekommen.

Hast du die OTP-Implementierung auf deinem nginx hinbekommen?

Du beschreibst genau das, was ich auch vorhabe: Ein vorgeschaltetes OTP ohne Benutzername/Kennung vor den Diensten.
Ich hoste einige für mich kritische Dienste (z.B. Guacamole, Proxmox, PiHole) , an die ich gerne ohne VPN per Web kommen möchte, die ich aber aufgrund der Tragweite absichern möchte.

Einige der Dienste haben zwar eine 2FA-Implementierung, die man aktivieren könnte.
Ich hätte jedoch gerne eine zentrale, vereinheitlichte, simple Lösung für alle Dienste.
Dieses Feature sollte nicht auf externe Dienstleister angewiesen sein.

Zwar wäre mir an einem OTP per Mail sehr gelegen, um nicht auf eine OTP-Software auf einem Smartphone angewiesen zu sein, aber ein Schritt nach dem Nächsten.

Vielleicht könntest du mir Starthilfe geben, damit ich einen Ansatz habe - ich brauche oft etwas Greifbares, ein kurzes HowTo, damit ich eine Richtung habe, in die ich recherchieren kann.
Im Moment sehe ich den Wald vor lauter Bäumen nicht.

Vielen Dank

Patrick
 
Hi Thunderbyte,
ja, Authelia klingt - das was ich auf die Schnelle recherchiert habe - schonmal ganz gut.
Die Frage ist, ist das nicht mir Kanonen auf Spatzen geschossen?

Ich sag mal so - außer mir greift keiner auf die Oberfläche zu. Es geht mir Hauptsächlich darum, von unterwegs mal meine Konfig daheim anzusehen. OK, meine Frau nutzt noch das Kanbanboard, das gegen einen OpenLDAP authentifiziert.

Prinzipiell hatte ich die naive Hoffnung, dass es ein öffes Script im nginx gibt, dass bei Zugriff auf einen Dienst zuerst eine schlichte Eingabemaske anbietet, im Hintergrund einen Code generiert und mir den dann zukommen lässt damit ich ihn eintragen kann - ähnlich der Aktivierungsmails z.B. dieses Forums hier oder halt wie es die "großen" alle machen. Selbst sämtliche Spiele-Anbieter senden dir eine Mail, um dich beim Login zu verifizieren).

Mein nginx läuft auf nem Raspberry, darauf läuft dann auch ACME.sh für Let's Encrypt.
Wenn ich also Authelia nutzen will, muss ich mir auf dem Proxmox dafür eine eigene VM erzeugen.
Kein Ding - aber das macht die Sache schon wieder extremst aufwändig.

Auf der Arbeit experimentieren die Kollegen gerade mit KeyCloak rum - das ist für unseren Rechenzentrumsbetrieb sicherlich lohnenswert. Aber daheim?

Trotzdem klingt Authelia dahingehend gut, dass ich mir bei Gelegenheit mal eine VM gönne.
Nichtsdestotrotz ist es im Moment glaube ich nicht das, was ich suche.
Ich mag mich irren.
 
Nicht ganz was du gefragt hast aber simpel, leicht zu verwalten und - recht wichtig - praktisch wartungsfrei.

Um Verkehr in ein nicht-öffentliches Netzwerk ab zu sichern gibt es noch die einfache Möglichkeit eine Service-Dienstleistung zu verwenden.
Meine Heimnetz-Dienste sind von aussen ausschliesslich über cloudflared (ehemals Argo Tunnel) erreichbar, also ohne port-forwarding und öffentliche IP. Kombiniert mit Cloudflare Access kann man dann entweder TOTP-Token oder spezifische Konten eines Identity-Providers freischalten.
Die praktischste Lösung ist dabei bspw ein Google-Login was eine robuste Authentisierung mit einfacher Nutzbarkeit kombiniert.
Nebenbei braucht man sich dann nicht um Zertifikate zu kümmern und eine Webfirewall rundet ab.

Wenn es selbst gehostet sein soll, so würde ich persönlich über JWT Cookies versuchen zu fahren welche über ein Captive-Portal über TOTP-Validierung generiert werden.
Will heissen: wenn der Benutzer kein oder ein ungültiges Cookie hat wird die Anfrage auf das Captive-Portal umgeleitet und ein TOTP-Prompt abgefragt. Stimmt dieses setzt der entsprechende LUA-Code (oder dediziertes Backend) ein Cookie mit Lebensdauer=Session und einem signierten JWT-Token. Weitere Anfragen werden dann über auth_jwt mit dem Token validiert und über das Reverse-Proxy durchgewunken.
Fertige Skripte dazu sind mir aber keine bekannt. Allerdings setzt dies voraus dass dein Heimnetz Webserver (so wie vermutlich aktuell) direkt aus dem Internet erreichbar ist, und dieser inklusive aller Authentisierungskomponenten rigorös gepatcht wird, was leider generell nicht der Fall ist :)
 
Sorry, aber mal ehrlich, für solchen privaten Kleinkram ist das gute alte Basic-Auth noch immer völlig ausreichend...

Und es funktioniert auch wenn man mal keinen Zugang zu seinem Mailkonto, Handy oder der Auth-App hat...
 
Basic Auth würde auch der Nginx Proxy Manager bringen, besonders hilfreich, wenn man seine Anwendungen Docker containerisiert hat (was zu empfehlen ist).

Ansonsten ja, Authelia mag zu komplex sein, allerdings ist OTP Integration in eine Anwendung, die das von Haus aus nicht anbietet halt auch nicht ganz trivial.

Die ganz andere Alternative wäre, die Anwendungen von außen gar nicht erreichbar zu machen und statt dessen auf https://www.zerotier.com/ auf allen beteiligten Geräten zu setzen und somit die internen Services nur über VPN zu verwenden. ZT ist dabei etwas anderes als "andere" VPNs und immer ein Ausprobieren wert.
 
You must log in or register to reply here.
Back
Top