Allgemeine Fragen

Was ist OpenWrt?

Eine gute Frage. OpenWrt ist eine kleine Linux-Distribution, also ein Betriebssystem für eingebettete Systeme. Oder - laut eigener Aussage - ein beschreibbares Dateisystem mit Paketverwaltung.

Diese Linux-Distribution bietet ein beschreibbares Dateisystem, einen Paketmanager namens opkg zur Verwaltung der installierten Software und out-of-the-box Netzwerkunterstützung, einen WLAN-Access-Point, DNS-Service und PPP. Also fast alles, was ich für einen Zugangsrouter brauche.

Was fehlt, kann ich mit dem Paketmanager nachträglich installieren. Alternativ kann ich mir ein eigenes Firmware-Image für meine Hardware zusammenstellen, das alle von mir benötigte Software enthält.

Bedienen, das heißt konfigurieren, kann ich es via serieller Schnittstelle, Telnet, SSH, Weboberfläche oder X-Windows-System, falls die Hardware ein geeignetes Display bereitstellt.

2004 startete das OpenWrt-Projekt mit dem “Stable Release”. Diesem folgten die Ausgaben “White Russian” (2007), “Kamikaze” (2007), “Backfire” (2010), “Attitude Adjustment” (2013), “Barrier Breaker” (2014).

Der aktuelle Entwicklungszweig, genannt “Chaos Calmer”, enthält die jeweils neueste für OpenWrt verfügbare Software.

Da der Entwicklungszweig experimentellen Code enthalten kann, sollte er nicht für produktive Umgebungen eingesetzt werden. Dieser Zweig unterstützt zusätzliche Hardware, wird aber als instabil eingeschätzt und lässt sich manchmal nicht kompilieren.

Was kann ich damit machen?

Als nächstes interessiert vielleicht, wofür sich OpenWrt einsetzen lässt. Dazu gebe ich hier nur einen kurzen Ausschnitt und beschränke mich auf Einsatzfälle, bei denen der Paketfilter eine Rolle spielt.

OpenWrt kann ich einsetzen:

• als Internet-Zugangsrouter für kleine Büros oder zuhause,
• als VPN-Router,
• als kurzfristigen Ersatz für einen anderen Router,
• als IPv6-Tunnel-Endpunkt, wenn mein Provider nur IPv4 anbietet,
• als WLAN-Basisstation, -Mesh-Router, -Client.

Bei diesen Einsatzfällen will ich den Paketfilter auf jeden Fall nutzen.

Internet-Zugangsrouter

Als Internet-Zugangsrouter nutze ich meist einfache, stromsparende Hardware, wie zum Beispiel einen billigen SOHO-Router, auf dem ich OpenWrt installiert habe. Die Liste der unterstützten Geräte finde ich in der Table of Hardware im OpenWrt-Wiki.

Hier muss ich bei IPv4 meistens Masquerading zum Uplink einstellen, um meine internen Adressen zu verbergen. Will ich dann Dienste nach außen anbieten oder Spiele nutzen, die Verbindungen vom Server zum Client benötigen, muss ich das Weiterleiten von Ports konfigurieren.

Bei IPv6 will ich zumindest den Verbindungsaufbau aus dem Internet in mein lokales Netz reglementieren.

VPN-Router

Einen Tunnel oder ein VPN verwende ich, wenn ich ein anderes Netz unabhängig vom Routing über das Internet erreichen will. Das kann sein, weil ich eine zentrale Geschäftsstelle aus einem kleinen Büro erreichen will, oder weil ich bestimmte Adressen mit einer anderen Absenderadresse erreichen will, um geographische Beschränkungen auf Grund meiner Absenderadresse zu umgehen.

Ich kann den Tunnel direkt auf dem Internet-Zugangsrouter einrichten oder ich verwende einen separaten Router nur für diesen Zweck. Im ersten Fall brauche ich nichts weiter zu tun, als den Tunnel einzurichten. Im zweiten Fall muss ich entweder beim Zugangsrouter oder beim Client-Rechner die Route zu den Netzen hinter dem Tunnel eintragen.

Den Paketfilter benötige ich hier nur, wenn ich den Zugang zum Tunnel beschränken will oder wenn ich Masquerading gegenüber dem anderen Tunnel-Endpunkt einsetzen will.

Kurzfristiger Ersatz für einen anderen Router

Manchmal geht mein Zugangsrouter einfach kaputt. Oder er hat eine gravierende Sicherheitslücke, die nicht schnell genug geschlossen werden kann.

Dann ist es praktisch, wenn ich einen alten PC mit zwei Netzwerkadaptern übrig habe. Hier kann ich auch OpenWrt in einer VM verwenden, was der Artikel [ctAhlers2014] am Beispiel eines Windows-Rechners unter Einsatz von VirtualBox beschreibt. Für den Paketfilter gilt das gleiche wie für einen normalen Zugangsrouter.

IPv6-Tunnel-Endpunkt

Habe ich einen Internet-Provider, der nur IPv4 anbietet, kann ich mir über einen der IPv6-Tunnel-Provider ein Subnetz geben lassen und eine IPv6-Verbindung damit bekommen.

Den Tunnel-Endpunkt kann ich ebenfalls beim Internet-Zugangsrouter einrichten oder in einem separaten System, welches in meinem Netz dann als IPv6-Router fungiert. Dieses benötigt nur einen Netzwerkadapter. Im Gegensatz zum IPv4-VPN-Router brauche ich aber keine Route explizit bei den Clients oder beim Zugangsrouter eintragen.

Mit dem Paketfilter muss ich in diesem Fall mein Netz gegen unerwünschten Datenverkehr abschirmen.

WLAN-Basisstation, -Client, -Mesh-Router

Bei all diesen Einsatzfällen nutze ich die Möglichkeiten der eingesetzten Hardware. Der Paketfilter hilft mir den Datenverkehr in geordnete Bahnen zu lenken.

Möglichkeiten und Grenzen

Der Paketfilter von OpenWrt bietet mir alle Möglichkeiten des Linux Netfilter-Frameworks. Ich kann:

• zustandsbehaftete (stateful) und zustandslose (stateless) Firewalls bauen,
• hochverfügbare Firewall-Cluster einrichten, wenn die Hardware das erlaubt,
• IP-Adressen mit NAT umsetzen oder mit Masquerading verstecken,
• Traffic-Shaping mit dem Programm tc unterstützen,
• Netzwerk-Traffic erfassen
• transparente Proxies und Captive Portals betreiben und
• Datenpakete, insbesondere deren Header, manipulieren.

Natürlich hat der OpenWrt-Paketfilter auch Grenzen.

Diese ergeben sich zum einen aus der eingesetzten Software durch Programmfehler und Sicherheitslücken sowie Fehler in der Konfiguration, mitunter auch durch den Funktionsumfang der bei OpenWrt verfügbaren Software. Das betrifft auch und vor allem den Kernel.

Zum anderen kann der OpenWrt-Paketfilter an Grenzen stoßen, die sich aus der Hardware, konkret aus den Peripheriegeräten, dem Hauptspeicher und der CPU ergeben.

Wie kann ich die Grenzen herausfinden?

Die Grenzen der Hardware kann ich durch Lasttests herausfinden. Ich sende so viel Traffic zum Gerät wie möglich und beobachte, wie viel durchkommt. Da ich am Paketfilter interessiert bin, kombiniere ich zulässigen und unzulässigen Traffic, um zu sehen, wie weit letzterer ersteren beeinträchtigt.

Softwarefehler und Sicherheitslücken kann ich durch Penetrationstests finden. Dabei neue Fehler zu entdecken, erfordert Erfahrung und Einblick in die inneren Abläufe, zum Beispiel aus dem Quelltext der Software heraus. Darauf können die wenigsten Anwender von OpenWrt zurückgreifen.

Einfacher ist es, Security-Mailinglisten und ähnliche Quellen zu verfolgen und bei neu entdeckten Schwachstellen zu prüfen, ob mein System dafür anfällig ist. Zu diesem Zweck gibt es Exploit-Frameworks, die solche Tests vereinfachen.

Wie kann ich die Grenzen verschieben?

In manchen Fällen, speziell bei Leistungsproblemen, bleibt mir nur, auf leistungsfähigere Hardware auszuweichen. In dringenden Fällen kann ich den Durchsatz begrenzen oder vielleicht Funktionen abschalten.

Gibt es Workarounds, kann ich diese zumindest temporär nutzen. Vielleicht sogar selbst welche entwickeln.

Bei Softwareproblemen gibt es mitunter neue Versionen oder Patches, die das Problem beheben. Sind diese über die Software-Paketverwaltung erhältlich, brauche ich das System nur zu aktualisieren.

Gibt es noch keine Version im Repository, in der das Problem behoben ist, kann ich die Software selbst übersetzen. Dafür brauche ich eine Entwicklungsumgebung für OpenWrt.

Stärken von OpenWrt

Ein großer Vorteil von OpenWrt ist seine Modularität, so dass ich mir ein System genau nach meinen Wünschen einrichten kann.

Dazu kommt die Paketverwaltung, die mir auch nachträglich erlaubt, mein System zu erweitern, ohne eine neue Firmware aufspielen zu müssen.

Und schließlich die Vielfalt an billiger Hardware, die unterstützt wird und damit zu eigenen Experimenten einlädt.

Schwächen von OpenWrt

Ein Kritikpunkt ist die Vielzahl von möglichen Erweiterungen in Form von Softwarepaketen, die gerade Einsteiger verwirren kann.

Je nach Hardware ist die Unterstützung verschieden gut. Vor dem Kauf eines Gerätes muss ich auf jeden Fall ein Blick in die Liste der unterstützen Hardware werfen.

Manchmal ist die Software in den Repositories nicht aktuell genug für meinen Einsatzfall. Dann muss ich eine neuere Version selbst übersetzen. Das kann sich über Abhängigkeiten von Versionen anderer Software zu einem eigenen Projekt entwickeln.

Wie kann ich die Schwächen kompensieren?

Wenn ich sowenig Softwarepakete wie möglich, also nur die für den Einsatz nötige Software installiere, umgehe ich Probleme mit Softwarepaketen, die nicht auf meinem Gerät sind. Natürlich muss ich mir trotzdem einen Überblick verschaffen, was vorhanden ist. Aber mit der Frage “Brauche ich das wirklich?” kann ich recht schnell irrelevante Pakete ausschließen und mein System schlanker und sicherer machen.

Die Hardware kann ich vor dem Einsatz prüfen, ob sie die benötigte Leistung bringen kann. Setze ich sie ein, ist es unter Umständen vorteilhaft, wenn ich ein Gerät zusätzlich - als Reserve - besorge, um im Fehlerfall nicht auf andere Hardware ausweichen zu müssen. Anderseits kann die gleiche Hardware zu einem späteren Zeitpunkt aus zweiter Hand preisgünstiger zu bekommen sein.

Bei Softwareproblemen kann es nötig sein, eine neue Version selbst zu übersetzen. Dafür benötige ich die Entwicklungsumgebung und muss mich in diese einarbeiten. Dann kann ich aber auch die Firmware an meine Wünsche anpassen und brauche nicht nachträglich zusätzliche Software installieren.

Alternativen zum OpenWrt-Paketfilter

Will ich mich nach Alternativen für den Paketfilter von OpenWrt umsehen, muss ich mir als erstes über den Einsatzzweck und meine Anforderungen klar werden.

Ist der Paketfilter nur ein kleiner Teil des Gesamtsystems und fiel die Wahl aus anderen Gründen auf OpenWrt, dann muss dessen Paketfilter reichen.

Bei erhöhten Sicherheitsanforderungen weiche ich für die Filterung des Datenverkehrs im Netz vielleicht auf andere Systeme aus und verwende, wenn nötig, andere Hardware.

Ein weiterer Aspekt ist das zur Verfügung stehende Budget. In diesem Punkt ist es allerdings schwierig, eine sinnvolle Alternative zu OpenWrt zu finden, da dieses nahezu kostenlos zu bekommen ist und auf sehr billiger Hardware laufen kann.

Ganz anders kann es bei den Vorkenntnissen aussehen. Wer sich mit dem Paketfilter pf von BSD sehr gut auskennt, muss sich vielleicht erst mit den Eigenheiten der Netfilter-Firewall von Linux vertraut machen und würde vielleicht ein BSD-System vorziehen.

Weitere Punkte sind die Lernbereitschaft desjenigen, der den Paketfilter betreuen soll und die Lernanforderungen des Systems. Gibt es ausreichend Dokumentation und vielleicht Schulungsmöglichkeiten? Wie verläuft die Lernkurve beim Einsatz des Systems? Gibt es Konfigurationsbeispiele für die wichtigsten Einsatzfälle?

Nicht zu unterschätzen ist der Support für den Paketfilter. Habe ich mehrere Systemadministratoren, die die Technologie beherrschen, kann ich diesen Punkt enspannter sehen, als wenn ich das System allein betreue und nicht so sattelfest bin. Abhängig vom Budget, den Anforderungen und den verfügbaren Vorkenntnissen wähle ich bezahlten oder Community-Support. Letzterer funktioniert aber nur dann wirklich auf Dauer, wenn ich bereit bin, etwas von meinen Kenntnissen zurückzugeben.

Wenn ich mir im Klaren über meine Kriterien zur Auswahl einer Alternative bin, kann ich versuchen, die Spreu vom Weizen zu trennen.

Ich kann die Alternativen unterteilen zwischen proprietären und freien beziehungsweise quelloffenen Systemen. Bei proprietären Systemen muss ich immer Geld ausgeben, kann in den meisten Fällen dafür mit einem ordentlichen Support rechnen. Es bleibt allerdings immer ein Rest von Unsicherheit, was das System genau macht. Quelloffene Systeme bieten demgegenüber prinzipiell die Möglichkeit, das System bis in die letzte Ecke zu verstehen. Dafür muss ich eigene Arbeit investieren und viel lernen. Ich kann aber auch für quelloffene Systeme und den zugehörigen Support bezahlen.

Eine weitere Unterteilung betrifft das eingesetzte Betriebssystem, welches die Arbeitsweise des Paketfilters bestimmt. Die wichtigsten sind hier:

• Linux mit Netfilter
• BSD-basierte Systeme mit pf
• proprietäre Systeme, die oft auf einem der beiden aufbauen

Auf das Betriebssystem setzt die Konfigurationssoftware auf, mit der der Paketfilter erst nutzbar wird. Hier gibt es:

• Konfiguration über die Kommandozeile beziehungsweise Textdateien,
• Webbasierte Konfiguration,
• Konfiguration direkt am Gerät über eingebaute Schalter und Anzeigen.
• Konfiguration mit speziellen Programmen,
• Zentrale Konfiguration für mehrere Geräte,

Die Konfiguration über die Kommandozeile und über Textdateien erfordert die genaue Kenntnis der erforderlichen Syntax und hat zu Beginn eine steile Lernkurve. Auf die Dauer wird diese Lernkurve jedoch kompensiert durch die Möglichkeit, die Konfiguration in beliebigen Versionsverwaltungssystemen zu pflegen und darüber Änderungen zu verfolgen. Außerdem ist es einfach möglich, die Konfiguration automatisch zu erzeugen sowie aus der Konfiguration automatisch die Dokumentation zu generieren.

Bei der Konfiguration über ein Webinterface ist die Lernkurve am Anfang flach und kleine Änderungen der Konfiguration sind schnell gemacht. Dafür sind komplexe Konfigurationen nur mühsam und fehlerträchtig zu pflegen. Versionskontrolle ist ohne weiteren Aufwand nicht möglich. Automatisierung über das Webinterface ist zwar möglich, aber aufwendig und fragil gegenüber Änderungen am Webinterface.

Neben der CLI-/Text-basierten und der Webkonfiguration gibt es die zentrale Konfiguration mehrerer Paketfilter. Diese bietet die Möglichkeit, mehrere Firewalls in einem Netz aufeinander abzustimmen. Einige proprietäre Systeme bieten von sich aus diese Möglichkeit. Bei Firewalls mit CLI-/Text-Interface lässt sie sich nachrüsten oder selbst programmieren. Bei einem Webinterface würde ich auf Grund der Fragilität davon abraten.

Die Konfiguration mit speziellen Programmen, die auf dem Arbeitsplatzrechner laufen und von dort aus die Firewall konfigurieren ist oft bei proprietären Systemen zu finden. Dabei bin ich an das Betriebssytem gebunden, auf dem das Programm läuft.

Als letzte Form der Konfiguration kann ich direkt am Gerät arbeiten. Damit ist oft nur eine minimale Grundkonfiguration möglich, sowie das Rücksetzen auf Werkseinstellungen.

Schließlich kann ich Alternativen nach der benötigten Hardware einteilen, beziehungsweise nach dem Virtualisierungssystem, falls ich den Paketfilter in einem Software Defined Network als virtuelle Maschine betreiben will.

Mit diesen Unterscheidungsmerkmalen wäge ich die Vor- und Nachteile gegenüber OpenWrt ab und entscheide mich dann an Hand meiner vorher aufgestellten Kriterien.