httpapi - funktioniert nur aus dem internen Netz, nicht per Portforwarding

[Eckat]

Moin zusammen,

ich habe ein httpapi device erstellt.

Damit möchte ich in einem Dummy-device einen Status setzen, ob mein Handy mit dem Auto-Bluetooth verbunden ist.
Der Aufruf klappt über die interne URL: http://192.168.2.10:8087/api/set?device=verbunden&action=1 zuverlässig.

Ich habe in der FritzBox einen DynDNS Dienst eingerichtet und ein Portforwarding auf den Raspberry Pi 4, auf dem fhem läuft, eingestellt 8087 -> 8087.
Der Aufruf über http://dyndnsadresse:8087/api/set?device=verbunden&action=1 funktioniert nicht.

Die Firewall auf dem RPi 4 habe ich mit folgendem Befehl geöffnet und danach reloaded:

Code Auswählen Erweitern

firewall-cmd --permanent --zone=public --add-port=8087/tcp
Die Rückmeldung wenn ich das per curl aufrufe (von einem externen Server oder intern ist egal):

Code Auswählen Erweitern

Recv failure: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt
Schaue ich mit mit "tcptrack -d -r20 -i eth0" die Verbindungen an, sieht das für die abgelehnte Verbindung wie folgt aus:

Code Auswählen Erweitern

88.111.222.77:61725   192.168.2.101:8087    RESET        17s    0 B/s
Mein aktueller Verständnisstand ist:

• Anfrage intern funktioniert: httpapi und URL an sich OK
• Portweiterleitung auf der FritBox funktioniert auch, da sonst keine Verbindung auf dem RPi ankommen würde
• Firewall müsste richtig sein, denn ohne die Freigabe von 8087 funktioniert es auch intern nicht

Hoffe mir kann jemand helfen. Wahrscheinlich sehe ich nur den Wald vor lauter Bäumen nicht.
Aber ich hab mich jetzt schon ein paar Abende damit rumgeschlagen und weiß auch nicht mehr weiter, wie ich das Problem noch eingrenzen soll.

Danke und Gruß
Carsten

[Otto123]

Hallo Carsten,

ich zitiere mal die Doku von FHEMWEB

allowfrom
Regexp der erlaubten IP-Adressen oder Hostnamen. Wenn dieses Attribut gesetzt wurde, werden ausschließlich Verbindungen von diesen Adressen akzeptiert.
Achtung: falls allowfrom nicht gesetzt ist, und keine gütige allowed Instanz definiert ist, und die Gegenstelle eine nicht lokale Adresse hat, dann wird die Verbindung abgewiesen. Folgende Adressen werden als local betrachtet:
IPV4: 127/8, 10/8, 192.168/16, 172.16/10, 169.254/16
IPV6: ::1, fe80/10

Das sollte genau Dein Problem sein.
Du musst eine allowed Instanz definieren https://fhem.de/commandref_DE.html#allowed

Gruß Otto

[passibe]

Und bitte später im Produktiveinsatz nicht HTTP benutzen und mindestens basic auth oder irgendeinen Token nutzen (hab httpapi noch nie verwendet, keine Ahnung, was da alles unterstützt wird) ...

[Eckat]

Hallo Carsten,

ich zitiere mal die Doku von FHEMWEB
[...]

Das sollte genau Dein Problem sein.
Du musst eine allowed Instanz definieren https://fhem.de/commandref_DE.html#allowed

Gruß Otto

Das klingt sehr danach! Vielen Dank, werde ich nachher testen.
Vielleicht bin ich auch zu dumm zum suchen, aber ich hab bei meinen Recherchen und Suchen keinen Hinweis auf FHEMWEB und allowedfrom gesehen. Evtl. könnte man das als Tipp mit in die CommandRef von httpapi aufnehmen.

Und bitte später im Produktiveinsatz nicht HTTP benutzen und mindestens basic auth oder irgendeinen Token nutzen (hab httpapi noch nie verwendet, keine Ahnung, was da alles unterstützt wird) ...

Danke für den Hinweis. Ja daran habe ich gedacht und mir ist das auch bewusst.
Allerdings ist das Risiko auch überschaubar, es ist ja nur der Port 8087 von außen erreichbar und ich gebe im httpapi auch nur zwei dummy devices frei.


Danke und Gruß
Carsten

[Wernieman]

Oder Du setzt wenigstens ein reverse-Proxy (nginx, apache) davor ....

[Eckat]

Wie ich geschrieben habe, ich habe das auf dem Schirm. Danke 
Aber das richte ich ein, nachdem ich das funktional fertig habe 

[Otto123]

Allerdings ist das Risiko auch überschaubar, es ist ja nur der Port 8087 von außen erreichbar und ich gebe im httpapi auch nur zwei dummy devices frei.

Nein das Risiko ist sehr hoch! Es dauert wahrscheinlich nur Sekunden bis einer Deinen freien Port findet und FHEMWEB übernehmen würde. Man kann von FHEMWEB ins System und wenn der User fhem erhöhte Rechte haben sollte ... Aber auch ohne ist FHEMWEB keine darauf getestete sichere Anwendung die man ohne Anmeldung ins Internet stellen könnte.

[Eckat]

OK, OK ... ich verspreche es vor Freigabe nach Außen abzusichern! 

Aber noch ist es nicht soweit.
Ich hatte schon eine allowed Instanz, diese habe ich abgeändert, aber auch eine neue Instanz erstellt.

Wenn ich es richtig sehe, kann man beim allowed beim Attribut validFor "nur" FHEMWEB, telnet usw. angeben?
Zur Auswahl steht mein httpapi device nicht und ein manuelles Eintragen funktioniert nicht.

Folgendes ist aktuell eingerichtet:

Code Auswählen Erweitern

define web_secure FHEMWEB 8183 global
attr web_secure HTTPS 1

Code Auswählen Erweitern

define allowedWEB allowed
attr allowedWEB allowedCommands get,set
attr allowedWEB allowedDevices verbunden,httpapi
attr allowedWEB basicAuth {"$user:$password" eq "test:test"}
attr allowedWEB basicAuthMsg Bitte das Passwort eingeben
attr allowedWEB validFor web_secure


Code Auswählen Erweitern

define httpapi HTTPAPI
attr httpapi devicesCtrl mobil_connect
Die Basic-Auth funktioniert, aber mit der URL
https://192.168.20.10:8183/api/set?device=verbunden&action=1
mit einem 302 nach /fhem umgeleitet.

Gibt es noch Tipps?

Danke und Gruß
Carsten

[Otto123]

Hallo Carsten,

sorry ich dachte es setzt alles auf FHEMWEB auf, da lag ich offenbar schief.
Da habe ich Dich in die falsche Richtung geleitet.

Gruß Otto

[passibe]

Dann ist es vielleicht wirklich einfacher einen reverse proxy davor zu hängen.
Damit erübrigt sich das Problem, weil dann aus Sicht von FHEM der Zugriff nur vom lokalen Netz kommt (bzw. sogar nur vom loopback-interface, sodass du HTTPAPI auch auf local stellen könntest).

Der reverse proxy kann dann direkt auch TLS-termination machen und basic auth zur Verfügung stellen (noch sicherer wäre mit mTLS oder einem VPN zu arbeiten, aber basic auth tut es schon auch).