Ansichten eines Informatikers

Vom Sicherheitsmurks bei AVM

Hadmut
16.6.2025 18:45

Die Fritzbox ist der Standard-Router der Deutschen.

Aber die Qualität lässt nach und bringt Sicherheitsprobleme mit sich.

Eigentlich habe ich mich ja gefreut, als AVM ankündigte, ab der OS Version 7.39 VPN-Verbindungen mit Wireguard zu unterstützen. Ich habe mir sogar extra deshalb einen neue Fritzbox gekauft, weil mein altes Modell, das noch gar nicht alt war, zwar mit einer neuen OS-Version versorgt wurde, aber auf der Hardware Wireguard nicht lief.

Ich baue seit über 25 Jahren VPN-Verbindungen. CISCO, IPSec, OpenVPN, GRE und noch ein paar proprietäre, und das war oft nicht einfach und auch nicht schnell, weil die Seiten miteinander nicht unbedingt immer kompatibel waren und die Implementierungen nicht so fehlerfrei. OpenVPN ist im Prinzip gut, aber langsam, und schon ein wenig kompliziert in der Konfiguration, da hat man zu viele Fähigkeiten eingebaut, Stichwort eierlegende Wollmilchsau.

Seit ein paar Jahren gibt es Wireguard.

Wireguard kann recht wenig – aber alles, was man in den allermeisten Fällen braucht (wenn es nicht um irgendwelche besonderen Firmen-LAN-Anwendungen geht). Und deshalb ist es auch überschaubar zu implementieren und zu konfigurieren. Manchmal ist weniger eben mehr.

Und: Wireguard ist effizienter, verheizt weniger Rechenleistung, ist schneller, läuft besser auf typischen Embedded-Prozessoren und was man halt in Router so einbaut. Von Wireguard gibt es keine Varianten wie bei IPSec, Wireguard kommt mit NAT klar und sowas alles. Und es wird auf immer mehr Geräten unterstützt.

Kurz: Feine Sache, das.

Aber, ach.

Obwohl der Witz an Wireguard ja gerade ist, dass es auf das Nötigste reduziert wurde und deshalb nicht alle, sondern nur die meisten Anwendungsfälle abdeckt, die dann aber einfach, schnell und leicht zu konfigurieren sind, wird das unter Linux schon wieder würzig, denn da muss ich inzwischen vier verschiedene Arten pflegen, Wireguard-Tunnel zu konfigurieren:

  • Wireguard selbst kommit mit „wg-quick“ und einer bestimmten Konfigurationssyntax, die sich als Standard etabliert hat. Kann man auch automatisiert über systemd starten, kommt mit Template Unit daher.
  • Weil man damit aber nur den Tunnel selbst, nicht aber die Systemintegration konfigurieren kann (man müsste Shell-Befehle in die config schreiben), gibt es auch nochmal eine Wireguard-Konfiguration über systemd, siehe man systemd.netdev und systemd.network. Die ist schön, wurde aber so stückchenweise implementiert, der Umfang hängt deshalb stark davon ab, welche Version von systemd man hat, also welches Linux man verwendet. Kann dafür den privat key per TPM verschlüsselt ablegen und sowas. Gut für Server.
  • Auf Client-Seite macht man das dann über den Network-Manager und eine Konfigurationsdatei in /etc/NetworkManager/system-connections.
  • Es sei denn freilich, man verwendet Ubuntu, dann nämlich läuft der Network-Manager über netplan und die Konfiguration muss in netplan eingetragen werden.
  • Und, das pflege ich jetzt aber nicht, verwendet man ChromeOS, geht es wieder anders.

Umso erfreulicher, dass die doch alle kompatibel sind (weil es nur die Konfigurations-Frontends sind und das einheitlich im Kernel läuft), und prächtig miteinander funktionieren.

Und: Jeder macht es auf seine Weise. Aber jeder bekommt es hin. Es läuft. Von ein paar kleinen Macken abgesehen, wenn etwa die GUI des Network-Managers korrekte Konfigurationsoptionen syntaktisch nicht akzeptiert.

Ganz viele Router können inzwischen Wireguard, auch für Android, iOS und MacOS gibt es Clients. Die machen es sich zwar oft einfach und einfach ein Textfenster auf, in das man die Konfguration in wg-quick-Syntax reinschreibt. Aber: Wenn man die Syntax versteht (und da ist ja nicht viel dran) und weiß, was man tut, dann kann man auch tun, was man will.

Der einzige mir bisher bekannte Hersteller, der es nicht ordentlich hinbekommt, ist: AVM.

Gut gemeint ist nicht gut gemacht

Dabei muss man AVM zugute halten, dass die versucht haben, es benutzerfreundlich zu machen. Und es gerade dadurch vermurkst und Sicherheitsprobleme geöffnet haben. Auch auf der Fritzbox ist Wireguard ganz normal im Kernel implementiert und läuft normal, aber das Konfigurationsfrontend, in diesem Fall die AVM Web-GUI, ist schlicht Murks.

Gut gemeinter Murks zwar, das will ich nicht in Abrede stellen, die Absichten waren gut. Aber wenn man nicht verstanden hat, was man tut, ist das Ergebnis eben schlecht.

Wie so oft haben da Leute versucht, möglichst einfache Standardfälle möglichst einfach über die GUI abzuklicken, um möglichst einfach an den Zustand „funktioniert“ zu kommen. Das führt aber zu Sicherheitsproblemen.

Die Wurzel des Übels

Nochmal: Ich kann durchaus nachvollziehen, was sie sich dabei gedacht haben, das so zu machen, und glaube ihnen, dass sie es gut gemeint haben. Aber das Ergebnis ist halt einfach Murks. Murks zwar, der in vielen Fällen „funktioniert“, aber Murks.

Das einfache Beispiel

Trägt man in der Fritzbox einen einfachen Client ein, etwa einen Notebook-Rechner oder ein Handy, geht das ganz einfach: Klicken Sie hier, geben sie einen Namen – fertig. Zeigt die Konfigurationsdatei an, auch als QR (Handys lesen die gerne als QR ein), fertig, schon läuft’s.

So schnell, so einfach, so gut.

So gut?

Nein.

Denn Wireguard-Konfigurationen beruhen auf Private-/Public-Key-Paaren. Und der Witz am Private Key ist eben, dass er privat bleibt, dass der andere ihn nicht kennt. Es kommt zwar immer mehr in Bequemlichkeitsmode, dass man sich seinen Private Key von der Gegenseite generieren lässte, weil so einfach, so bequem, so angenehm – aber dann ist der Witz weg. Der Witz am Private Key ist, dass niemand ihn kennt außer man selbst.

Nun ist es aber so, dass viele Client-Programme, etwa die Apps auf Android, selbst keinen Private-/Public-Key ausrechnen können, sondern einfach ein Textfenster aufmachen und sagen, hier, trag’ ein, oder gleich per QR scannen wollen.

Nun ist auf einem Linux- oder anderem Rechner das schnell gemacht, wg genkey, und *zack*, hat man einen. Dann schiebt man ihn noch durch wg pubkey und hat auch den Public Key.

Aber: Wer weiß das, wer macht das, wer kann das? In der Praxis niemand.

Deshalb hat man es bei AVM einfach gemacht: Klicken, und schon kommt die Konfigurationsdatei herausgefallen. Aufs Handy, auf den Rechner laden – fertig, läuft.

Ich will dagegen noch nicht einmal viel sagen, weil es effektiv wohl immer noch besser ist, wenn der Private Key kurz angezeigt und auf der Fritzbox danach gelöscht wird, als wenn Laien versuchen, da irgendwas zusammenzustoppeln. Da gäbe es nämlich ruckzuck Betrügerwebseiten, die empfehlen „Tragen Sie hier diesen Schlüssel ein …“.

Insofern ist das unter sicherheitstechnischen Gesichtspunkten zwar eigentlich nicht korrekt und nicht so sicher, wie es sein sollte – aber pragmatisch-praktisch immer noch viel besser als das, was man hätte, wenn eine Republik von Laien versucht, damit klarzukommen und Murks reinschreibt.

Das Problem

Das Problem ist, dass die Programmierer bei AVM sich sehr weitgehend auf die Variante „Eine Seite erzeugt beide Konfigurationen und die Gegenseite importiert ihre“ versteift haben, und nicht merken, dass das ein Sicherheitsproblem ist, weil man dabei die Private Keys durch die Gegend schaufelt und sich von der Gegenseite erzeugen lässt. Das ist eigentlich ein No-Go bei Private Keys.

Sie versuchen unbedingt, beide Seiten der Konfiguration auf einer Seite zu erzeugen und auf der anderen zu „importieren“. Entweder erzeugt die Fritzbox sie und die Gegenseite soll sie importieren, oder umgekehrt.

Dass aber in einem Private-Public-Key-Schema jede Seite ihren Private Key selbst erzeugt und eben nicht von irgendwoher „importiert“, scheinen sie nicht verstanden zu haben.

Erste Variante von „geht nicht“

Wenn man also eine LAN-LAN-Verbindung eintragen will, muss man erst einmal zwei bis drei einfach klingende Fragen beantworten, die aber irreführend sind. Obwohl an Laien gerichtet, muss man sich schon gut auskennen, um sich denken zu können, was sie sich dabei gedacht haben. Gibt man also an, dass es noch gar keine Konfiguration gibt, kommt man sogar eigentlich – verblüffenderweise – an die richtige Maske (wenn man nein – ja – nein antwortet):

Bis auf das Detail, dass der PresharedKey fehlt (ich glaube, der kommt, warum auch immer, erst im nächsten Schritt) und IPv6 nur /64 geht, bzw. immer nur ein Netzwerkbereich eintragen werden kann und nicht mehrere, wäre das genau die richtige Maske, um alles einzutragen, was einzutragen ist. Mit der Maske wäre es im Grundsatz gut.

Aber fällt Euch was auf?

Unten rechts, das Feld „Fertigstellen“ ist ausgegraut. Man kann es nicht drücken und die Maske nicht eingeben. Das Feld wird erst dann aktiv und drückbar, wenn man auch das Feld „Internetadresse“ ausfüllt.

Manchmal kann man das ausfüllen. Wenn man beispielsweise die Fritzbox als Wireguard-Client für Homeoffice an das Firmennetz anbindet, dann geht das.

Wenn aber die Fritzbox selbst der Server sein soll, in den sich andere einwählen, dann kann (und darf) man da nichts eintragen.

Bei Wireguard gibt es, genau genommen, kein Einwählen, sondern nur eine oder beide Seiten, die die Verbindung initiiert, wenn benötigt, und sie gerade nicht aktiv ist, oder der Schlüssel neu ausgehandelt werden muss.

Und dabei kann es eben sein, dass eine Seite (z. B. mobiler Client)

  • keine statische IP-Adresse hat,
  • keine dynamische IP-Adresse mit DynDNS-Eintrag hat, also nicht gefunden werden kann,
  • oder sogar hinter NAT oder Firewall steht und von außen gar nicht erreichbar ist.

In dem Fall muss der Verbindungsaufbau immer vom Client ausgehen. Und Wireguard unterstützt das, kommt wunderbar damit klar. Man trägt dann so etwas wie PersistentKeepalive = 25 ein, damit der Client auch dann, wenn er nichts zu sagen hat, die Verbindung aufrecht erhält, damit sie durch NAT, Firewall usw. bestehen bleibt. Ganz einfache Sache. Eigentlich nämlich ist Wireguard sehr einfach zu konfigurieren und sehr gutmütig.

Auf der Fritzbox kann man das aber nicht eintragen, weil der Button erst dann aktiv wird, wenn man eine IP-Adresse der Gegenseite einträgt, was man oft aber eben nicht kann.

Kurioserweise haben sie in der Webseite die Angabe sogar als optional gekennzeichnet und „Falls..“ drüber geschrieben – aber trotzdem wird der Button erst aktiv, wenn man das eingibt. Und wenn es nicht geht, geht es eben nicht.

Vielleicht ginge es, wenn sie das Javascript auf der Seite korrigieren würden, damit der Button auch ohne die Angabe einer IP-Adresse (die nämlich nicht nötig und oft nicht möglich ist) ginge.

Zweite Variante von „geht nicht“

Also dachte ich, nehmen wir es mal mit der Sicherheit nicht so genau, und machen es so, wie die sich das vorstellen. Erzeuge also extern ein Konfigurationsdateienpaar und importiere das in die Fritzbox.

Nee, is’ nich:

Wird abgelehnt, weil das den private Key überschreiben würde. Was an sich richtig ist, weil es ja eine dumme Idee ist, den Private Key zu importieren.

Keine Ahnung, ob das gehen würde, wenn man denselben Schlüssel setzt, den die Fritzbox ja – ebenso dummer Weise – als Private Key in der GUI anzeigt. Natürlich unverschlüsselt über HTTP. Aber ich kann gerade nicht zu kühn experimentieren, um mir nicht den Ast abzusägen, auf dem ich sitze.

Dritte Variante von „geht nicht“

Also dachte ich, ich probiere mal die dritte Variante aus, die sie anbieten: Die Fritzbox erzeugt alles, und dazu lädt man die Konfigurationsdatei des anderen Routers in die Fritzbox, die trägt dort ein, was einzutragen ist, und gibt das fertige Ergebnis wieder aus.

Sicherheitstechnisch ist das übel. Denn damit geht der Private Key der Gegenseite erst durch den Browser, dann per HTTP (potentiell unverschlüsselt) an die Fritzbox, wird dort von der rumgeknödelt, und geht dann per HTTP und Browser wieder zurück. Sicherheitstechnisch eine Scheiß-Idee.

Aber: Die Fritzbox ist zufrieden. Keine Fehlermeldung. Erfolgsmeldung.

Hurra? Nein.

Ich bin nicht zufrieden. Denn die Fritzbox hat nicht etwa das IPv4-Netz übernommen, dass ich als Address= eingtragen hatte, ein /20, obwohl es den Eintrag sogar um eine IPv6-Adresse ergänzt, den Eintrag also erkannt hat. Aber in ihrer eigenen Konfiguration hat sie das nicht als LAN-LAN-Adresse, sondern als Client-Maschine mit einer /32-Maschine eingetragen, und das mit einer anderen IPv4-Adresse. Es würde also über IPv4 vermutlich nicht mal funktionieren.

Grausam

Warum bekommen das selbst chinesische 20-Euro-Router brauchbar hin, während sich die Fritzbox so daran verrenkt?

Auf mich wirkt das, als habe der, der das programmiert hat, nicht verstanden, wie Wireguard und die Sache mit den Pubkey-/PrivateKey funktioniert, sondern sich im Internet ein paar Praxis-Beispiele aus Foren ergoogelt, die dann nachgebildet, und versucht, mit drei Eingangsfragen herauszufinden, welches Beispiel passt. Das sieht nämlich so aus wie so eine typische Forendiskussion: Und dann trägst Du das da ein und kopierst die Datei rüber, und drückst auf „Import“ und fertig. – Oh, Danke, das hat funktioniert! Weil es in Foren immer um Funktion in bestimmten Fallbeispielen geht, aber fast nie um die grundsätzlich Funktion oder gar Sicherheit.

Und genau so wirkt das auf mich.

Als ob sich da jemand große Mühe gegeben hat, das schön und benutzerfreundlich, idiotensicher zu machen – es aber selbst nicht verstanden hat.

Etwas Hintergrund:

Die AVM Computersysteme Vertriebs GmbH ist vor allem als Hersteller der Fritz!Box bekannt, einem Router, der in vielen Haushalten in Deutschland im Einsatz ist. Da die Gründer von AVM mittlerweile etwa 70 Jahre alt sind, steht das Unternehmen seit September 2023 zum Verkauf. Am 10. Juli 2024 hat der Hardware-Hersteller bekannt gegeben, dass der Mehrheitsanteil des Hardwareherstellers an den Investor Imker Capital Partners verkauft wurde. Die Übernahme wird dabei über ein Tochterunternehmen abgewickelt, namentlich Rucio Investment S.à r.l. (Luxemburg) und Spree 24 Beteiligung.

Und anscheinend ist das Licht da seither nicht mehr sehr helle.

Ein großer Teil der deutschen Haushalte und Kleinstunternehmen hängt per Fritzbox am Netz, während wir uns alle zähneklappernd vor Hackern und Kriegern fürchten.

Ergebnis

Ich habe es selbst unter Verzicht auf Sicherheitsanforderungen wie Schutz von Private Keys heute nicht vermocht, unter der 8.03 eine LAN-LAN-Verbindung für einen externen Router hinter NAT korrekt einzutragen. Die Fritzbox selbst kann das, weil ich auf derselben Fritzbox noch eine alte, damals noch unter 7.x eingetragene Verbindung laufen habe, die funktioniert (aber noch kein IPv6 hat). Wireguard ist da ganz normal implementiert, Linux-Kernel eben. Aber die GUI zur Konfiguration ist das Problem. Und die kommt von AVM.