Hilfe bei ipv6 und DynDNS

JeGr

Hallo Woodym,

@woodym said in Hilfe bei ipv6 und DynDNS:

Bezüglich des Logins, kann ich nur sagen: peinlich. Vielleicht hätte ich die letzten Änderungen auch stagen sollen :-( . Also die Registrierung über Mailaddresse sollte nun auch reibungslos funktionieren.

Kommt vor ;) Immerhin ists jetzt aufgefallen. Allerdings scheints mit deiner Aktivierungsmail noch Probleme zu geben. Die kommt zwar an, klickt man sie aber an, kommt man wieder ins Dashboard mit der gleichen Meldung "Weil du einen Neuen Account ... etc.etc." anstatt hier der Bestätigungslink akzeptiert wird. Scheint also im Backend noch etwas zu knirschen ;)

Deine Anregung zur DSGVO habe ich aufgenommen und explizit die gespeicherten Daten aufgeführt. Vielleicht hilft es einen Nutzer zu entscheiden ob er den Dienst nutzen möchte oder nicht.

Transparenz ist immer super! :)

Aber bei einem Dienst den ich vielleicht 1 mal im Jahr besuche ist das schwieriger. Zumal die Hinterlegten Update-Informationen im Router vollkommen abgetrennt sind von Account.

Korrekt von der Idee. Aber nicht die Daten im Router werden ja ausgelesen oder "gekapert", sondern ein Bot feuert bspw. die jüngste geleakte E-Mail Liste von einem Data Breach wie vom jüngsten XKCD Board gegen deinen Service um zu sehen, wer von den IT Jungs da nen Account hat. Muss er das mit der ganze Liste (bspw. 100k) Adressen, wird Passwort Brute-Forcing schwer. Macht er das am Ende mit 5 Adressen hat sich die Komplexität der Aktion um einige Faktoren reduziert.
Eine andere Möglichkeit wäre hier beim PW Reset einen Counter pro IP oder Mail zu setzen, der nach 3-5 Versuchen für die gleiche Mailadresse oder von der gleichen IP für verschiedene Adressen erstmal ne Zwangspause verhängt :) Das würde gegen PW Bruting und Tabellen-Attacken auch erstmal temporär helfen.

Grüße
Jens

JeGr

@woodym Anhang: OK gleich die nächsten Anmerkungen zur Implementation ;)

Bei jedem Klick im Dashboard kommt die Meldung mit der "Nicht-Aktivierung" -> nervt. Einmal nach dem Login anzeigen und dann einen roten Banner obendrüber wie bei pfSense bei nicht geändertem Standard Passwort als Erinnerung. Alles andere ist Behinderung solange die Validierungs-Mail nicht geht.
Die Beispiele und Domainliste etc. ist von der Übersicht her erstmal toll. Ich sehe aber keinen Grund für die Glühbirne (die etwas unscheinbar ist) -> warum nicht direkt die Beispiele mit den Live-Daten füttern die er aus Browser und Account ausliest?
Ich würde rein theoretisch gar keinen Service mehr via HTTP anbieten. Du hast HTTPS - nutze es :)
Beim Re-Send wird genau die gleiche Aktivierungs-URL gesendet. Normalerweise erwartet man rein vom Code-Design her, dass die bisherige Aktivierungs-ID ungültig gemacht wird und eine neue erzeugt (weil ggf. was mit der alten ID o.ä. nicht stimmte oder geklappt hat). Hier bekomme ich die gleiche Mail einfach wieder. Entweder also Templating oder die ID ist eindeutig - was sie theoretisch nicht sein sollte um Rückschlüsse auf den Account zu vermeiden. Die Zuordnung der Aktivierungs-ID sollte rein theoretisch temporär und zeitgebunden sein - hier einfach im Popup konkrete Zeit definieren (48-72h bspw. um Probleme mit Mailservern auszuschließen) und dann bei der Generierung der Aktivierungs-ID einfach auch nen Verfallstimer dranhängen. Dann noch Garbage Collector o.ä. drauf ansetzen, die IDs jede Stunde bspw. zu bereinigen und wenn der Account für diese AktivierungsID noch nicht aktiviert wurde, Account Login deaktivieren (und nach Übergangszeit entsorgen). Das wäre mein Ansatz aber ich bin schon länger aus dem Coding raus ;) Manche Sachen wird man aber nach dem Studium einfach nicht los :D
Alternativ statt der curl Get Methode wäre ein HTTP/PUSHnoch schöner. Dazu dann eben Push Parameter und pushen per JSON/XML/o.ä. -> funktioniert zwar (noch) nicht in vielen Routern, macht den Dienst aber flexibel nutzbar UND Push per HTTPS wäre sicherer beim Abhören von Daten -> Keine Parameter der URL zum Auslesen :)

Edit 2:

OK ich habe jetzt verstanden dass mit IP/encrypt wohl IP pushen und LetsEncrypt ausstellen gemeint ist? Da fehlt mir trotzdem Dokumentation dazu was das heißt bzw. ob ich als Nutzer dann noch auf irgendwas achten muss. Was für ein Token muss ich setzen oder wird das automatisch gesetzt, etc.
Minor C&P Error: Edit-Maske bei "Token" hat als Überschrift "IPv6 Ändern" ;)

woodym

Kommt vor ;) Immerhin ists jetzt aufgefallen. Allerdings scheints mit deiner Aktivierungsmail noch Probleme zu geben. Die kommt zwar an, klickt man sie aber an, kommt man wieder ins Dashboard mit der gleichen Meldung "Weil du einen Neuen Account ... etc.etc." anstatt hier der Bestätigungslink akzeptiert wird. Scheint also im Backend noch etwas zu knirschen ;)

Du solltest nach der Registrierung sofort im Dashborad sein mit dem Hinweis das du noch den Account Aktiviern mußt (instant access). Nach wegklicken des Hinweises kannst du schon alles machen. Nur wenn du nicht aktivierst wird der Account nach einem Tag gelöscht. Durch den sofortigen Zugang zum Dashboard hast du die Möglichkeit bei Bedarf die Aktivierungsmail nochmals zusenden zu lassen.

Aber bei einem Dienst den ich vielleicht 1 mal im Jahr besuche ist das schwieriger. Zumal die Hinterlegten Update-Informationen im Router vollkommen abgetrennt sind von Account.

Korrekt von der Idee. Aber nicht die Daten im Router werden ja ausgelesen oder "gekapert", sondern ein Bot feuert bspw. die jüngste geleakte E-Mail Liste von einem Data Breach wie vom jüngsten XKCD Board gegen deinen Service um zu sehen, wer von den IT Jungs da nen Account hat. Muss er das mit der ganze Liste (bspw. 100k) Adressen, wird Passwort Brute-Forcing schwer. Macht er das am Ende mit 5 Adressen hat sich die Komplexität der Aktion um einige Faktoren reduziert.
Eine andere Möglichkeit wäre hier beim PW Reset einen Counter pro IP oder Mail zu setzen, der nach 3-5 Versuchen für die gleiche Mailadresse oder von der gleichen IP für verschiedene Adressen erstmal ne Zwangspause verhängt :) Das würde gegen PW Bruting und Tabellen-Attacken auch erstmal temporär helfen.

Das werde ich Aufnehmen, danke

JeGr

@woodym said in Hilfe bei ipv6 und DynDNS:

Du solltest nach der Registrierung sofort im Dashborad sein mit dem Hinweis das du noch den Account Aktiviern mußt (instant access).

Richtig, das Popup kommt allerdings bei jedem Klick in der Seitenleiste erneut.

Nur wenn du nicht aktivierst wird der Account nach einem Tag gelöscht. Durch den sofortigen Zugang zum Dashboard hast du die Möglichkeit bei Bedarf die Aktivierungsmail nochmals zusenden zu lassen.

Siehe Anhang :D Gerade nochmal 2 Sachen reineditiert :)

woodym

@JeGr said in Hilfe bei ipv6 und DynDNS:

@woodym Anhang: OK gleich die nächsten Anmerkungen zur Implementation ;)

Die Beispiele und Domainliste etc. ist von der Übersicht her erstmal toll. Ich sehe aber keinen Grund für die Glühbirne (die etwas unscheinbar ist) -> warum nicht direkt die Beispiele mit den Live-Daten füttern die er aus Browser und Account ausliest?

wenn du 5 Domains hast (3 aktive und 2 inaktive) kannst du hier 6 Beispiele zeigen lassen. Welches Beispiel sollte ich dann per Default nehmen?

Ich würde rein theoretisch gar keinen Service mehr via HTTP anbieten. Du hast HTTPS - nutze es :)
das ist dem Umstand geschuldet das Embeddet Systeme nicht zwingend die Möglichkeit haben https zu verwenden. Da reicht einfach nicht die Rechenpower aus oder der Speicher. So kann man einen ESP8266 oder Arduino den Update per HTTP machen lassen.

Beim Re-Send wird genau die gleiche Aktivierungs-URL gesendet. Normalerweise erwartet man rein vom Code-Design her, dass die bisherige Aktivierungs-ID ungültig gemacht wird und eine neue erzeugt (weil ggf. was mit der alten ID o.ä. nicht stimmte oder geklappt hat). Hier bekomme ich die gleiche Mail einfach wieder. Entweder also Templating oder die ID ist eindeutig - was sie theoretisch nicht sein sollte um Rückschlüsse auf den Account zu vermeiden. Die Zuordnung der Aktivierungs-ID sollte rein theoretisch temporär und zeitgebunden sein - hier einfach im Popup konkrete Zeit definieren (48-72h bspw. um Probleme mit Mailservern auszuschließen) und dann bei der Generierung der Aktivierungs-ID einfach auch nen Verfallstimer dranhängen. Dann noch Garbage Collector o.ä. drauf ansetzen, die IDs jede Stunde bspw. zu bereinigen und wenn der Account für diese AktivierungsID noch nicht aktiviert wurde, Account Login deaktivieren (und nach Übergangszeit entsorgen). Das wäre mein Ansatz aber ich bin schon länger aus dem Coding raus ;) Manche Sachen wird man aber nach dem Studium einfach nicht los :D

Das wurde bewust so gestaltet. Auch wieder eine Sache aus dem eigenen Leid geboren. Ich verwende Greylisting... das bedeutet das ein Link der mir vor 15 Minuten zugesendet wurde nach einer 2. Mail erst eintrifft (wenn die Widerholungsversuche innerhalb des Zeitfensters erfolgen in denen die eine mail noch geblockt wird, die andere aber bereits freigeschaltet ist). So habe ich schon Stunden damit zugebracht einen gültigen Aktivierungslink zu erhalten. Die Nerverei wollte ich den Nutzern ersparen.

Alternativ statt der curl Get Methode wäre ein HTTP/PUSHnoch schöner. Dazu dann eben Push Parameter und pushen per JSON/XML/o.ä. -> funktioniert zwar (noch) nicht in vielen Routern, macht den Dienst aber flexibel nutzbar UND Push per HTTPS wäre sicherer beim Abhören von Daten -> Keine Parameter der URL zum Auslesen :)

das nehme ich gerne als anregung auf... wobei auch ein POST dann denkbar wäre.

BTW: nirgends wird erklärt, was mit IP/encrypt gemeint ist bzw. was es leistet :)

#ooops#
Und ich dachte das ich das auch der Homepage mich schon viel zu viel darüber ausgelassen hatte.

woodym

OK ich habe jetzt verstanden dass mit IP/encrypt wohl IP pushen und LetsEncrypt ausstellen gemeint ist? Da fehlt mir trotzdem Dokumentation dazu was das heißt bzw. ob ich als Nutzer dann noch auf irgendwas achten muss. Was für ein Token muss ich setzen oder wird das automatisch gesetzt, etc.

Das sind noch die Beispiele die ich mit aufnehemn will. Bei Let's encrypt will ich komplett eine Beschreibung für Dehydrated und einem Update machen.
Das kommt dann auch mit der Beschreibung für pfsense und noch einige andere Geräte wie das dort eingetragen werden muß.

Minor C&P Error: Edit-Maske bei "Token" hat als Überschrift "IPv6 Ändern" ;)

das ist geändert ;-)

Ich bin wirklich begeistert. Ich hätte nicht erhofft soviel Input zu bekommen.
vielen Dank! jetzt bin ich nur noch gespannt wie das mit IPv6 und pfSense funktioniert.

bye woodym

JeGr

@woodym said in Hilfe bei ipv6 und DynDNS:

wenn du 5 Domains hast (3 aktive und 2 inaktive) kannst du hier 6 Beispiele zeigen lassen. Welches Beispiel sollte ich dann per Default nehmen?

Ah, da ich nichts angelegt hatte, habe ich die Birne bei den Domains nicht gesehen. Ich würde default die User Auth machen oder alternativ die erste angelegte Domain weil das die meisten Fälle trifft. Andere Alternative wäre vielleicht die Birne bei der User-Auth vielleicht hinter die User ID zu packen damit sie mehr auffällt. Nur ne Kleinigkeit :)

So habe ich schon Stunden damit zugebracht einen gültigen Aktivierungslink zu erhalten. Die Nerverei wollte ich den Nutzern ersparen.

Verständlich. Vielleicht kann man aus der Essenz von beidem eine Zwischenlösung finden (Link gültig für 30/60min?) und danach neu erstellen. Nur eine Idee/Feedback.

wobei auch ein POST dann denkbar wäre.

Sorry, PUSH war da falsch, POST war gemeint :)

Und ich dachte das ich das auch der Homepage mich schon viel zu viel darüber ausgelassen hatte.

Nach anlegen von einer Domain dann was zu LE zu lesen hat mir dann auch den Anstoß gegeben, was das sein könnte ;)

vielen Dank! jetzt bin ich nur noch gespannt wie das mit IPv6 und pfSense funktioniert.

Wenn mein Aktivierungslink funktionieren würde, bekämst du dein Feedback zeitnah :D

JeGr

Eine kleine UI Anmerkung am Rande: POLS - Prinzip der kleinsten Überraschung. Dazu:

Mache das "i" für die Infos auch blau wie die Glühbirne und/oder such dir ggf. ein "i" im Kreis aus (wie das typische info-i von Infopoints). Dann assoziiert man das automatisch als Info und bei blau denken mehr an einen Link -> onmouseover als bei einem schwarzen i

woodym

Wenn mein Aktivierungslink funktionieren würde, bekämst du dein Feedback zeitnah :D

Du kannst alles machen, auch ohne Aktivierung. Nur das die 'box' immer wieder kommt im Dashboard. Davon abgesehen sehe ich das der Account aktiviert ist. Du mußt also den Aktivierungslink also bereits geklickt haben. Und auch die Box sollte nicht mehr erscheinen.

JeGr

Jap kurz nach meinem Post hat es dann "gefruchtet" und der Link hatte plötzlich einen Effekt ;) Wie oben beschrieben, würde ich die UI dafür aber etwas umbauen und den Reminder nach einem Mal ausgeblendet lassen und nur noch als Leiste einblenden. Und wer eingeloggt den Link klickt, bekommt sein Dashboard auf und ne grüne Meldung dass der Account jetzt aktiviert ist - wer nicht eingeloggt ist dann einfach die jetzige Info mit Login.

JeGr

@woodym Oookay wo soll ich anfangen ;)

Erster Punkt und kurze Rückfrage: Warum im Dashboard so komplex mit UserID/PW und nicht nur einen langen sagen wir SHA256 Hash als API Token für die ID des entsprechenden DynDNS? Sollte es nicht unsicherer machen, aber mich persönlich irritiert User/PW da das "scheinbar" random hashes sind und die UserID auch bei jedem Eintrag und beim "alle ändern" unterschiedlich ist. Somit wäre ein einzelner API Key String pro Punkt (alle ändern / all per user | einzelne ändern / per domain) als Token sicher einfacher.
Zweiter Punkt: deine jetzige API/GET Struktur lässt es überhaupt nicht zu, dass du IP4 und IP6 gleichzeitig übergibst. Kann die pfSense zwar (momentan) noch nicht, wäre aber einfach einzupflegen und würde somit einen unnötigen Call und Check sparen. Du wertest aber nur $ip aus, somit kann man nur eines pro Call übergeben.
Dritter und bösester Punkt: Du machst keine Eingabeprüfung. Sowas ist nicht nur schlechter Stil sondern auch potentieller Buffer Overflow/OutOfBounds/whatever Security Impact. Warum hab ich das bemerkt? Weil ich beim manuellen Submit einer IP6 mich noch gewundert habe, wie du rausfinden willst bei nur einem IP Parameter, was ich eigentlich sende - IP4 oder IP6. Leider gar nicht. Die Doppelpunkte der IP6 werden schlichtweg verworfen und statt dessen der komplette Zeichensalat der über bleibt in dein IP4 Feld geschrieben. Das klingt nach Code Desaster waiting to happen ;) Geht also gar nicht.
Ich würde hier ganz klar zwischen ip4/ip6 als Parameter unterscheiden, dann können auch beide mit einem Call übergeben werden UND es muss dringend eine Eingabeprüfung her, was als Wert für ID/PW/Token/Whatever und als IP4/IP6 reinkommt. Nie einfach irgendwelche Werte platt weiterverarbeiten. Immer vom Schlimmsten ausgehen ;) Und selbst wenn irgendein Framework einen Schutz gegen Injects hat - trotzdem immer Input Validation machen. Bringt ja nichts wenn ich "irgendeinen quark" da reinschreiben kann und das steht bei IPv4 -> du trägst das ja im DNS ein und dort killt der Mist dann ggf. die DNS Zone für alle...
vierter Punkt: ich habe es dadurch nicht geschafft überhaupt deine API dazu zu bewegen, irgendeinen Wert in IP6 Felder zu übernehmen. Egal welchen Quatsch ich reingeschrieben habe, alles ist im IP4 Feld gelandet - for better or worse. Dadurch dass wohl beim Verwerten ein paar Sonderzeichen wie Klammern und eben auch Doppelpunkte entfernt werden, wird keine gültige IP6 zusammen gebaut.
fünfter Punkt: Die Ausgabe nach dem Submit ist erstmal nett und ausführlich - aber zu viel. Die meisten APIs von Routern, die die Ausgabe checken erwarten höchstens die erste Zeile, nämlich ein OK %IP% oder derlei bei der die IP4 oder IP6 nochmal bestätigt wird oder ein ERROR/FAIL und %IP% (was eben übermittelt wurde -> vielleicht ja falsches Format). Alles mehr und vor allem Multiline ist für die Parser der Tod. Die pfSense kanns zwar theoretisch, spuckt aber auch seltsam rum und bekommt nur "OK <IP-Kauderwelsch> change false" zurück, was doof ist. Warum der Submit von pfSense false gibt während der exakt gleiche String "true" im Browser wirft ist mir auch noch nicht klar. Dazu weiß ich nicht was auf Serverseite ankommt.

Grüße

woodym

@JeGr said in Hilfe bei ipv6 und DynDNS:

@woodym Oookay wo soll ich anfangen ;)

Erster Punkt und kurze Rückfrage: Warum im Dashboard so komplex mit UserID/PW und nicht nur einen langen sagen wir SHA256 Hash als API Token für die ID des entsprechenden DynDNS? Sollte es nicht unsicherer machen, aber mich persönlich irritiert User/PW da das "scheinbar" random hashes sind und die UserID auch bei jedem Eintrag und beim "alle ändern" unterschiedlich ist. Somit wäre ein einzelner API Key String pro Punkt (alle ändern / all per user | einzelne ändern / per domain) als Token sicher einfacher.

Das ist dem Umstand geschuldet das viele Router nur eine begrenzte Anzahl von DynDNS können. Deshalb habe ich die User/PW-Kombination gewählt um möglichst hohe kompatibilität zu haben.

Zweiter Punkt: deine jetzige API/GET Struktur lässt es überhaupt nicht zu, dass du IP4 und IP6 gleichzeitig übergibst. Kann die pfSense zwar (momentan) noch nicht, wäre aber einfach einzupflegen und würde somit einen unnötigen Call und Check sparen. Du wertest aber nur $ip aus, somit kann man nur eines pro Call übergeben.

Natürlich (ich gehe davon aus das bei den Beispielen User und PW auch übergeben werden):
update -> verwendet ipv4 die durch die verbindung verwendet wurde
update?aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv4 und ipv6
update?ip=no&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv6 aber keine ipv4
update?ip=1.2.3.4&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv6 und eine beliebige ipv4

Dritter und bösester Punkt: Du machst keine Eingabeprüfung. Sowas ist nicht nur schlechter Stil sondern auch potentieller Buffer Overflow/OutOfBounds/whatever Security Impact. Warum hab ich das bemerkt? Weil ich beim manuellen Submit einer IP6 mich noch gewundert habe, wie du rausfinden willst bei nur einem IP Parameter, was ich eigentlich sende - IP4 oder IP6. Leider gar nicht. Die Doppelpunkte der IP6 werden schlichtweg verworfen und statt dessen der komplette Zeichensalat der über bleibt in dein IP4 Feld geschrieben. Das klingt nach Code Desaster waiting to happen ;) Geht also gar nicht.
Ich würde hier ganz klar zwischen ip4/ip6 als Parameter unterscheiden, dann können auch beide mit einem Call übergeben werden UND es muss dringend eine Eingabeprüfung her, was als Wert für ID/PW/Token/Whatever und als IP4/IP6 reinkommt. Nie einfach irgendwelche Werte platt weiterverarbeiten. Immer vom Schlimmsten ausgehen ;) Und selbst wenn irgendein Framework einen Schutz gegen Injects hat - trotzdem immer Input Validation machen. Bringt ja nichts wenn ich "irgendeinen quark" da reinschreiben kann und das steht bei IPv4 -> du trägst das ja im DNS ein und dort killt der Mist dann ggf. die DNS Zone für alle...

Nicht ganz richtig. Die nicht gültigen Zeichen werden aus den Übergaben entfernt. Deswegen hattest du eine sehr seltsame IPv4 weil du IPV6 dort übergeben hattest. Auch die Längen sind zur Verarbeitung begrenzt.
Die Unterscheidung (siehe punkt 3) für ipv4 und ipv6 ist durchaus vorhanden. Nur muß ipv4 nicht zwingend angegeben werden (einfacherer Aufruf) weil ich die aus der Verbindung ermitteln kann.

vierter Punkt: ich habe es dadurch nicht geschafft überhaupt deine API dazu zu bewegen, irgendeinen Wert in IP6 Felder zu übernehmen. Egal welchen Quatsch ich reingeschrieben habe, alles ist im IP4 Feld gelandet - for better or worse. Dadurch dass wohl beim Verwerten ein paar Sonderzeichen wie Klammern und eben auch Doppelpunkte entfernt werden, wird keine gültige IP6 zusammen gebaut.

hast du auch aaaa= für ipv6 verwendet?

fünfter Punkt: Die Ausgabe nach dem Submit ist erstmal nett und ausführlich - aber zu viel. Die meisten APIs von Routern, die die Ausgabe checken erwarten höchstens die erste Zeile, nämlich ein OK %IP% oder derlei bei der die IP4 oder IP6 nochmal bestätigt wird oder ein ERROR/FAIL und %IP% (was eben übermittelt wurde -> vielleicht ja falsches Format). Alles mehr und vor allem Multiline ist für die Parser der Tod. Die pfSense kanns zwar theoretisch, spuckt aber auch seltsam rum und bekommt nur "OK <IP-Kauderwelsch> change false" zurück, was doof ist. Warum der Submit von pfSense false gibt während der exakt gleiche String "true" im Browser wirft ist mir auch noch nicht klar. Dazu weiß ich nicht was auf Serverseite ankommt.

Du mußt eigentlich nur die 1. Zeile auch wirklich auswerten. die ersten Zeichen sind 'OK' oder 'FAIL'. Danach kommt die verwendete ipv4
als nächste Zeile kommen die Weiteren Übergabeparameter. Dann ob ein Update stattgefunden hat oder nicht (change true/false). Ein Update findet nur statt wenn sich die Daten zum letzten Update (also den DNS-Einträgen) geändert haben. Wenn es einfacher für dich ist, kannst du das auch als JSON bekommen (out=json). Wenn du also OK und change false erhälst, heißt das das alles in ordnung ist und deine Daten zu keiner Änderung im DNS geführt haben (weil schon so gesetzt).

Ich habe mir auch gerade die Log-Files angesehen und gesehen das du ip=<ipv6> verwendet hast und nicht aaaa=<ipv6>. Ich befürchte das ich die Beschreibung dafür nicht in den FAQ's machen sollte... das scheint zu undurchsichtig zu sein.

bye woodym

edit:
jetzt habe ich in den Logfiles auch die Aufrufe gefunden die scheinbar von der pfSense gekommen sind oder von einem DynDNS-Client:

"GET /update?user=xxxxx&pw=yyyyyy&ip=xx.yyy.z.aaa HTTP/1.1" 200 60 "-" "phpDynDNS/0.7"
"GET /update?user=xxxxx&pw=yyyyyy&ip=aaaa:bbbb:cccc:dddd:eee:fff:aaa:eeee HTTP/1.1" 200 78 "-" "phpDynDNS/0.7"

(User/PW/IPv4/IPv6 verfremdet)

JeGr

@woodym said in Hilfe bei ipv6 und DynDNS:

hast du auch aaaa= für ipv6 verwendet?

Das ist nirgends dokumentiert ;) Auch in keinem Beispiel.
Zudem: warum wieder POLS unterlaufen mit ip= und aaaa= ? Das ist etwas unintuitiv. Wären es bspw. ip4= und ip6= gewesen (was ich ausprobiert hatte), wäre das sinnvoller gewesen. oder eben a= und aaaa= wenn wir bei DNS Notation sind, da bin ich dann dabei. :)

Das ist dem Umstand geschuldet das viele Router nur eine begrenzte Anzahl von DynDNS können. Deshalb habe ich die User/PW-Kombination gewählt um möglichst hohe kompatibilität zu haben.

Richtig, aber die Router kennen verschiedene Dienste und haben ggf. auch Custom Settings wo man selbst die URL eingibt. Dann sind die Parameter doch egal? Einen vorhandenes Dienst-Template kann man eh nicht nutzen, da dann die URL nicht stimmt, daher sehe ich da den Sinn nicht unbedingt, getrennte User/Pass Hashes zu nutzen. Zumal es die URI ziemlich unhandlich macht irgendwo einzutragen, da durch die User/Pass Parameter alles so weit nach hinten geschoben wird, dass es kaum eine UI geben dürfte, wo man den wichtigen Punkt -> also die IP4/IP6 Parameter noch sehen kann.

Natürlich (ich gehe davon aus das bei den Beispielen User und PW auch übergeben werden):

Klar :) Aber wie gesagt: Principle of least surprise! a) dass du an der Stelle plötzlich DNS Notation als Parameter nutzt mit aaaa= steht/stand nirgends ;) und b) ist das unintuitiv wenn der andere Parameter ip= heißt. Ich würde - wie oben gesagt - sehr stark dafür plädieren, das in ip4 und ip6 zu benennen, das ist klar und präzise und jeder weiß was gemeint ist :)

Nicht ganz richtig. Die nicht gültigen Zeichen werden aus den Übergaben entfernt. Deswegen hattest du eine sehr seltsame IPv4 weil du IPV6 dort übergeben hattest. Auch die Längen sind zur Verarbeitung begrenzt.

Das mag sein - deshalb hatte ich das auch eingegrenzt und nochmal genannt, dass da Zeichen rausgefiltert werden. Aber es ist trotzdem nicht fehlersicher. Wenn ich da "das ist der letzte Quatsch" übergebe muss das einfach kommentarlos abgelehnt werden weil es keine IP ist. Und nicht dann als "dasistderletzteQuatsch" im IPv4 Feld drinstehen und ggf. im blödesten Fall noch so als "IN A" Record im DNS landen ;)

Nur muß ipv4 nicht zwingend angegeben werden (einfacherer Aufruf) weil ich die aus der Verbindung ermitteln kann.

Und wie? Vorsicht Falle. Wenn ich mit primärer IP6 Adresse bei dir ankomme dann liest deine $Scriptsprache im Normalfall die IP der Verbindung aus und listet diese. Das ist nicht fix eine IP4 Adresse, das kann auch problemlos bei einem v6 only Netz eine IP6 sein. Und dann pushst du wirklich wieder die Adresse ins falsche Feld -> wo wir wieder bei plausability checks für die Felder sind ;) Wir haben selbst eine Art Mini DynDNS Check geschrieben (Output unterschiedlich aber mit Parameter bspw. auch identisch zu http://checkip.dyndns.org nur eben mit HTTPS) und das dort bemerkt: wenn wir aus unserem Office mit v6 kommen listet PHP bspw. im $SERVER Array als Verbindungs-IP des Clients unsere IP6, nicht die IP4. Daher mussten wir extra Parameter mit einbauen bzw. unterschiedliche DNS Namen einbauen, damit man gezielt die IP4 oder IP6 eines Clients auslesen kann. Was du bekommst kannst du meistens nicht bestimmen :)

Du mußt eigentlich nur die 1. Zeile auch wirklich auswerten. die ersten Zeichen sind 'OK' oder 'FAIL'.

Im "Check Output" der pfSense wird aber alles verarbeitet. Daher sind da Multiline Ausgaben der Tod ;) Zudem müsste ich z.B. die letzte Zeile jetzt nicht haben (mit dem Host bzw. User Hash). Wenn du Update true/false noch mit anzeigen willst, klar, dann aber besser hintendran. Allerdings fliegt dir dann der DynDNS Check weg wenn man auf

OK %IP% update true

prüft und dann beim zweiten Update ggf. das update false zurück kommt, weil die IP schon gesetzt ist. Dann failt der Check und meckert (unnötig).

"phpDynDNS/0.7"

Jup das ist der Client den die pfSense nutzt.

nicht in den FAQ's machen sollte... das scheint zu undurchsichtig zu sein.

Das liegt in der Sache: FAQs sind Anlaufstelle wenn ich Fragen habe oder was wirklich nicht klappt. Wenn aber im Dashboard die Hilfen/Beispiele sind und ich die ausprobiere und die nicht funktionieren, weil statt dessen Unsinn in die Variable geklopft wird, gehe ich von Bug aus, nicht von "Muss die FAQ lesen, obs irgendwelche Hidden-Secret-Parameter gibt" :D
Zudem sind die FAQs nicht im Dashboard verlinkt soweit ich sehe ;)

Deswegen hattest du eine sehr seltsame IPv4 weil du IPV6 dort übergeben hattest. Auch die Längen sind zur Verarbeitung begrenzt.

Richtig -> aber wurde das SO in den DNS gepusht? Wenn ja noch schlimmer weil das dann für einen DNS DOS simpelst genutzt werden kann, da dir mit so einem Quatscheintrag wie oben der gesamte Resolver bzw. die DNS Zone weggeschossen werden kann.

Edit:

AAAA... Update IP6

Habe ich gerade getestet. Das nächste Problem: Wenn ich nur aaaa= angebe (würde trotzdem den Parameter ändern), werden beide IPs geändert. IP4 wird "geraten" aus der Verbindung, IP6 wird gesetzt wie angegeben. Sollte man IMHO so nicht machen aus Gründen wie oben (ggf. wird IP auch als IP6 ausgelesen etc., was passiert bei reiner v6 Verbindung ...). Zudem ist der Rückgabewert für die pfSense faktisch "falsch" weil dann als Resonse "OK <IP4>" zurückkommt, wenn ich ne IP6 geändert habe.

Gruß Jens

JeGr

Noch einen Punkt oben ergänzt

woodym

Richtig, aber die Router kennen verschiedene Dienste und haben ggf. auch Custom Settings wo man selbst die URL eingibt.

das 'ggf.' ist genau das problem. Eben nicht alle haben diese mit der Möglichkeit der Angabe der URL.

Natürlich (ich gehe davon aus das bei den Beispielen User und PW auch übergeben werden):

Klar :) Aber wie gesagt: Principle of least surprise! a) dass du an der Stelle plötzlich DNS Notation als Parameter nutzt mit aaaa= steht/stand nirgends ;) und b) ist das unintuitiv wenn der andere Parameter ip= heißt. Ich würde - wie oben gesagt - sehr stark dafür plädieren, das in ip4 und ip6 zu benennen, das ist klar und präzise und jeder weiß was gemeint ist :)

Das war hier anders gemeint.. In pfSense kann ich auch User und PW angeben. Diese werden auch richtig verarbeitet. Auch bleibt dann die URL etwas verständlicher ;-)

Das mag sein - deshalb hatte ich das auch eingegrenzt und nochmal genannt, dass da Zeichen rausgefiltert werden. Aber es ist trotzdem nicht fehlersicher. Wenn ich da "das ist der letzte Quatsch" übergebe muss das einfach kommentarlos abgelehnt werden weil es keine IP ist. Und nicht dann als "dasistderletzteQuatsch" im IPv4 Feld drinstehen und ggf. im blödesten Fall noch so als "IN A" Record im DNS landen ;)

Nur muß ipv4 nicht zwingend angegeben werden (einfacherer Aufruf) weil ich die aus der Verbindung ermitteln kann.

Und wie? Vorsicht Falle. Wenn ich mit primärer IP6 Adresse bei dir ankomme dann liest deine $Scriptsprache im Normalfall die IP der Verbindung aus und listet diese. Das ist nicht fix eine IP4 Adresse, das kann auch problemlos bei einem v6 only Netz eine IP6 sein. Und dann pushst du wirklich wieder die Adresse ins falsche Feld -> wo wir wieder bei plausability checks für die Felder sind ;) Wir haben selbst eine Art Mini DynDNS Check geschrieben (Output unterschiedlich aber mit Parameter bspw. auch identisch zu http://checkip.dyndns.org nur eben mit HTTPS) und das dort bemerkt: wenn wir aus unserem Office mit v6 kommen listet PHP bspw. im $SERVER Array als Verbindungs-IP des Clients unsere IP6, nicht die IP4. Daher mussten wir extra Parameter mit einbauen bzw. unterschiedliche DNS Namen einbauen, damit man gezielt die IP4 oder IP6 eines Clients auslesen kann. Was du bekommst kannst du meistens nicht bestimmen :)

Du mußt eigentlich nur die 1. Zeile auch wirklich auswerten. die ersten Zeichen sind 'OK' oder 'FAIL'.

Im "Check Output" der pfSense wird aber alles verarbeitet. Daher sind da Multiline Ausgaben der Tod ;) Zudem müsste ich z.B. die letzte Zeile jetzt nicht haben (mit dem Host bzw. User Hash). Wenn du Update true/false noch mit anzeigen willst, klar, dann aber besser hintendran. Allerdings fliegt dir dann der DynDNS Check weg wenn man auf
OK %IP% update true
prüft und dann beim zweiten Update ggf. das update false zurück kommt, weil die IP schon gesetzt ist. Dann failt der Check und meckert (unnötig).

Muß dann für den test nicht nur 'OK' oder 'OK ' oder '^OK' eingetragen werden?

"phpDynDNS/0.7"

Jup das ist der Client den die pfSense nutzt.

nicht in den FAQ's machen sollte... das scheint zu undurchsichtig zu sein.

Das liegt in der Sache: FAQs sind Anlaufstelle wenn ich Fragen habe oder was wirklich nicht klappt. Wenn aber im Dashboard die Hilfen/Beispiele sind und ich die ausprobiere und die nicht funktionieren, weil statt dessen Unsinn in die Variable geklopft wird, gehe ich von Bug aus, nicht von "Muss die FAQ lesen, obs irgendwelche Hidden-Secret-Parameter gibt" :D
Zudem sind die FAQs nicht im Dashboard verlinkt soweit ich sehe ;)

Das ist eine gute Anregung!

Deswegen hattest du eine sehr seltsame IPv4 weil du IPV6 dort übergeben hattest. Auch die Längen sind zur Verarbeitung begrenzt.

Richtig -> aber wurde das SO in den DNS gepusht? Wenn ja noch schlimmer weil das dann für einen DNS DOS simpelst genutzt werden kann, da dir mit so einem Quatscheintrag wie oben der gesamte Resolver bzw. die DNS Zone weggeschossen werden kann.

Dann würde nur dieser Eintrag zerschossen sein, der Zone macht das nichts ;-)

Wie sollte das für ein DDOS genutzt werden?

Edit:

AAAA... Update IP6

Habe ich gerade getestet. Das nächste Problem: Wenn ich nur aaaa= angebe (würde trotzdem den Parameter ändern), werden beide IPs geändert. IP4 wird "geraten" aus der Verbindung, IP6 wird gesetzt wie angegeben. Sollte man IMHO so nicht machen aus Gründen wie oben (ggf. wird IP auch als IP6 ausgelesen etc., was passiert bei reiner v6 Verbindung ...). Zudem ist der Rückgabewert für die pfSense faktisch "falsch" weil dann als Resonse "OK <IP4>" zurückkommt, wenn ich ne IP6 geändert habe.

so wie oben gescrieben:

update?ip=no&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv6 aber keine ipv4

dann wird nur die IPv6 geändert, alles andere bleibt unberücksichtigt.

bye woodym

JeGr

@woodym said in Hilfe bei ipv6 und DynDNS:

das 'ggf.' ist genau das problem. Eben nicht alle haben diese mit der Möglichkeit der Angabe der URL.

Natürlich (ich gehe davon aus das bei den Beispielen User und PW auch übergeben werden):

Sollte dann aber kein Problem sein das PW einfach leer zu lassen (oder den User). Evtl. mal mit FritzBox und Custom Setting testen... grübel

@woodym said in Hilfe bei ipv6 und DynDNS:

Das war hier anders gemeint.. In pfSense kann ich auch User und PW angeben. Diese werden auch richtig verarbeitet. Auch bleibt dann die URL etwas verständlicher ;-)

Ja ich habe inzwischen gelesen in der FAQ dass man die User/Pass Hashes auch als htaccess-style Basic Auth übergeben kann. Das vereinfacht das Ganze an der Stelle natürlich. Soweit die Randomisierung von User/Pass Hashes ordentlich ist und da gesalzener SHA2 drinsteckt ist mir das dann recht egal :)

Muß dann für den test nicht nur 'OK' oder 'OK ' oder '^OK' eingetragen werden?

Müsste ich durchspielen. Momentan sieht es danach aus als würde der komplette Output geparsed.

Dann würde nur dieser Eintrag zerschossen sein, der Zone macht das nichts ;-)

Sagst du oder dein DNS Server? ;) Hängt stark vom DNS Server ab und wie er Zonen lädt. Bind ist da anders als PDNS bspw. und der wieder anders als andere. Schlußendlich hängt es am Resolver, was der aus der Zone macht. Es sei denn du behandelst jeden Eintrag als eigene voll-qualifizierte DNS Subdomain Zone, dann ist natürlich nur diese betroffen, sofern die Delegation passt.

Wie sollte das für ein DDOS genutzt werden?

DDOS != DOS. Ich schrieb absichtlich DoS -> Denial of Service. Indem ich absichtlich Bullshit in die Zone schreibe was ungeparsed als "A" oder "AAAA" in den DNS übernommen wird, kann ich die entsprechende Subzone oder ggf. auch die Master Zone killen, weil der DNS dann beim Reload die Zone entlädt wegen Fehlern. Damit funktioniert dann der Dienst nicht mehr. Daher meinte ich unbedingt sicherstellen dass bei IP4, IP6 und Token nur das korrekte Format und nur die korrekten Daten drinstehen können.

@woodym said in Hilfe bei ipv6 und DynDNS:

so wie oben gescrieben:
update?ip=no&aaaa=2001:0db8:85a3:0000:0000:8a2e:0370:7334 -> setzt ipv6 aber keine ipv4

Wie gesagt, solche halb-Automatismen würde ich tunlichst meiden! Zumal du IMHO noch keinen Test von einer reinen IP6 Maschine hattest, oder? Du nimmst an einigen Stellen einfach an, dass Dinge so passieren. Würde ich so absolut nicht empfehlen.

Meine "Wanted" Liste wäre momentan:

Parameter entwirren und ip4 und ip6 nutzen statt ip und aaaa
Parameter absichern und keinen quatsch als Inhalt übernehmen (bringt niemand was)
Keine unerwarteten Automatismen! Wenn ich nur ip6 als Parameter angebe WILL ich vielleicht gar nicht, dass ip4 automatisch gesetzt wird. Das erwarte ich auch nicht von einem DynDNS Dienst, dass der bei Weglassen von Parametern einfach Dinge automatisch "annimmt". Ist sicher benutzerfreundlich gedacht, läuft aber IMHO genau der POLS bzw. deiner zitierten KISS Strategie diametral entgegen ;)
Token-Geschichte erklären
Beispiele für Token und IP6 mit aufnehmen
FAQ ggf. im Login Zustand irgendwo nochmal anzeigen (Sidenote: beim Zuklapp-Effekt der FAQ scrollt die Seite immer ans Ende was etwas nervig ist)

Ansonsten ggf. noch ein bisschen optischer Feinschliff und es wuppt. Außer dass mir nicht klar ist, wie dein LE/Tokensystem von der pfSense aus triggerbar sein kann/soll?

woodym

Hallo Jens,

vielen dank für deine Analyse und deiner konstruktiver kritik. Ich muß deine Vorschläge noch auf den Blick auf andere Router beurteilen. Die Beschreibungen sind ja gerade noch am werden was ja der Grund für meine bitte um hilfe war ;-). Die FAQ's bzw. die Beschreibung der Parameter auch im Dashboard zugänglich zu machen ist sicher ein sehr guter Vorschlag. Ob ich die Parameter so einfach ändern kann ist fraglich, da schon einige die bisherigen verwenden (muß ich aber in den logfiles nochmal genau prüfen was genommen wird... vielleicht die Namen ändern und die alten noch erhalten um kompatibel zu sein).
Was mich noch interessieren würde wie du bei pfSense jetzt den Update machst? Wie übermittelst du die ipv6? Über custom (v6) und %IP% ?

bye woodym

JeGr

@woodym said in Hilfe bei ipv6 und DynDNS:

vielen dank für deine Analyse und deiner konstruktiver kritik.

Sehr gern

@woodym said in Hilfe bei ipv6 und DynDNS:

Die Beschreibungen sind ja gerade noch am werden was ja der Grund für meine bitte um hilfe war ;-)

Verständlich :)

@woodym said in Hilfe bei ipv6 und DynDNS:

Ob ich die Parameter so einfach ändern kann ist fraglich, da schon einige die bisherigen verwenden (muß ich aber in den logfiles nochmal genau prüfen was genommen wird...

Nutzen "viele" das wirklich mit IPv6? Wenn nicht änders einfach und dokumentiere es entsprechend. Klare Cuts sind sinnvoller und im frühen Stadium sinnvoller als ewig alten Kram mitzuschleppen. Als Übergang kann man sicher beides etablieren und testen - wenn es geht, würde ich einfach eine kurze Infomail an die vorhandenen Accounts senden mit der Bitte die Konfiguration zu prüfen/ändern und gut. Genauso auch wegen der "automagischen" Defaults. Da würde ich definitiv zu raten, das abzuklemmen und keine Parameter einfach automatisch zu erraten - schon allein weil man diese dann versuchen könnte zu spoofen über die übergebenen Server-Header.

Was mich noch interessieren würde wie du bei pfSense jetzt den Update machst? Wie übermittelst du die ipv6? Über custom (v6) und %IP% ?

Ah natürlich. Das Wichtige bei der pfSense ist das korrekte Interface (muss v6 fähig sein) und custom(v6) Auswahl. Wählt man versehentlich nur custom aus, wird mit %IP% die IP4 übergeben, bei custom (v6) wird immer versucht, die IP6 Adresse des angegebenen Interfaces auszulesen (kann man auch als Fehler im Log nachlesen). Ich muss noch untersuchen, ob man auch in einem Aufwasch beides übergeben kann, einzeln tut es auf jeden Fall schonmal brauchbar, auch wenn der Return noch nicht sauber aus/eingelesen wird wegen Multiline. Das wollte ich mir allerdings auch noch ansehen. Evtl. kann man hier einen Parameter mitgeben (ähnlich dem JSON Parameter) der die OK/Feedback Ausgabe dann etwas informationsärmer ausgibt :)

woodym

Nutzen "viele" das wirklich mit IPv6? Wenn nicht änders einfach und dokumentiere es entsprechend....

Nein, nicht IPV6. Aber was viel genutzt wird das automatische erkennen der IP :-( . Die früheren DynDNS Client haben irgend wo die externe IP angefragt und dann nur bei änderungen die an DynDNS übertragen. Solche Router wie pfSense machen das etwas inteligenter, sie wissen aufgrund der etablierten Verbindung zumindest den Zeitpunkt wann die IP sich ändert und können dann aktiv werden fals Handlungsbedraf besteht. Das ermittel der IP übernimmt ja srvhome selber womit ein intelligenter Client nicht mehr nötig ist. Einfache Systeme die hinter der FW sitzen können damit eine IP mitteilen ohne sie kennen zu müssen. Genau das wird gerne genutzt.
Das sind eigentlich zwei Forderungen die sich wiedersprechen. Um dem gerecht zu werden denke ich über einen weiteren Update-Aufruf nach... der eine mit und der andere ohne automatismus.

Ah natürlich. Das Wichtige bei der pfSense ist das korrekte Interface (muss v6 fähig sein) und custom(v6) Auswahl. Wählt man versehentlich nur custom aus, wird mit %IP% die IP4 übergeben, bei custom (v6) wird immer versucht, die IP6 Adresse des angegebenen Interfaces auszulesen (kann man auch als Fehler im Log nachlesen). Ich muss noch untersuchen, ob man auch in einem Aufwasch beides übergeben kann, einzeln tut es auf jeden Fall schonmal brauchbar, auch wenn der Return noch nicht sauber aus/eingelesen wird wegen Multiline. Das wollte ich mir allerdings auch noch ansehen. Evtl. kann man hier einen Parameter mitgeben (ähnlich dem JSON Parameter) der die OK/Feedback Ausgabe dann etwas informationsärmer ausgibt :)

Das ist eine gute Idee ein Parameter für eine einfach Antwort ;-).
Übrigens sollte dein Update so (custom (v6)) mit IPV4 sofort funktionieren. Du übermittelst per Variable %IP% deine IPV6. Die IPV4 würde ermittelt werden und muß nicht explizit angegeben werden ;-).

Das mit dem automatischen ermitteln der IP hatte bisher bei einem Nutzer nicht funktioniert weil dessen Aufrufe über ein Zwangsproxy gesendet wurden. Da wiederum ist auch keine Verbindung direkt zu seinem Router möglich.

JeGr

@woodym said in Hilfe bei ipv6 und DynDNS:

haben irgend wo die externe IP angefragt

meistens: http://checkip.dyndns.org

Genau das wird gerne genutzt.

Kein Grund das nicht zu unterstützen, aber dann sollte man das ggf. als Parameter wie "ip=auto" oder als extra Parameter "...&discover=auto" oder ähnliches anhängen. IMHO sollte deine Default URL nicht standardmäßig "magic" machen ;)

Um dem gerecht zu werden denke ich über einen weiteren Update-Aufruf nach... der eine mit und der andere ohne automatismus.

Oder zwei URLs. Aber mit Parametern wäre es IMHO sinnvoller. Weniger Pflegeaufwand und niemand sagt, dass man keine neuen Features über Trigger/Parameter hinzufügen kann :) So wie bspw. der Output in JSON. Hier noch ein "output=minimal" (als Beispiel) für die pfSense als Feedback mit "OK <bla>" ist ja ein anderer Punkt. Stört keine vorhandene Konfiguration. Oder umgekehrt: ein "minimum" als Standard ausrollen -> KISS. Und alles andere als schweizer Messer dranbauen mit Parametern. Das wäre zumindest die Design-Philosophie die ich verfolgen würde :)

Du übermittelst per Variable %IP% deine IPV6. Die IPV4 würde ermittelt werden und muß nicht explizit angegeben werden ;-).

Jein. Taucht sie nicht :) Nicht wenn dein Service komplett wäre, was er nicht ist. Deine Seite ist nämlich nicht Dual Stack fähig. Sprich ich kann mein DynPrefix nur via v4 einliefern. Wenn ich aber DSlite habe, will ich gerade das ja nicht ;) Somit sollte deine Adresse (www.srvhome.de) dringend DualStack liefern und per v6 erreichbar sein.

Wenn sie das ist, kann sie sinnvoll von allen genutzt werden. Vorher nicht. Und wenn sie das ist, dann funktioniert deine "automagic" leider nicht mehr, denn dann wird - je nachdem was das OS präferiert - die Verbindung bereits via IP6 aufgebaut und du erhältst beim Auslesen der Verbindung ... die IP6. Und keine IP4 mehr ;) Außer dein Check/Test würde noch weitere nachgeschaltete komplexere Sachen aufrufen, um außer der IP4 auch die IP6 und umgekehrt zu ermitteln. Würde gehen, aber nunja ... vielleicht unnötig.

Grüße