Die Bluebox-Firewall hieße richtiger Blackbox: Konfiguriert doch bei dieser Linux-Appliance nicht der Admin vor Ort die Filterregeln, sondern ein geschulter Bluebox-Vertriebspartner. Laut Hersteller eignet sich das Gerät besonders für kleinere Firmen ohne eigene IT-Abteilung – eine Behauptung, die zu prüfen ist.

Korrekte Firewall-Regeln zu zimmern ist für viele Anwender sehr problematisch, stehen sie doch ständig in der Gefahr, unwissentlich durch eine Fehlkonfiguration Sicherheitslöcher aufzureißen. Solche fehlerhaften Firewalls sind oft ein größeres Sicherheitsrisiko als ein nicht vorhandener Paketfilter, da der Admin im Vertrauen auf ein dichtes Netz Angriffe schlicht übersieht.

Genau an diesem Faktor Mensch setzt die am mathematischen Institut der Universität Göttingen[8] entwickelte Bluebox an. Nicht der Admin vor Ort konfiguriert die Linux-Appliance, sondern der Bluebox-Vertriebspartner. Der – so die Idee – verfügt über ausreichend große Fachkenntnis und Routine, um auch in exotischen Konstellationen eine saubere Firewall zu konstruieren. Zudem entfällt auf dem Gerät der potenziell verwundbare Webserver, über dessen HTML-Interface der Admin normalerweise das Setup tätigt.

Ob das Konzept der Bluebox aufgeht und ob sie auch Software-seitig den vielfältig denkbaren Angriffsszenarien standhält, klärt dieser Test.

Testkonfiguration

Dazu bestellte das Linux-Magazin bei einem der beiden Vertriebspartner ([1],[2]) eine Bluebox. Der Auftrag an dessen Vertrieb lautete, die Firewall so zu konfigurieren, dass sie das in Abbildung 1 dargestellte Netzwerk vor Zugriffen von außen schützt. Zudem sollte das Gerät die internen Hosts so reglementieren, dass ihre Nutzer neben HTTP, HTTPS und SSH nach überall nur via SMTP auf den SMTP-Server in der Demilitarized Zone (DMZ) zugreifen dürfen.

Zwei Nutzer im LAN, deren IP-Adressen die Tester explizit nannten, sollten auch den AOL Instant Messenger (AIM) nutzen dürfen. Das interne Netz musste via Network Address Translation (NAT) Zugang nach außen haben. Zur Namensauflösung dürfen die lokalen Nutzer und jene in der DMZ nur den DNS-Server der DMZ erreichen. Die Server in der DMZ sollten von überall für alle erreichbar sein – so wie allerorts üblich.

Tückisch für die Firewall ist der in der DMZ liegende FTP-Server. Bei ungeschickter Konfiguration kann FTP im Passive-Modus ein erhebliches Sicherheitsloch in die Firewall-Konfiguration reißen, da der Server auf allen Highports auf Verbindungsversuche eines Clients reagieren muss. Da auch MySQL standardmäßig auf einem Highport, nämlich 3306, lauscht, steht in der DMZ zusätzlich ein solcher Server. Die Anforderungen schienen die beauftragte Bluebox-Firma nicht weiter zu beeindrucken. Sie wies nur auf die Gefahr von Klartextpasswörtern bei FTP hin und versprach die Firewall zügig zuzusenden.

Blaue Hardware

Tatsächlich traf die Bluebox einige Tage später ein (Abbildung 2). Die Hardware beruht auf einem Lex Thin Client[3] mit einem VIA-Eden-Prozessor (533 MHz) und drei Realtek-100-MBit-Netzwerkports on Board. Das Gerät kommt ohne bewegte Teile aus, arbeitet also lautlos und Strom sparend. Aufgabe des Vertriebspartners ist es, die Bluebox professionell zu konfigurieren. Das Betriebssystem und die Konfiguration der Firewall sind auf je einem per Hardwareschalter schreibgeschützten USB-Stick gespeichert. Zweifellos erleichtert dieses Medium Updates der Konfiguration: Stick auswechseln – fertig.

Abbildung 1: Der Bluebox-Vertrieb erhielt dieses Testsetup inklusive verwendeter IP-Adressen und sollte das Gerät entsprechend konfigurieren. Tückisch ist der FTP-Server in der entmilitarisierten Zone.

Der Konfigurations-Stick steckt im Front-USB, der fürs Betriebssystem an der Rückseite, was laut Hersteller auch unveränderlich ist. Beim rückseitigen Stick ist das gleichgültig, da hier sowieso viele Kabel die Sicht versperren. An der Frontseite ragt der USB-Stick aber allein und somit mechanisch gefährdet heraus. Da das Betriebssystem selbst seltener zu updaten ist, wäre hierfür eine Compactflash im Gehäuse geschickter. Ein CF-Adapter ist nämlich bei dem Gerät sowieso on Board.

Missglückte Farbenlehre

Eigentlich sehr einsteigerfreundlich ist die farbige Netzverkabelung im Lieferzustand. Das rote Kabel geht zum Router, das grüne zum internen Netz und das gelbe zur DMZ. Nur Abziehen sollte man sie nicht – dann wird’s schwierig, die richtige Schnittstelle zu finden, da die Anschlüsse wenig intuitiv mit »LAN1«, »LAN2« und »LAN3« beschriftet sind (siehe Abbildung 3). Ein serielles Kabel liegt auch bei, über das der Admin einen anderen Rechner zum Loggen der Firewall-Meldungen anschließen kann. Das ist auch zu empfehlen, denn alle Datenträger sind schreibgeschützt.

Fummeln unmöglich

Selbst ein Login mit angeschlossenem Monitor und Tastatur ist nicht möglich. Aus Sicht des Anbieters ist das konsequent: Der Anwender kann mangels Zugang keine Sicherheitslöcher durch eine Fehlbedienung in das System reißen. Dieser Philosophie folgend ist auch das Angebot zu verstehen, dass nach der Erstkonfiguration der Firewall die ersten kleinen Ergänzungen und Anpassungen im Kaufpreis enthalten sind.

Das ist sinnvoll, da nur eine Feinjustage die Probleme schnell behebt, zu denen eine restriktiv konfigurierte Firewall in der Praxis meist führt. Der Kunde bekommt dann einen neuen USB-Stick mit der geänderten Konfiguration zugesandt und schickt im Gegenzug den alten Stick zurück. Spätere und größere Änderungen der Konfiguration verrechnet der Vertrieb nach Preisliste. Insgesamt ist die Hardware der Bluebox technisch unproblematisch und robust.

Gepatchter Kernel

Spannender als die Hardware ist bei Firewall-Systemen die Software. Die Bluebox läuft unter Linux und verwendet IPtables. Als Kernel dient ein statischer 2.4.5 mit den GRsecurity-Patches[4],[5]. Diese Patches haben einige Bekanntheit erlangt, seit ihr Entwickler auf zahlreiche Schwachstellen im Linux-Kernel 2.6 hingewiesen hat.

GRsecurity nutzt mehrere Techniken, um das System sicherer und für Angreifer unübersichtlicher zu machen. Es wählt die TCP-Highports für ausgehende Verbindungen und die initialen TCP- Sequenznummern mit einer größeren Zufälligkeit, was neben OS-Fingerprinting die Vorhersage der Ports und Sequenznummern und darauf basierende Hijacking-Angriffe erschwert.

Zusätzlich implementiert es Schutzsysteme gegen typische Angriffe wie Buffer Overflows, Chroot-Verletzungen oder Race Conditions in »/tmp« sowie erweiterte Access Control Lists (ACL). Letztere bringen jedoch auf einer Firewall, die selbst weder Dienste noch Logins ermöglicht, bei korrekter Konfiguration praktisch nichts. Die GRsecurity-Patches schaffen gute Voraussetzungen für eine sichere Firewall. Offen bleibt noch die Frage, wie gut die Konfiguration der Firewall-Regeln selbst ausfällt.

Abbildung 2: ALs Bluebox-Hardware dient ein Lex Thin Client mit einem VIA-Eden-Prozessor und drei Ethernet-Schnittstellen. Links ragt der USB-Stick mit der Firewall-Konfiguration aus dem Gehäuse.

Abbildung 3: Auf den ersten Blick sehr einsteigerfreundlich ist die farbige Netzverkabelung im Lieferzustand. Nur die Beschriftung der Ethernet-Buchsen will dazu gar nicht passen.

Augekochtes Testsetup

Um die Wirksamkeit der Firewall zu untersuchen, überlegte sich der Test-Autor ein ziemlich trickreiches Setup: Er simulierte die DMZ und das interne Netz auf jeweils einem Rechner, auf dem der Honeynet-Daemon Honeyd[6] lief. Der vermag auf einem Rechner beliebig viele Systeme zu simulieren. Insbesondere kann man ihn so konfigurieren, dass er auf allen Ports des Systems Verbindungen entgegennimmt und sie protokolliert. Für den Test einer Firewall ist das sehr hilfreich.

Crossover-Kabel verbanden die Rechner mit der Bluebox. Anstelle des Routers musste ein dritter Rechner an einem Crossover-Kabel herhalten, der zunächst von der IP des Routers aus einen Nmap-Portscan[7] auf die Firewall losjagte. In diesem Testteil probierte der Pseudo-Router nacheinander alle denkbaren TCP-Flag-Kombinationen aus – ohne Lücken zu finden.

Das GRsecurity-Patch schien den Portscan unglaublich zu verlangsamen. Um den Effekt eindeutig zuordnen zu können, bauten die Tester kurzerhand eine Bluebox nach. Zum Einsatz kam ein VIA Epia-VE5000-Board mit einem 533-MHz-Eden-Prozessor und 512 MByte RAM, deren Leistung etwa einer Bluebox entspricht. Darauf spielten sie Fedora Core 3. Ohne zusätzliche Filterregeln lautete die IPtables-Default-Policy »DROP«.

Scanner-Falle

Anschließend scannte Nmap alle Ports mit allen konfigurierbaren Flag-Kombinationen. Nmap protokollierte dabei seine Laufzeit selbstständig. Als Vergleich kompilierten die Tester dann einen Kernel und IPtables mit den GRsecurity-Patches neu und booteten mit ihm das System. Die Default-Policy war gleich, allerdings fügten sie in die »INPUT«-Chain noch zwei Regeln ein, die die Patches bereitstellen:

iptables -A INPUT -p tcp -m stealth -j DROP
iptables -A INPUT -p udp -m stealth -j DROP

Der Portscan lief in gleicher Reihenfolge mit den gleichen Parametern ab. Die Geschwindigkeit der zweiten Portscans auf dem Bluebox-Nachbau reduzierte sich erwartungsgemäß teilweise massiv – den UDP-Scan brach das Team gar nach zwei Tagen unvollendet ab. Ohne GRsecurity dauerte dieser Scan rund 900 Sekunden. Bei den anderen Scans war der Effekt weniger deutlich.

Das nächste Szenario mit der echten Bluebox baute Verbindungen von außen zu den jeweiligen Diensten auf den Servern der DMZ auf. Der Autor fuhr dazu die meisten Protokolle von Hand mit Telnet nach. Im Ergebnis verhielt sich die Firewall, wie sie sollte. Auch bei FTP gibt es keine Unregelmäßigkeiten zu berichten. Dieser Teil schloss darum klar mit dem Prädikat “Bestanden” ab.

Abbildung 4: Der Konfigurationseditor ist nur für Fachhandelspartner gedacht. Seine Oberfläche wirkt schnörkellos und intuitiv.

Wider den Feind im eigenen Hause

Firewalls werden nicht nur von außen, sondern sehr oft von innen angegriffen. Außerdem wollen manche Nutzer unerwünschte Verbindungen nach außen aufbauen. Daher wanderte das Angreifersystem nun in die virtuelle DMZ und eine der Honeyd-Boxen an die Stelle des Routers. Dieser Test förderte selbst bei extremer Fragmentierung der Pakete, zum Beispiel mit Hping[9], keine bösen Überraschungen zutage – die Firewall lies nur das passieren, was sie laut Auftrag auch durchlassen musste.

Im letzten Schritt landete der Angreifer-Server an der internen Netzwerkschnittstelle der Bluebox. Der Rest blieb wie gehabt. Wie der vorige vermochte auch dieser Test der Bluebox keine Fehler nachzuweisen. Schön: Der Hersteller scheint für die FTP-Verbindungen das Kernelmodul »ip_ ftp_conntrack« mit einzukompilieren. Damit arbeitet IPtables für aktive und passive FTP-Datenverbindungen als Statefull-Firewall.

Nur fürs Personal

Der Test-Autor hatte die Möglichkeit, den Regeleditor (Abbildung 4), der nur den Fachhandelspartnern vorbehalten ist, zu nutzen und so sowohl die vom Vertrieb eingespeicherten Regeln zu überprüfen als auch neue anzulegen. Der Editor ist plattformunabhängig in Java geschrieben und bezieht seine Konfigurationsdaten über die vorliegende Bluebox zentral von einem Göttinger Server.

Dass Informationen auf einem entfernten Server liegen, öffnet potenziell ein Sicherheitsloch: Gelänge es einem Angreifer, die Daten von diesem Server auszulesen, dann könnte er Informationen über die Konfigurationen aller Blueboxes bekommen. Die Kenntnisse über Kundennetze würden ihm bei der Vorbereitung von Angriffen helfen.

Noch ärger wäre, ein Angreifer könnte die Konfigurationsdaten auf dem Server manipulieren. Ab dem nächsten Konfigurationsupdate wäre damit die Firewall für den Angreifer offen. Allerdings muss der Angreifer dazu sowohl unbemerkt bleiben als auch einen geeigneten Regelsatz finden, was die Wahrscheinlichkeit des Erfolgs etwas dämpft. Das Signieren der Konfigurationsdaten auf dem Server wäre eine sichere Lösung.

Ein theoretisch anderer Weg wäre, den Konfigurationseditor die Konfiguration vom USB-Stick nachladen zu lassen. Da der aktuelle Stick aber stets beim Anwender und nicht beim Vertriebspartner ist, ist das ohne Postlaufzeit-bedingte lange Downtime leider nicht möglich.

Empfehlenswert

Im Vergleich zur selbst gezimmerten Linux-Firewall entfällt bei der Bluebox neben der nötigen Hardware der Aufwand, ein sicheres System zu installieren und sich selbst die Firewall-Regeln zu überlegen. Als Bonbon ist zudem die Haftungsfrage elegant vom Tisch. Die umfänglichen Angriffe aus den Testszenarien bestand das Testgerät mit Bravour. Für eine Folgeversion wäre es schön, wenn der Front-USB-Stick zu einer Compactflash-Karte mutierte und optional die Konfigurationsdaten auf dem Server der Uni Göttingen deaktivierbar würden.

Der beziehungsweise die Preise erscheinen angemessen – angesichts der Hardware und der aufwändigen Erstberatung und -konfiguration ist er sogar sehr günstig. Denn im Zuge der Erstberatung ist vielfach eine gründliche Analyse des Kundennetzwerks fällig. Zusammen mit der vom Autor erlebten zügigen und kompetenten Beratung ist das System uneingeschränkt empfehlenswert. (jk/fjl)