lighttpd htpasswd authentification

[fl0wde]

Hi Jens,

vorab vielen Dank für deine tolle Arbeit und Unterstützung im ganzen Projekt. So, nun aber zum "fehlerhaften" Part. Ich nutze aktuell (noch bzw. wieder) das Release "RaspberryMatic 2.31.25.20180225", bei welchem alles so funktioniert wie es soll.

Seit dem Update auf "RaspberryMatic 2.31.25.20180324" oder auch "RaspberryMatic 2.31.25.20180428" stimmt irgend was nicht mehr mit lighttpd und zwar konkret mit dem Authentifizierungsmodul über htpasswd.

Über den Aufruf einer geschützen Seite (z.B. XML API) gehen leider wirklich willkürlich Benutzer und Passwörter oder eben auch nicht beim Login. Ich habe diverse Kombinationen ausgetestet, leider kein logisches Muster. Ebenso wird in den Logs nichts gespeichert, nur das eben die Kobination zwischen Benutzer und Passwort nicht stimmen. Es wurden zudem die User + PW neu generiert, sowie die vorhandenen getestet... keine Chance ein Muster zu erkennen.

Beispiel:
User: test
Passwort: test
--> geht

Beispiel 2:
User: test2
Passwort: test
--> geht nicht

/etc/lighttpd/conf.d/auth.conf:

auth.backend = "htpasswd" 
auth.backend.htpasswd.userfile = "/etc/lighttpd/.lighttpdpassword"
auth.require = (
        "/config/xmlapi" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
        "/addons/xmlapi" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
	"/config/email" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
        "/addons/email" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),	
	"/config/cuxd" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
        "/addons/cuxd" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        )
)

/etc/lighttpd/.lighttpdpassword:

test:$apr1$bUJZ8ZB0$xxLP2bXQbocyASNUd3htD0
test2:$apr1$bUJZ8ZB0$xxLP2bXQbocyASNUd3htD0

/etc/lighttpd/lighttpd.conf: -> nur letzte Zeile hinzugefügt

include "/etc/lighttpd/conf.d/auth.conf"

/etc/lighttpd/lighttpd_ssl.conf: -> nur letzte Zeile hinzugefügt

include "/etc/lighttpd/conf.d/auth.conf"

Ggf. kannst du mal schauen was sich zwischen deinen Releases am lighttpd und auth modul selbst geändert hat. Kann gerne sonst noch Feedback geben, falls du Infos für einen PoC brauchst.

[jens-maus]

Danke erst einmal für den Hinweis, muss ich mir bei Gelegenheit einmal näher anschauen denn aus dem Kopf heraus fällt mir jetzt kein Grund ein warum das nicht funktionieren sollte wie du es hier beschreibst.

Trotzdem jedoch der Hinweis (auch wenn du es sicher weisst) das direkte Änderungen im rootfs (d.h. In dem Falle unter /etc/lighttpd) keine gute Idee sind da sie ein Update nicht überleben. Deshalb hatte ich jedoch vor einigen Versionen die Möglichkeit geschaffen unter /usr/local/etc/lighttpd entsprechende *.conf dateien ablegen zu können die dann automatisch beim hochfahren eingebunden werden und dann auch teil eines backups sind und eben dann auch ein RaspberryMatic update überleben.

Abgesehen davon wäre es natürlich im sinne des OpenSource Gedankens von RaspberryMatic schaffen könntest dein Basic-Auth Ansatz für die Absicherung des Webservers mehr zu verallgemeinen damit dieser vielleicht in einer zukünftigen Version direkt integriert werden könnte (solche prinzipiellen Plänehabe ich nämlich schon länger). Natürlich würde das z.b. notwendig machen über ein eventl lighttpd auth modul nachzudenken damit man die logindaten der WebUI dafür nutzen könnte sich zu authentifizieren. Wäre schön wenn du darüber mal nachdenken könntest.

[fl0wde]

Hi Jens, danke für das schnelle Feedback und ebenso die Info mit der ablage über /usr/local/etc/lighttpd.

Ich werde mir das mal die Tage anschauen und meine Scripte entsprechend anpassen und dir dann zur Verfügung stellen. Danach können wir das Thema gerne gemeinsam angehen, denn ich denke einen offenen Zugriff über eine API bzw. Admin-Oberflächen halte ich für sinnfrei ;) Ggf. kannst du dann auch noch "htpasswd" bzw. "apache2-utils" mit in dein Build mit rein compilen um die User/Passwort Erstellung on the fly laufen zu lassen - aktuell fehlt "htpasswd".

Ebenso wäre eine automatische Generierung der auth.conf möglich, jedoch müssten dann pro AddOn der bzw. die API-Pfade in deren Config übergeben werden um so eine genereische Lösung für die Zukunft zu schaffen.

Bin gespannt und gerne mit an Bord :)

[jens-maus]

@fl0wde Wie gesagt, mein Plan ist nicht nun weitere extra Nutzeraccounts nur für die Absicherung des Webservers einzuführen. Meines Erachtens sollte man ggf. für lighttpd ein auth plugin entwickeln das die Username/Passwortdaten über die ReGaHss abträgt damit man nur über die normale WebUI die Nutzer/Passwortdaten pflegen muss und nicht manuell via htpasswd oder yet-another-addon. Sowas sollte IMHO voll integriert sein.

[fl0wde]

@jens-maus
Kurzes update: Im Release "RaspberryMatic 2.31.25.20180526" ist nun der lighttpd auth bug behoben! Danke :)

Ich habe zudem nun auch versucht die conf files bzgl. Pfad anzupassen. Leider wird der Pfad "/usr/local/etc/lighttpd" nicht included, d.h. "meine auth.conf" nicht nicht automatisch eingelesen. Ebenso nicht, wenn ich die komplette "lighttpd.conf" in den besagten Pfad kopiere, dieser wird komplett ignoriert.

Wie hast du dies denn umgesetzt, denn ich der "/etc/lighttpd/lighttpd.conf" und "/etc/lighttpd/lighttpd_ssl.conf" wird kein include vom Verzeichnis "/usr/local/etc/lighttpd" gesetzt?

Bzgl. auth von HomeMatic selbst, hier gibt es folgende auth module: https://redmine.lighttpd.net/projects/1/wiki/docs_modauth. Interessant könnte hier sasl (mod_authn_sasl) (since lighttpd 1.4.48) sein. Geb doch bescheid wie du hier weiter machen möchtest ;)

[jens-maus]

@fl0wde Tschuldigung, der richtige Pfad um eigene lighttpd config Files in das user filesystem abzulegen ist /etc/config/lighttpd. Die entsprechende include Anweisung ist hier zu sehen: https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/patches/occu/0000-RaspberryMatic/occu/arm-gnueabihf/packages/lighttpd/etc/lighttpd/lighttpd.conf#L492.

Übrigens sollte hier noch bedacht werden, das eQ3 selbst gerade an einer Absicherung arbeitet und man erst einmal IMHO abwarten sollte was daraus entsteht damit nicht etwaige Inkompatibilitäten entstehen. Mein Favorit wäre, wie ich schon vorher gesagt hatte, das man es irgendwie schafft (mittels eines eigenen auth plugins) die lighttpd authentification gegen die ReGaHss eigene Nutzerdatenbank durchzuführen und nicht via einer eigenen Userdatenbank oder ähnliches. Ob das via SASL möglich ist, müsste ich mir erst einmal anschauen. Danke aber auf jedenfall für deine Vorarbeiten.

[fl0wde]

@jens-maus
Danke für den Hinweis mit dem Include Path, jedoch hast du diese nur in der "/etc/lighttpd/lighttpd.conf" eingebunden, jedoch nicht in der "/etc/lighttpd/lighttpd_ssl.conf". D.h. in der SSL Veriante geht dein include von include_shell "test -d /etc/config/lighttpd && cat /etc/config/lighttpd/*.conf". Ggf. kannst du das noch beim nächsten Release nachziehen, sonst ist es etwas inkonsistent und für mich nicht nutzbar ;)

Und leider muss ich mich korrigieren, der Bug ist leider doch noch vorhanden und ich habe ihn leider übersehen. D.h. letztes funktionierendes Release mit auth ist: "RaspberryMatic 2.31.25.20180225"

Kannst du dir ggf. mal ein Diff des httpdlight anschauden und derer module, was sich da geändert hat, wäre dir sehr dankbar dafür. Kann dir auch gerne einen kleinen PoC zusammen schreiben, dass du es nachvollziehen kannst ;) Danach können wir ggf. ja dann wirklich mal die Auth Sache im Ganzen anschauen und rausfinden wie wir an die ReGaHss Nutzerdatenbank kommen.

[jens-maus]

@fl0wde Bei RaspberryMatic hat die Datei /etc/lightttpd/lighttpd_ssl.conf keinerlei Funktion und ist obsolete (SSL wird standardmäßig in der /etc/lightttpd/lighttpd.confbereits in Betrieb genommen). Insofern wird das include_shell dort auch nicht benötigt.

Und wenn es da doch noch Probleme gibt mir bitte mehr Detailinfos zukommen lassen da ich momentan nicht genau weiss was dein Problem ist die auth Module aufzunehmen.

[fl0wde]

Gerne, dann hier mein kleiner PoC. Habe alle Pfade angepasst, d.h. keine Schreibrechte mehr mit extra mount nötig.

/etc/config/lighttpd/auth.conf

auth.backend = "htpasswd" 
auth.backend.htpasswd.userfile = "/etc/config/lighttpd/.lighttpdpassword"
auth.require = (
        "/config/xmlapi" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
        "/addons/xmlapi" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
		

		"/config/email" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
        "/addons/email" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
		
		
		"/config/cuxd" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        ),
        "/addons/cuxd" =>
        (
                "method" => "basic",
                "realm" => "api",
                "require" => "valid-user"
        )
)

/etc/config/lighttpd/.lighttpdpassword (pro Zeile ein User:Passwort)

test:$apr1$e3VyFbci$fZYDOEKytnbJO2pWsI7oe/
test2:$apr1$e3VyFbci$fZYDOEKytnbJO2pWsI7oe/
test3:$apr1$e3VyFbci$fZYDOEKytnbJO2pWsI7oe/

-> Passwort ist immer: test
-> Kannst du auch selbst in der Shell erstellen mit: htpasswd -n test

1. Restart von httplight: /etc/init.d/S50lighttpd restart
2. curl Aufruf mit user: curl -k http://test:test@10.24.1.30/addons/xmlapi/info.html -> 200 - OK
3. curl Aufruf mit user2: curl -k http://test2:test@10.24.1.30/addons/xmlapi/info.html -> 401 - Unauthorized
4. curl Aufruf mit user3: curl -k http://test3:test@10.24.1.30/addons/xmlapi/info.html -> 401 - Unauthorized

Fazit: Die 3 User sind nur exemplarisch, d.h. manche User gehen und manche nicht. Ggf. regex match oder so... und dann falsches Passwort herangezogen. Bin gespannt was dein Debug bringt. Danke :)

[fl0wde]

Hab die Files mal in ein Repository geschoben, dann ist es ggf. einfacher für dich:
https://github.com/fl0wde/RaspberryMatic_Authentification

[fl0wde]

@jens-maus Problem besteht leider auch noch mit aktueller Version "RaspberryMatic 2.35.16.20180708". Konntest du dir meinen kleinen PoC bereits ansehen?

[jens-maus]

@fl0wde Nein, ich kam da leider noch nicht dazu. Und wie ich gesagt hatte arbeitet eh eQ3 an der direkten Integration einer solchen authentifizierungsmethode sodass ich das erst einmal damit synchronisieren muss. Da wird sich in Zukunft das Eine oder Andere dann ändern. Sobald ich aber dazu komme werde ich dein PoC mal probieren - hat aber leider wie gesagt niedrige Priorität.

[viper2097]

Gibt es irgendeinen Workaround?
Da ich auf den Passwortschutz angewiesen bin muss ich nach wie vor noch auf der Version 2.31.25.20180225 bleiben :-/...

[pfetzing]

Ich vermute mal, dass das verwandt ist mit dem Lighttpd Fix:

lighttpd/lighttpd1.4@d4083ef

[jens-maus]

@pfetzing Deine Vermutung war richtig, es liegt an der lighttpd 1.4.48 version die anscheinend einen Bug in der base64 dekodierungsfunktion hat. Habe nun für den nächsten Release auf die 1.4.50 version geupdatet und hoffe das damit das Problem beseitigt sein wird.

[pfetzing]

Ich kann auch bestätigen, dass dieser Issue mit dem neusten RaspberryMatic 2.35.16.20180826 nicht mehr auftaucht. Ich habe soeben mit der Version http auth erfolgreich konfiguriert.
Endlich ist Webmatic etwas abgesichert.

[Zefau]

Bitte unbedingt beachten, dass die Methode (vgl. #332) nur Port 80 (und damit die Web GUI) schützt und nicht die API (Port 2000). Diese ist trotzdem ungeschützt.

[jens-maus]

Mit dem Release der 3.41.x firmware reihe ist dieses Ticket wohl obsolete, denn diese Firmware kommt mit einer Default Authentifizierungsmöglichkeit daher.

[libertyx82]

Die Authentifizierung der 3.41.x greift aber nicht für Port 80 & 443 wenn ich das richtig gesehen habe oder?

[jens-maus]

Doch, dafür greift dann die Web-Authentifizierung wenn man den AutoLogin entsprechend abgeschalten hat. Kann auch nicht erkennen warum man das anders haben wöllte. Und wenn ja, dann kann man hier einen eigenen Reverse-Proxy auch vorschalten.

[libertyx82]

Aber nicht für die Addons wie CUxD, XMLAPI usw?

Wenn man weiß wie man einen Reverse-Proxy aufsetzt kann man das, du weißt das vielleicht, ich bekomme das auch noch hin, aber viele andere nicht ;)

[jens-maus]

Mit den Methoden die es in der 3.41.x gibt können CUxD, XMLAPI usw. nun entsprechende Methoden einbauen damit deren Webseiten auch via authentifizierung abgesichert werden. Das müssen aber momentan die Addon Entwickler selbstständig tun denn RaspberryMatic/CCU kann ja nicht wissen ob das erwünscht ist oder nicht.