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.