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) curve25519-sha256@libssh.org -- [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) kexguess2@matt.ucc.asn.au -- [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 curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,aes256-ctr # Message authentication codes MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,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.
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:
Hilf mit die Spendenziele zu erreichen!
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.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 nitrokey@kuketz.de
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 / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
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 über aktuelle Beiträge informiert werden möchtest, hast du 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
Keine Werbung und Tracker mit Adblock-Addon – OpenWrt Teil4
9 Ergänzungen zu “Hardening SSH- und LuCI-Webzugang – OpenWrt Teil3”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Genau aus diesem Grund insbesondere bei Anpassung der sshd_config via SSH auf einem „Remote Host” immer daran denken:
1. Vor den Änderungen eine Sicherheitskopie machen!
2. In der angemeldeten Session service sshd reload
3. ANGEMELDET BLEIBEN!!!
4. in einem separaten Terminal-Fenster versuchen, sich per SSH zu verbinden
Punkte 1 & 3 sind besonders wichtig. Vergisst man die und Punkt 4 schlägt fehl, hat man sich erfolgreich ausgesperrt. Andernfalls kann man in der noch angemeldeten Session einfach die Sicherheitskopie wieder zurückspielen, und nach einem Reload funktioniert alles wieder.
Bei OpenWrt vielleicht weniger kritisch, weil man es über die Web-Oberfläche wieder richten kann? Weiß ich jetzt nicht zu sagen, da ich kein OpenWrt habe…
Ich meinte das eigentlich anders: Ich musste die beiden Parameter hinzufügen, bevor eine Verbindung per SSH überhaupt möglich war.
Ansonsten sind deine Ausführungen korrekt. So kann man sich nicht aussperren, aber gleichzeitig testen.
Das ist so leider nicht korrekt. Ein Schlüssel bietet gegenüber einem Passwort Vorteile bzw. Unterschiede in der Handhabung, ist aber NICHT per se sicherer.
Was viele nicht wissen: ein Private Key kann genauso millionenfach erzeugt und somit der Server per Brute-Force attackiert werden. Bei gleicher Länge und Entropie ist ein Schlüssel exakt genauso sicher wie ein Passwort.
Schlüssel sind meist länger und bieten Vorteile in der Handhabung, das sind die wichtigsten Unterschiede.
Korrekt. Daher habe ich mich in diesem Kontext auch für die Aussage entschieden, dass Schlüssel gegenüber Passwörter meist bzw. grundsätzlich sicherer sind.
Hallo Mike,
sobald ich in System->Administration mein Interface für Dropbear auf LAN beschränke, kann ich nicht mehr per SSH auf den Router zugreifen. Es funktioniet nur, wenn ich das Interface auf WAN setzte.
Woran könnte das liegen?
Liebe Grüße
Contax
Kann es vielleicht sein, dass du dich über das WAN-Interface, anstelle von LAN, verbindest? Bist du denn mit dem OpenWRT Router verbunden oder weiterhin mit deinem Modem vom Anbieter?
Hallo rhizoet,
das war natürlich auch erst mein Gedanke und habe es tätsächlich mehrmals kontrolliert.
Aber:
Pc via Kabel an Lan 4040
6490 via Lan an Wan 4040
Ich dachte erst ich muss evtl ne bridge zwischen Lan und Wan erzeugen,allerdings hat Mike das niergends eingestellt noch ergibt ess für mich anderweitig keinen Sinn, da ich die beiden Zonen ja getrennt haben möchte.
Grüße
Contax
Mir fallen zwei mögliche Erklärungen ein:
Ist LAN als Zone dem richtigen Interface zugeordnet. Vielleicht ist die Zuordnung da falsch?
Oder sind die IP-Adressen der beiden Zonen nicht unterschiedlich?
Danke libertador!
Ersteres traf zu, eth1 und eth0 waren jeweils vertauscht…
Jetzt gehts :)