1. Administrationsschnittstelle
Ein OpenWrt-Router verfügt standardmäßig über zwei Administrationsschnittstellen: Die LuCI-Weboberfläche und der Zugang mittels Secure Shell (SSH). Generell sollte der Zugriff über diese zwei Schnittstellen zumindest über eine Passwort-Authentifizierung vor dem direkten Zugriff geschützt sein. Immerhin ist der OpenWrt-Router das Herzstück eures Netzwerks, auf das nicht jeder unautorisiert Zugriff haben sollte.
Für die Absicherung der Administrationsschnittstellen gibt es ganz unterschiedliche Varianten bzw. Wege. Im vorliegenden Beitrag möchte ich euch eine Variante vorstellen, die bei korrekter Anwendung eine vergleichsweise hohe Hürde für einen Angreifer darstellt.
- FRITZ!Box 4040 und Netzwerkaufbau – OpenWrt Teil1
- Flash OpenWrt auf FRITZ!Box 4040 – OpenWrt Teil2
- Hardening SSH- und LuCI-Webzugang – OpenWrt Teil3
- Keine Werbung und Tracker mit Adblock-Addon – OpenWrt Teil4
- Stubby: Verschlüsselte DNS-Anfragen – OpenWrt Teil5
- Firewall | Kontrolle ausgehender Datenverkehr – OpenWrt Teil6
- OpenWrt-Upgrade einspielen – OpenWrt Teil7
2. Absicherung SSH-Zugang
Der SSH-Zugang auf den OpenWrt-Router wird mittels Dropbear realisiert – eine Alternative zum OpenSSH-Server, die darauf ausgelegt ist, wenig Speicher und Prozessorressourcen zu benötigen. Dropbear lauscht also auf Port 22 auf eingehende SSH-Verbindungen. Leider sind die verwendeten bzw. angebotenen OpenSSH-Cipher-Suiten nicht auf dem neuesten Stand, was vermutlich auf die Dropbear-Version v2017.75 zurückzuführen ist, die das OpenWrt-Projekt integriert – die letzte Version ist 2019.78. Eine kurze Prüfung mit ssh-audit offenbart die Defizite:
# general (gen) banner: SSH-2.0-dropbear (gen) compatibility: OpenSSH 6.5-6.6, Dropbear SSH 2013.62+ (gen) compression: disabled # key exchange algorithms (kex) [email protected] -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62 (kex) diffie-hellman-group14-sha1 -- [warn] using weak hashing algorithm `- [info] available since OpenSSH 3.9, Dropbear SSH 0.53 (kex) diffie-hellman-group1-sha1 -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm `- [fail] disabled (in client) since OpenSSH 7.0, logjam attack `- [warn] using small 1024-bit modulus `- [warn] using weak hashing algorithm `- [info] available since OpenSSH 2.3.0, Dropbear SSH 0.28 (kex) [email protected] -- [info] available since Dropbear SSH 2013.57 # host-key algorithms (key) ssh-rsa (2048-bit) -- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28 # encryption algorithms (ciphers) (enc) aes128-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 (enc) aes256-ctr -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52 # message authentication code algorithms (mac) hmac-sha1 -- [warn] using encrypt-and-MAC mode `- [warn] using weak hashing algorithm `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28 (mac) hmac-sha2-256 -- [warn] using encrypt-and-MAC mode `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56 # fingerprints (fin) ssh-rsa: SHA256:CWcR8ygJypOnS7epla1igqdO2arOR3C0MjvF3PcNNwA # algorithm recommendations (rec) -diffie-hellman-group1-sha1 -- kex algorithm to remove (rec) -diffie-hellman-group14-sha1 -- kex algorithm to remove (rec) -hmac-sha1 -- mac algorithm to remove
Dropbear-Version v2017.75 bietet bspw. als Schlüsselaustauschprotokoll noch immer diffie-hellman-group1-sha1 an, das in der OpenSSH-Version 6.7 aufgrund des Logjam-Angriffs bereits entfernt wurde. Aufgrund der angebotenen Schlüsselaustauschprotokolle und Message-Authentication-Code-Algorithmen (MAC) musste ich sogar meine lokale OpenSSH-Client-Konfiguration (siehe Ausschnitt) anpassen:
# Key exchange algorithms KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256,aes256-ctr # Message authentication codes MACs [email protected],[email protected],[email protected],hmac-sha2-256
Die Parameter aes256-ctr und hmac-sha2-256 habe ich manuell hinzugefügt, da sonst kein SSH-Verbindungsaufbau mit dem OpenWrt-Router möglich war. Es ist höchste Zeit, dass das Dropbear-Paket in OpenWrt aktualisiert wird.
Unterstütze den Blog mit einem Dauerauftrag!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Nur auf LAN-Interface lauschen
Standardmäßig lauscht Dropbear (Port 22) auf allen Interfaces bzw. Netzwerkschnittstellen auf eingehende Verbindungen – also auch auf dem WAN-Interface. Aus Sicherheitsgründen sollte der SSH-Port bzw. die Administrationsschnittstelle von außen nicht erreichbar sein. Daher wird unter System -> Administration ein internes Interface ausgewählt, auf dem Dropbear in Zukunft lauschen soll. Am ehesten eignet sich ein kabelgebundenes Interface:
2.2 Authentifizierung per Public-Key
Die Authentifizierung an einem SSH-Server wie Dropbear erfolgt in der Regel mittels Passwort. Eine alternative Anmeldemöglichkeit ist die Public-Key-Authentifizierung, die wir nachfolgend aktivieren. Die Verwendung eines kryptografischen Schlüssels anstelle eines Passworts ist grundsätzlich sicherer. Für die Public-Key-Authentifizierung benötigt ihr entweder einen RSA-/ECC-Schlüssel oder GPG-Schlüssel. Im Beitrag GnuPG-Public-Key-Authentifizierung – Nitrokey Teil3 hatte ich bereits aufgezeigt, wie die passwortlose Anmeldung an einem SSH-Server via GnuPG realisiert wird.
Zunächst muss der öffentliche Teil eures Schlüssels exportiert werden. Hier am Beispiel eines GPG-Schlüssels:
gpg --export-ssh-key [email protected]
Ausgabe:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDC
[…]
y9mRrM2/qbBxv+aiVH3jhEcxgDWvFzgVn9VYNB4xSN==
openpgp:0xDF66A331
Dieser öffentliche Teil wird anschließend in das Feld SSH-Keys auf dem OpenWrt-Router kopiert:
Deaktiviert anschließend noch die Anmeldemöglichkeit via Passwort (Häkchen bei Password authentication entfernen) und versucht euch anschließend per SSH auf euren OpenWrt-Router zu verbinden. Wenn alles funktioniert, könnt ihr das SSH-Administrationsmenü verlassen.
3. Zugriff auf die Weboberfläche
Eine weitere Möglichkeit ist die Administration über die LuCI-Weboberfläche. Allerdings besteht in der Auslieferungskonfiguration die Gefahr, dass ein Angreifer den Netzwerkverkehr mitschneidet und die LuCI-Web-Anmeldeinformationen abgreift – der uHTTPd-Webserver lauscht standardmäßig nämlich nur auf Port 80 (Plaintext).
OpenWrt bietet die Möglichkeit, ein TLS-Zertifikat zu hinterlegen, um die Verbindung zur Weboberfläche über HTTPS bzw. TLS abzusichern. Diese Variante macht allerdings die Installation weiterer Pakete (luci-ssl und Abhängigkeiten) notwendig – und meist wird danach auch noch ein selbst signiertes Zertifikat verwendet. Grundsätzlich ist das in Ordnung, allerdings möchte ich euch eine andere Variante vorstellen, mit dem sich der Zugang zur OpenWrt-Weboberfläche absichern lässt: Wir tunneln den LuCI-HTTP-Verkehr über SSH.
Zunächst muss die Konfiguration von uHTTPd angepasst werden. Per SSH verbinden wir uns auf den OpenWrt-Router und öffnen die Konfiguration:
nano /etc/config/uhttpd
Anschließend kommentieren wir die Zeilen mit list listen_http * aus und fügen die grün markierte Zeile neu hinzu:
# Server configuration
config uhttpd main
# HTTP listen addresses, multiple allowed
# list listen_http 192.168.150.1:80
# list listen_http 192.168.200.1:80
# list listen_http [::]:80
list listen_http 127.0.0.1:80 # HTTPS listen addresses, multiple allowed # list listen_https 0.0.0.0:443 # list listen_https [::]:443 Speichern und anschließend den uHTTPd-Service neu starten:
/etc/init.d/uhttpd restart
Danach ist die LuCI-Weboberfläche nicht mehr über die gewohnte IP-Adresse erreichbar, sondern lauscht ausschließlich auf der IP-Adresse 127.0.0.1:80 auf neue Verbindungen – diese IP-Adresse ist für Clients bzw. andere Rechner im Normalfall nicht erreichbar. Bei 127.0.0.1 bzw. Localhost handelt es sich um eine lokale Adresse, auf die nur das eigene System bzw. in diesem Fall der OpenWrt-Router zugreifen kann. Mit einem SSH-Tunnel-Kommando können wir diese lokale Adresse allerdings erreichbar machen:
ssh -L127.0.0.1:8000:127.0.0.1:80 root@IP-Adresse-OpenWRT-Interface Der lokale Port bzw. Adresse 127.0.0.1:8000 wird auf die OpenWrt-Web-Adresse 127.0.0.1:80 weitergeleitet. Ruft ihr in eurem Browser also die Adresse
http://127.0.0.1:8000
auf, findet eine Weiterleitung zu 127.0.0.1:80 statt – also dorthin, wo der uHTTPd auf Anfragen wartet. Der gesamte Verkehr zur LuCI-Weboberfläche wird also über SSH getunnelt bzw. verschlüsselt übertragen.
Die Einrichtung ist nach meiner Auffassung nicht aufwendiger, als die Installation des luci-ssl-Pakets und die anschließende Hinterlegung eines (selbst-signierten) TLS-Zertifikats. Sie hat allerdings folgende Vorteile:
- Es sind keine zusätzlichen TLS-Bibliotheken notwendig
- Der Port bzw. uHTTPd-Dienst ist nicht direkt erreichbar
Ob ihr euch nun für die TLS- oder SSH-Variante entscheidet, liegt bei euch. Persönlich finde ich die SSH-Variante elegant und einfach in der Handhabung. Dabei ist es für mich auch verschmerzbar, zunächst einen SSH-Tunnel aufzubauen, damit die LuCI-Weboberfläche erreichbar ist.
4. Fazit
Die Absicherung bzw. Härtung der Administrationsschnittstellen eines OpenWrt-Routers zählen zu den ersten Tätigkeiten, die man nach der Inbetriebnahme erledigen sollte. Neben der vorgestellten Variante beinhaltet das OpenWrt-Wiki noch weitere Vorschläge, um den Zugang zum OpenWrt-Router abzusichern.
Im nächsten Teil der OpenWrt-Artikelserie werden wir den DNS-Werbe- und Tracking-Filter in Betrieb nehmen: Eine Kombination aus dem Paket adblock und luci-app-adblock, für die Konfiguration über die LuCI-Weboberfläche.
Bildquellen:
Bulletproof Vest: Freepik from www.flaticon.com is licensed by CC 3.0 BY
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester und Sicherheitsforscher bei Kuketz IT-Security überprüfe ich IT-Systeme, Webanwendungen und mobile Apps (Android, iOS) auf Schwachstellen. Als Lehrbeauftragter für IT-Sicherheit an der DHBW Karlsruhe sensibilisiere ich Studierende für Sicherheit und Datenschutz. Diese Themen vermittle ich auch in Workshops, Schulungen sowie auf Tagungen und Messen für Unternehmen und Fachpublikum. Zudem schreibe ich für die Computerzeitschrift c’t und bin in Medien wie heise online, Spiegel Online und der Süddeutschen Zeitung vertreten. Der Kuketz-Blog und meine Expertise finden regelmäßig Beachtung in der Fachpresse und darüber hinaus.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du immer über neue Beiträge informiert bleiben möchtest, gibt es verschiedene Möglichkeiten, dem Blog zu folgen:
OpenWrt-Upgrade einspielen – OpenWrt Teil7
OpenSSH: Aktuelle Cipher-Suites für die Konfiguration
Flash OpenWrt auf FRITZ!Box 4040 – OpenWrt Teil2
FRITZ!Box 4040 und Netzwerkaufbau – OpenWrt Teil1
Abschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern spiegeln den Informationsstand zum Zeitpunkt der Veröffentlichung wieder, ähnlich wie Zeitungsartikel.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.