Login
Newsletter
Werbung

So, 12. Februar 2006, 00:00

Simple Security Policy Editor

Der Unterschied zwischen Information und Desinformation ist nicht virtuell.

Simple Security Policy Editor, im Folgenden sspe genannt, ist eine verteilte Firewall mit FreeSwan IPSec-VPN für Linux ab 2.4.x-Kerneln. Aus Text-Steuerdateien werden Netfilter-Kommandos generiert, BSD-Filter und Router-Accesslisten sind noch zu integrieren. Mehrere Jahre Betriebserfahrung zeigten Effektivität und Stabilität.

Larry Ewing

Hintergrund

Diese kleine Vorgeschichte soll das Verständnis der komplexen Thematik erhöhen. Will der geneigte Leser direkt zum Kern kommen, möge er bitte sofort zum zweiten Abschnitt vorblättern.

ipfwadm

Als ich 1998 in die interne DV-Abteilung der deutschen Filiale eines europäischen IT-Herstellers wechselte, hatte ich meinen Bellovin als wichtigstes Buch zum Thema Sicherheit verinnerlicht und kannte Linux seit einigen Jahren im Zusammenhang mit DNS- und Webservern. Die benutzten Geräte wurden stets durch ipfwadm-Kommandos in Shellskripten geschützt, Flexibilität war aufgrund geringer Änderungshäufigkeit nicht notwendig. RFCs, Bücher und die Linux-Kernel-Quellen hatten mir etwas Verständnis von IP ermöglicht. Meine Ansicht, daß dies alles elektrisch sei, wurde dennoch nicht von allen Kollegen geteilt. ;-)

Die wichtigste Forderung an Linux-Firewalls war neben der zu erbringenden Sicherheit deren einfache Handhabung im Sinne von Änderungen des Regelwerks, um die vielfältigen Erfordernisse des alltäglichen IT-Betriebes zu erfüllen. Mein Ansatz, alle erforderlichen Daten in einfachen ASCII-Dateien zu sammeln, ergab mit Dialog und Shellskripten eine LPFC (Linux Packet Firewall Configurator) genannte Lösung, die den harten Anforderungen des Alltags gewachsen war und vereinzelt bis heute im Einsatz ist. Sie wurde nicht veröffentlicht. Ausgehend von einer Datei hostnet (Format: name IP/Netzmaske) mit Definitionen der beteiligten Netz- und Hostadressen und einer anderen Datei mit dem Regelwerk mit einfacher Syntax (Format: source destination direction protocol port action options) wurde ein Shellskript erstellt, welches die ipfwadm-Kommandos sofort und bei jedem Boot absetzte. Insbesondere die Möglichkeit, Pakete aufgrund einer solchen Regeloption zu loggen, erwies sich als Entstörungsmaßnahme sehr nützlich. Die Einschränkungen durch die Verwendung von ipfwadm wurden durch die Kompatibiltätsmodi der späteren Kernel und entsprechende Wrapper aufgehoben.

ipchains

1999 war die neue stabile Kernelversion 2.2 da. Neue Funktionalitäten brachte das Userlandprogramm ipchains. Aus konservativen Überlegungen heraus verzichtete ich lange Zeit auf Anpassungen in meinen Skripten. Als ich dann wenig später las, daß ipchains sowieso nur als Übergangslösung gedacht sei, bis eine weitere, nochmals neue Version des Filterns von IP-Paketen als Ablösung fertig sei, entschied ich endgültig, auf ipchains bei meiner Arbeit und in meinen Entwicklungen zu verzichten und bis zur nächsten stabilen Kernelversion 2.4 zu warten. Bei dem Versuch, mittels Gibraltar eine VPN-Verbindung aufzubauen, hatte ich 2001 erneut Kontakt mit ipchains und dies jedoch schnell aufgrund von Zeitmangel aufgegeben, um mich ganz der bis heute aktuellen Netfilter-Architektur auf Linux zu widmen...

iptables

Mein Arbeitgeber verkaufte Ende 2001 einen Teil seiner Firma. Hieraus ergab sich die für mich aufregende Aufgabenstellung, das lokale Netzwerk der Zentrale ebenfalls zu teilen, etwa die Hälfte der Serverlandschaft sollte die IP-Nummern wechseln und das Ganze physikalisch getrennt werden. Lediglich ein einziger Netzwerkübergang wurde für eine Übergangszeit gestattet. Dieser war einfach durch die oben beschriebene Architektur zu bewerkstelligen. Ein anderer Aspekt der Teilung war, an den sechs bestehenden Standorten die jeweilig vorhandenen Strukturen unter allzeitiger Wahrung der Konnektivität ebenfalls zu teilen, um anschließend diese wieder miteinander zu verbinden.

Es existierten bereits kommerzielle Produkte mit zentraler Administration, die Filtermechanismen für beliebig viele Firewalls erzeugen und verteilen konnten. Eine unternehmensweite und damit konsistente Filterung dank automatischer Erzeugung faszinierte mich, die Kosten sprachen sehr dagegen. Daher machte ich den Vorschlag, ein ähnliches Konzept mit Linux in Eigenleistung zu erbringen. Einige Diskussionen später waren meine Vorgesetzten überzeugt, auf dem richtigen Weg zu sein: die Kosten der kommerziellen Lösung verglichen mit den avisierten Einsparungen bereiteten auch dem Finanzverantwortlichen Vergnügen.

Die Kernelversion bewegte sich etwas oberhalb von 2.4, stabil genug, um in produktiver Umgebung mit Sicherheitsbedürfnissen eingesetzt zu werden. Netfilter mit iptables war angesagt; mir unbekanntes Neuland, aber ich war bereit, Über- und Lesestunden auch an Wochenden zu leisten. Schnell füllte sich ein Ordner mit HOWTOs, READMEs und anderen Dokumenten zum Thema. Einige Dutzend PC wurden gekauft, zwecks Hardware-Backup fast doppelt so viele wie nötig. Da Manager ungern ohne Netz und doppelten Boden arbeiten, musste eine Linuxversion mit kommerziellem Support zum Einsatz gebracht werden. Also wurde die Geschmacksrichtung Roter Hut gewählt. Die Güte bzw. Qualität der Supportleistungen sollte sich erst später erweisen.

Kommentare (Insgesamt: 0 )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung