Abschlussbericht. Version 1.2 vom Mitglieder der Arbeitsgruppe:

Transkript

1 SecITEK Arbeitsgruppe Firewall-Filtering/Intrusion Detection Projektleitung Armin Brunner Clausiusstr. 59 Tel Fax brunner@id.ethz.ch Abschlussbericht Version 1.2 vom Mitglieder der Arbeitsgruppe: Projektleiter: Armin Brunner (KOM/ID), Tel: brunner@id.ethz.ch Projektteam: Franz Koch (KOM/ID), Tel: koch@id.ethz.ch Hp. Scherbel (D-MATH),Tel: scherbel@math.ethz.ch Peter Bircher (D-INFK), Tel: bircher@inf.ethz.ch Ch. Hallqvist (KOM/ID), Tel: hallqvist@id.ethz.ch Klaus Ethgen (D-ELEK), Tel: ethgen@ee.ethz.ch Alan Butler (D-MATH),Tel: butler@math.ethz.ch Inhaltsverzeichnis: Management Summary...2 Motivation und Auftrag...3 Grundsatzgedanken der Arbeitsgruppe...4 Langfristige Anforderungen an das ETHZ-Daten-...5 Die Funktionen der einzelnen e...6 Beschreibung der verschiedenen möglichen Sicherheitselemente...7 Granularität der Sicherheitselemente...9 Konnektivitäts-Matrix...10 Auswirkungen auf den Arbeitsalltag...11 Intrusion Detection Systeme...12 Anhang 1: Wer definiert die Rulesets?...13 Anhang 2: Beispiel zur Definition der Rulesets...14 Anhang 3: Technische Umsetzung...16 Anhang 4: Ressourcenbedarf...19

2 Management Summary Die SecITEK Arbeitsgruppe Firewall-Filtering / Intrusion Detection ist davon überzeugt, dass in einer sinnvollen IT-Sicherheits-Architektur das Datennetzwerk einen zusätzlichen Teil der Gesamt-IT-Sicherheit zu übernehmen hat. Dies bedeutet aus sicht einen eigentlichen Paradigmenwechsel. Die Arbeitsgruppe empfiehlt das Datennetzwerk mit Sicherheitselementen zu ergänzen. Diese Sicherheitselemente sollen auf Subnetz-Ebene greifen, d.h. nur der subnetzübergreifende Verkehr wird durch ein Sicherheitselement geführt. Innerhalb eines Subnetzes ist jeglicher Verkehr transparent und ungeschützt. Es gibt dabei 5 grundsätzliche Sicherheitselemente.: Transparente Sicherheitselemente mit nur den allernötigsten Restriktionen (praktisch keine). Alle Subnetze mit dem transparenten Sicherheitselement bilden zusammen das transparente. In diesem befinden sich im wesentlichen die öffentlichen Server und die Rechner von Forschungsgruppen, die auf ein transparentes angewiesen sind. Sicherheitselemente mit einem mittleren Schutz, die in der täglichen Arbeit der allermeisten Personen nur wenig wahrgenommen werden, aber vor vielen IT-Gefahren auf -Ebene einen akzeptablen Schutz bieten. Alle Subnetze mit diesen Sicherheitselementen bilden das Default-. In diesem befinden sich die meisten Rechner. Die exakte Ausprägung des Schutzes wird für jedes Subnetz in diesem in einer Vereinbarung zwischen dem Besitzer dieses Subnetzes und den Informatikdiensten geregelt. Für alle Subnetze ohne eine solche Vereinbarung gelten restriktive Sandbox -Regeln, die einen relativ hohen Schutz bieten. Sicherheitselemente mit einem hohen Schutz sind für die wichtigen IT-Güter gedacht. Alle Subnetze mit diesem Sicherheitselement bilden zusammen das geschützte. Den höchsten Schutz bietet das Sicherheitselement getrenntes. Subnetze mit diesem Sicherheitselement haben keine zum ETHZ-Produktions-. Jede dose ist genau einem Subnetz zugeordnet und jedes Subnetz hat genau ein Sicherheitselement. Je nach Sicherheitsbedürfnis eines Rechner, resp. dessen Benutzer, wird die dose auf ein Subnetz mit dem richtigen Grad an Schutz geschaltet. Das korrekte Funktionieren der Sicherheitselemente wird mit Intrusion Detection Systemen (IDS) überprüft. Die konkrete Definition des Verhaltens der verschiedenen Sicherheitselemente, die sog. Rulesets, werden in Vereinbarungen zwischen den Informatikdiensten und den Kunden-Einheiten geregelt. Dies gilt insbesondere für das transparente und das geschützte. Subnetze von Einheiten, mit denen keine Vereinbarung vorliegt oder die Vereinbarung nicht einhalten können, befinden sich alle in einem Spezialteil des Default-es, dem Sandbox-. Eine erste grobe Abschätzung der notwendigen Ressourcen ergibt einen Investionsbedarf von 1.5 bis 2 Mio Fr., jährliche Reinvestitions- und Wartungskosten von 500 bis 800kFr und jährliche Personalmittel von 500 bis 700kFr. Der Gewinn für die ETHZ zeigt sich indirekt durch das Minimieren der Anzahl von IT-Sicherheits-Ereignissen. Mit dieses Sicherheitskonzept, über die gesamte ETHZ und über das gesamte IT-Budget gesehen, sind keine Einsparungen zu erwarten. Mittelfristig jedoch, ist mit einem geringerem Anstieg der Gesamt-IT-Kosten zu rechnen. Der eigentliche Gewinn liegt aber darin, dass die Kernfunktionen der ETHZ, Lehre, Forschung und Dienstleistung, trotz deren zunehmenden Abhängigkeit von den diensten, auch in Zukunft störungsfrei erbracht werden kann. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 2 von 20

3 Motivation In der Vergangenheit war die ETHZ immer wieder Ziel von Angriffen. Diese Angriffe traten in Form von Viren- und Worm-Attacken, Denial of Service Attacken von ausserhalb und innerhalb der ETHZ und als eigentliche Einbrüche in ETHZ-Rechnersysteme auf. Dabei wurden oft Rechner innerhalb der ETHZ als Relay-Station missbraucht, um von da aus weitere Aktionen zu unternehmen. Der dabei entstandene Schaden war in bezug auf Arbeitszeit und Image enorm (siehe dazu im Anhang 4 beispielhaft die Aufstellung des monetären Schadens der DoS-Attacke im November 99). Aktuell ist eine markante Zunahme solcher schädlichen Aktivitäten zu beobachten. Durch die breite Verfügbarkeit von sehr einfach zu bedienenden Cracking- oder Viren-Tool-Kits ist in der Zukunft mit einer rapiden Verschärfung dieser Situation zu rechnen. Gerade sogenannte Scriptkiddies, d.h. Jugendliche, die aus purer Lust und Langeweile solche Tools-Kits breit anwenden, ohne wirklich zu wissen, was sie damit anrichten und erreichen, werden weltweit zu einem echten Problem. Angesichts dieser Problematik ist das IT-Sicherheitsniveau wesentlich zu erhöhen. Bisher gilt der hehre Grundsatz: Die ETHZ hat ein und eine Internet-Anbindung ohne jegliche Restriktionen, ein sogenanntes transparentes. Die notwendigen Sicherheitsvorkehrungen müssen in den angeschlossenen Rechnern selbst vorgenommen werden. Der Rechner schützt sich selbst, das bietet keinen Schutz. Dies ist vertretbar, wenn davon ausgegangen werden kann, dass alle Rechner an der ETHZ professionell betreut werden und das Betreuungspersonal dem Thema Sicherheit oberste Priorität einräumen (kann). Diese Voraussetzungen sind leider bei den meisten Rechner an der ETHZ nicht gegeben. Es muss leider davon ausgegangen werden, dass es für einen Grossteil der Rechner nicht möglich sein wird, ein genügend hohes IT-Sicherheitsniveau zu erreichen und zu erhalten. Der Grundsatz des transparenten es lässt sich also über kurz oder lang nicht mehr vertreten. Damit muss in Zukunft ein Teil der Gesamt-IT-Sicherheit vom -System erbracht werden können und diese Sicherheit muss überprüfbar sein. Diese Erkenntnis führte zur Bildung dieser Arbeitsgruppe. Auftrag Aus der obigen Motivation hat die SecITEK Arbeitsgruppe Firewall-Filtering / Intrusion Detection den Auftrag, folgende Punkte zu erarbeiten: Erarbeiten der zukünftigen, strategischen Anforderungen an datennetzwerkseitige Sicherheitselemente. Erarbeiten der Anforderungen an die Überprüfbarkeit der datennetzwerkseitigen Sicherheitselemente durch Intrusion Detection Systeme. Erarbeiten der Anforderungen an Instrumente zur Analyse von datennetzwerkseitigen Sicherheitsproblemen Die datennetzwerkseitigen Sicherheitsmassnahmen können nicht alle Sicherheitsprobleme lösen. Ein Sicherheitskonzept darf sich darum nicht nur auf netzwerkseitige Massnahmen abstützen. Es ist absolut notwendig, dass auch weiterhin alle am angeschlossenen Rechner ihrerseits einen vernünftigen Sicherheits-Standard aufweisen. Diese rechnerseitigen Anforderung an die Sicherheit werden in der SecITEK Arbeitsgruppe Security Standards ( ) detailliert bearbeitet. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 3 von 20

4 Grundsatzgedanken der Arbeitsgruppe Das im Abschnitt Motivation beschriebene Problem wird beim aktuellen Stand der gängigen Technik relativ einfach gelöst: Zwischen dem externen bösen (Internet) und dem internen guten (Intranet) wird ein Firewall platziert mit je einem Interface in Richtung Internet und in Richtung Intranet. Dabei ist das Intranet in sich transparent. Damit wird implizit angenommen, dass die Gefahr ausschliesslich vom Internet her droht und dass von den internen Benutzern und Rechnern keinerlei Gefährdung für die anderen Rechner im Intranet ausgeht. Die Arbeitsgruppe ist davon überzeugt, dass dieser Weg der Problemlösung für die ETHZ nicht adäquat ist, und zwar aus folgenden Gründen: Die -Benutzerschaft an der ETHZ ist sehr unterschiedlich. Von Rechnern ausschliesslich mit Office-Applikationen über Rechner mit nur Mess- und Regelfunktionen bis zu Forschung im bereich finden sich Benutzergruppen mit sehr unterschiedlichen Bedürfnissen in vielfacher Hinsicht. Die ETHZ ist eine Universität mit vielen Mitarbeitenden und Studierenden. Die meisten dieser Personen, insbesondere die Studierenden, sind nur relativ kurz an der ETHZ und stehen nicht in einem klassischen Arbeitsverhältnis. Von dieser Community geht ein erhöhtes Sicherheitsrisiko aus. Die ETHZ hat eine föderalistische IT-Landschaft. Einzig das Datennetzwerk ist unter zentraler Verantwortung. An dieses interne sind sehr viele Rechner angeschlossen, die zudem noch sehr unterschiedlich gewartet werden. Es gibt viele Rechner, für die sich niemand zuständig fühlt und die aus sicherheitstechnischer Sicht in einem sehr schlechten Zustand sind. Auch mit den besten organisatorischen Massnahmen lässt sich dies nicht vollständig verhindern. Wir werden auch in Zukunft damit leben müssen, dass es innerhalb des es der ETHZ Rechner gibt, die ein erhöhtes Sicherheitsrisiko für sich und für die anderen Rechner innerhalb und ausserhalb der ETHZ darstellen. Obige Gründe sind typisch für Universitäten. Ein kurze Umfrage (Jul./Aug. 2001) bei vergleichbaren Universitäten hat folgendes Bild ergeben: Grosse Universitäten sind wie die ETHZ eher mit komplexen IT-Landschaften (verschiedenste, höchst unterschiedlich gewartete Systeme, in allen möglichen technischen Zuständen) ausgerüstet. Diese Landschaften sind zudem sehr heterogen, veränderlich und ausserdem dezentral administriert. Unterschiedliche und zum Teil individuelle Systeme mit angepasster Hardware oder angepassten Betriebssysteme und Applikationen werden benutzt. Die Universitäten haben ausserdem ein ausgeprägtes Bedürfnis nach einem offenen und effizienten Zugang zum Internet. Dies führt zu sicherheitstechnischen Zielkonflikten. Bei den antwortenden Universitäten ist die zentrale sicherheit meist durch rudimentäre Routerkonfigurationen durchgesetzt. Das heisst ing und eine gewisse Verkehrsüberwachung/Analyse. Bei einer Universität müssen sogar die MAC-Adressen zentral registriert sein um erlaubten -Zugang zu erhalten. In einigen Fällen sind IDS (Intrusion Detection System) für Verkehrsüberwachung/Analyse im Einsatz. Wo hohe Sicherheit notwendig ist, werden eher fokussierte, dezentrale und individuell angepasste Massnahmen eingesetzt. In diesen Fällen werden vielfach Firewalls dezentral benutzt und nicht selten sind sie sehr restriktiv konfiguriert. Da auch solche Massnahmen nicht ausreichende sicherheit bieten, werden die Problemfälle individuell von Sicherheitsteams bearbeitet. Die ETHZ hat eine lange Tradition in dezentraler Verwaltung und Verantwortung Es besteht ebenfalls ein sehr liberale Grundhaltung gegenüber den Mitarbeitenden und Studierenden. Wir versuchen in diesem Konzept diese Kultur aufzunehmen und in ein sichereres IT-Umfeld einzubetten. IT-Sicherheit ist nicht Selbstzweck. Wir versuchen in diesem Konzept ebenfalls die Balance zu finden zwischen Nutzen und Aufwand, beides sowohl aus Sicht der IT-NutzerInnen, als auch aus Sicht der IT- BetreiberInnen. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 4 von 20

5 Langfristige Anforderungen an das ETHZ-Daten- Ausgehend vom Bericht der SecITEK-Arbeitsgruppe Risikoanalyse ( ) schlägt die Arbeitsgruppe vor, dass das der ETHZ in mehrere logisch getrennte e aufgeteilt werden soll. Dies sind: transparentes : alle Subnetze ohne jeglichen Schutz Default-: alle Subnetze mit einem mittlerem Schutz durch IP-Access-Listen Sandbox-: alle Subnetze mit erhöhten Schutz durch IP-Access-Listen Geschütztes : alle Subnetze mit einem hohem Schutz durch echte Firewalls Getrennte e: e ohne zu anderen en Jede einzelne -Anschlussdose (UTP-Dose) soll dabei genau einem Subnetz zugeordnet werden können und damit einem dieser e. Jedes dieser e verfügt über spezifische, im integrierte Schutzelemente, welche die rechnerseitigen Sicherheitsvorkehrungen ergänzen. Da dieser Schutz nur unterstützend wirken kann, gelten für jedes dieser e bestimmte Basisanforderungen (Security Standards) für die daran anzuschliessenden Rechner. Die Erarbeitung dieser Basisanforderungen erfolgt in der entsprechenden Arbeitsgruppe der SecITEK. Die IT-Sicherheits-Architektur sieht schematisch folgendermassen aus: Sicherheitsniveau Sehr Hoch Hoch Mittel Klein Transparentes Default Geschütztes Host Netz Host Netz Host Netz Host Netz Total Total Sandbox Total Total Durch die Kombination von den Sicherheitsmassnahmen in den Rechnern selbst und den Sicherheitsmassnahmen im kann ein wesentlich höheres Sicherheitsniveau des Gesamtsystems erreicht werden. Auch wenn das Sicherheitsniveau eines Rechners nicht so hoch ist wie es eigentlich sein sollte (leider auch in Zukunft nicht auszuschliessen), kann durch die netzwerkseitigen Sicherheitselemente ein Sicherheitsniveau erreicht werden, das wesentlich höher ist als ohne (wenn auch nicht genügend). Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 5 von 20

6 Die Funktionen der einzelnen e Das transparente bietet keinerlei Restriktionen und maximale Performance (Durchsatz, Latenz, Jitter, u.s.w.). Die Rechner in diesem bieten öffentliche Dienste an oder werden für Forschungszwecke eingesetzt, die ein transparentes verlangen. An die Wartung dieser Rechner werden hohe Anforderungen gestellt, da diese Rechner stets auf dem aktuellen Sicherheitsstand sein müssen. Typische Rechner in diesem sind: o Öffentliche Server wie o Server und Workstation von Forschenden im Bereich Kommunikationstechnik Das mit mittlerem Schutz ist das Default-. (Mit Default- ist die Menge der Subnetze gemeint, die einen vergleichbaren mittleren Schutz aufweisen.) Die meisten Rechner sollen an dieses angeschlossen sein. Die Rechner in diesem Netz bieten keine öffentliche oder halböffentliche Dienste an und sind nicht von strategischer Bedeutung für eine grosse Anzahl von Personen. Die Arbeit an diesen Rechnern wird durch die Sicherheitselemente des Default-Netzes nicht, oder nur sehr wenig tangiert. Gegenüber dem transparenten ist nur mit minimalen Performance-Einbussen zu rechnen. Die Benutzer in diesem arbeiten in der Regel von innen nach innen oder von innen nach aussen. saufbau von aussen nach innen ist die Ausnahme. Innen bedeutet dabei das eigene Subnetz und aussen bedeutet alles ausserhalb des eigenen Subnetzes. Dies bedeutet im wesentlichen, dass die en in der Regel von einem Rechner in diesem ausgehen (Client) und selbst keine Serverdienste anbietet, die von Rechnern ausserhalb des eigenen Subnetzes angefordert werden können. Typische Rechner in diesem sind: o Fast alle persönlichen Arbeitsrechner o Normale Instituts-Server Das Default- teilt sich in zwei Untergruppen von e. Da sind einmal alle Subnetze von Einheiten mit denen eine Sicherheits-Vereinbarung besteht. In dieser Vereinbarung wird zwischen dieser Einheit und den Informatikdiensten geregelt, wie die genaue Ausprägung des Schutzelementes für dieses Subnetz aussehen und welche Anforderungen die Einheit auf allen Rechnern in diesem Subnetz erfüllen muss. Zwischen solchen Subnetzen gelten liberale Filter- Regeln. Für alle Subnetze im Default- für die noch keine solche Vereinbarung getroffen oder eine bestehende Vereinbarung nicht eingehalten werden konnte, gelten restriktive Filter-Regeln (sog. Sandbox-Regeln). Dies ist einerseits zum Schutz dieser Rechner vor Gefahren und andererseits zum Schutz der anderen Rechner der ETHZ vor diesen möglicherweise unsicheren Rechnern. Das für die strategischen Güter ist das sogenannte geschützte und enthält alle Rechner, die für die interne Funktion der ETHZ oder einer grossen Anzahl von Personen von grosser Wichtigkeit ist. Dies könnten sein: SAP, Infrastruktur-Management, Directory-Server, Software-Server, Lizenz-Server, Netbackup-Server sowie alle grossen Datenbanken wie Personen-DB, Bibliotheks-DB und so weiter. Die auf diesen Gütern aufbauenden Dienste sollen jedoch ohne Einschränkung zur Verfügung stehen. Die logisch getrennten e verbinden geschlossene Gruppen von Rechnern, die nur unter sich haben müssen und normalerweise keine zu Rechner im Internet oder den anderen en innerhalb der ETHZ benötigen. Beispiele dafür sind: - Ein Daten- für das zentrale Management aller Telefonzentralen - Ein Daten- für das zentrale Management der Haustechnik in den ETHZ-Liegenschaften Alle diese getrennten e haben keine transparente zur Aussenwelt. Falls notwendig kann mittels spezifischen VPN-Devices (Virtual Private Networking) auf eine sichere Art von aussen auf diese e zugegriffen werden. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 6 von 20

7 Beschreibung der verschiedenen möglichen Sicherheitselemente Es gibt viele verschiedene Arten von Firewalls, die aber alle unter dem gleichen Namen segeln. Um Missverständnisse zu vermeiden wird im weiteren nur noch von Sicherheitselementen gesprochen. Unter einem Sicherheitselement verstehen wir eine Funktion, die an einem bestimmten logischen Ort aktiv ist und den Datenverkehr, abhängig von für dieses Sicherheitselement definierten Regeln in sicherheitstechnischer Hinsicht, überprüft und manipuliert. Da gibt es im wesentlichen drei Grundtypen von Sicherheitselementen: Filter überprüfen jedes IP-Paket unabhängig von den anderen Paketen. Die Paket-Header-Informationen kann dabei nach folgenden Feldern, resp. Kombinationen davon, ausgewertet werden: o Protokoll (IP, ICMP, IP V6, u.a.) o Ziel- und Quelladresse (Rechneradressen) o TCP/UDP Protokoll (Ziel- und Quellport) o Protokollflags (z.b. TCP SYN) Das Sicherheitselement lässt sich oft in Hardware/Firmware realisieren und bedeutet dadurch meistens keine oder nur eine kleine Performance-Einbusse. Stateful-Inspection Stateful-Inspection-Sicherheitselemente betrachten nicht jedes Packet für sich alleine sondern im Zusammenhang mit den vorangegangenen Paketen derselben TCP-Session. Dadurch ist immer bekannt, in welchem Status sich eine befindet und nur die diesem Status entsprechenden Pakete werden erlaubt. Auch wird der Hin- und der Rückweg als eine Einheit erfasst und entsprechend die Sicherheitsregeln angewendet. Stateful-Inspection-Sicherheitselemente werden manchmal auch dynamische Filter genannt. Normalerweise schauen diese Sicherheitselemente nicht nur auf den TCP-Session-Status (IP und TCP Header) sondern auch noch etwas in die Applikationsschicht (Layer 4), um festzustellen, ob die Applikation auf anderen Ports Daten transportieren wird (z.b. FTP). Dies bedeutet, dass für jedes Applikations-Protokoll, welches einen Portwechsel erfordert, spezielle Unterstützung eingebaut sein muss. Selbstverständlich sind auch alle Sicherheitsmerkmale des s möglich. Das Sicherheitselement Stateful-Inspection ist bisher meistens in Software realisiert und verursacht daher eine mittlere bis grosse Performance-Einbusse. In zukünftigen Entwicklungen wird jedoch diese Funktion in Hardware/Firmware realisiert sein, so dass dann nur noch mit einer kleinen bis mittleren Performance-Einbusse zu rechnen sein wird. Applikations-Gateways/Proxies Proxies arbeiten komplett auf Applikationsebene. Sie stehen zwischen den beiden Endpunkten einer Applikationssession (z.b. WWW-Session). Es bestehen also zwei Transport-Sessions (TCP- Sessions), je eine von beiden Enden der Applikations-Session zum Applikations-Proxy. Beim Beispiel einer WWW-Session sendet der WWW-Browser seinen Request nicht direkt zum WWW-Server sondern zum WWW-Proxy, der dann seinerseits eine TCP-Session zum WWW-Server aufbaut und den Original-Request weitersendet. Es besteht also zu keiner Zeit eine direkte TCP/IP-Kommunikation, sondern alle Daten müssen durch den Proxy geschleust werden. Dadurch steht im Proxy der komplette Applikations-Datenstrom für genaue Untersuchung zur Verfügung. So kann z.b. der Mailverkehr auf Viren untersucht werden. Für jede zu unterstützende Applikation muss ein separater Proxy eingerichtet werden. Manche Proxy- Systeme lassen sich so einrichten, dass sie für den Benutzer völlig transparent sind, d.h. in der täglichen normalen Arbeit nicht spür- und sichtbar sind. Die meisten Proxies jedoch müssen vom Benutzer speziell berücksichtigt werden und bedeuten in der Regel eine gewisse Erschwerung der Kontaktaufnahme. Manche Proxies lassen sich so konfigurieren, dass mit etwas Hilfe seitens des s, ein transparenter Betrieb möglich ist. Dies bedeutet dann, dass die Existenz dieser Proxies vom Benutzer nicht Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 7 von 20

8 mehr bemerkt wird und der saufbau wie ohne Proxy funktioniert. Applikations-Gateways/Proxies sind meistens in Software auf general purpose Hardware realisiert. Damit ist mit erheblichen Performance-Einbussen zu rechnen. Manche Proxies stützen sich auf spezialisierte Hardware und lassen damit nur noch eine mittlere Performance-Einbusse erwarten. Neben diesen drei Grundtypen von Sicherheits-Elementen gibt es noch zwei Zwischenformen, die von gewisser Bedeutung sind: TCP-Interception Das Sicherheits-Element TCP-Interception ist vor allem als Abwehrmethode gegen Denial of Service Attacken gedacht. Es unterbricht eine TCP-saufbau und signalisiert dem Quellsystem, anstelle des Zielsystems, die Bereitschaft zum saufbau. Erst wenn das Quellsystem richtig reagiert und damit der saufbau aus Sicht des Quellsystems erfolgt ist, baut das TCP-Interception-System eine TCP- zum Zielsystem auf. Nachdem die Session zum Zielsystem steht, werden diese beiden Halbsessions miteinander verbunden und ein ungehinderter und unkontrollierter Datenaustausch kann erfolgen. Manche Stateful-Inspection-Systeme beinhalten das Sicherheitselement TCP-Interception. Es gibt aber auch stand alone Implementationen. TCP-Interception ist bisher nur in Software realisiert. Der saufbau wird etwas verzögert, der Datentransport ist anschliessend jedoch ungehindert, auch in der Performance. TCP/UDP-Relays TCP/UDP-Relays verbinden je ein TCP- oder UDP-Port vom Eingang zum Ausgang. Es handelt sich um wohldefinierte Löcher im Sicherheitselement. Die anwendbaren Regeln sind fast gleich wie bei den reinen n, jedoch müssen Eingangs- und Ausgangsport nicht identisch sein. Diese Relays werden statisch konfiguriert. Eine automatisierte Art von solchen TCP/UDP-Relays ist mit dem SOCKS-System realisiert. Beim SOCKS System übernimmt im Client-Host eine SOCKS-Zwischenschicht den saufruf (z.b. des WWW-Browsers) und meldet sich beim Relay. Nach einer erfolgreichen Validierung des Clients beim Relay wird temporär für diese Applikation auf diesem Host im Sicherheitselement ein Loch gebohrt, das genau so lange besteht wie es für die Applikation nötig ist. SOCKS muss von der Applikation (resp. dessen Client-Software) unterstützt werden. Manche Applikationsprogramme bringen diese Unterstützung mit (z.b. Internet-Explorer ). Die meisten Applikationsprogramme müssten jedoch mit der SOCKS-Library neu kompiliert werden. TCP/UDP-Relays sind ähnlich wie s oft sehr effizient in Hardware realisiert, mit Unterstützung von Software im saufbau. D.h. der saufbau verzögert sich unwesentlich und der anschliessende Datentransport geschieht nur mit kleinen Performance-Einbussen. Kein eigentliches Sicherheitselement sind die VPN-Tunnel-Server. Da der VPN-Services in diesem Bericht einige Male erwähnt ist wird diese Funktion etwas erläutert. Mit einem VPN-Tunnel kann ein Rechner temporär die -Identität wechseln. Dies geschieht folgendermassen: Ein Rechner ist mit einem verbunden (Internet oder innerhalb der ETHZ auf einem der e). Dieser Rechner baut eine zum gewünschten VPN-Tunnel-Server auf und authentisiert sich (resp. der an diesem Rechner arbeitende Benutzer). Ist die Authentisierung erfolgreich, erhält der Rechner vom Tunnel-Server eine IP-Nummer (=Identität) zugewiesen die vergleichbar ist mit anderen Rechnern, die im selben sich befinden wie der VPN-Tunnel-Server. Ab diesem Moment findet jegliche Kommunikation des Rechners nur noch durch den Tunnel unter der VPN-Identität statt. Jegliche Datenkommunikation innerhalb des Tunnels ist dabei so stark verschlüsselt wie es im VPN- Server definiert wird. Es gibt auch noch andere Formen von VPN-Tunnels, die hier jedoch nicht weiter diskutiert werden sollen. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 8 von 20

9 Granularität der Sicherheitselemente Klassische Firewalls wurden bisher immer an der Campus-Grenze installiert. Sie bildeten die zwischen dem Intranet (dem geschützten, internen ) und dem Internet (dem bösen, globalen ). In solchen Installationen gelten alle Rechner im Intranet als gut und freundlich, jede Gefahr kommt nur vom Internet. Die Granularität der Sicherheitselemente ist somit auf Campus-Ebene, oder anders ausgedrückt, ein Sicherheitselement für den ganzen Campus. Dieser Ansatz ist speziell für eine Universität wie die ETHZ nicht adäquat. Mit der grossen Anzahl von Rechnern für Studierende und auch den unkontrollierten oder schlecht gewarteten Rechner der Mitarbeitenden besteht ein erhebliches Gefährdungspotenzial. ETHZ-Rechner müssen auch vor den anderen ETHZ-Rechnern geschützt werden. Dieser Gedanke zu Ende gedacht bedeutet, dass die Granularität der Sicherheitselemente auf Host-Ebene liegen muss. Ein Sicherheitselement pro Host - so quasi mein personal firewall in meiner -Anschlussdose. Dieser Ansatz erschien uns jedoch als zu akademisch und wir sind auch der Meinung, dass die Kommunikation innerhalb einer sozialen Gruppe transparent und unkontrolliert möglich sein soll. Unter einer sozialen Gruppe verstehen wir dabei eine Gruppe von Personen, bei denen die soziale Kontrolle noch funktionieren kann (oder wenigstens sollte), wenn man sich gegenseitig auf die Füsse steht (sprich behackt oder sonst wie bedroht). Wir sind der Meinung, dass ein IP-Subnetz diesem Ansatz der sozialen Gruppe nahe kommt und empfehlen daher die Granularität der Sicherheitselemente auf Subnetz-Ebene. IP-Subnetze werden per Definition durch Router miteinander verbunden. Die Sicherheitselemente sollen also auf der Ebene der Router-Interfaces implementiert werden. Jedes dieser Sicherheitselemente, wir sprechen hier von einer Anzahl im Bereich von 1 000, ist dabei eine eigenständige Entität mit eigenem Ruleset. Ein Ruleset ist dabei die Konfiguration eines Sicherheits-Elements. Im Anhang sind die Vorschläge für die Default-Rulesets der verschiedenen Sicherheitselemente aufgelistet. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 9 von 20

10 Konnektivitäts-Matrix Von Internet Nach Internet Subnetz im transparenten transparent Subnetz im Default- restriktiv extern Subnetz im Sandbox- gesperrt Subnetz im geschützten Nur Proxy Subnetz in getrenntem Subnetz im transparenten transparent transparent liberal intern restriktiv intern Stateful Subnetz im Default- Subnetz im Sandbox- Subnetz im geschützten Subnetz in getrenntem liberal extern liberal extern Proxy Rest stateful liberal intern liberal Sandbox liberal intern liberal Sandbox restriktiv intern restriktiv intern Stateful Stateful Stateful Stateful Stateful Stateful liberal bedeutet im Grundsatz: Es ist alles erlaubt was nicht verboten ist (Negativ-Liste). Der liberal intern ist dabei sehr liberal und angepasst an die internen Bedürfnisse. Der liberal extern bietet einen angemessenen Schutz des externen Internet vor den Rechnern im Default-. liberal Sandbox bietet angepassten internen Schutz vor den Rechnern im Sandbox-. restriktiv bedeutet im Grundsatz: Es ist alles verboten was nicht erlaubt ist (Positiv-Liste) restriktiv extern schützt die Rechner im Default- vor dem Internet. restriktiv intern schützt die Rechner im Sandbox- vor den anderen internen Rechner. Stateful bedeutet ein Stateful-Inspection-Sicherheitselement Proxy bedeutet ein Application-Gateway/Proxy für bestimmte Protokolle; Rest stateful meint, dass die nicht durch einen Proxy abgedeckten, aber erlaubten Protokolle durch ein Stateful-Inspection Sicherheitselement geschützt werden. Anti-Spoofing-Filter für das betreffende End-User-Subnetz müssen an allen Router-Interfaces aktiviert sein (auch im transparenten ). Ein erster Vorschlag zur Frage Wie werden die Rulesets definiert? ist im Anhang 1. Ein Beispiel zu den Definitionen der und Stateful-Elemente sind im Anhang 2 ersichtlich. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 10 von 20

11 Auswirkungen auf den Arbeitsalltag Sicherheitsmassnahmen sind nie gratis. Je besser der Schutz ist, mit umso stärkeren Auswirkungen, sprich Behinderungen oder Restriktionen, ist zu rechnen. Bei den vorgeschlagenen Massnahmen sind moderate Behinderungen nicht zu vermeiden. Transparentes : Im transparenten ist gegenüber dem Internet mit keinen Auswirkungen zu rechen. Gegenüber den anderen internen en (default, Sandbox und geschützt) sind jedoch Behinderungen zu erwarten (siehe dort). Default- (Subnetze mit Vereinbarung): Vom Internet aus sind die Rechner im ETHZ Default- im wesentlichen nicht mehr zu erreichen. Ausnahmen werden in der Vereinbarung zwischen der Einheit und den Informatikdiensten geregelt. Vom Default- aus sind jedoch fast alle Internet-Dienste problemlos nutzbar. Es gibt kleine Einschränkungen für TCP-Protokolle, die unterscheiden zwischen einer Command-Session und einer Transport-Session wie z.b. FTP. Bei diesen Protokollen baut die Daten-sendende Seite die Daten- auf, d.h. es soll von aussen nach innen eine Daten- aufgebaut werden, was aber von den restriktiven Filtern nicht erlaubt wird. FTP kennt aber den sog. Passiv-Mode, der den s-aufbau der Daten-Session umkehrt (von innen nach aussen). Die in den üblichen Web-Browsern eingebauten FTP-Clients funktionieren immer im Passiv-Mode und somit ist diese Restriktion für die meisten User nicht spürbar. Bei selbständigen FTP-Clients kann in den meisten Fällen der Passiv-Mode eingestellt werden. Für solche FTP-Clients, die keinen Passiv-Mode kennen, wird ein Proxy-Server zur Verfügung stehen. Nicht funktionieren werden Protokolle wie Netmeeting oder ähnliche Dienste, bei denen ein saufbau von aussen nach innen notwendig ist. Beim Beispiel Netmeeting: saufruf von aussen zu einer Videokonferenz. saufbau von innen nach aussen funktioniert jedoch einwandfrei. Falls sich der Bedarf ergeben sollte, könnten auch die von H.323 (das Protokoll für Videokonferenzen über IP) benötigten Ports freigegeben werden (siehe dazu Anhang 1). Zwischen den Subnetzen innerhalb des Default-es, wie auch zu und von den Subnetzen des transparenten en, sind die liberalen internen aktiv. Diese blockieren nur sehr wenige unnötige und potenziell gefährliche Ports (Negativliste). Die Schutzfunktion dieser internen ist nicht besonders hoch, aber auch nicht besonders wichtig. Viel wichtiger die Existenz eines administrativen Eingriffspunktes an der Grenze eines jeden Subnetzes, wo im Bedarfsfall (z.b. bei Security-Ereignissen) sehr schnell entsprechende Massnahmen ergriffen werden können. Sandbox- (Subnetze ohne Vereinbarung): In den Subnetzen des Sandbox- sind alle Rechner mit deren Betreibern (noch) keine Vereinbarung besteht. Es ist darum anzunehmen, dass diese Rechner nicht wirklich gut betreut werden und dadurch stark verletzlich sind, resp. eine potentielle Gefährdung für die anderen Rechner der ETHZ darstellen. Die Rechner im Sandbox- sind vom Internet überhaupt nicht erreichbar. Von anderen Subnetzen der ETHZ aus gelten die restriktiv-internen Filter, die einen saufbau nur auf wenige Ports erlauben. Von einem Rechner auf einem Subnetz im Sandbox- sind jedoch fast alle Dienste innerhalb der ETHZ und im Internet problemlos nutzbar. Die Einschränkungen sind dieselben wie im Default-. Geschütztes : Die Rechner des geschützten es sind vom Internet aus nicht mehr zu erreichen. Wenn auf geschützte Dienste von ausserhalb der ETHZ zugegriffen werden muss (z.b. von der EMPA aus auf das SAP-System) muss vorgängig ein VPN-Tunnel eröffnet werden. Proxy-Server für SMTP (Mail) und http (Web) ermöglichen den unbedingt notwendigen saufbau von aussen. Die Rechner selbst können jedoch die üblichen Dienste im Internet via Proxies benutzen. Die nicht von einem Proxy abgedeckten Dienste werden nach Bedarf freigeschaltet und durch das Stateful-Inspection Sicherheitselement geschützt. Getrennte e: Für bestimmte Anwendungen sind logisch getrennte e möglich. Zu diesen en besteht keine transparente. Innerhalb eines logisch getrennten es ist jedoch alles transparent und es existieren keine weiteren Sicherheitselemente. Mittels dedizierter VPN-Server kann es, falls notwendig, ermöglicht werden, dass von Rechnern ausserhalb eines solchen es auf Ressourcen innerhalb zugegriffen werden kann, ohne die generelle Sicherheit der getrennten e grundsätzlich zu verletzen. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 11 von 20

12 Intrusion Detection Systeme Intrusion Detection Systeme (IDS) sind Geräte, die den -Verkehr passiv mithören und Alarm schlagen, wenn in diesem Verkehr Muster auftreten, die als Hacking -Aktivität bekannt sind. (Ein Alarm ist in diesem Zusammenhang ein Ereignis, das eine Aktion eines Menschen verlangt, z.b. entscheiden, ob es sich nicht um einen Fehlalarm handelt). Diese Aufgabe birgt einige Probleme in sich: IDS sind nur so gut wie die Qualität der gespeicherten Muster. Die Aufgabe ist sehr CPU-intensiv und damit ist die Menge an Verkehr die zuverlässig beobachtet werden kann beschränkt. Alarme dürfen nicht zu häufig auftreten. Hunderte oder auch nur Dutzende von Alarme täglich können nicht mehr mit der nötigen Sorgfalt bearbeitet werden. IDS sind aus diesen Gründen nicht primär gedacht, um den Ereignis-reichen Internet-Haupt-Zugang zu überwachen, sondern eher in einem Ereignis-armen, geschützten Umfeld sinnvoll. In diesem Umfeld sind IDS jedoch mächtige Instrumente, um die Wirksamkeit der schützenden Sicherheitselemente zu überprüfen. In dieser Funktion sollte eigentlich hinter jedem Sicherheitselement ein IDS platziert werden. Dies erscheint uns jedoch wiederum als zu akademisch und im Default- als nicht erstrebenswert. Es soll jedoch hinter jedem Sicherheitselement bei Bedarf ein IDS platziert werden können - und dies ohne grossen Aufwand. Nach eingehenden Diskussionen schlägt die Arbeitsgruppe folgenden Einsatz von Intrusion Detection Systemen vor: Im geschützten soll hinter jedem Sicherheitselement ein IDS fest installiert werden. Dieses IDS soll allen Verkehr, der durch das Sicherheitselement fliesst, erfassen. Nach Möglichkeit soll dieses IDS auch allen Subnetz-internen Verkehr erfassen. Im Default- soll der Verkehr zum transparenten, resp. zum Internet, durch ein fest installiertes IDS überwacht werden. Der Verkehr zwischen den einzelnen Subnetzen des Default-es und der Verkehr innerhalb eines Subnetzes wird nicht erfasst. Auf Wunsch des Informatik Support Leiters eines Departements (und mit entsprechender Kostenfolge) kann auf einem oder mehreren Subnetzen ein IDS installiert werden, das allen Verkehr zu anderen Subnetzen erfassen kann und nach Möglichkeit auch allen internen Verkehr. Die Logs und Alarme eines solchen IDS werden nicht nur zentral erfasst und ausgewertet, sondern stehen auch direkt und unverarbeitet dem betreffenden Departement zur Verfügung. Mobile Intrusion Detection Systeme sollen ohne grossen zeitlichen und/oder finanziellen Aufwand an jedem beliebigen (logischen) Port bei Bedarf installiert werden können. Die für die an diesem Port angeschlossenen Rechner verantwortliche Person oder Organisation muss dabei umgehend über die Massnahme orientiert werden. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 12 von 20

13 Anhang 1 Wie werden die Rulesets definiert? Im wesentlichen gibt es zwei Arten der Definition der Rulesets: Die Rulesets der Sicherheitselemente von Subnetzen ohne Vereinbarung werden von den Informatikdiensten definiert. Die Rulesets der Sicherheitselemente von Subnetzen mit Vereinbarung werden in der jeweiligen Vereinbarung definiert. Was ist diese Vereinbarung und was wird damit bezweckt? Die Vereinbarung zwischen dem Verantwortlichen eines Subnetzes und den Informatikdiensten ist eine Art Service Level Agreement, resp. mehr ein Security Level Agreement. Darin wird abgemacht, in welchem Mass die Rechner in einem Subnetz geschützt werden sollen, d.h. welche Ports sind vom externen Internet her offen sein sollen. Es wird darin ebenfalls abgemacht, welche Massnahmen der Subnetz- Verantwortliche zum Schutz dieser Ports auf den Rechners selbst implementieren muss. In der Vereinbarung wird aufgezeigt, wie der Subnetz-Verantwortliche diesen Schutz zu implementieren und zu warten plant. Mittels dieser Vereinbarungen sollen die lokalen Verantwortlichen stärker in das gesamte IT-Sicherheits- System eingebunden werden. Die Schutzmassnahmen werden nicht von den Informatikdiensten verordnet sondern mit den Betroffenen ausgehandelt. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 13 von 20

14 Anhang 2 Beispiel zur Definition der Rulesets Transparentes : Es gibt keinerlei Filter ausser der absolut notwendigen Anti-Spoofing Filter. Default-: -Regeln Unter dem liberalen externen (Verkehr in Richtung Internet) ist folgendes zu verstehen: Gesperrt sind die (risikoreichen) Ports: 0/tcp, 0/udp (reserved) 1/tcp 1/udp (tcpmux) 7/tcp, 7/udp (echo) 11/tcp, 11/udp (systat) 17/tcp, 17/udp (quoted) 19/tcp, 19/udp (chargen) 69/tcp, 69/udp (tftp) 111/tcp, 111/udp (rpcbind, portmap) 137/tcp, 137/udp (netbios-ns) 138/tcp, 138/udp (netbios-dgm) 139/tcp, 139/udp (netbios-ssn) 161/tcp, 161/udp (snmp) 162/tcp, 162/udp (snmptrap) 445/tcp, 445/udp (microsoft-ds) 515/tcp, 515/udp (printer) Alle anderen Ports sind offen. Die liberalen internen innerhalb der ETHZ (zwischen den Subnetzen im Default-) sind noch liberaler und sperren nur noch: 0/tcp, 0/udp (reserved) 1/tcp, 1/udp (tcpmux) 11/tcp, 11/udp (systat) 19/tcp, 19/udp (chargen) Alle anderen Ports sind offen. Unter dem restriktiven internen (Verkehr zu Subnetzen im Sandbox-) ist folgendes zu verstehen: Offen sind die sicheren oder notwendigen Ports: icmp-echo (Ping) mit Bandbreitenbeschränkung auf <128kBit/s 22/tcp (ssh) SecureShell 443/tcp (https) HTTP über SSL 25/tcp (smtp) ausschliesslich für registrierte Mail-Server 995/tcp (pop3s) POP3 über SSL 993/tcp (imaps) IMAP über SSL 636/tcp (ldaps) LDAP über SSL 989/tcp, 990/tcp (ftps-data, ftps) FTP über SSL 992/tcp (telnets) Telnet über SSL 1293/tcp IPSec 500/tcp,udp isakmp Internet Key Management Alle anderen Ports sind gesperrt. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 14 von 20

15 Die restriktiv externen (Verkehr vom Internet in Richtung ETHZ) werden pro Subnetz in einer Vereinbarung mit dem Besitzer des Subnetzes festgelegt. Wenn keine Vereinbarung vorliegt, gelten die Sandbox-extern Regeln, d.h. alle Ports sind gesperrt. Bestandteil des restriktiv externen Filters ist das TCP-Interception für eingehende en. (Zur Verhinderung/Abschwächung von ddos-attacken.) Für FTP steht ein Proxy zur Verfügung. Für Mail (SMTP) steht ein zentrales Mailsystem zur Verfügung, über das auf Wunsch/Verlangen eines Departementes/Institutes aller eingehender und/oder ausgehender SMTP-Verkehr geroutet wird und alle Mails auf Viren geprüft werden (Mail-Proxy). Minimale Granularität für eingehende Mails ist die Maildomain (es kann minimal pro Maildomain gewählt werden, ob der Verkehr über den Mail-Proxy geführt werden soll). Mit dem zentralen VPN (Virtual Private Networking) System kann von ausserhalb der ETHZ, über den restriktiven hinweg, eine transparente TCP/IP in das Default- erstellt werden. Von dem VPN-Server aus, resp. für den mit dem VPN-Server verbundenen VPN-Client, gelten dann die liberalen internen, resp. die restrikiv internen Filter bei Sandbox-Subnetzen. Geschütztes : An der ETHZ existiert bisher wenig Erfahrungen mit Firewalls. Es ist daher sehr schwierig bereits ein sinnvolles Default-Ruleset für die Sicherheitselemente im geschützten anzugeben. Sicher ist, dass jeglicher Verkehr über Stateful-Inspection-Sicherheitselemente geführt wird. Es wird Aufgabe eines Pilotprojektes sein, diese Rulesets, allenfalls für verschiedene Sicherheitsstufen, zu erarbeiten. Die eigentliche Grundhaltung, die in den Rulesets implementiert werden soll, kann jedoch folgendermassen angegeben werden: Verkehr vom geschütztes zum Internet Analog zu den entsprechenden Sicherheitselementen im Default- soll eine liberale Grundhaltung mit einer Negativliste zur Anwendung kommen. Zusätzlich zu der im Default- definierten Liste sollen einige Protokolle über Proxies geführt werden. Verkehr vom Internet zum geschützten In dieser Richtung ist Verkehr nur über die Proxies erlaubt (Positiv-Liste). Allenfalls sind bei einigen Protokollen eine User-Validierung notwendig. Verkehr zwischen geschütztem und Default- Der Verkehr zwischen den Subnetzen des geschützten Netzes und den Subnetzen des Default- es unterliegen zwei Negativlisten, je eine für jede Richtung. Die Negativ-Liste für den Verkehr vom geschützten zum Default- soll dabei noch etwas liberaler sein (z.b. Drucker-Access erlaubt) als in der anderen Richtung. Verkehr zwischen geschütztem und dem transparenten Das transparente wird mit dem Internet gleichgesetzt, ausser dass keine Proxy-Funktionen zum Einsatz kommen. Verkehr zwischen den Subnetzen des geschützen es Dieser Verkehr wird grundsätzlich gleich behandelt wie der Verkehr zum Default-, d.h. eine Negativliste ohne Proxy-Funktionen. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 15 von 20

16 Anhang 3 Technische Umsetzung Basis für die Umsetzung der Anforderungen in diesem datennetzwerkseitigen Sicherheitskonzept ist die flächendeckende Versorgung der ETHZ mit -Anschlüssen innerhalb des Projekts KOMETHng. Innerhalb dieser -Infrastruktur wird sehr stark mir virtuellen LANs (VLAN) gearbeitet. Ein VLAN verhält sich dabei fast wie ein richtiges physisches -Kabel (LAN). Alle Rechner, die an das selbe VLAN angeschlossen sind, können unbeschränkt untereinander kommunizieren. An der ETHZ entspricht ein VLAN einem IP-Subnetz. Dabei kann, zumindest theoretisch, jede -Dose jedem beliebigen VLAN, resp. Subnetz zugeordnet werden. In der Praxis wird jedoch sehr darauf geachtet, dass VLANs einigermassen lokal, d.h. innerhalb der selben Trunking-Domain, bleiben. Backbone-übergreifende VLANs sind und bleiben die Ausnahme. Die IP-Subnetze sind mit IP-Routern untereinander verbunden und bilden damit das ETHZ-Intranet. Ein Subnetz ist dabei in der Regel mittels virtuellen Interfaces in zwei physischen Routern erschlossen. Diese Interfaces bilden die Schnittstellen an welche die Sicherheitselemente angedockt werden können. Es folgen nun die Ergebnisse der Abklärungen zur Umsetzung der Sicherheitsanforderungen. Die angegebenen Produkte sind jeweils beispielhaft gemeint und sind nicht das Ergebnis einer eigentlichen Evaluation. Transparentes Dieses entspricht im wesentlichen dem heutigen ETHZ-. Die Sicherheitselement im transparenten fast leer und beinhalten nur die allernötigsten Einträge die für transparentes, jedoch stabiles notwendig sind (z.b. Anti-Spoofing Filter). Diese Sicherheitselement werden als Access-Control-List (ACL) innerhalb der bestehenden Router implementiert. machbar; die Verwaltung von Tausenden von ACLs ist aber aufwändig. Default- Dieses wird die meisten bisherigen Subnetze aufnehmen. Die Sicherheitselemente sind ebenfalls als Access-Control-Listen (ACL) in den bestehenden Routern implementiert. machbar; die Verwaltung von Tausenden von ACLs ist aber aufwändig. Des weiteren sind vorgesehen: Mail-Proxy mit Virenscanning und Anti-Spam-Filter Die Mail-Proxy-Funktion ist implementiert mit einem Cluster von Mailservern die von der Sektion Basisdienste verwaltet werden. Das Routing der ankommenden Mails wird durch entsprechende Änderungen in den MX-Einstellungen im DNS eingestellt. machbar; ist bereits in Vorbereitung. Transparenter Web-Proxy Es gibt auf dem Markt Switches, die so konfiguriert werden können, dass sie TCP-Sessions auf bestimmte Destinations-Ports (z.b. 80, 8080) auf einen Web-Proxy-Server umleiten. Da dabei keinerlei Konfiguration im Client-Webbrowser notwendig ist und trotzdem die Vor- und Nachteile des Webproxy zur Anwendung kommen, spricht man von einem transparenten Web-Proxy. Da man aber als normaler User diesen Proxy nicht umgehen kann, also ein eigentlicher Proxy-Zwang besteht, muss das transparent-proxy-system sehr hohen Anforderungen bezüglich Verfügbarkeit und Leistung genügen. Mögliches Web-Proxy-Produkt ist der WebCache von NetApp ( machbar; benötigt aber weitere Abklärungen bezüglich Stabilität und Performance. Signatur-matching innerhalb Web-Proxy das on-the-fly Scanning des Contents auf Viren und andere schädliche Inhalte wie spezifische Hacking-URLs ist an sich möglich, wenn die eigentliche Web-Proxy-Funktion innerhalb oder hinter einem echten Firewall implementiert wird. Eine alternative Möglichkeit zeichnet sich mit Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 16 von 20

17 dem ICAP Protokoll ab (siehe Dabei steht einem normalen Web-Proxy ein ICAP-Server zur Seite, der den Proxy in den Content-Scanning Funktionen unterstützt. machbar; jedoch noch sehr aufwändig. In diesem Bereich muss noch Erfahrung gesammelt und der Markt weiterhin beobachtet werden. TCP-Interception TCP-Interception ist möglich mittels spezialisierter Switches, die auch die Umleitungs-Funktionen für den transparenten Web-Proxy implementieren können. Beispiel dafür sind die AP3500 Switches von TopLayer ( Ob diese Geräte auch unter Produktionsbedingungen genügend stabil und leistungsfähig sind, bleibt abzuklären. machbar; benötigt aber weitere Abklärungen. FTP-Proxy Ein transparenter FTP Proxy ist nicht machbar, weil dazu Proxy-Unterstützung in den FTP- Clients notwendig ist. In den normalen Web-Browsern ist dieser Support wohl vorhanden, jedoch normalerweise nicht konfiguriert. In reinen FTP-Clients ist in der Regel keinerlei Proxy-Unterstützung eingebaut. Der FTP-Proxy ist darum vorgesehen, weil im Default- keinerlei saufbau von aussen nach innen möglich sein soll. FTP baut die eigentliche Datenverbindung vom Server zum Client, also von aussen nach innen, auf. Es gibt wohl den sogenannten Passiv-Mode, bei dem die Datenverbindung ebenfalls vom Client zum Server geschieht. Dieser Passiv- Mode ist jedoch nicht in jedem FTP-Client implementiert und nicht der default-modus in dem FTP arbeitet. D.h. die User müssten darin geschult werden, entweder den Passiv-Mode zu verwenden, oder eben den FTP-Proxy zu benutzen. Beides ist eher mühsam und wird einiges an Support-Aufwand erzeugen. Die Alternative dazu ist, den saufbau einer FTP-Datenverbindung von aussen nach innen zu erlauben. Um das Risiko zu minimieren, könnten allenfalls solche en umgeleitet und über einen echten stateful Firewall geführt werden. machbar; benötigt aber weitere Abklärungen. Geschütztes Die Subnetze im geschützten liegen hinter einem echten Stateful-Inspection Firewall. Diese Subnetze sind also nicht mehr mit einem Router verbunden, sondern der Firewall übernimmt die Router-Funktionen, allenfalls kombiniert mit Network-Address-Translation (NAT). Wir erwarten einen mittelfristigen Bedarf von bis zu Hundert Subnetzen im geschützten. Mittels virtual LANs (VLANs) des Transportnetzwerkes KOMETHng können diese Subnetze an einigen wenigen zentralen Punkten zusammengefasst und auf einigen wenigen Firewalls terminiert werden. Dies bedeutet jedoch, dass der Firewalls mit der im KOMETHng verwendeten VLAN-Technologie kompatibel sein muss. Es ist ebenfalls zu erwarten, dass einige fette Server (z.b. Fileserver oder Middleware-Server) im geschützten sein werden. Daher ist es absolut notwendig, dass das Firewall-System Bandbreiten im Gigabit/Sec-Bereich ohne Probleme verkraften kann. Es gibt auf dem Markt unseres Wissens momentan nur ein Produkt, das diese Bedingungen zu erfüllen im Stande ist: der Netscreen 500 oder 1000 ( machbar; benötigt aber weitere Abklärungen. Was die Proxy-Funktionen betrifft, gilt im wesentlichen die selbe Situation wie im Default-. Getrennte e Die getrennten e werden ebenfalls als VLANs auf KOMETHng realisiert, wo notwendig ergänzt durch getrennte physische Kabel. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 17 von 20

18 Vorgehensweise Eine realistische Vorgehensweise wird sein, dass in einem vernünftig grossen Pilotprojekt innerhalb der Informatikdienste Erfahrungen gesammelt wird. Dabei sollen die offenen Fragen beantwortet und die geeigneten Geräte evaluiert werden. Es gilt ebenfalls, die vorgeschlagenen Default-Rulesets auf ihre Sicherheit und Alltags-Tauglichkeit zu überprüfen. Wir stellen uns vor, dass ein solcher Pilot innerhalb eines halben Jahres abgeschlossen werden kann. Mit den Erfahrungen aus dem Pilot kann dann anschliessend die Umsetzung innerhalb der ETHZ erfolgen, so dass innerhalb eines weitern Jahres die Umsetzung weitgehend abgeschlossen sein wird. Die Arbeitsgruppe stellt sich dabei vor, dass die allermeisten Rechner ohne grosse Änderung in das Default- wechseln. D.h. dass in den Routern zu den meisten Subnetze das Sicherheitselement eingerichtet wird. Die Rechner im transparenten und auch diejenigen im geschützten sind Server und Workstations, an die in punkto Sicherheit erhöhte Anforderungen gestellt werden und darum von professionellem IT-Personal betreut werden. Ist daher damit zu rechnen, dass pro Informatik Support Gruppe ein transparentes Subnetz und ein geschütztes Subnetz (allenfalls einige wenige) eingerichtet werden muss. Auf diesen wenigen speziellen Subnetzen werden die Rechner zusammengefasst, die in das transparente oder geschützte gehören. Es ist also nicht notwendig, dass die bestehenden Subnetze verdoppelt oder verdreifacht werden. Um den administrativen Aufwand des Vereinbarungs-Konzeptes klein zu halten, werden die Informatikdienste mehrere (2 bis 3) Muster-Vereinbarungen entwickeln, die die Sicherheitsbedürfnisse der allermeisten Einheiten abdecken. Diese Rulesets dieser Muster-Vereinbarungen sollen in der Pilotphase erarbeitet und abgestimmt werden. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 18 von 20

19 Anhang 4 Ressourcenbedarf Was kostet Nichtstun Als Einleitung in das Thema Ressourcenbedarf sei das Ereignis vom November 99 in Erinnerung gerufen, wo während rund 3 Wochen wegen den Seiteneffekten einer distributed Denial of Service (ddos) Attacke das der ETHZ zu grossen Teilen nicht funktionierte. Diese Attacke ging von rund 50 Unix-Servern innerhalb der ETHZ aus, die wegen Sicherheitsmängel von ETHZ-externen Crackern übernommen werden konnten und als DoS-Agenten verwendet wurden. Die Reparatur dieser 50 Rechner benötigte etwa 250 Personentage, was etwa 100kFr entspricht. Während dieser 3 Wochen konnte jedoch die gesamte ETHZ-Belegschaft ihre Arbeit nur eingeschränkt erledigen. Wenn wir davon ausgehen, dass während dieser 3 Wochen eine Produktivitätseinbusse von nur 10% erfolgte, kostete dieses Einzel-Ereignis rund 2 Mio Fr. (bei einer Jahreslohnsumme der ETHZ von 400Mio Fr). Nicht eingerechnet sind die Behinderungen in der Lehre. Vom Imageschaden für die ETHZ ganz zu schweigen. Dieses Ereignis vom Nov. 99 ist sicher ein Grossereignis, das zum Glück nicht allzu häufig vorkommt. Es ist seither jedoch schon mehrmals vorgekommen, dass einzelne Rechner den betrieb für mehrere Stunden beeinträchtigt oder sogar lahm gelegt haben. Durch die Hochleistungs-- Anschlüsse steigt auch das Gefährdungspotenzial, das von jedem einzelnen Rechner ausgeht. Es braucht nicht mehr 50 Rechner es reicht einer! Durch diese Entwicklung, aber vor allem durch die im Kapitel Motivation erwähnten Scriptkiddies und Tools-Kits, ist damit zu rechnen, dass auch Grossereignisse öfters auftreten werden. Dies auch, weil Lehre und Forschung je länger je mehr von einem funktionierenden absolut abhängig sind und dadurch auch hochgradig verletzlich werden. In Geld ausgedrückt ist Nichtstun, mit etwas Glück, nicht teurer als die in diesem Bericht vorgeschlagenen Sicherheitsmassnahmen. Es ist jedoch für die ETHZ und deren Ansehen in der Öffentlichkeit sicher besser, wenn in die Verhinderung von Sicherheitsproblemen investiert wird als in deren Reparatur und in frustrierende Wartezeiten. Notwendige Investitionen Für das Transparente und das Default- sind im Rahmen des Projektes KOMETHng bereits die notwendigen Investitionen getätigt oder in der mittelfristigen Investionsplanung berücksichtigt. Für die getrennten e sind ebenfalls keine Investionen notwendig. Falls VPN-Server oder ähnliches für vereinzelte getrennte e notwendig sind, werden diese im Rahmen des jeweiligen Projektes angeschafft. Grössere Investitionen sind jedoch im geschützten notwendig. Firewalls in der von uns benötigten Leistungsklasse sind sehr teuer. Einer der erwähnten Firewalls Netscreen1000 kosten etwa kFr. Zwei Stück sind für einen Produktionsbetrieb notwendig (Redundanz), und ein Stück als Entwicklungs- und Testgerät inkl. Ersatzteillager. Dies bedeutet, dass Investitionen in der Grössenordnung von 1Mio Fr. notwendig sind. Es sind nachher jährliche Reinvestionen in der Grössenordnung von 250 bis 350kFr zu erwarten. Es ist ebenfalls mit Wartungskosten von 100 bis 200 kfr. jährlich zu rechnen. Eine weitere Investition muss in die Anschaffung von Proxy-Servern getätigt werden. Da im Moment noch nicht ganz klar ist, welche Applikationen über Proxy-Server geführt werden und welche Transport-orientierten Massnahmen (z.b Switches zur transparenten Umleitung zu den Proxies), ist nur eine grobe Schätzung möglich. Je nach Anforderungen sollten kFr an Investitionen mit jährlichen Reinvestitionen von kfr. genügen. Ferner sind Intrusion Detection Systeme (IDS) anzuschaffen. Gemäss Konzept soll in jedem Subnetz des geschützten es ein IDS platziert werden. IDS, die im Bereich von Gigabit/Sec mithalten können, sind nicht billig. Je nachdem, ob mit kommerziellen IDS oder mit Open Source Implementationen gearbeitet wird, sind Investitionen von 5 bis 15kFr pro Subnetz zu erwarten. An zentraler Stelle, wo alle IDS-Meldungen zusammengefasst und ausgewertet werden, ist mit kFr Investitionen zu Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 19 von 20

20 rechnen. Ebenfalls gemäss Konzept soll in jedem Subnetz des Default-es auf Wunsch der User eines Subnetzes ein IDS platziert werden können. Ein solches (Massen-)IDS ist sicher Open Source basierend und kostet je nach Leistungsklasse zwischen 2 und 5kFr. Zusammenfassend sind Initial-Investitionen von 1.5 bis 2 Mio Fr. notwendig, bei jährlichen Reinvestitions- und Wartungskosten von kfr. Notwendige personelle Ressourcen Ein solches Sicherheits-Framework, wie es in den Berichten der SecITEK aufgezeigt und skizziert wird und im besonderen die Konzepte in diesem Bericht, gehen weit über die bisherigen Aufgaben der Informatikdienste hinaus und sind ohne zusätzliche personelle Mittel im Aufbau und Betrieb nicht denkbar. Die Abschätzung dieses Bedarfes ist jedoch noch schwieriger als bei den Investitionen. Obwohl keine Investitionen für das transparente und Default- notwendig sind, wird der Aufbau und Betrieb dieser e durch den breiten Einsatz von IP-Access-Listen wesentlich komplizierter und anspruchsvoller. Das Gesamtsystem ist durch die sehr viel grössere Zahl an Fehlermöglichkeiten anfälliger und die Fehlersuche erschwert. Um trotzdem die Stabilität und Verfügbarkeit des Datennetzwerkes zu erhalten und zu verbessern, sind mehr Personal auf hohem technischen Niveau notwendig. Eine Aufstockung des Personals im Datenkommunikations-Bereich von 12 auf Vollzeit- Stellen scheint angebracht. Im Bereich des geschützten s kommen gänzlich neue Aufgaben auf uns zu. Es gilt Know How im Firewall-Bereich aufzubauen und die neuen Firewalls zu betreiben. Dies gilt gleichermassen für die Datentransport-Aspekte als auch die Sicherheits-technischen Aspekte. Ein kleines Team von etwa 2 Vollzeit-Personen, die beide Aspekte abdecken und sich gegenseitig vertreten können, sollte mittelfristig ausreichend sein. Im Bereich IDS gilt es ein Gesamtsystem zu entwickeln, das einerseits ohne grossen Aufwand um weitere IDS erweitert werden kann und andererseits die anfallende Log-Flut auf automatische, aber intelligente Art vorverarbeitet und zusammenfasst. Die resultierenden Meldungen müssen gesichtet und ausgewertet werden. Abgesehen von einem initialen Design des Systems scheint eine Vollzeitstelle für beide Funktionen (Weiterausbau und Log-Auswertung) genügend. Sinnvollerweise sollte diese Stelle mit dem Firewall-Team zusammengelegt werden, so dass 3 Vollzeit-Personen zusammen die Aspekte Firewall und IDS bearbeiten können. Zusammenfassung: Um die in diesem Konzept empfohlenen Massnahmen umsetzen zu können, sind neben den erwähnten Investitionen ungefähr 4-5 zusätzliche Vollzeitstellen notwendig, was in Geld ausgedrückt etwa kfr. pro Jahr bedeutet. Abschlussbericht SecITEK Arbeitsgruppe Firewall / Intrusion Detection Seite 20 von 20