Härten des Systems
Ein wichtiger Aspekt beim Betrieb eines jeden Rechners ist das Härten des Systems, damit ich meine Geräte kontrolliere und nicht jemand anders.
Für das konkrete Absichern eines OpenWrt-Systems finde ich Informationen im Wiki. Außerdem kann ich auf allgemeine Tipps zum Härten von Linux-Systemen zurückgreifen, die ich entsprechend der Situation an meinem Gerät adaptiere.
Allgemeine Hinweise
In [ctKaps2014] finden sich allgemeine Hinweise um automatisierten Angriffen auf Routern vorzubeugen, die sich auch für Geräte mit OpenWrt bewähren:
- Keine Konfiguration über Internet, oder
- wenn dann nur mit geänderten Ports und
- Verschlüsselung.
- Geänderte Kennworte und,
- wenn möglich, geänderte Anmeldenamen sowie
- geänderte interne Netzbereiche und darin
- geänderte Routeradressen.
Das sind einfache grundlegende Maßnahmen, die nicht viel gegen einen gezielten Angriff ausrichten können, aber dafür sorgen, dass einfach gestrickte Skripts ins Leere laufen.
Den Zugang sichern
Eine der ersten Maßnahmen ist die Absicherung des Zugangs zum Gerät. Dabei geht es um die Art und Weise der Anmeldung selbst.
Das OpenWrt-Wiki unterscheidet vier Arten, sich am System anzumelden, die von völlig unsicher bis ziemlich sicher reichen.
- Frag nach gar nichts
- Frag nach Benutzername und Kennwort über eine ungesicherte Verbindung
- Frag nach Benutzername und Kennwort über eine gesicherte Verbindung
- Frag nach Benutzername und einer Signatur anstelle eines Kennworts
1. Frag nach gar nichts
Jeder, der diesen Zugang erreichen kann, kann alles mit dem System machen, ohne sich anmelden zu müssen. Offensichtlich ist das für feindliche Umgebungen wie das Internet völlig ungeeignet.
In vertrauenswürdigen Umgebungen ist so ein Zugang vielleicht tolerabel, wenn absolut nichts von der Sicherheit des Gerätes abhängt. Das kann zum Beispiel eine Testumgebung sein, in der vor jedem Test der OpenWrt-Router automatisch konfiguriert wird.
2. Frag nach Benutzername und Kennwort über eine ungesicherte Verbindung
Das entspricht der Administration via Telnet oder HTTP. Es ist etwas besser als Variante 1. Bevor jemand anderes das Gerät manipulieren kann, muss er sich die Zugangsdaten besorgen.
Dazu reicht es allerdings, wenn er die Möglichkeit hat, den Datenverkehr zwischen Administrator und Gerät genau dann mitschneiden kann, wenn der Administrator sich anmeldet.
Da entsprechende Software bereits seit vielen Jahren verfügbar ist, reduziert sich der Aufwand für den Angreifer auf das Installieren und Starten eines solchen Programms auf einem geeigneten Rechner zwischen Administrator und OpenWrt-Gerät.
3. Frag nach Benutzername und Kennwort über eine gesicherte Verbindung
Hier verwende ich SSH oder HTTPS für die Administration. Damit ist das System relativ sicher.
Natürlich kann die Verschlüsselung gebrochen werden. Der Aufwand dafür hängt von den verwendeten Algorithmen, der Länge der Schlüssel und der Stärke des Kennworts ab.
Ein Angreifer muss hier den Datenverkehr mitschneiden und entschlüsseln, um an das Kennwort zu kommen.
Alternativ kann er versuchen die korrekte Kombination von Benutzername und Kennwort mit einem Brute-Force-Angriff zu erraten.
4. Frag nach Benutzername und einer Signatur anstelle eines Kennworts
Das entspricht der Anmeldung via SSH mit Public-Key-Authentication beziehungsweise HTTPS mit Client-Zertifikat.
Beim Public-Key-Verfahren verwende ich einen privaten Schlüssel, um mich am Gerät anzumelden. Den zugehörigen öffentlichen Schlüssel habe ich auf dem Gerät hinterlegt.
Ein Angreifer kann keine Passworte erraten, da keine für die Anmeldung verwendet werden. Um Zugang zu dem Gerät zu bekommen, muss er in den Besitz des privaten Schlüssels gelangen. Damit ist die Hürde für ihn noch etwas höher.
Allerdings muss ich nun aufpassen, dass mir der private Schlüssel nicht abhanden kommt. Und das sowohl in dem Sinne, dass jemand der den Schlüssel bekommt, Zugang zum OpenWrt-Gerät erhält, als auch in dem Sinne, dass ich ohne den Schlüssel keinen Zugang habe.
Neben diesen vier Arten, wie der Zugang zum Gerät geregelt ist, gibt es begleitende Maßnahmen, die die Sicherheit erhöhen können.
Mittels Paketfilterregeln kann ich den Zugang zur Administrator-Schnittstelle auf vertrauenswürdige IP-Adressen beschränken. Das ist ein starker Schutz, wenn die freigegebenen IP-Adressen wirklich zu vertrauenswürdigen Geräten führen.
Wenn ich einen anderen Benutzernamen als root verwende, mache ich Brute-Force-Attacken, die nur auf diesen Benutzernamen abzielen, wirkungslos.
Mit starken Kennworten erschwere ich Brute-Force-Attacken, die auf Wörterbüchern aufbauen.
Als weitere Schutzmaßnahme kann ich die Administrator-Zugänge auf andere Ports verlegen, anstelle von 22 für SSH und 443 für HTTPS. Damit schütze ich mich vor Skripts, die nach Services an diesen Ports suchen um anschließend Brute-Force-Attacken darauf zu beginnen.
System härten
Der nächste Schritt ist die Härtung des Systems selbst. Das ist vor allem dann wichtig, wenn das Gerät nicht nur als Router arbeitet, sondern zusätzlich weitere Dienste anbietet.
Der erste Punkt ist, so wenig wie möglich Software auf dem Gerät zu installieren und zu starten. Nur das, was wirklich nötig ist.
Falls ich Dienste auf dem Gerät anbiete, die als Einfallstor für Angreifer dienen können, kann ich mit SELinux den Schaden im Fall eines erfolgreichen Angriffs in Grenzen halten. SELinux ist für OpenWrt verfügbar. Da das Thema aber sehr umfangreich ist, gehe ich hier nicht weiter darauf ein.
Ein weiterer Punkt, der bereits bei der Absicherung des Zugangs angedeutet war, ist das Verwenden von anderen Benutzernamen. Prinzipiell brauche ich nur das Paket sudo um den Zugang zu privilegierten Diensten für die einzelnen Benutzer zu steuern. Das Paket shadow-useradd erleichtert das Einrichten von weiteren Benutzern, erfahrene Unix-Administratoren können weitere Benutzer aber auch ohne dieses anlegen. Für die Public-Key-Authentication bei SSH kopiere ich für jeden Benutzer die zugelassenen Schlüssel in die Datei $HOME/.ssh/authenticated_keys.
Mit individuellen Zugängen für die einzelnen Administratoren kann ich auch einfacher nachvollziehen, wer wann am Gerät administriert hat. Außerdem ist es einfacher, kompromittierte Zugänge zu sperren, ohne gleich alle Administratoren auszusperren.
Netzwerk härten
Ein wichtiger Punkt ist, keinen Port am externen Interface des Routers (WAN) zu öffnen. Generell. Auch, wenn ich Dienste auf dem Gerät betreibe.
Dienste, die ich nach außen anbiete, sollten auf dedizierten Servern, am besten in einem dedizierten Netz (DMZ) laufen.
Natürlich können auf dem Router laufende Dienste auch aus dem internen Netz angegriffen werden. Nur ist die Wahrscheinlichkeit, dass das aus einem öffentlichen Netz geschieht, um viele Größenordnungen höher.
Ein kompromittierter Server ist auch in einem dedizierten Netz problematisch. Ein kompromittierter Router gibt das ganze Netz dahinter preis.
Eine Ausnahme kann man für den Endpunkt eines VPN machen, das auf dem OpenWrt-Gerät endet. Hier kann ich den Zugriff auf die Adressen aus dem VPN beschränken und für alle anderen sperren.
Um einzelne Ports für einzelne Adressen freizugeben, kann ich Port-Knocking verwenden. Dafür gibt es bei OpenWrt das Paket knockd.
Eine weitere Möglichkeit, beliebige, vorher definierte Aktionen auf dem Gerät aus der Ferne zu starten ist Ostiary, für das es ebenfalls ein Paket bei OpenWrt gibt und Client-Programme für sehr viele Betriebssysteme. Damit lassen sich ebenfalls Ports für einzelne IP-Adressen freischalten.
Mit fail2ban kann ich Brute-Force-Attacken, die von einzelnen Adressen ausgehen, abbrechen. Ähnliches kann ich mit dem Programm logtrigger selbst implementieren.
Bei der Absicherung des Zugangs schrieb ich bereits, dass ein verschlüsselter Administrator-Zugang sicherer ist, als ein unverschlüsselter. Für SSH anstelle von Telnet ist das einfach zu installieren, und mittlerweile meist sowieso schon eingerichtet.
Beim Web-Interface muss ich oft noch selbst Hand anlegen, die notwendige Software installieren, konfigurieren und aktivieren. Das geht so:
Bei px5g handelt es sich um den Zertifikatsgenerator. Dieser wird nur zum Erzeugen eines Zertifikats für den Webserver benötigt und kann am Ende wieder entfernt werden.
Alternativ kann ich das Web-Interface auch durch einen SSH- oder OpenVPN-Tunnel verwenden.
Allgemeine Hinweise
Im Internet finden sich etliche Seiten mit Hinweisen, wie ein Linux-System gehärtet werden kann. Einige dieser Hinweise lassen sich für das Härten eines OpenWrt-Systems adaptieren.
Minimiere die Anzahl der Software-Pakete, ist immer sinnvoll, da dadurch die Angriffsfläche reduziert wird. Nun ist auf vielen OpenWrt-Systemen sowieso wenig Platz, so dass dieser Punkt ohnehin schon in den meisten Fällen berücksichtigt ist. Bei Standard-Images sollte man nur das nachinstallieren, was wirklich benötigt ist. Und bei selbst erstellten Images erst gar nichts überflüssiges hinein nehmen.
Kontrolliere die offenen Ports.
Damit vergewissere ich mich, dass ich keinen Dienst vergessen habe,
abzuschalten beziehungsweise zu sperren.
Von außen kann ich das mit dem Programm nmap auf einem benachbarten Rechner
machen.
Bei einem Zugangs-Router kann ich einen der vielen Dienstleister im Internet,
die solche Scans anbieten, bemühen.
Von innen, also auf dem Gerät selbst zeigt mir der Befehl netstat -aunt
alle offenen TCP- und UDP-Ports an.
Halte das System aktuell. ist immer wichtig, da ständig Programmfehler gefunden und beseitigt werden. Aber nur, wenn ich mein System auch aktualisiere.
Schaue regelmäßig in die Logs, ist ein sehr guter Rat. Nicht nur, weil ich dann Einbruchsversuche sehen und nötigenfalls Gegenmaßnahmen ergreifen kann, sondern auch, weil sich System- und Hardware-Fehler oft dort bemerkbar machen. Sehr komfortabel kann ich in die Logs schauen, wenn ich einen zentralen Log-Server mit Software zur Auswertung der Protokolle habe und diese vom OpenWrt-Gerät dorthin sende.
Beobachte das System mit IDS und Monitoring-Systemen. Während Logs meist erst nach dem Vorfall konsultiert werden, melden sich diese Systeme sofort, wenn sie Anomalien entdecken.
Ein Netzwerk-Service pro System. Dieser Grundsatz hat mehrere Vorteile. Vom Standpunkt der Sicherheit fällt nur ein Dienst aus, wenn das System ausfällt. Und als Administrator muss ich mich bei einem Ersatz oder Upgrade eines Systems nur auf einen Dienst konzentrieren, was die Sache sehr erleichtert.
Deaktiviere den Zugang für root. Das ist bei Embedded Systems eher nicht die Norm, da sich im Normalfall keine Benutzer anmelden. OpenWrt bietet jedoch die Möglichkeit und wenn sowieso schon verschiedene Zugänge für Revision und Operating existieren, sind die Hürden gering, den root-Zugang ganz zu deaktivieren.