Wie http für das Webinterface der Fritzbox deaktivieren?

[Tom01]

Meine FB 7490 ist bisher sowohl per https als auch per http über das LAN erreichbar.
Per http werden die Inhalte, wie z.B. die Zugangsdaten im Klartext übertragen.

Wie kann man bei oben genannter Fritzbox deaktivieren das die Fritzbox per http über das LAN erreichbar ist?

Mir ist bekannt das die Frage in der Vergangenheit bereits gestellt wurde, wie z.B. folgende Fragestellung, mir ist jedoch bisher keine Möglichkeit hierfür bekannt.:
* https://www.ip-phone-forum.de/threa...-auf-weboberfläche-deaktiviert-werden.289541/

 

[Peter_Lehmann]

Hallo @Tom01!

Grundsätzlich gebe ich dir völlig recht, die (jede!) unverschlüsselte Übertragung von Daten (über das Internet) ist heute einfach verantwortungslos und sollte (wo möglich) immer vermieden werden.

Aber trotzdem kann ich das von dir angesprochene Problem nicht so richtig als ein solches verstehen.

1. Jeder einigermaßen moderne Browser verwendet von sich aus eine gesicherte Verbindung, indem https zumindest priorisiert und "pures" http fast immer per Default verhindert wird. (beim Fx kannst du in begründeten Fällen eine Ausnahme dafür setzen - schon mal überprüft?).
2. Erst dann, wenn du dich mit deinem sicheren (langen und "komplizierten") Passwort gegenüber dem Server authentisiert hast, fließen überhaupt Daten. Dafür, dass da bereits die Sicherung mit TLS aktiv ist, sorgen ja bereits dein Browser oder auch deine eigene Aufmerksamkeit. (Ja, der Nutzer hat eine gewisse Verantwortung!)
3. Jeder "Angreifer", der aus dem Netz das GUI deiner F!B aufruft, stößt an die Schranke der geforderten Authentisierung. Egal, ob er (immer noch) http oder /automatisch) https benutzt. Das Passwort in einer gewissen Qualität ist immer der einzige Schutz. Also auch, wenn https genutzt wird.
4. Eigentlich sollte bei einem modernen Webserver per Default immer ein Redirect auf htps erfolgen. Zumindest, wenn in den Einstellungen der F!B (Freigaben => Internetzugriff ...) der Zugriff aus dem "bösen" Netz per https aktiviert wurde.
   Ob das in der F!B tatsächlich so erfolgt, weiß ich nicht, denn alle meine internen Geräte, einschließlich der F!B sind keinesfalls aus dem Internet über Freigabe erreichbar. Der einzige Zugang erfolgt bei mir über mein WireGuard-VPN (über externe Geräte). Und aus dem Hausnetz ist eben nicht, aus dem Internet!
   Aber sicherlich gibt es hier User, welche das bei sich überprüfen werden und dir dann berichten. Aber trotzdem => siehe 1. - 3.

vy 73 de Peter

 

[Tom01]

Grundsätzlich gebe ich dir völlig recht, die (jede!) unverschlüsselte Übertragung von Daten (über das Internet) ist heute einfach verantwortungslos und sollte (wo möglich) immer vermieden werden.

Auch im LAN sollte man Geräte die sich an bestimmte Grundregeln nicht von der Grundeinstellung her halten so konfigurieren das sie es tun oder sie aus dem Netzwerk verbannen.

Der richtige Weg ist hierbei den der einen falsch konfigurierten Dienst anbietet zu fixen. In dem Fall also die Fritzbox und nicht etwa eine wechselnde Anzahl von im LAN befindlichen Clients hinterher rennen und bei diesen hilfsweise irgend welche Krücken zu etablieren.

 

[Peter_Lehmann]

Auch hier gebe ich dir grundsätzlich recht.
Aber, wenn man befürchten muss, den Angreifer im eigenen Haus zu haben und dieser Angreifer auch noch meine sicheren Passwörter kennt und dieser dann auch noch fachlich und technisch in der Lage ist, meinen eigenen (!!) Traffic zu sniffen - ja dann muss man selbstverständlich erweiterte Sicherheitsmaßnahmen ergreifen.

Und ich dachte immer, dass ich nach über 20 Jahren ehemaliger einschlägiger Tätigkeit einer der Menschen hier bin, mit der größten "Paranoia" auf dem Gebiet der IT-Sicherheit.

Aber trotzdem noch ein Vorschlag:
Wende dich an AVM und schlage vor oder verlange, dass der integrierte Webserver der F!B einen nicht zu deaktivierenden Redirect auf den https-Port erhält und dass der unverschlüsselte http-Port komplett dicht gemacht wird.

Und vergiss bitte auch nicht, dass es sich bei der Fritz!Box um ein Consumer-Gerät handelt und nicht etwa eine SINA-Box oder ein anderes Gerät aus dem Bereich der Hochsicherheit.

Noch ein "edit":
Ich kann mir auch gut vorstellen, dass AVM den "nicht zu deaktivierenden Redirect auf den https-Port" bei den internen Verbindungen aus dem folgenden Grund (zumindest aktuell) bewusst nicht aktiviert hat:
Eine reine Abwägung zwischen der (unbestrittenen kleinen) Erhöhung der Sicherheit im internen Netz und den Problemen, welche reihenweise bei ONU (hier als Otto-Normal-User) auftreten, wenn diese das GUI ihrer eigenen F!B aufrufen und immer wieder eine Warnung vor einer gefährlichen unsicheren Verbindung (resultierend von dem selbst signierten Zertifikat der F!B) erhalten. Wie viele Leute werden dann den Support mit Anfragen zuschütten? Denn Hilfeseiten und Anleitungen sind ja grundsätzlich nur etwas für Weicheier - oder?

 

[H´Sishi]

Sofern der "Angreifer" nebst seinem Gerät bekannt ist: Läßt sich dieser Client isolieren und entweder per LAN4 oder WLAN aus dem internen Netzwerk in's "Gast"-Netz verfrachten? Dann kann der Nutzer zwar noch in's Internet, aber nicht mehr in's Heimnetz.

Selbstverständlich muß dann auch der physische Zugang zur FritzBox unterbunden werden - ein zugänglicher und aktivierter WPS-Knopf hebelt die vorher genannten Maßnahmen aus.

 

[Peter_Lehmann]

Und schon sind wir bei den von mir erwähnten "erweiterten Sicherheitsmaßnahmen".
Wie weit wollen wir gehen?

In der IT-Sicherheit gibt es eine Definition, welche sich "zu akzeptierendes Restrisiko" nennt.
Aus dem Gedächtnis und in eigenen Worten zitiert, ist das eben das Risiko, welches man nach genauer und gründlicher Abwägung von zu erbringendem Aufwand/Kosten usw., den reellen und zu erwartenden Gefahren und Risiken (wo wird diese Technik betrieben, wie hoch sind die Daten eingestuft usw.) und der mit diesem Aufwand zu erreichender Erhöhung der IT-Sicherheit (und auch dem Auftreten eventueller nicht gewollter Nebeneffekte - siehe ONU!) akzeptieren darf/kann oder will.

Man kann es bis zum "geht nicht mehr" übertreiben (siehe: Der Absolute Sichere Firewall) oder meinetwegen, so wie ich das mache, dass alle meine transportablen Geräte, wie unsere Smartphones oder die Notebooks, immer und überall dauerhaft über mein WireGuard-VPN mit der F!B verbunden sind.
Aber das sind eben meine eigenen Ansprüche, welche ich niemandem aufdrängen werde.

 

[Tom01]

In der IT-Sicherheit gibt es eine Definition, welche sich "zu akzeptierendes Restrisiko" nennt.

Zugangsdaten und Konfigurationen im Klartext durch die Gegend zu übertragen, magst du als Restrisiko betrachten, ich sehe das deutlich kritischer.

 

[B612]

Es gibt in der ar7.cfg unter websrv einen Parameter:
users_only_for_https = no;
Den könnte man ja mal auf yes setzen.

 

[Tom01]

Es gibt in der ar7.cfg unter websrv einen Parameter:
users_only_for_https = no;
Den könnte man ja mal auf yes setzen.

Davon habe ich bereits in einem einige Jahre alten Beitrag gelesen. Ich dachte jedoch das AVM einen nicht mehr per ssh an die Box ran lässt. Wie kommt man diesen Parameter ran, ist der und vlt. auch über das Webinterface änderbar ?

 

[B612]

Ich dachte jedoch das AVM einen nicht mehr per ssh an die Box ran lässt.

Normal nicht aber nach einer Modifikation geht das.

auch über das Webinterface änderbar ?

Nein aber du kannst ja die Konfig ändern.

 

[Tom01]

Normal nicht aber nach einer Modifikation geht das.


Nein aber du kannst ja die Konfig ändern.

Wo liegt die ar7.cfg und wie komme ich an diese ran um sie zu editieren ?

Macht man das über den FBEditor ?
* https://develcore.de/2019/10/fritzbox-einstellungen-uber-die-konfigurationsdatei-anpassen/
* https://github.com/mypikachu/FBEditor/releases/tag/v0.6.9.7

 

[B612]

Macht man das über den FBEditor ?

Ja das ist eine Möglichkeit. Man kann die Konfig aber auch mit Notepad++ bearbeiten dann noch die Prüfsumme anpassen und wieder einspielen. Das ist aber schon 'zig mal hier im Forum beschrieben.

 

[Tom01]

Ja das ist eine Möglichkeit. Man kann die Konfig aber auch mit Notepad++ bearbeiten dann noch die Prüfsumme anpassen und wieder einspielen. Das ist aber schon 'zig mal hier im Forum beschrieben.

Cool. Das ist an mir vorbei gegangen, da ich schon eine Weile nicht im Forum war.

Kennst du da einen passenden Link zu einer relevanten Diskussion ?

Ich bekomme da bei der Suche recht viele Ergebnisse, ohne so recht zu wissen wie das was ich suche aussehen nuß
* https://www.ip-phone-forum.de/search/818388/?q=Prüfsumme&o=date

 

[B612]

Dann nimm doch den FBEditor. Der kann das alles.

 

[NDiIPP]

Ich dachte jedoch das AVM einen nicht mehr per ssh an die Box ran lässt.

Das hat AVM einerseits noch nie aktiv/ootb unterstützt und andererseits bisher auch noch nicht wirklich unterbunden.

Zugangsdaten und Konfigurationen im Klartext durch die Gegend zu übertragen, …

Wann passiert das?

… magst du als Restrisiko betrachten,

Ich befürchte da hast du @Peter_Lehmann falsch verstanden.

 

[FlyingToaster]

Auf welche Domain soll dann das Zertifikat für den internen HTTPS-Zugriff eigentlich ausgestellt werden?

Obwohl fritz.box oder die die IP-Adresse eigentlich dabei ausscheiden sollten, macht trotzdem AVM fritz.box und noch mehr möglich:

Zur Erklärung:
Natürlich bekomme ich "... verwendet ein ungültiges Sicherheitszertifikat. Dem Zertifikat wird nicht vertraut, weil es vom Aussteller selbst signiert wurde. Fehlercode: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT" und muss bei Firefox eine Ausnahme für die die angesteuerte Seite fritz.box usw. einstellen.
Vom angezeigeten Zertifikat sind der Inhabername, der Ausstellername und die Zeile 1 aus "Alternative Inhaberbezeichnungen" identisch zu meinem intern nicht verwendbaren DynDNS-Domainnamen flying.toaster.lol.
Intern brauchbare weil im Netz unterschiedlich sind dann aber die FRITZ!Box-Namen flying-toaster-master und flying-toaster-repeater.

Mit AVMs selbst signierten Zertifikaten lässt sich die LAN/WLAN-interne Kommunikation zur Fritzbox längst per HTTPS absichern.

 

[Tom01]

Tom01 schrieb:

Zugangsdaten und Konfigurationen im Klartext durch die Gegend zu übertragen, …

Wann passiert das?

Wie bereits geschrieben, das passiert naturgemäß bei einer Übertragung per http.

 

[NDiIPP]

… das passiert naturgemäß bei einer Übertragung per http.

Aber wie wird diese ermöglicht? Dazu müsste man sich ja gegenüber der Fritzbox erst einmal verifizieren (Login/SID erhalten).

 

[Tom01]

Aber wie wird diese ermöglicht? Dazu müsste man sich ja gegenüber der Fritzbox erst einmal verifizieren (Login/SID erhalten).

Netzwerk datenverkehr kann man mitschneiden, mit angepasster extra Hardware (In D vorgeschriebene automatische Aufschaltvorrichtung die wohl Bestandteil der Switche beim Provider sind oder mit der in der Fritzbox eingebauten Mitschnitteinrichtung oder mit einer Netzwerkkarte + passenden Treiber + z.B. Wireshark.

Im Falle des Mitschnittes von http, ftp, NTP und noch ein paar anderen unverschlüsselten Protokollen, bedarf es eben keinerlei Sicherheitslücken oder irgend eines passenden oder eines Nachschlüssels, da das komplett im Klartext übertragen wird. Das ist das Problem.

Die Fritzbox verwendet hierbei sträflicher Weise stellenweise z.B. folgende unverschlüsselte Kommunikation, sowie hat noch etliche weiter Sicherheitsprobleme:
* http
* NTP
* FTP
* verwendet mgl. Weise noch immer erneut das unsichere Samba 1
* künstlich von 63 auf 32 Zeichen eingeschränkte Zugangskennwörter
* usw., usw.

 

[NDiIPP]

Netzwerk datenverkehr kann man mitschneiden, …

Das Login selbst? Ja, kann man mitschneiden. Auch wenn man dabei zwar eine SID mitschneiden kann, das Passwort selbst (trotz http) dagegen nicht (auch nicht mit Wireshark). Aber es bleibt bei der Frage, warum sollte man das dann überhaupt tun?