Aus Linux-Magazin 05/2002

Microliss: Firewall-Appliance im kleinen Gehäuse

Die Kombination aus Paketfilter, VPN-Gateway und DSL-Router passt bei der Microliss-Firewall in ein Gehäuse, das etwa so klein wie ein Modem ist. Das Gerät enthält zusätzlich ein Intrusion-Detection-System.

Wer eine platzsparende Firewall sucht, bei der sich der Administrator nicht um die Hardware kümmern muss, sollte die Microliss[1] der Firma Telco-Tech näher betrachten: Nach dem Auspacken reibt man sich verwundert die Augen und fragt sich, ob man einen Switch gekauft hat. Die kleine Firewall kommt ohne Lüfter und Festplatte aus, sie kann daher praktisch überall stehen.

Mit ihren drei Netzwerk-Interfaces eignet sich die Microliss sowohl als einfacher Zugangsrouter als auch für komplexere Setups mit einer DMZ (demilitarisierten Zone). Neben dem Netzteil liegen auch ein Nullmodemkabel, eine Diskette mit einem Terminalprogramm und eine Bedienungsanleitung bei.

Der erste Kontakt

Die Netzwerk-Schnittstellen sind bereits vorkonfiguriert: »eth0« mit 192.168.1.1, »eth1« mit 192.168.2.1 und »eth2« mit 192.168.3.1, jeweils mit der Netzmaske 255.255.255.0. Falls diese Einstellungen überhaupt nicht passen, können sie über das serielle Interface und das mitgelieferte Nullmodemkabel verändert werden. Die beiliegende Diskette enthält das Windows-Programm Hyperterminal in einer Evaluierungsversion und zwei Konfigurationsdateien zur Ansteuerung des Geräts über COM1 (»ttyS0«) oder COM2 (»ttyS1«).

Leider kam nach der Beschreibung im Handbuch keine Verbindung mit dem Hyperterminal zustande, für andere Terminalprogramme fehlen die Informationen zu den nötigen Parametern – schließlich arbeitet nicht jeder Admin mit einem Windows-PC. Mit folgenden Einstellungen kann »minicom« unter Linux die Microliss dennoch kontaktieren: Terminalemulation ANSI, 19200 Baud, acht Datenbits, keine Parität, ein Stoppbit, Hardware-Flusskontrolle aktiviert und Software-Flusskontrolle deaktiviert. Wichtig ist, dass die Initialisierungs- und Reset-Sequenzen für Modems gelöscht werden. Mit diesen Einstellungen reicht ein Drücken der [Enter]-Taste zum Aufbau der Verbindung.

Nach dem Login auf der seriellen Konsole mit der Standard-Benutzerkennung »config« und dem Passwort »config« kann man die IP-Adresse und die Netzmaske verändern. Da sich das Passwort für die serielle Konsole nicht verändern lässt, sollte der serielle Port nicht jedem zugänglich sein. Ein Terminal-Server könnte hier also durchaus zu einem Problem werden.

Nun ist der Webserver der Microliss von allen Netzwerk-Schnittstellen aus über »https:// IP-Adresse« erreichbar. Bevor er die Verbindung herstellt, muss sich der Administrator mit einer kleinen Besonderheit auseinander setzen: Grundsätzlich sind die Partitionen mit den Konfigurationsdateien nur zum Lesen gemountet (read-only). Um überhaupt etwas zu verändern, muss er vor dem Login einen kleiner Metallstift aus der Buchse ziehen und in die zweite Buchse für »read-write«-Zugriff stecken. Erst jetzt kann er die Firewall konfigurieren.

Schreibschutz eingebaut

Nach dem Umkonfigurieren und dem Speichern muss der Admin den Stift wieder in die ursprüngliche Buchse stecken. Vergisst er das, tritt eine interessante Erweiterung in Kraft: Nach zwei Stunden schaltet die Firewall automatisch wieder zurück in den Read-only-Modus, obwohl der Stift noch in der Schreib-Buchse steckt. Während der zwei Stunden läuft ein zweiter Counter: Wenn innerhalb von 30 Minuten keine Daten geschrieben werden, deaktiviert die Firewall das Routing. Sie aktiviert es automatisch wieder, wenn ein Schreibvorgang stattgefunden hat. Es gibt noch einen dritten Zähler: Innerhalb von 15 Minuten sollte der Admin auf die Microliss zugreifen, sonst muss er sich neu einloggen.

Nach dem ersten Login mit dem Superuser-Account »liss« und Standard-Passwort »start« muss das Passwort verändert werden, sonst lässt die Web-Oberfläche alle anderen Konfigurationsmasken im Read-only-Modus. Sehr gut ist die Gütekontrolle für das Passwort, sie verhindert zu einfache Passwörter.

Das SSL-Zertifikat für die HTTPS-Verbindung stammt aus dem Hause Telco-Tech, es ist auch mit einer firmeneigenen Signatur versehen. Als Krypto-Algorithmus kommt das nicht allzu starke RC4 mit 128 Bit zum Einsatz.

Konfiguration

Nach dem Einloggen begrüßt ein übersichtlich wirkendes Interface den Administrator, Abbildung 1 vermittelt einen ersten Eindruck. Des Englischen sollte der Admin mächtig sein, eine deutsche Übersetzung des Web-Frontends gibt es nicht. Die ersten Konfigurationspunkte sind die IP-Adresse und die Netzmaske für jede Netzwerk-Schnittstelle. Leider sind zurzeit keine Netzmasken kleiner als 255.128.0.0 möglich, dieses Problem soll aber laut Telco-Tech demnächst behoben werden.

Man kann mehrere Standard-Gateways angeben, zu diesen leitet die Firewall alle IP-Pakete weiter, für die keine expliziten Host- der Netzwerk-Routen konfiguriert sind. Der im Handbuch angegebene Hinweis, »eth0« müsse immer als Schnittstelle zum Internet konfiguriert sein, erwies sich nach einer Rückfrage bei einem Techniker von Telco-Tech als unbegründet: »eth0« wird nicht speziell behandelt.

Etwas verwirrend ist die Benutzung dieser Standard-Gateways: Wenn mehrere angegeben sind, kommt nur das oberste zum Zuge. Nur wenn es ausfällt, schaltet die Microliss als Fallback-Lösung auf das nächste Gateway um. Um statische Routen für spezielle Netzwerke oder Hosts anzulegen, muss man das jeweilige Gateway ebenfalls zu den Standard-Gateways hinzufügen und dann den Host oder das entsprechende Netzwerk in einer anderen Maske des Web-Frontends an-geben.

Falls nötig kann die Interface-Konfiguration auch vir- tuelle IP-Adressen pro Netzwerkkar- te vergeben. Für jedes Interface ist PPPoE für einen DSL-Anschluss möglich, sinnvoll ist das aber sicherlich nur für den externen. Gut gelungen ist die grafische Anzeige der gesendeten und empfangenen Datenmenge. Das Ganze erinnert an MRTG, wurde aber von Telco-Tech selbst entwickelt und liest als Daemon die Informationen in »/proc/net/dev«.

Falls Server im internen Netz oder in der DMZ von außen erreichbar sein sollen, ohne ihre IP-Adresse zu routen, kann man auf der Microliss ein Port-Forwarding aktivieren. Dabei wird ein Port des Interface »eth0« mit einem Port des internen Zielsystems verbunden. Man kann damit unter anderem eine DMZ mit nicht öffentlichen IP-Adressen betreiben, in der ein Webserver steht, der von außen erreichbar ist.

Für einen Port lassen sich mehrere Weiterleitungsregeln definieren. Netzwerkverbindungen, die diesen Regeln entsprechen, verteilt die Firewall nach einem Round-Robin-Mechanismus auf die einzelnen Zielsysteme. Sie kann auch warten, bis die Anzahl der weiterzuleitenden Verbindungen einen einstellbaren Level übersteigt, bevor sie neue Verbindungen zum nächsten Zielsystem weiterleitet.

Die VPN-Unterstützung ist in die Firewall mit Hilfe von FreeS/Wan[2] integriert. Neben der nicht empfohlenen Verwendung eines beliebigen, selbst gewählten Schlüssels (als Preshared Secret) kann auch ein RSA-Sigkey mit 1024 Bit eingesetzt werden, den die Microliss selbst erzeugt. Der Schlüsselaustausch findet mittels IKE am UDP-Port 500 statt, die Authentifizierung erfolgt mit ESP oder mit ESP/AH. Abbildung 2 zeigt die Einstellungsmaske für das VPN innerhalb des Web-Frontends.

Abbildung 1: Das Administrations-Frontend der Microliss teilt sich in mehrere übersichtliche Bereiche, die links oben gewählt werden. Rechts ist die Maske für die Interface-Einstellung zu sehen.

Abbildung 1: Das Administrations-Frontend der Microliss teilt sich in mehrere übersichtliche Bereiche, die links oben gewählt werden. Rechts ist die Maske für die Interface-Einstellung zu sehen.

Kernel 2.2 und die zustandslosen IPChains

Als Paketfilter nutzt die Firewall die zustandslosen IPChains des 2.2er Linux-Kernels. Ähnlich wie bei großen kommerziellen Firewalls kann man auch bei der Microliss vor der Definition der eigentlichen Regeln Gruppen von IP-Adressen und Gruppen von Verbindungen angeben. Bei den Verbindungen lässt sich eine Verbindungslogik festlegen. Dazu gehören die folgenden Informationen, getrennt für jede Transportrichtung der IP-Pakete: Protokoll (nur TCP, UDP, ICMP, ESP, AH, GRE), Quell- und Zielport beziehungsweise ICMP-Nummer, gegebenenfalls Überprüfung des ToS (Type of Service) und des SYN-Flags im TCP-Header.

Es sind bereits viele dieser Verbindungslogiken für verschiedene Protokolle vorkonfiguriert. Einige davon kann der Administrator selbst verändern, andere sind read-only, und natürlich kann man eigene Regeln hinzufügen. Erst nach diesen Vorarbeiten lassen sich die Paketfilter-Regeln generieren. Für diese Regeln gibt man an, welche IP-Adressgruppe die Quelle und welche das Ziel ist, und wählt dann eine oder mehrere Verbindungslogiken aus. Jede Regel kann bestimmen, dass der Paketfilter ein passendes IP-Paket weiterleitet (ac-cept), es einfach löscht (deny), es löscht und eine ICMP-Nachricht an den Sender schickt (reject) oder ob er die Verbindung maskiert (NAT, Network Address Translation).

Abbildung 2: Die Konfigurationsseite für VPNs ist sehr übersichtlich: Die Grafik verdeutlicht, welche Adressen und Netze in der unteren Hälfte gemeint sind.

Abbildung 2: Die Konfigurationsseite für VPNs ist sehr übersichtlich: Die Grafik verdeutlicht, welche Adressen und Netze in der unteren Hälfte gemeint sind.

Snort an Bord

Zur Überwachung des Datenverkehrs dient das Netzwerk-IDS (Intrusion Detection System) Snort[3]. Vor dessen Einsatz sollte dem Administrator aber klar sein, dass es einige Rechenleistung benötigt. Vor dem Produktivbetrieb an einem ausgelasteten 100-MBit-Netzwerk sollte er sich von der Praxistauglichkeit überzeugen.

Ein von Telco-Tech geschriebenes Programm kann bei einem IDS-Alarm dynamisch eine Paketfilter-Regel generieren, die die Kombination aus Quell-IP-Adresse, Quell-Port, Protokoll und Ziel-IP-Adresse und -Port blockt. Das IDS kann auch eine E-Mail an einen externen Account schicken. Die Regeln für verschiedene Arten von Angriffen, unter anderem Portscans und Fragmentierungsattacken, lassen sich einzeln ein- und ausschalten. Außerdem können verschiedene Signaturen für bestimmte Angriffsszenarien aktiviert werden.

Die Regeln, die Snort für die Überprüfung der Netzwerk-Kommunikation einsetzt, lassen sich zur Zeit nur durch ein Update der Firmware verändern. Telco-Tech will in Zukunft aber auch das Ändern und Generieren von Snort-Regeln ermöglichen.

Damit mehrere Administratoren auf der Microliss arbeiten können, enthält das Web-Frontend ein Benutzersystem. Es kann neue User anlegen und Lese- und Schreibrechte pro Konfigurationsmaske und pro Benutzer vergeben. Obwohl alles dokumentiert ist und auch das Frontend keinen Warnhinweis enthält, funktioniert die Einschränkung der Rechte nicht. Nach Angaben eines Technikers von Telco-Tech sollte dieser Teil des Web-Frontends ein undokumentiertes Dasein fristen, bis alles funktioniert. Derzeit darf jeder Benutzer alles – egal welche Rechte er haben soll.

Die letzte Maske im Web-Frontend kann die Dienste (Paketfilter, IPsec, DNS, DHCP, IDS) aktivieren. Als Schutz vor Fehlkonfigurationen des Paketfilters, mit denen sich der Administrator selbst aussperrt, muss er innerhalb von 30 Sekunden nach dem Start des Paketfilters diesen Start bestätigen. Andernfalls werden sämtliche Filterregeln deaktiviert. Da das Web-Frontend die angezeigten Informationen nicht aktiv ändern kann, steht die Maske mit der Bestätigung des Starts auch nach den 30 Sekunden unverändert im Browser. Der Administrator sollte sich davon nicht verwirren lassen.

Technische Feinheiten

Die Microliss-Firewall sieht von außen aus wie ein kleiner Switch, tatsächlich verbirgt sich in ihr jedoch ein normaler PC mit einer Flashdisk und drei RTL8139-Netzwerkkarten. Das Betriebssystem liegt als »initrd« vor und wird während der Initialisierung des Kernels in den RAM geladen. Die Partitionierung des System zeigt Tabelle 1.

Das System nutzt den Linux-Kernel 2.2.18 mit Patches für »ip_masq_vpn« und »FreeS/Wan 1.95«. Telco-Tech hat noch zwei weitere Kernel-Patches eingebaut: Das erste modifiziert den Blockgeräte-Treiber so, dass abhängig vom Status am zweiten seriellen Port der Read-only-Modus aktiviert wird. Das zweite überprüft mit einer MD5-Summe das Programm »/sbin/init« auf Veränderungen. Für Netzwerkkarten ist der neuere Treiber »rtl8139too« zuständig.

Der Kernel enthält leider kein Openwall-Patch; es würde unter anderem verschiedene Rechte im »/proc«-Verzeichnis verändern, den User-Stack sichern, Symlinks und FIFOs in »/tmp« einschränken und die Eigenschaften der File-Deskriptoren Null, Eins und Zwei verändern. Mit einem solchen Patch sind mögliche Schwachstellen in den eingesetzten Programmen weniger kritisch.

Da nur sehr wenige Programme auf dem System installiert sind, können der Administrator und der Hersteller sehr leicht den Überblick über Probleme in der Software behalten. Tabelle 2 gibt einen Überblick über die eingesetzten Pakete, die nicht von Telco-Tech stammen.

Interner SNMP-Daemon

Auf den ersten Blick fällt der SNMP-Daemon auf, besonders nach den Sicherheitsproblemen in verschiedenen SNMP-Programmen[4]. Der Webserver ist statisch gegen die SNMP-Bibliothek gelinkt. Da er die Konfigurationsdateien schreiben muss, obwohl er unter einer unprivilegierten User-ID arbeitet, verwendet der Webserver SNMP-Aufrufe für die Kommandos, die Root-Rechte benötigen. Der SNMP-Daemon ist vom Paketfilter geschützt und wird nur für diesen internen Zweck verwendet, obwohl das White Paper eine “Schnittstelle für die Kommunikation mit beliebiger SNMP-fähiger Clientsoftware” anpreist. Auf der Firewall sind keine Client-Programme wie »snmpwalk« installiert.

Sehr positiv ist, dass Telco-Tech als DNS-Forwarder das Programm »djbdns« verwendet und nicht den großen, relativ problematischen und in diesem Fall mit unnötigem Funktionsumfang ausgestatteten »bind«.

Der Webserver mit der Administrationssoftware ist eine Eigenentwicklung. Alle Masken sind in den Server integriert, er unterstützt keine CGIs. Als SSL-Wrapper dient »ucspi-ssl«. Da der Webserver nicht in ein Chroot-Jail eingesperrt ist, hängt die Sicherheit ausschließlich an den programmierten Web-Anwendungen. Man kann nur hoffen, dass das Programm die vom Benutzer abgefragten Zeichenketten sauber prüft, damit zum Beispiel keine Verzeichnisse ausgelesen werden können, etwa mit »https:// firewall/../../../../« oder mit ähnlichen Unicode-kodierten Strings.

Fazit

Das Design der Firewall und die verwendeten Softwarekomponenten machen einen soliden Eindruck. Über die Qualität der von Telco-Tech programmierten Software ist keine Aussage möglich, da sie nicht im Quellcode vorliegt.

Ihr Aufbau prädestiniert die Firewall für den Einsatz in kleineren Unternehmen, man muss sie nur auspacken und konfigurieren – der Installationsprozess entfällt. Beachten muss der Administrator, dass er physischen Zugang zu dem System haben muss, um die Pins für eine Umkonfiguration umzustecken. Die Firewall sollte physisch gesichert werden, denn über die serielle Schnittstelle können die IP-Adressen und Netzmasken einfach modifiziert werden.

Ihr Einsatzgebiet ist relativ begrenzt, da die Microliss fast ausschließlich ein Paketfilter mit VPN-Anbindung ist. Ausnahmen bilden nur das DNS-Forwarding und der DHCP-Server, es sind aber keine Proxies vorhanden. Sie ist daher nur als Internet-Gateway mit nicht allzu hohen Sicherheitsanforderungen einzusetzen oder als Gateway zwischen LAN, Internet und DMZ. Für diese Aufgabe ist die Microliss aber sehr gut vorbereitet.

Sinnvoll, aber nicht vorhanden, wären Mechanismen zur Hardwarekontrolle. Da der Admin nicht so einfach Einblick in das Gerät hat, wären »lm_sensors« oder »SMART« vorteilhaft. (fjl)

Tabelle 1: Dateisysteme

Tabelle 1: Dateisysteme

Tabelle 2: Installierte Software

Tabelle 2: Installierte Software

Microliss

Hersteller: Telco-Tech GmbH

Preis: ca. 1 720 Euro

Lizenz: keine Limits für die Anzahl der Benutzer oder verwendeten Server

Größe: 24 x 14 x 5,5 cm

Interfaces: dreimal Fast Ethernet, ein serielles Interface

Funktionen: Paketfilter, NAT, VPN, IDS, DSL-Router, DHCP, DNS-Relay

Version: ml300-v0.5rel1.0-std

Service: lebenslanger Update-Service

Infos

[1] Microliss: [http://www.microliss.de]

[2] FreeS/Wan: [http://www.freeswan.org]

[3] Snort: [http://www.snort.org]

[4] “Fehler in SNMP-Implementierungen”, Linux-Magazin 04/02, Seite 14, und “InSecurity-News” in dieser Ausgabe

Der Autor

Stephan Müller arbeitet seit Mai 2001 für die Atsec Information Security GmbH als Netzwerk-Security-Consultant. Im Bereich Linux hat er Skripte für die Nutzung des Linux-Traffic-Control-Subsystems zusammen mit einem Paketfilter geschrieben [http://www.chronox.de/]. Außerdem arbeitet er am Open-Source-Projekt Sitar mit [http://sitar.berlios.de/].

LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben