Ipcop

IPCop
IPCop-Logo
Basisdaten
Entwickler	IPCop-Team
Version	1.4.21 (23. Juli 2008)
Abstammung	\ Smoothwall   \ IPCop (bis 1.3.0) \ Linux From Scratch   \ IPCop (seit 1.4.0)
Architekturen	i386
Größe	50,0 MB (ISO)
Startmedium	Festplatte, USB-Stick, CompactFlash
Lizenz	GPL
Sonstiges	Preis: kostenlos Sprache: mehrsprachig
Website	www.ipcop.org

IPCop ist eine freie Linux-Distribution, die in erster Linie als Router und Firewall fungiert. Darüber hinaus bietet die Distribution noch ausgewählte Server-Dienste an und kann um zusätzliche Funktionen erweitert werden. IPCop basierte bis zur Version 1.3.0 auf der freien GPL-Version von Smoothwall, seit der Version 1.4.0 basiert IPCop auf Linux From Scratch (kurz LFS).

Server-Dienste

Der IPCop stellt direkt nach der Installation einen Router, eine funktionierende Firewall, einen Proxyserver (Squid), einen DHCP-Server, einen Caching-Nameserver (dnsmasq) sowie ein Intrusion Detection System (Snort) bereit. Weitere Funktionen wie Traffic-Shaping, VPN und Dynamic DNS sind vorhanden.

Systemvoraussetzungen

Die benötigte Rechenleistung des PCs richtet sich nach dem Einsatzbereich. Erforderlich sind 133 MHz mit 32 MByte RAM (besser 64 MByte). Es werden mindestens 2 Netzwerkkarten benötigt (PCI, PCMCIA, USB, ISA oder VL-Bus), eine für den Anschluss von DSL (oder anderen Router), eine zum Anschluss ans LAN.

Die Rechenleistung bei privatem Gebrauch kann bereits ein 486er übernehmen, wenn man Squid und das Intrusion Detection System (IDS) abschaltet.

Schnittstellen

Firewall-Regeln der Schnittstellen

IPCop unterscheidet zwischen unterschiedlichen Netzwerken, die verschiedenfarbig dargestellt werden. Das grüne Netzwerk stellt das eigene LAN dar, das rote Netzwerk symbolisiert das „ungeschützte“ Internet. Ein eventuell vorhandenes WLAN wird durch die Farbe Blau symbolisiert, während orange die DMZ (Demilitarized Zone) darstellt. Diese wird für Server verwendet, die aus dem Internet erreichbar sein sollen (Webserver, FTP-Server, etc.). Würde nun dieses Netzwerk erfolgreich angegriffen (kompromittiert), sind die anderen Netzwerke davon unabhängig geschützt.

Für jedes Netzwerk, das verwendet wird, wird eine eigene Netzwerkkarte mit IP-Adresse benötigt. Es ist nicht erforderlich, jedes Netzwerk zu verwenden. Ist kein WLAN vorhanden, existiert einfach kein blaues Netzwerk. Ist kein Webserver (o. ä.) vorhanden, wird keine DMZ, also kein oranges Netzwerk benötigt.

Web-Schnittstelle

Konfiguriert wird der IPCop über eine Webschnittstelle, zu erreichen über http://SERVERNAME:81 oder über SSL auf https://SERVERNAME:445, alternativ zum Servernamen auch über dessen IP-Adresse.

Über diese Webschnittstelle werden dann Dinge wie Port-Weiterleitung, öffnen von Ports (externer Zugang), Proxy- und DHCP-Server, aber auch DDNS (Dynamisches DNS), Traffic-Shaping, IDS und Zeitserver (NTP) konfiguriert. Des Weiteren erhält man über die Webschnittstelle Zugriff auf die verschiedenen Log-Dateien und deren Auswertungen, die als Grafiken bereitgestellt werden.

Auf die Unix-Shell kann der Benutzer (und Linux-Kenner) auch zugreifen, um tiefergehende Konfigurationen zu erstellen oder zu ändern. Dies ist aber nur selten nötig. Der Zugriff erfolgt hierbei dann per SSH auf dem (bewusst vom Standard abweichenden) Port 222 (statt 22).

Die Möglichkeiten des IPCop lassen sich über Add-Ons deutlich erweitern und den individuellen Bedürfnissen des Netzwerks anpassen. Als Beispiel seien hier genannt:

• ein URL-Filter,
• der beliebte Dateimanager mc (Midnight Commander),
• der Editor Joe,
• ein Layer-7-Filter,
• P2P-Blocks über Content-Filtering,
• Virenscanning von Mails und Websites,
• QoS-Add-Ons,
• oder auch ein Advanced Proxy.

Verweise zu mittlerweile wöchentlich erscheinenden Erweiterungen sind auf der offiziellen Website von IPCop zu finden.

Sicherheitsaspekte

IPCop leistet für viele Installationen gute Dienste und ist darüber hinaus eine sehr vielseitige und auch anpassbare Firewall-Distribution – doch gerade hier wird ein Kompromiss zwischen Leistungs- bzw. Funktionsumfang und Sicherheit versucht. Das Resultat ist eine aus Sicherheitsaspekten relevante Designschwäche des Systems. Für Firewalls gilt „keep things simple“ (im Sinne von: „man halte die Dinge einfach“) und „do a few things well“ (im Sinne von: „man mache nur ein paar Dinge, die aber gut“), das bedeutet, eine Firewall sollte aus so wenig Hardware, Code, Modulen, Teilsystemen usw. bestehen wie nur möglich; diesem Teilaspekt wird IPCop nicht ganz gerecht.

• Da die meisten Angriffe von innen erfolgen, ist die Modularität bereits ein erstes Problem: einem modularen System könnten, in einer unbeobachteten Minute, schnell manipulierte Module untergeschoben werden, und schon hat ein Angreifer Zugriff auf die gesamte Sicherheitsarchitektur.
• Ein weiteres Problem ist der reichhaltige Funktionsumfang: bereits mit der Grundinstallation wird z. B. ein für die Firewall-Funktionen nicht notwendiger Webserver mitsamt Webschnittstelle, die sogar Grafiken bereitstellt, installiert. Bei sichereren Systemen ist die Benutzeroberfläche (GUI) als separate Anwendung auf einen separaten Rechner ausgelagert und verändert die Konfigurationsdateien per gesichertem Filetransfer, z. B. mit SSH-Copy (SSH ist ja bereits installiert). Die Filetransfer-Funktion der Firewall (SSH-Server) lässt sich, wenn sie nicht benötigt wird, natürlich auch abschalten. Das gleiche gilt sinngemäß auch für den NTP-Server (und andere); auch diese sind nicht unbedingt notwendig und könnten für Angriffe ausgenutzt werden. Noch extremer verhalten sich aber die Add-Ons, wie z. B. Samba^[1], die jede Menge zusätzliche Angriffsflächen schaffen, gerade wenn man bedenkt, dass viele Angriffe von innen erfolgen.

Obwohl es für den hochsensiblen Bereich bessere (minimalistischere) Lösungen gibt, bleibt IPCop ein gutes und sinnvolles Produkt gerade dort, wo Sicherheit, Komfort, Energieverbrauch, Platzbedarf und weitere Attribute konkurrierend bedient werden müssen.

IPCop in virtueller Maschine/User Mode Linux

Die Zeitschrift c't aus dem Heise-Verlag hatte mit Ausgabe 04/2005 im Rahmen eines Server-Projekts den c't-Debian-Server^[2] vorgestellt, in dem IPCop in User Mode Linux (UML), einer virtuellen Maschine unter einem umfangreich ausgestatteten Linux-Home-Server-System mit vielen Services wie Samba, CUPS oder E-Mail läuft. Dies spart einen zweiten Rechner für die Firewall ein, wird von vielen Fachleuten jedoch als unsicher eingestuft, da ein Angreifer die Kontrolle über den virtuellen Host übernehmen könnte und so das UML sowie die Firewall aushebeln könnte.^[3] In der aktuellen Version des c't-Servers^[4] wurden diese Risiken durch den Einsatz von Xen und zwei darauf basierenden virtuellen Servern (Linux-Home-Server-System; Endian Firewall) verringert. Das Risiko ist nicht auszuschließen, aber die Angriffswege sind recht unwahrscheinlich:

• Der Angreifer findet und nutzt einen Fehler im Bridging-Code zur virtuellen Maschine und hat damit direkte Kontrolle über den Rechner erlangt. Der Bridge-Code soll die Daten nur zwischen den Netzwerken weiterreichen, ohne in irgendeiner Art die Daten zu interpretieren. Damit sollte der Bridge-Code eigentlich nicht über das Netzwerk angreifbar sein.
• Der Angreifer findet und nutzt einen Fehler im IPCop, um Kontrolle über die virtuelle Maschine zu erlangen, und greift dann mit „bewährten Mitteln“ über das Netzwerk den Rechner an. Dieses Szenario ist der GAU für eine Firewall, bei dem die Firewall selbst vom Angreifer für einen Angriff benutzt wird. Hier besteht auch kein Unterschied mehr zwischen einer Firewall auf eigener Hardware und einer Firewall in einer virtuellen Maschine.
• Der Angreifer findet und nutzt einen Fehler im IPCop, um Kontrolle über die virtuelle Maschine zu erlangen, und findet und nutzt dann einen Fehler im User Mode Linux, um aus der virtuellen Maschine auszubrechen, und schließlich findet und nutzt einen Fehler im Host-Betriebssystem (das direkt auf der Hardware läuft), um die Kontrolle über den Rechner zu erlangen. Drei kaskadierte Fehler sind sehr unwahrscheinlich. Auch hier tritt wieder der Firewall-GAU auf, der Angreifer nutzt die Firewall als Plattform für einen weiteren Angriff.

Ein deutlich höheres Risiko besteht jedoch, wenn neben der Firewall weitere Server-Anwendungen (insbesondere Webserver) auf der gleichen Hardware laufen, wie es auch im c't-Debian-Server (aber auch durch die zahlreichen Add-ons innerhalb von IPCop) der Fall sein kann. Ein Angreifer, der durch einen Fehler in diesen Server-Anwendungen innerhalb der virtuellen Maschine Administrator-Rechte erlangt, könnte durch einen weiteren Fehler in der Virtualisierungssoftware auch Administrator-Rechte im Hostsystem bekommen. Dann ist auch der Weg zur Modifikation der virtuellen Maschine der Firewall frei. Da gerade in Webservern ständig Fehler gefunden werden, müsste man auf die Fehlerfreiheit der im Allgemeinen recht komplexen Virtualisierungssoftware bauen (dies gilt für UML, aber genauso für z. B. VMware, Xen, QEMU). Dies ist durchaus kein unrealistisches Szenario, Firewalls in virtuellen Maschinen sollten deshalb nur dann eingesetzt werden, wenn man wirklich weiß, was man tut.

VM-Vorteile

Trotz aller berechtigter Kritik, haben Firewalls, die als VM installiert sind, auch Vorteile. Einige, wie die leichte Portierbarkeit und die daraus resultierenden kurzen Ausfallzeiten, die Möglichkeit mehrere Instanzen zu installieren und dann mit wesentlich übersichtlicheren und einfacheren Regelsätzen zu arbeiten oder auch die Kombination verschiedener Firewall-Features die üblicherweise nicht vorgesehen sind, wurden anderweitig bereits kontrovers diskutiert.

Vorbemerkungen: Generell muss solide Hardware verwendet werden (optimaler Weise baut man den Host aus den gleichen Hardware-Komponenten die auch emuliert werden). Überladene Host-Betriebssysteme wie Windows sind unbedingt zu vermeiden – weniger ist hier mehr. Sinnvoll sind – das gilt für den VM-Host gleichermaßen wie für die Firewall-Installation – "schlanke" Installationen/Distributionen, die alles weg lassen, was nicht unbedingt gebraucht wird (Keine unnützen Scriptsprachen, Kompiler, Tools, Dienste, X-Server, KDE, Gnome usw.).

• Ein weniger beachteter zentraler Punkt ist der Betriebssystem-Kernel. Vereinfacht gilt: je mehr Zeilen kompiliert werden, um so fehleranfälliger ist ein System. Da bei Virtualisierungen wie dem VM-Ware Server standardisierte Hardware emuliert wird, z. B. eine Intel-basierte Gigabit Netzwerkkarte (und keine 100 verschiedenen Billigkarten), kann der Kernel auf viele Treiber verzichten und folglich aus weniger, aber dafür gut geprüften Treibern bzw. Zeilen bestehen. Auch kann der Kernel bereits Distributions-seitig ohne Modul-Unterstützung kompiliert werden, was ein zusätzlicher enormer Sicherheitsvorteil ist.

Man könnte zwar sagen, dass dies das Problem vom Firewall-Betriebssystem in das Host-Betriebssystem der VM verlagert, jedoch stimmt das nicht ganz. Bei den meisten Firewalls, wie auch bei IP-Cop, ist das TCP/IP-Protokoll aus verschiedenen Gründen an die Netzwerkkarten gebunden, und folglich das Firewall-System per TCP/IP angreifbar. Beim Host-Betriebssystem der VM ist das TCP/IP-Protokoll weder notwendig und meist auch gar nicht sinnvoll – hier braucht glücklicherweise kein Protokoll an die Karte gebunden zu werden. Angriffe per TCP/IP auf des Host-Betriebssystem der VM sind also so einfach gar nicht möglich.

Installation

Ein fertiges ISO-Abbild für eine Boot-CD ist auf der Website erhältlich. Sollte man kein CD-ROM-Laufwerk in seinem PC haben, kann man auch mit Boot-Diskette starten und die restlichen Daten über HTTP/FTP-Server herunterladen.

Die Installation gestaltet sich auch für Linux-Laien als sehr einfach, da sie weitestgehend selbständig abläuft und von Anfang an eine sichere Grundkonfiguration bietet.

Prinzip: Vom eigenen Netzwerk zum Internet ist alles offen, vom Internet ins eigene Netzwerk ist alles geschlossen.

Grundsätzliches Know-How in Sachen Netzwerk und Protokolle ist beim Benutzer dennoch nötig.

Versionen

<= 1.3.0 Version Datum 0.0.9 28. Dezember 2001 0.1.0 3. Januar 2002 0.1.1 22. Januar 2002 1.2.0 27. Dezember 2002 1.3.0 22. April 2003

>= 1.4.0 Version Datum 1.4.0 1. Oktober 2004 1.4.1 21. November 2004 1.4.2 16. Dezember 2004 1.4.4 15. März 2005 1.4.5 30. März 2005 1.4.6 11. Mai 2005 1.4.8 26. August 2005 1.4.9 4. Oktober 2005 1.4.10 9. November 2005 1.4.11 23. August 2006 1.4.12 16. Januar 2007 1.4.13 16. Januar 2007 1.4.14 3. März 2007 1.4.15 9. März 2007 1.4.16 17. Juli 2007 1.4.17 1. Dezember 2007 1.4.18 1. Dezember 2007 1.4.19 22. Juli 2008 1.4.20 22. Juli 2008 1.4.21 23. Juli 2008

>= 1.5.0 Version Datum 1.5.0 Noch nicht erschienen

Weblinks

• IPCop-Homepage
• SourceForge-Projekt

Hilfen

• Dokumentationen
• Tutorials von Ecki Gutzeit
• Mailing-List der Entwickler (englisch)
• ein Wiki, welches sich ausschließlich mit dem IPCop beschäftigt
• Professioneller Internet-Router im Eigenbau

Modifikationen und Dienstprogramme

• Endian_Firewall Ein friendly Fork von IPCop, mit dem Focus auf umfassende Gateway-Sicherheit
• IPFrog Add-ons – Samba und weitere Add-ons für IPCop (1.4.2 & höher)
• Tools von Tom Eichstaedt
• IPCop Addon Datenbank
• Firewall-AddOns
• Cop Filter – Erkennt und entfernt Viren so wie Spam aus E-Mails und Internet Traffic (SMTP, POP3, FTP, HTTP)
• URL Filter
• Advanced Proxy
• MH AddOns
• UPS Server AddOn von Stephan Feddersen
• OpenVPN-AddOn für IPCop (Zerina)
• OpenVPN/Zerina-Forum
• embcop – ipcop on embedded pc

Literatur

• Marco Sondermann: IPCop kompakt: Mehr Sicherheit für Ihr lokales Netz dank des freien Firewall-Systems. Bomots Verlag, 2008, ISBN 978-3-9393-1641-1. 

Einzelnachweise

1. ↑ Sicherheitslücke in Datei- und Druckserver Samba geschlossen, heise.de, 11. Dezember 2007
2. ↑ c't-Debian-Server aus Heft 04/2005
3. ↑ Artikel bei IPcop-Forum.de
4. ↑ c't-Debian-Server aus Heft 14/2007