Institutsfirewall
Der digitale Türsteher vom (Zentralen Informatik-)Dienst

von Ulrich Kiermayr (Ausgabe 03/2, Oktober 2003)

 

Kasten: SQL Slammer

Kasten: Wie filtert eine Firewall?

 

Die Bedrohung für die Rechner im Netz durch Angriffe von HackerInnen, Viren, Würmern und Trojanern hat in den letzten Jahren stetig zugenommen: Mit dem raschen Wachstum des Internet ist auch die Zahl der erfolgreichen Einbrüche in Computersysteme sprunghaft angestiegen, und die rasante Verbreitung von Schädlingen wie I love you, Code Red, SQL Slammer oder W32.Blaster hat gezeigt, wie schnell ein kleiner Fehler in einem weitverbreiteten Softwareprodukt zu einer globalen Gefahr werden kann.

Am Beispiel des SQL Slammer (siehe Kasten unten) wird auch deutlich, daß es im Ernstfall nur weniger verseuchter PCs bedarf, um für die gesamte Universität den Internetzugang lahmzulegen: An der Uni Wien waren insgesamt rund 30 Rechner infiziert. Da die Computersysteme der Universität durchwegs gut (oft mit 100 Mbit/s) an das Uni-Datennetz angebunden sind, können diese 30 Rechner gemeinsam bis zu 3 Gbit/s an Datenverkehr verursachen - das ist etwa das Zwölffache der gesamten Internet-Bandbreite der Uni Wien.

 

SQL Slammer

Im Jänner 2003 wurde das Internet vom SQL Slammer heimgesucht. Dieser Wurm macht sich eine Schwachstelle des Microsoft SQL Server zunutze (Details siehe http://www.cert.org/advisories/CA-2003-04.html) und ist in der Lage, mit nur einem Datenpaket einen fremden Server zu infizieren und sich weiterzuverbreiten. Er verursacht zwar auf den befallenen Servern keinen weiteren Schaden, beginnt sich aber sofort selbst zu kopieren und wahllos an andere Rechner zu verschicken, in der Hoffnung, auch diese zu infizieren. Eine Rückmeldung ist nicht notwendig, da er nur ein einziges Datenpaket versenden muß.

Der SQL Slammer verbreitete sich mit unglaublicher Geschwindigkeit. Innerhalb von nur 15 Minuten (!) stieg das Verkehrsaufkommen im Internet auf ein Vielfaches an. Infolge der Überlastung brachen viele Router zusammen; zahllose Rechner waren aufgrund hoffnungslos verstopfter Datenleitungen nicht mehr erreichbar. Da sich der Vorfall an einem Samstag ereignete, waren zwar einerseits weniger Angriffsziele verfügbar (viele PCs sind am Wochenende abgeschaltet), andererseits benötigten dadurch aber auch die Gegenmaßnahmen wesentlich mehr Zeit.

Besonders bitter war der Umstand, daß der Softwarefehler im SQL Server, der das Desaster ermöglichte, schon seit Monaten bekannt und eine entsprechende Programmkorrektur (Patch) verfügbar war. Dennoch hatten es viel zu viele ServerbetreiberInnen verabsäumt, den Patch in ihr System einzuspielen, und waren somit dem Wurm schutzlos ausgeliefert

Wozu eine Firewall?

Wie bereits im Titel angedeutet, fungiert eine Firewall gewissermaßen als "Torwächter" im Internet, wobei zwischen Personal Firewalls, die einzelne PCs schützen, und netzwerkbasierten Firewalls, die ganze (Sub-)Netze absichern, unterschieden wird.1) Aus Benutzersicht teilt eine Firewall das Internet in eine geschützte "innere" Zone und eine ungeschützte "äußere" Zone und filtert den Datenverkehr zwischen diesen beiden Bereichen anhand sogenannter Zugriffsregeln. Näheres dazu finden Sie im Kasten Wie filtert eine Firewall?.

Der Zentrale Informatikdienst betreibt etliche Firewalls, die z.B. die zentralen Server der Uni Wien, die Rechner des ZID und die PCs der uniADSL-Benutzer gegen Angriffe aus dem Internet abschirmen. Diese Firewalls verzeichnen (und blockieren) praktisch ununterbrochen unerlaubte Zugriffe. Hochgerechnet auf alle Rechner im Uni-Datennetz - auch die ungeschützten - kommt man auf etwa 5 Millionen "Angriffe" an einem durchschnittlichen Tag. Dies entspricht einem unerlaubten Zugriff pro 5 bis 10 Minuten auf jeden einzelnen PC im Uni-Datennetz.

Firewalls können im Falle gezielter Attacken, aber auch bei breit angelegten Angriffen (wie dem des SQL Slammer) äußerst wertvolle Dienste leisten, was letztendlich allen NetzwerkteilnehmerInnen - nicht nur den direkt betroffenen - zugute kommt. Idealerweise sollten daher alle Subnetze der Universität Wien entsprechend abgesichert sein (von den 30 Rechnern, die vom SQL Slammer infiziert waren, befand sich kein einziger hinter einer vom Zentralen Informatikdienst betreuten Firewall).

Der Betrieb und die Wartung einer Firewall gestaltet sich in der Praxis aber leider eher mühsam und erfordert einige Fachkenntnisse; darüber hinaus ist eine leistungsfähige Firewall auch in der Anschaffung nicht gerade billig. Aus diesen Gründen bietet der Zentrale Informatikdienst jenen Instituten, die den Schutz einer Firewall zwar brauchen, diese aber nicht selbst betreiben können oder wollen, das neue Service Institutsfirewall an.

Die Institutsfirewall des ZID

Die vom ZID betriebene Institutsfirewall ist eine leistungsfähige, netzwerkbasierte Hardware-Firewall, mit deren Hilfe komplette Institutsnetzwerke abgeschirmt werden können.

Im wesentlichen handelt es sich dabei um einen Router mit integriertem Paketfilter (siehe Kasten Wie filtert eine Firewall?).Die Zugriffsregeln werden gemeinsam mit dem Institut ausgearbeitet, um einerseits eine optimale Sicherheit zu bieten, andererseits aber auch die Bedürfnisse der InstitutsmitarbeiterInnen zu berücksichtigen. So ist es beispielsweise durchaus möglich, einzelne Netzwerkservices des Instituts (Webserver, FTP-Server, ...) nach außen freizugeben, sofern diese tatsächlich vom Institut selbst betrieben werden müssen. Allerdings sollte hierbei genau überlegt werden, ob die Services nicht auch sinnvoll in die vom ZID angebotenen Netzwerkdienste integriert werden könnten. Zu einem späteren Zeitpunkt soll außerdem für Institutsangehörige die Möglichkeit geschaffen werden, mittels Mailbox- bzw. Unet-UserID von außen Zugang zum geschützten Bereich zu erhalten.

Voraussetzungen

Um die Institutsfirewall des ZID für ein Institut realisieren und einen reibungslosen Betrieb gewährleisten zu können, müssen einige technische und administrative Voraussetzungen erfüllt sein:

  • Das Institut muß über eine VLAN-fähige Verbindung an das NIG angebunden sein - Institute mit gerouteter Verbindung können dieses Service derzeit nicht in Anspruch nehmen. Das betrifft derzeit noch ca. 15 Universitätsstandorte, die allerdings im Laufe der nächsten Monate ebenfalls mit einer entsprechenden Anbindung versehen werden sollen, sodaß die Institutsfirewall in absehbarer Zeit flächendeckend verfügbar sein wird.
  • Das Institut muß über einen einzigen, eigenen, zusammenhängenden IP-Adreßbereich verfügen (oder die IP-Adressen im Zuge der Firewall-Implementierung umstellen).
  • Aus administrativen Gründen werden nur komplette Institutsnetzwerke durch die Firewall abgeschirmt. Die Anmeldung erfolgt durch den Institutsvorstand per Formular, die Umsetzung in Zusammenarbeit mit den EDV-BetreuerInnen des Instituts.
  • Um bei Problemen effektiv und schnell reagieren zu können, müssen alle Rechner des Instituts mit Standort (jener Ort, an dem der Rechner hauptsächlich zu finden ist - bei Notebooks z.B. das Büro des Besitzers), IP- und MAC-Adresse sowie Kontaktperson(en) registriert werden. Auch Änderungen dieser Daten und neue Rechner sind zu melden: derzeit per eMail an die Adresse hostmaster@univie.ac.at; eine entsprechende Webmaske ist in Entwicklung.
  • Für Server (d.h. Rechner, die Dienste über die Firewall hinaus freigeben) sind zumindest zwei Kontaktpersonen erforderlich.
  • Die Benutzungsordnung für die Institutsfirewall ist einzuhalten.

Wir sind bemüht, in jedem einzelnen Fall die optimale Lösung zu finden und die Unterbrechungen, die sich aus der Installation der Institutsfirewall ergeben, so kurz wie möglich zu halten. Daher wird jeder Fall mit den zuständigen EDV-Beauftragten des Instituts genau analysiert, was mitunter einige Zeit in Anspruch nehmen kann.

Was kann die Institutsfirewall nicht?

Auch einer Firewall sind Grenzen gesetzt - sie leistet zwar einen wesentlichen Beitrag zur Erhöhung der Sicherheit, ist aber kein Allheilmittel. Ein optimaler Schutz läßt sich nur durch eine Kombination mehrerer Maßnahmen erreichen.

  1. Eine Firewall sieht nur den Datenverkehr zwischen innen und außen.
    Wenn Angriffe auf Rechner innerhalb der geschützten Zone von einem Rechner ausgehen, der sich ebenfalls innerhalb dieser Zone befindet, kommen sie mit der Firewall nicht in Berührung und können daher von ihr auch nicht verhindert werden. Aus diesem Grund ist es trotz Firewall unumgänglich, auf die Sicherheit jedes einzelnen Rechners im internen Netz zu achten - d.h. Patches einzuspielen und die lokalen Virenscanner aktuell zu halten. Besonders wichtig ist dies bei Rechnern, die Serverdienste anbieten (vgl. Punkt 4).
  2. Eine Firewall verhindert in der Regel nur Zugriffe, die von außen initiiert werden.
    Viren, Trojaner usw., die BenutzerInnen aktiv von außen anfordern (z.B. Schädlinge in eMail-Nachrichten, die vom Mailserver abgeholt werden), werden üblicherweise nicht blockiert. Ein typisches Beispiel dafür ist der Sobig.F-Wurm, der kürzlich grassierte: Da sich dieser via eMail verbreitete, konnten Firewalls nichts gegen ihn ausrichten. In solchen Fällen ist wieder der lokale Virenscanner gefordert.
  3. Eine Firewall kontrolliert nur den Datenaustausch über das Internet.
    Von Trojanern und dergleichen, die über Disketten, CDs usw. eingeschleppt werden, bemerkt eine Firewall natürlich nichts. Und wenn das Problem erst einmal im Institutsnetz ist, gilt automatisch Punkt 1: Alle Rechner sind gefährdet.
  4. Eine Firewall kann nicht zwischen "guten" und "bösen" Daten unterscheiden.
    Gegen Angriffe auf ein Service, das in der Firewall freigeschaltet ist, ist sie im allgemeinen machtlos. Server, die Dienste nach außen freigeben, müssen deshalb in Hinblick auf Updates und Patches unbedingt auf aktuellem Stand gehalten werden. Aus diesem Grund sollte man auch sehr genau überlegen, was man in der Firewall wirklich freischalten muß, und keinesfalls - damit nur ja alles funktioniert - "sicherheitshalber" Services freigeben, deren Funktion man nicht genau kennt bzw. die man nicht benötigt.
  5. Komplexere Protokolle können zu Problemen führen.
    Wenn ein Protokoll auf komplizierteren Übertragungsmechanismen basiert als auf einfachen TCP/UDP-Verbindungen (z.B. FTP), muß die Firewall das Übertragungsprotokoll kennen, um damit richtig umgehen zu können. Gerade in den Bereichen Internet-Telefonie, Instant Messaging und Filesharing gibt es aber eine Vielzahl neuer Protokolle, die nicht jeder Firewall bekannt sind. Services, die solche Protokolle verwenden, funktionieren dann nicht oder nur eingeschränkt.

Bei allen weiteren Fragen bezüglich der Institutsfirewall wenden Sie sich bitte an die Mailadresse firewall.zid@univie.ac.at.


Wie filtert eine Firewall?

Für Firewalls kommen verschiedene Filtertechniken zum Einsatz, von denen hier nur die drei wichtigsten vorgestellt werden (eine genauere Auflistung finden Sie unter http://www.ap.univie.ac.at/security/kurse_vorlesung.html). Je diffiziler die Arbeitsweise des Filters ist, desto leistungsfähiger muß die verwendete Hard- und Software sein, um den Datenverkehr nicht allzusehr zu bremsen - und desto höher sind natürlich auch die Anschaffungskosten. Für die Institutsfirewall des ZID wird ein Stateful Packet Filter eingesetzt, der teilweise auch Funktionen eines Application Level Gateway besitzt.

  • Ein Stateless Packet Filter beurteilt jedes Datenpaket, das die Firewall passiert, für sich. Abhängig von verschiedenen Parametern des Pakets (IP-Adressen, Protokolle, Ports, Flags, ...) läßt er das Paket passieren oder blockiert es. Stateless Packet Filter sind oft in Router integriert und werden im allgemeinen für relativ grobe Filterfunktionen verwendet - z.B. um bestimmte Ports generell zu sperren.
  • Der Stateful Packet Filter arbeitet bereits etwas raffinierter: Er betrachtet die Datenpakete nicht mehr isoliert, sondern analysiert die IP-Datenströme (dies geschieht auf OSI-Layer 2 bis 4). Dazu merkt er sich jeden einzelnen Datenstrom in einer sogenannten State Table und kann dann ein Paket nicht nur nach den Parametern aus Punkt 1 beurteilen, sondern auch nach seinem Kontext: Gehört das Paket zu einer bestehenden Verbindung? Bei einer neuen Verbindung: Wird sie von innen oder außen initiiert? Ist der Verbindungsaufbau protokollkonform? - Letzteres ist (insbesondere bei TCP) eine ganz wesentliche Erweiterung gegenüber dem Stateless Packet Filter. Im Vergleich zu diesem bietet der Stateful Packet Filter außerdem den Vorteil einer einfacheren Konfiguration: Aufgrund seiner "Vorkenntnisse" ist es weniger kompliziert, die einzelnen Zugriffsregeln exakt zu definieren. Stateful Packet Filter benötigen allerdings meistens bereits eine spezielle Hardware, um ihre Aufgaben in einer vertretbaren Geschwindigkeit abwickeln zu können.
  • Das Application Level Gateway ist die stärkste Form einer Firewall. Hier kennt die Firewall auch das Übertragungsprotokoll und beurteilt Pakete nicht nur nach ihrer Header-Information (wie in Punkt 1 und 2), sondern auch nach ihrem Inhalt. Dadurch kann sichergestellt werden, daß der Datenverkehr nicht nur auf TCP/IP-Ebene standardkonform ist, sondern auch auf der Ebene der höherrangigen Protokolle (OSI-Layer 5+). Bei manchen Protokollen ist eine derartige Analyse nicht nur wünschenswert, sondern sogar notwendig - das klassische Beispiel dafür ist das "zweigleisige" FTP (File Transfer Protocol), bei dem die Firewall wissen muß, welche Datenverbindungen zu welchen Kontrollverbindungen gehören. Ein Application Level Gateway stellt deshalb auch die höchsten Anforderungen an die Leistungsfähigkeit von Hard- und Software der Firewall.

Eine Firewall ist typischerweise so konfiguriert, daß sie nur Verbindungen erlaubt, die von innen aufgebaut werden, und Verbindungen von außen verbietet (zur korrekten Umsetzung dieses Setup ist zumindest ein Stateful Packet Filter notwendig). Die Rechner innerhalb der Firewall sind so vor einem Angriff von außen geschützt.

Wenn sich nun innerhalb der Firewall ein Server befindet, auf den von außen zugegriffen werden soll - d.h. die Verbindung wird von außen initiiert -, muß dies der Firewall mittels spezieller Zugriffsregeln gesondert mitgeteilt werden. In diesen Regeln sind jene Parameter definiert, denen ein Datenpaket entsprechen muß, um die Firewall passieren zu dürfen. Beispielsweise lautet die entsprechende Regel für einen Webserver, daß Verbindungen von außen auf diesen Server nur über TCP-Port 80 (den Standard-Port für Webservices) erlaubt sind. Durch diese Regel würde z.B. der SQL Slammer, der sich stets über UDP-Port 1434 verbreitet, blockiert werden - sofern der Zugriff nicht von innen initiiert bzw. mittels anderer Regeln gestattet wurde.

 

1) Grundlegende Informationen über Firewalls finden Sie im Comment 02/2.