Projekt Intrusion Detection System. Semesterarbeit, Fachhochschule Zürich, Informatik. Semesterarbeit_Einführung_IDS_V06.doc

Transkript

1 Projekt Intrusion Detection System Projektname Arbeitspakete Auftraggeber Autor Projektleiter: Projekt Team: Auftragsnummer Dok Nr. Version Status Einführung eines Intrusion Detection System siehe Phasenplan Semesterarbeit, Fachhochschule Zürich, Informatik R. Caspar R. Caspar, (RC) R. Caspar, (RC) xxx-xxx-xxx Semesterarbeit_Einführung_IDS_V06.doc final Datum 20. Juni 2003 Druckdatum Verteiler Roger Caspar Versionenliste Version Dateiname Datum Autor 01 Semesterarbeit_Einführung_IDS_v01.doc Januar 2003 R.Caspar 02 Semesterarbeit_Einführung_IDS_v02.doc R.Caspar 03 Semesterarbeit_Einführung_IDS_v03.doc R.Caspar 04 Semesterarbeit_Einführung_IDS_v04.doc R.Caspar 05 Semesterarbeit_Einführung_IDS_v05.doc R.Caspar Qualitätssicherung Review Dokument Datum Status 06 Semesterarbeit_v06.doc final Name: Erstellt R.Caspar Geprüft T. Pospisek Freigegeben T. Pospisek Visum: Semesterarbeit, R.Caspar, FHZH 1/62

2 1. PROJEKTANTRAG 5 2. KURZBESCHREIBUNG 6 3. EINFÜHRUNG Aufgabe Funktionale Anforderungen Aufgaben 8 Bedrohungsanalyse 9 Sensor Integrität 9 Produkte eruieren 9 4. VORGEHEN 9 5. RANDBEDINGUNGEN 9 6. INFRASTRUKTUR Server Topologie Netzwerk Topologie ZU ERWARTENDE RESULTATE Analyse Bewertung der IDS Hersteller Was muss abgegeben werden TERMINE Start/Ende Zeitplan und Meilensteine 11 Meilensteine: 12 Zeitplan: PROJEKTMANAGEMENTPLAN Vorgehens Model 14 Meilensteine Organisationsstruktur Organisation: Abgrenzung und Schnittstellen Projektverantwortlichkeiten Risk Management BEDROHUNGSANALYSE Sinn und Zweck Bestehende Bedrohungsarten Netzwerk 15 Sniffen, Mithören 16 Semesterarbeit, R.Caspar, FHZH 2/62

3 Netzkomponente hinzufügen 16 Spoofing (IP, MAC) 17 (D)DoS 17 Port-Scan Management 18 Account Missbrauch (Verwendung eines fremden Login) 18 Passworte 18 Lokaler Zugriff 19 Test Accounts / Test User 19 Zerstörung durch löschen Prozesse 21 Viren 21 Trojaner 21 Schwachstellen in Server-Diensten 22 Hack-Tools 22 Java 23 ActiveX RISIKOBEWERTUNG Risikobewertung Risikobewertung von Sicherheitslücken / Angriffsarten SENSOR UND MANAGEMENT INTEGRITÄT Kommunikation zwischen Sensor und Managementstation stören 25 Gefälschte Managementstation 25 Gefälschte Netzwerkverbindung 25 DoS der Managementstation 25 DoS des Sensors 26 Kommunikationsunterbruch Angriffspunkte beim Sensor 26 Der Sensor wird ausgetauscht 26 Abschalten des Sensors, durch beenden des Prozesses Fazit - Integrität EVALUATION Ein IDS-System und seine Anforderungen Bewertungskriterien 28 Allgemeine Kriterien: Übersicht der bekannten Produkte 28 etrust Detection v ( früher Session Wall-3) 29 EnGarde T-Sight Snort Secure IDS 2.5 Cisco (früher NetRanger) 30 Dragon 6.0 Intrusion Detection von Enterasys Networks 31 SecureNet Pro Version von Mime Star 31 Real Secure 7.0 von ISS Bewertung; Stufe Bewertung; Stufe 2 34 Semesterarbeit, R.Caspar, FHZH 3/62

4 14. IMPLEMENTATION DES SYSTEMS Vorbemerkung Benötigte Hardware 35 Managementstation: 35 Sensor: Software Installation der Managementstation 36 Setup des Betriebssystems Anschliessendes Hardening Installation des Sensors Initialisieren der Datenbank Setup von Snortcenter Sensor Agent VORBEREITUNG VOR DER ERSTEN INBETRIEBNAHME Sensoren definieren Netze definieren Signatur Management Eigene Signaturen erstellen Übersicht Snortcenter Auswertung der Alert GEFUNDENE ERKENNTNISSE Einführung Auftretende Probleme MIGRATION IN EINE SKALIERBARE/SINNVOLLE INFRASTRUKTUR Ausgangslage Lösungsansatz Integration mit einem Loadbalancer (Fireproof) Übersicht Fireproof Änderung des Signatur Management ERFAHRUNGEN MIT DER GEWÄHLTEN LÖSUNG Allgemeines Inventar der Infrastruktur Bringt das IDS den gewünschten Nutzen 56 Semesterarbeit, R.Caspar, FHZH 4/62

5 Reine Informationssammlung Wirkliche Angriffe Gefundene Angriffe Fazit GLOSSAR ANHANG Referenzen Projektantrag Projektantrag für Semesterarbeit Bezeichnung: Evaluation / Einführung eines IDS (Intrusion Detection System) Auftraggeber: Projektleiter/Verantwortlicher: Roger Caspar Dozent: T.Pospisek tpospise@fhzh.ch Problembeschreibung: In heutigen Netzwerken ist es nur erschwert möglich, alle Verbindungen und die damit verbundenen Angriffe zu überwachen und somit auch darauf reagieren resp. agieren zu können. Somit ist man Angriffen ausgesetzt und entdeckt solche, wenn überhaupt erst zu dem Zeitpunkt, wo sie eintreten und das System lahm legen oder beschädigen. Ausgangslage: Heute werden Paketfilter und Firewall für die Sicherheit der Server und deren Services eingesetzt. Diese Sicherheitsvorkehrungen decken alle Anforderungen zum Schutz der Layer 3 und 4 des OSI Modells, weiter haben Stateful Inspection Firewalls eine höhere Sicherheit als Paketfilter, weil sie eine Session Table führen und auch gegen Fragmentierung schützen. Firewalls und Paketfilter loggen jedoch nur gegen bekannte Ports und unbekannte Ports. Sie sind nicht in der Lage, weiterführende Logs zu erstellen, welche tiefer in das Protokoll von TCP/IP gehen. Es soll nun ein System eingeführt werden, mit dem man mehr Möglichkeiten hat, den Netzwerkverkehr nach allen Wünschen zu Überwachen. Zielsetzung/Zielinhalte: Folgende Punkte sollen erkannt, und danach Lösungen für das Problem gefunden werden. - Bedrohungsanalyse erstellen, welche die Schwächen eines Netzwerkes aufzeigt - Möglichkeit von IDS Sensoren zum detektieren von Angriffen über das Netzwerk. - sowohl für 2-tier- wie auch für 3-tier Netzwerke - Nutzen/Gefahren solcher Sensoren sollen erkannt werden - Verifizieren der diversen IDS Herstellern Semesterarbeit, R.Caspar, FHZH 5/62

6 - Kostenanalyse (was kostet ein solches IDS System) - wie skalierbar ist es (Vergleich Kosten - Skalierbarkeit) - Die IDS Managementstation erfasst alle Meldungen der Sensoren und zeigt diese an. - Implementierung eines solchen IDS - Detaillierter Plan zur Einrichtung der Sensoren und des Management System (Datenbank) - Plan zur Auswertung der erhaltenen Daten Kostenbudget: Anfallende Kosten werden vom Auftraggeber übernommen Termin und Kosten: Die Termine sind dem Projektplan zu entnehmen. Darin sollen alle Meilensteine und die Phasen für die oben erwähnten Ziele ersichtlich sein. Vorsteher Fachstudium Begleitender Dozent Semesterarbeit, R.Caspar, FHZH 6/62

7 2. Kurzbeschreibung Es soll ein Intrusion Detection System evaluiert werden. Dieses Intrusion Detection System, besteht aus einer Managementstation und/ oder einem Datenbank Server, und einem Sensor oder mehreren Sensoren (je nach Bedarf). Die Sensoren befinden sich auf Rechnern, die alles überwachen. Sie melden Attacken einer zentralen Managementstation/DB Server. Diese verwaltet alle Konfigurationen der verschiedenen Sensoren. Im Zusammenhang mit dem IDS System, soll auch eine Risiko und Bedrohungsanalyse für das Firmennetzwerk gemacht werden. Aufgaben: Vorarbeit: Bedrohungsanalyse erstellen, welche die Schwächen eines Netzwerkes aufzeigt. Möglichkeiten zur Sicherstellung der Sensor Integrität sollen gesucht werden. Schon erhältliche Komponenten suchen. Sensor Sensor zum detektieren von Angriffen über das Netzwerk. Updaten der Angriffs-Signaturen. Angriffe sollen an die Managementstation gemeldet werden. Managementstation / DB-Server Managementstation erfasst alle Meldungen und zeigt diese an. Auf der Managementstation werden die Daten in einer Datenbank abgelegt und mittels eines sinnvollen Kollerationstool entsprechend dargestellt. Sie stellt Update-Signaturen für die Sensoren bereit. Die Managementstation überprüft, ob die Sensoren nicht deaktiviert wurden. Alle Konfigurationen der Sensoren werden von der Managementstation aus verwaltet. 3. Einführung Viele Statistiken haben gezeigt, dass Angriffe auf Computersysteme zu 70% von innerhalb einer Firma ausgeführt werden. Die Firmen schützen sich oft sehr gut gegen Angriffe aus dem Internet. Der Schutz gegen interne Angriffe fehlt und die internen Angriffe werden gar nicht bemerkt. Mit dieser Evaluation soll eine Möglichkeit aufgezeigt werden, wie Angriffe aus dem Internet, sowie firmeninterne Angriffe, sichtbar gemacht werden können Aufgabe Die Aufgabe besteht darin, einen Sensor in das Netzwerk zu integrieren, welcher bekannte wie aber auch selbstgeschrieben Angriffe (anhand von Signaturen) auf Computersysteme Semesterarbeit, R.Caspar, FHZH 7/62

8 erkennt und an eine zentrale Stelle meldet. Zudem sollen die Sensoren die neuen Angriffsmuster von der zentralen Stelle beziehen. Die Managementstation soll die für die Sensoren bereitgestellten Signaturen, automatisch im Internet herunterladen und somit immer die aktuellsten Signaturen bereitstellen. Abbildung 1 Vereinfachte Topologie 3.2. Funktionale Anforderungen Die Anforderungsanalyse ist Teil des Projektes. Die folgenden Anforderungen müssen in die Anforderungsanalyse einfliessen: IDS Sensor:?? Erkennen von Angriffen über das Netzwerk?? Automatisches Update der Angriffs-Muster?? Angriffe auf die Managementstation IDS Managementstation:?? Erfassen und Anzeigen der gemeldeten Angriffe?? Speichern der Alerts in einer Datenbank?? Update der Signaturen bereit halten?? Verwalten der Konfigurationen Kommunikation zwischen Sensor und Mgmt. Station:?? Die Kommunikation sollte verschlüsselt oder über ein dediziertes Netzwerk erfolgen?? Nur authentifizierte Verbindungen?? Wenn möglich Standardprotokolle verwenden Semesterarbeit, R.Caspar, FHZH 8/62

9 3.3. Aufgaben Die folgenden Problembereiche sollen bearbeitet werden: Bedrohungsanalyse - Welche Bedrohungen bestehen in einem firmeninternen Netzwerk? - Wie können Angriffe erkannt werden? Sensor Integrität - Wie kann verhindert werden, dass der Sensor manipuliert wird? - Kann festgestellt werden, wenn der Sensor manipuliert oder deaktiviert wurde? Produkte eruieren - Gibt es bereits Komponenten, welche für diese Aufgabe verwendet werden können? 4. Vorgehen Ein Projektmanagementplan ist als erstes zu erstellen und enthält:?? Eine erste Aufteilung der Aufgaben?? Berücksichtigung der vorgegebenen Teilaspekte. Die genaue Aufteilung muss spätestens nach der Anforderungsanalyse erfolgen.?? Den Projektplan (Zeitplan) und die Meilensteine. 5. Randbedingungen Betriebskomponenten: Die Systeme werden auf einer Unix Sun Solaris oder Linux Plattform betrieben. Das entwickelte System ist auf diesen Plattformen zu optimieren. Gewisse bereits bestehende Komponenten sollen, wenn möglich wieder verwendet werden. Modularität und Ausbaubarkeit: Beim Bau des IDS soll zudem auf Modularität und Ausbaubarkeit geachtet werden. Eine ausführliche Dokumentation des erarbeiteten Systems soll erstellt werden. Projektspezifisch: Eine Projektpräsentation und ein schriftlicher Bericht werden erwartet. Diese sind vor der Präsentation vollständig bereitzustellen. An Projektmeetings, wird der aktuelle Stand des Projekts kontrolliert, und es werden Fragen und Probleme besprochen. Semesterarbeit, R.Caspar, FHZH 9/62

10 6. Infrastruktur 6.1. Server Topologie Die vorgefundene Server Topologie, besteht zum grössten Teil aus verschiedenen Modellen der Firma Sun. Auf diesen Servern laufen, die Betriebssysteme Sun Solaris Version 2.7, und Version 2.8. Diese Version von Unix (Solaris), sind auf keinem Server in der Standard Installation vorzufinden, alle sind auf dem aktuellen Patschlevel. In den meisten Teilen des Netzwerkes, sind keine Server von Microsoft zu finden. Teilweise werden Linux Server eingesetzt. Diese werden aber nicht für den produktiven Dienst eingesetzt! Es existiert ein Programm für die Systemsicherheit, welche in die bestehende Unix/Linux Umgebung integriert werden muss. Anmerkung: Die Server Topologie ist für die Einführung eines Intrusion Detection System und für dessen Funktion, nur von bedingter Bedeutung Netzwerk Topologie Das komplette Netzwerk, alle DMZ s, sowie der gesamte Backbone besteht aus Cisco Produkten. Die Mitbenützung des Netzwerk Equipment, ist für das IDS System von Bedeutung, da die Überwachung des gesamten Verkehrs nur im Zusammenspiel mit dem Netzwerk vollzogen werden kann. Um die Funktionen der Sensoren überhaupt zu gewährleisten, wird auf den Backbone Switchen (Catalyst 6000), die Spiegelungsfunktion (Span resp. rspan, bei Cisco Produkten) eingeschaltet. Diese Spiegelungsfunktion ermöglicht es einem, den gesamten Netzwerkverkehr, an einem Anschlusspunkt zu überwachen. Sowohl Einkommender- wie auch Ausgehender Verkehr. Semesterarbeit, R.Caspar, FHZH 10/62

11 7. Zu erwartende Resultate 7.1. Analyse Erwartet wird eine entsprechende Bedrohungsanalyse, mit allen potentiellen Bedrohungen, für Dienste und Daten Bewertung der IDS Hersteller Es soll aus allen auf dem Markt erhältlichen Herstellern, der für den entsprechenden Anwendungszweck beste Hersteller, herauskristallisiert werden. Anhand dieser Evaluation, kann danach die benötigte Software und auch Hardware bestellt werden Was muss abgegeben werden?? Projektmanagementplan und Projektplan?? Projektdokumentation?? Bedrohungsanalyse?? Risikoanalyse?? Produkte Evaluation?? Risikobewertung?? Einführungsplan 8. Termine 8.1. Start/Ende Da es sich bei diesem Projekt um eine Semesterarbeit der Informatikabteilung der FHZH handelt, sind die Randtermine festgelegt. Insbesonders ist darauf zu achten, dass am Schluss des Projektes eine angemessene Präsentation stattfindet. Die Vorbereitung dieser Präsentation, nimmt natürlich auch noch Zeit in Anspruch. Projektstart: 09. Dezember 2002 Projektende: 28. Mai 2003 Präsentation: Juni 2003 Für die Präsentationsvorbereitung und Durchführung, sollten etwa weitere zwei Wochen eingeplant werden. Es müssen Folien erarbeitet werden Zeitplan und Meilensteine Zeitplan und Meilensteine für das Projekt, sind zusammen mit dem begleitenden Dozenten abzusprechen. Nach einem Review des begleitenden Dozenten und allfälligen Änderungsnassnahmen, gelten diese Rahmendaten und Meilensteine als verpflichtend. Durch unerwartete Probleme, können die Termine einer Änderung unterliegen. Semesterarbeit, R.Caspar, FHZH 11/62

12 Die angestrebten Projektziele, in vorgesehener (geplanter) Zeit zu erreichen, hat deshalb Priorität! Meilensteine: Folgende grössere und abschliessbare Ziele sind vorgegeben: Vorgehen und Randbedingungen Eine Einarbeitung in die komplexe Theorie des IDS, erfordert einigen Einsatz. Eine detaillierte Einarbeitung in das Projekt ist in diesem Fall sehr wichtig, da es sich um eine Art Forschungsprojekt handelt. In diesem Projekt sind viele Ungewissheitsfaktoren (Machbarkeit, Aufwand, unerwartete Probleme), welche es gilt, so weit möglich einzuschränken. Nur gründliche Vorstudien garantieren den grösst möglichen Projekterfolg oder Projektgewinn Erwartete Resultate Die genaue Formulierung der zu erwartenden Resultate, ist ein wichtiger Punkt. Hier entscheidet sich über Projekterfolg oder Projektmisserfolg Projektmanagementplan Der Projektmanagementplan wird vom Dozenten kontrolliert und anschliessend ausgebessert. Erst nach einer Freigabe durch den Dozenten gilt dieser Plan als verbindlich Bedrohungsanalyse Die IT-Bedrohungsanalyse, ist im wesentlichen eine Wissens- und Erfahrungsanalyse. In einer Analyse, werden die wichtigsten IT-Risiken zusammengestellt. Alle Risiken und Bedrohungen für den Einsatz eines IDS-Systems, müssen analysiert werden Produktevaluation Eine technische Lösung für das IDS wird erarbeitet. Alle Komponenten werden genau spezifiziert. Von allen Herstellern wird eine Produktevaluation, hinsichtlich Preis, Leistungsmerkmale und Qualität durchgeführt Risikoanalyse Die grössten Risiken und Gefahren sollen erkannt werden. Ausführliche Risikoanalysen brauchen grosse Ressourcen an Zeit und Fachkräften, welche im sich schnell verändernden IT-Bereich nicht vorhanden sind. Deshalb kommen Quick-and-Dirty Analysen zum Einsatz. Semesterarbeit, R.Caspar, FHZH 12/62

13 Sensor Integrität Eine Überprüfung der möglichen Sensor Integrität wird durchgeführt. Dabei werden Machbarkeit, Manipulierbarkeit und Schwachstellen (Angriffspunkte), gesucht und überprüft Einführungsplan Nach den verschiedenen Analysen, der einzelnen Phasen, wird ein Einführungsplan erarbeitet. Dieser stützt sich auf die spezifische Umgebung und ist auf diese Infrastruktur abgezielt. Zeitplan: Die Meilensteine werden jeweils bei Phasenende erreicht. Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Vorgehen und Randbed. Erwartete Resultate Projektmanage mentplan Bedrohungsanal yse Produktevaluati on Phase 6 Risikoanalyse Phase 7 Sensor Integrität Phase 8 Einführungsplan Phase 9 Präsentation Dokumentation dez dez dez jan jan jan jan feb feb feb feb mar mar mai mai Semesterarbeit, R.Caspar, FHZH 13/62

14 9. Projektmanagementplan 9.1. Vorgehens Model Meilensteine Meilenstein Tätigkeiten und Resultate Datum 1?? Vorgehen und Randbedingungen ?? Erwartete Resultate?? Projektmanagementplan 2?? Bedrohungsanalyse ?? Produkte Evaluation ?? Risikoanalyse ?? Sensorintegrität 5?? Einführungsplan ?? Projektende?? Erstellen der gesamten Dokumentation?? Abgabe/Präsentation Organisationsstruktur Das Projekt wird von R. Caspar bis zur Projektabgabe durchgeführt Organisation: Abgrenzung und Schnittstellen Die dem Projekt übergeordnete Organisation ist die FHZH. Direkter Ansprechpartner für dieses Projekt ist der begleitende Dozent Projektverantwortlichkeiten Die Projektverantwortlichkeiten sind wie folgt definiert: Funktion / Aktivität Begleitender Dozent Student Verantwortliche Person T. Pospisek Roger Caspar, RC 9.5. Risk Management Zur Zeit sind folgende Risiken zu sehen:?? Es ist uns zur Zeit nicht bekannt, wie die Integrität der verschiedenen Softwarekomponenten sichergestellt werden kann. Massnahmen: 1. Bedrohungsanalyse mit Möglichkeiten zur Sicherstellung der Agent Integrität erstellen. Semesterarbeit, R.Caspar, FHZH 14/62

15 10. Bedrohungsanalyse Sinn und Zweck Diese Analyse soll zeigen, welche potentiellen Schwachstellen in einem Netzwerk zufinden sind und welcher Bedrohung ein Sensor ausgesetzt ist. Es soll kurz aufgezeigt werden, wie diese Schwachstellen behoben werden können. Es sollen wo möglich, für jede Lösung, die Vorteile und Nachteile kurz diskutiert werden Bestehende Bedrohungsarten Für einen Rechner im Netzwerk, gibt es verschiedene Arten der Bedrohung. Es wurden acht Hauptklassen erkannt. Jede Bedrohung besteht aus einem Angreifer, einem Ziel und einem Angriffspunkt. Für jede Bedrohung gibt es detektions Möglichkeiten und Gegenmassnahmen. Bedingung: Es wird davon ausgegangen, dass sich noch kein Hacker oder Cracker im lokalen Netzwerk befindet. Ziel des Angriffs: Diese Punkte zeigen die Ziele, die der Angreifer verfolgen kann. Zugriff auf Daten: Sensitive Daten können manipuliert, entwendet, gelesen oder gelöscht werden. Zugriff auf Account: Alle Manipulationen, die mit dem erlangten Account getätigt werden können, können auch vom Angreifer ausgeführt werden. Zugriff auf Funktionalität: Zugriff auf Dienste von Servern. Diese können vom Angreifer ausgeführt oder verändert werden. Schädigung der Firma: Materielle Schäden oder immaterielle Schäden, die direkt oder indirekt die Firma treffen. Sicherheitsmassnahmen umgehen: Die getroffenen Sicherheitsmassnahmen werden umgangen. Detektion von Sicherheitslücken: Es wird nach Sicherheitslücken im System, zwecks späterem Eindringen gesucht. Behinderung der Funktionalität: Die Funktionalität von Arbeitsmechanismen werden verhindert. Eindringen in das System: Der Angreifer gelangt ins System. Er hat keinen Schaden angerichtet, weiss aber von der Sicherheitslücke und kann jeder Zeit wieder kommen um Schaden anzurichten. Semesterarbeit, R.Caspar, FHZH 15/62

16 10.3. Netzwerk Der Rechner wird von einem zweiten Rechner bedroht. Der zweite Rechner kann vom internen Firmennetzwerk sein, aber auch aus dem Internet kommen. Sniffen, Mithören Die Daten von einem Rechner werden mitgehört, aber nicht verändert. Ziel des Angriffs:?? Zugriff auf Daten?? Zugriff auf Account Massnahmen: Detektierung: Switches einsetzen Durch Switches werden nur Datenpakete weitergeleitet, welche für den Rechner bestimmt sind. Zur Filterung werden die MAC-Adressen verwendet. + Um Sniffen zu können, muss die Netzwerkkarte in den Promiscouse-Mode gebracht werden. Dieses Verfahren kann herausgefunden werden. - Nicht angemeldete Komponenten können nicht überprüft werden. - Auch Switches können dazu gebracht werden, wie ein Hub zu funktionieren und den ganzen Verkehr an alle Anschlusspunkte zu senden. Netzkomponente hinzufügen Hub, Router, Server, Modem, Netzwerkkarte oder PC, wird dem Netzwerk hinzugefügt. Auf jeder Komponente könnten Programme laufen, die das Firmennetzwerk ausspionieren könnten. Massnahmen: DHCP verwenden + Der DHCP-Server kann so konfiguriert werden, das unbekannte Netzwerkkomponenten keine IP-Adresse bekommen. - Der DHCP-Server kann nicht verhindern, dass Netzwerkkomponenten ins Netzwerk hinzugefügt werden. Manuelle (persönliche) Kontrolle + Jede unerlaubte Komponente kann identifiziert werden. - Eine permanente Überwachung ist zu teuer - Komponenten können nur temporär hinzugefügt werden, danach wieder entfernt werden. Diese Manipulation kann nicht festgestellt werden. Semesterarbeit, R.Caspar, FHZH 16/62

17 Spoofing (IP, MAC) Ein Rechner gibt sich als einen Anderen aus. Dies kann IP- oder MAC-Spoofing sein. Damit kann der Angreifer eine Trust-Verbindung zwischen zwei Maschinen übernehmen und erhält Zugriff auf Daten. Er kann versuchen den Zielcomputer (Server oder Client) zu übernehmen. Ziel des Angriffs:?? Zugriff auf Daten?? Zugriff auf Account?? Sicherheitsmassnahmen umgehen?? Eindringen in das System Massnahmen: Detektierung: Switches + Ein IP-Spoofing kann verhindert werden. - Keine Unterbindung von MAC-Spoofing. Verschlüsselte Kommunikation Session kann übernommen werden, Datenstrom kann nicht entschlüsselt werden. IDS + Detektiert ein Spoofing und kann eine Meldung absetzen. (D)DoS Mit dieser Attacke wird versucht, den angegriffenen Computer unerreichbar für dritte Computer zu machen. Es wird die Funktionalität des Systems behindert. Ziel des Angriffs:?? Behinderung der Funktionalität?? Schädigung der Firma Massnahmen: Detektierung: Firewall mit Detektion und Sperrung + Ist einfach zu realisieren. + Mit der Firewall kann der Angreifer ignoriert werden, da seine DoS-Attacke nicht die gewollte Maschine erreicht. - Der Firewall wird zum Ziel des DoS IDS + Ist einfach zu realisieren. Lokale Kontrolle ob kein (D)DoS - Client auf der Maschine läuft + Die Ursache kann bei den Wurzeln gepackt werden. Es ist sofort klar, von wo aus die Attacke gemacht wird. Semesterarbeit, R.Caspar, FHZH 17/62

18 Port-Scan Ein Rechner macht einen Port-Scan auf einen anderen Rechner, damit herausgefunden wird, auf welchem Port Dienste laufen. Ziel des Angriffs:?? Detektion von Sicherheitslücken Massnahmen: Einsatz eines Firewall + Ist einfach zu realisieren. - Mit der Firewall kann der Angreifer ignoriert werden, damit sein Scan nicht die gewollte Maschine erreicht. Detektierung: Einsatz eines IDS + Ist einfach zu realisieren Management Eine unbefugte Person gelangt in das System. Account Missbrauch (Verwendung eines fremden Login) Jemand ist zum Passwort eines bestehenden Accounts gekommen und verwendet diesen. Er hat zudem alle Berechtigungen des Accounts. Ziel des Angriffs:?? Zugriff auf Daten?? Zugriff auf Account?? Zugriff auf Funktionalität?? Sicherheitsmassnahmen umgehen?? Eindringen in das System Massnahmen: Detektierung: Ortsbeschränkte Zugriffsrechte + Ein Login kann nicht in der gesamten Firma verwendet werden. Systemkritische Logins wie das root -Login können nur in speziellen Bereichen oder lokal benützt werden. Sensitive Bereiche können so speziell abgesichert und überwacht werden. - Kein einloggen in fremden Bereichen mehr möglich, was störend sein kann. Statistisches IDS + Detektiert Login auf fremden Maschinen. + Detektiert Login zu ungewöhnlichen Zeiten. - Heikles System während der Trainingsphase. Passworte Um ein Passwort herauszufinden, gibt es verschiedene Methoden. Entweder hat der User kein, oder ein sehr einfaches Passwort. Manchmal werden auch Passwörter mit Post-It Zetteln an den Bildschirm geklebt. Eine Möglichkeit ist auch, das Passwort beim Eintippen mitzuhören. Zuletzt gibt es noch die Möglichkeit, das Passwort mit einem Tool zu knacken. Ziel des Angriffs:?? Zugriff auf Daten Semesterarbeit, R.Caspar, FHZH 18/62

19 ?? Zugriff auf Account?? Zugriff auf Funktionalität?? Eindringen in das System Massnahmen: Detektierung: Passwort - Kontrollen gegen schwache Passworte (Passwort -Cracker) + Schwache Passwörter können herausgefunden werden, eventuell bei der Eingabe sogar abgelehnt werden. Periodische Änderung + Wenn ein Passwort schon geknackt wurde, es aber nicht mehr zum Login passt, ist es nutzlos. Je einfacher das Passwort, desto öfters sollte es gewechselt werden. - Es ist eine Schulung der Mitarbeiter nötig. Lokale Kontrolle ob Passwort -Cracker läuft + Mögliche Angreifer können sofort herausgefunden werden. - Nicht alle Passwort - Cracker sind bekannt. Manueller Rundgang (gegen Passwörter am Bildschirm) +Passworte sind nicht mehr einfach vom Bildschirm zu lesen. - Passwortzettel werden versorgt, aber immer noch aufgeschrieben. IDS + Zufälliges ausprobieren von Login & Passwort (mit Passwortliste) kann detektiert werden. Lokaler Zugriff Ein Benutzer sperrt seinen Arbeitsplatz nicht, somit kann eine andere Person mit dessen Account arbeiten. Ziel des Angriffs:?? Zugriff auf Daten?? Zugriff auf Account?? Zugriff auf Funktionalität Massnahmen: Detektierung: Kurze Zeiten bis Arbeitsplatz gesperrt wird (Screen- Saver). + Arbeitsplatz wird sicher gesperrt. - Bei kurzer Abwesenheit wird der Arbeitsplatz auch gesperrt. Ein wiedereingeben des Passwortes ist mühsam, daher könnten Mitarbeiter kurze Passwörter verwenden. Keine Test Accounts / Test User Der Eindringling verwendet einen Testaccount, welcher eventuell ein einfaches Passwort hat. Semesterarbeit, R.Caspar, FHZH 19/62

20 Ziel des Angriffs:?? Zugriff auf Daten?? Zugriff auf Account?? Zugriff auf Funktionalität?? Eindringen in das System Massnahmen: Zeitliche Beschränkung der Benutzung (bis Account ungültig wird). + Ein vergessener Account schaltet sich selbständig ab. Zeitliche Gültigkeit (von wann bis wann der Account gültig ist). + Normale Tests werden zu Bürozeit gemacht. Daher sind Testaccounts auch nur zu dieser Zeit gültig. Ausserhalb der Bürozeiten sind diese Account gesperrt und niemand kann damit arbeiten. Örtliche Gültigkeit + Benutzung nur auf wenigen Maschinen (ev. getrenntes Testnetz) möglich. + Keine Möglichkeit damit auf einem Server einzuloggen. Zugriffsrestriktionen + Jeder Testaccount wird für einen bestimmten Test aktiviert. Andere Bereiche können mit dem Testaccount nicht eingesehen oder verändert werden. Detektierung: Statistisches IDS + Detektiert ungewöhnliche Logins. - Das Testsystem ist vielen Änderungen unterworfen. Das IDS befindet sich oft in der Trainingsphase. - Befindet sich der Testaccount im eigentlichen Firmennetzwerk, so ist der Angriff schwer zu detektieren. Man kann nicht unterscheiden ob das Muster von einem Mitarbeiter oder von dem Testaccount stammt. Zerstörung durch löschen Eine Person zerstört Daten, indem sie diese löscht. Ziel des Angriffs:?? Schädigung der Firma?? Behinderung der Funktionalität Massnahmen: Backups + Daten können rekonstruiert werden. - Der Arbeitsaufwand bis zum letzten Backup geht verloren. Zugriffsrestriktionen + Nicht alle Benutzer können die Datei löschen, da ihnen diese Aktion nicht gestattet ist. Semesterarbeit, R.Caspar, FHZH 20/62

21 Detektierung: Log File + Jede Permutation wird registriert, somit können Änderungen verfolgt werden. - Im Log File steht nur, welche Datei welche Permutation erfahren hat. Wenn eine Datei gelöscht wird, steht nicht, was in der Datei zuvor gestanden hat Prozesse Auf einem Windows NT laufen verschiedene Prozesse. Diese Prozesse werden oft mit Admin - Rechten gestartet, und laufen meist im Hintergrund. Diese sind für den Benutzer nicht direkt sichtbar. Im folgenden eine Liste der gefährlichsten Prozesse: Viren Ziel des Angriffs:?? Zugriff auf Daten?? Behinderung der Funktionalität Massnahmen: Virenscanner + Erkennt Viren und kann diese eventuell entfernen. - Nicht alle Virensignaturen sind bekannt. - Mühsames updaten. Trojaner Durch Trojaner erhalten unberechtigte Personen, Zugriffsrechte auf eine Maschine. Ziel des Angriffs:?? Zugriff auf Daten?? Zugriff auf Account?? Zugriff auf Funktionalität?? Sicherheitsmassnahmen umgehen?? Eindringen ins System Massnahmen: Virenchecker + Virenchecker können die Trojaner wie Viren erkennen und melden. Die Trojaner werden eventuell sogar entfernt. - Nicht alle Versionen von Trojanern sind bekannt, daher kann der Virenchecker nicht alle erkennen. Nur die Bekanntesten werden erkannt. - Mühsames updaten. Personal Firewall + Jeder Trojaner muss eine Verbindung aufbauen, damit er kommunizieren kann. Dies verhindert eine Personal Firewall. Detektierung: IDS + Da die bekannten Trojaner immer auf den gleichen Ports kommunizieren, kann dies ein IDS feststellen. Danach kann eine Meldung an die Managementstation gemacht werden. Semesterarbeit, R.Caspar, FHZH 21/62

22 - Unbekannte Trojaner werden so nicht erkannt, da es wie ein normaler Netzwerkverkehr aussehen könnte. - Mühsames updaten. Schwachstellen in Server-Diensten Server-Dienste haben einige Schwachstellen, über welche der Angreifer in das System gelangen kann. Ziel des Angriffs:?? Zugriff auf Daten?? Zugriff auf Account?? Zugriff auf Funktionalität?? Sicherheitsmassnahmen umgehen?? Behinderung der Funktionalität?? Eindringen in das System Massnahmen: Personal Firewall. + Mit einer Personal Firewall kann gesagt werden, wer mit dem Server kommunizieren darf. - Fehlerhafte Pakete, die den Server zum abstürzen bringen, werden nicht herausgefiltert. Wenn der Server permanent auf dem neusten Stand gehalten wird, können Bugs eliminiert werden. Die CERT gibt sporadisch Recommendations heraus. In diesen, könnten die neusten Erkenntnisse von Sicherheitslücken über den Server stehen. Diese Erkenntnisse könnten für die Filterregeln vom IDS oder Firewall verwendet werden. Updates können nicht nur Bugs beheben, sondern auch neue Bugs ins System bringen. IDS. + Fehlerhafte Pakete werden detektiert und an die Managementstation eine Meldung gesendet. - Nur bekannte Fehlpakete werden detektiert. - IDS ist nur eine Detektion. Es kann keine direkte Aktion auf das fehlerhafte Paket anwenden. Port-Scanner. Mit dem Port-Scanner kann überprüft werden, ob irgendwelche Ports offen sind. Jeder Port-Scan ist eine mögliche Attacke auf das System. Läuft auf diesem System ein IDS mit Firewall - Funktionalität, wird der Angreifer automatisch ignoriert. Hack-Tools Mit einem Hack-Tool kann herausgefunden werden, wo Schwachstellen im System vorhanden sind. Semesterarbeit, R.Caspar, FHZH 22/62

23 Ziel des Angriffs:?? Zugriff auf Daten?? Zugriff auf Account?? Zugriff auf Funktionalität?? Sicherheitsmassnahmen umgehen?? Detektion von Sicherheitslücken?? Eindringen in das System Java Ein Java-Programm, das lokal gestartet wird, hat alle Rechte die ein Java-Applikation haben kann. Somit kann dieses Java-Programm alles machen. Ziel des Angriffs:?? Schädigung der Firma?? Sicherheitsmassnahmen umgehen?? Eindringen in das System ActiveX ActiveX hat keine Sicherheitsmechanismen (wie z.b. Sandbox). Ziel des Angriffs:?? Schädigung der Firma?? Sicherheitsmassnahmen umgehen?? Eindringen in das System 11. Risikobewertung Die verschiedenen Aspekte der Risikobewertung werden hier kurz diskutiert. Es soll zeigen, welche Wahrscheinlichkeit sie haben, dass sie auftreten und wie gross der Schaden ist, wenn sie auftreten. Risiko = Auftreten * Schaden Risikobewertung Der Zugriff auf Daten und Schädigung der Firma, sind die grössten Bedrohungen der wir direkt ausgesetzt sind. Es gibt auch Täter, die nicht die Daten angreifen, sondern die Verfügbarkeit und Integrität.?? Zugriff auf Daten o Versucht man ein System zu schützen, so muss darauf geachtet werden, das ausreichende Sicherheitsmassnahmen getroffen werden. Die verhindern, dass firmensensitive Daten gelesen, entwendet, gelöscht oder verändert werden können. Semesterarbeit, R.Caspar, FHZH 23/62

24 ?? Schädigung der Firma o Die Schädigung der Firma kann eine direkte Folge von Zugriff auf Daten sein. Die entwendeten Daten können publiziert oder verkauft werden. o Die Verfügbarkeit wurde so beeinträchtigt, dass der Kunde daran gehindert wird den Dienst der Firma zu nutzen. Infolge dieser nicht Verfügbarkeit, kann es Schadenersatzforderungen geben oder die Kunden verlassen die Firma Risikobewertung von Sicherheitslücken / Angriffsarten Der direkte lokale Zugriff, mit bestehendem Account und dem entsprechenden Passwort, sowie die Weiterleitung von kritischen Daten, stellen die grösste Bedrohung dar.?? Lokaler Zugriff Wird eine verlassene Arbeitsstation nicht gesperrt, besteht die Möglichkeit, dass jemand Zugriff auf Daten, Account und die Funktionalität erhält. Da nur Personen, welche sich im Raum befinden, Zugriff auf die Station erhalten, müssen keine Massnahmen gegen Attacken aus dem Netzwerk getroffen werden. Den besten Schutz erhält man, wenn ein Bildschirmschoner verwendet wird, den man nur mit einem Passwort beenden kann.?? Passwörter Schwache Passwörter oder herumliegende Passwörter, ermöglichen den Zugriff auf Daten, Account, Funktionalitäten und die Möglichkeit des Eindringens in das System. Die besten Massnahmen sind die Verwendung von speziellen Zeichen in den Passwörtern, sowie periodische Änderung der Passwörter. Die Prävention durch Aufklärung ist ein wichtiger Bestandteil. Damit sollte es möglich sein, diese Bedrohung zu minimieren.?? Datenweiterleitung Das Weiterleiten von firmensensitiven Daten, ist eines der grössten Probleme für die Firma. Wichtige Geschäftsgeheimnisse und Strategien gelangen an die Öffentlichkeit oder an einen Konkurrenten. Das Ziel ist immer, die Firma zu schädigen. Leider lässt sich das Weiterleiten von Daten nicht oder nur sehr schlecht detektieren. Der Ansatz, um das zu unterbinden, ist eher auf der Prozessebene zu suchen. Prozesse, die es den Mitarbeitern klar machen, wie sie mit sensitiven Daten umzugehen haben. Wo sie solche ablegen können und an wen sie diese überhaupt weitergeben dürfen. Semesterarbeit, R.Caspar, FHZH 24/62

25 12. Sensor und Management Integrität Der Sensor ist für die Detektierung von unerlaubten Useraktivitäten zuständig. Seine detektierten Alerts werden dann der Managementstation gemeldet, wo sie zur weiteren Auswertung in eine Datenbank eingetragen werden. Auf dem Sensor sind die Daten allenfalls noch für einen gewissen Zeitraum vorhanden. Es ist also davon auszugehen, dass diejenige Person, die solche Aktivitäten tätigen möchten, versuchen den Sensoren ausser Betrieb zu setzen Kommunikation zwischen Sensor und Managementstation stören Hier werden die Probleme, die sich aus der Kommunikation zwischen Sensor und Managementstation ergeben, angeschaut. Welche die Funktion der Sensoren beeinträchtigen oder verhindern können. Gefälschte Managementstation Ein anderer Rechner gibt sich als Managementstation aus und empfängt Meldungen vom Sensor. Lösung: Managementstation muss sich authentifizieren. + Dies stellt sicher, dass der Sensor der richtigen Managementstation die Meldungen sendet. - Zertifikate müssen im Sensor implementiert werden. Gefälschte Netzwerkverbindung Die Netzwerkverbindung wird zurück geschlauft (Loopback). Lösung: Managementstation muss sich authentifizieren. + So wird sichergestellt, dass der Sensor tatsächlich mit einer Managementstation spricht. Kein DNS-Lookup durchführen. Namen im DNS können lokal überschrieben werden. Der Sensor soll nur mit IP-Adressen arbeiten. MAC-Adresse fix einstellen Anstelle der IP- wird die MAC-Adresse für die Verbindung verwendet. DoS der Managementstation Die Managementstation wird blockiert. Es können keine Befehle gesendet oder Meldungen empfangen werden. Lösung: Schutz durch Firewall Die Managementstation wird durch eine Firewall geschützt, welche bei DoS die Konsole absichert. Bandbreite der Client-Stationen minimieren Die Clients habe eine viel kleinere Bandbreite als die Managementstation. Semesterarbeit, R.Caspar, FHZH 25/62

26 + Verhindert, dass ein einzelner Client die Konsole angreifen kann. - Dies schützt nicht vor einem DDoS. DoS des Sensors Der Sensor wird blockiert, kann keine Befehle empfangen oder Meldungen senden. Kann für lokales Hacken der Maschine verwendet werden. Lösung: Einzelne Netzwerksegmente bilden, dadurch verhindern, dass der DoS auf das gesamte Netzwerk übergreifen kann. + Gesamtes Netzwerk ist nicht vom DoS betroffen. - Das lokale Netzwerk ist aber vom DoS betroffen. Kommunikationsunterbruch Kommunikation mit der Managementstation, wird durch ausstecken des Netzwerkkabels unterbrochen. Der Sensor kann keine Befehle von der Managementstation empfangen und keine Meldungen an sie senden. Lösung: Physikalisch nicht unterbrechbare Verbindung Netzwerkkabel ist mit der Netzwerkkarte fest verbunden. +User kann den PC nicht mehr vom Netzwerk trennen. - In der Praxis schlecht durchsetzbar. Lokale Log-File Einträge im Sensor und Managementstation Bei einem Netzwerkunterbruch müssen die Useraktivitäten im lokalen Log- File gespeichert werden. Die Managementstation muss den Unterbruch auch detektieren und in ihrem Log-File vermerken Angriffspunkte beim Sensor Der Sensor führt die Erkennung der Angriffe von unerlaubten Signaturen durch. Gelingt es einem Angreifer, die Funktion des Sensors zu behindern, so können auf dem Sensor keine unerlaubten Aktivitäten erkannt werden. Der Sensor wird ausgetauscht Der Sensor, welcher an einem Anschlusspunkt am Switch angeschlossen ist (wo der gesamte Verkehr gespiegelt ist), wird durch einen anderen Sensor ersetzt. Dadurch würden auf der Managementstation keine Meldungen mehr geloggt und der unerlaubte Sensor hätte die Möglichkeit den gesamten Verkehr zu scannen. Lösung: Der Gebäudezutritt, sowie der Zutritt zu dem Schrank, wo der Sensor eingebaut ist, muss auf ein Maximum erhöht werden. Damit ein Zutritt für unerwünschte nicht möglich ist. Zudem muss, sobald von einem Sensor keine Logs mehr auf dem Management Server eintreffen, sofort abgeklärt werden warum keine Logs mehr erfolgen. Abschalten des Sensors, durch beenden des Prozesses Der Prozess wird während dem Betrieb beendet; Es werden keine Aktivitäten mehr detektiert, der Host bleibt aber in Betrieb. Semesterarbeit, R.Caspar, FHZH 26/62

27 Lösung: Eigentlich ist es nur möglich, mit Zutritt an der Konsole den Prozess zu beenden. Da der Sensor weder eine IP Adresse besitzt, und nicht über TCP/IP ansprechbar ist. Um dies trotzdem zu gewährleisten, soll von der Managementstation aus, in einem Zeitintervall kontrolliert werden, ob der Prozess auf den Sensoren noch aktiv ist. Somit kann von der Konsole aus festgestellt werden, wenn der Prozess abgeschaltet wird Fazit - Integrität Die zwei Angriffspunkte sind:?? Netzwerkverbindung Um den Angriffspunkten im Bereich Netzwerkverbindung vorzubeugen, sollte man das komplette System (Sensor und Managementstation) in einem nicht öffentlichen IP Netz platzieren und die Zugriffsrechte sehr restriktiv halten. Lokaler Zugriff Mit lokalem Zugriff versteht man, den physischen Zugriff zu den Systemen. Den lokalen Zugriff kann man durch genügende Zutrittskontrollen und ständiger Verbesserung sicherstellen. Semesterarbeit, R.Caspar, FHZH 27/62

28 13. Evaluation Ein IDS-System und seine Anforderungen Das Ziel eines IDS System ist, die Erkennung von Angriffen auf zu schützende Dienste. Dies dient den folgenden übergeordneten Zielen:?? Die Verfügbarkeit der vom IDS zu schützende Dienste sicherzustellen?? Die Integrität, sowie die Verfügbarkeit der Informationen im zu schützenden System zu garantieren Um die oben genannten Ziele zu erreichen, sammelt das IDS Daten von einem oder mehreren Sensoren. Es untersucht den Datenstrom auf einen möglichen Angriff, gegen das zu schützende System. Wird ein Angriff entdeckt, alarmiert der Sensor die Managementstation, der Sensor überträgt die Daten des Angriffs in die Datenbank. Diese Datenbank läuft auf der Managementstation und wird dort mittels einem Tool ausgewertet. Die wichtigsten Anforderungen:?? Keine Beeinflussung der Netzgeschwindigkeit?? Die Möglichkeit eigene Signaturen zu schreiben?? Echtzeitfähigkeit?? Sicherheit?? Verschiedene Datenquellen?? Update Fähigkeit?? Flexibilität?? Bedienung und Konfiguration Bewertungskriterien Allgemeine Kriterien: 1 Preis 2 Anzahl der erkennbaren Angriffe 3 Erkennung von der Normalabweichung 4 Max. Datenverkehr welcher überwacht werden kann 5 Generierung von Logfiles 6 Angriffe in Echtzeit 7 Laufende Aktualisierung von Signaturen 8 Benachrichtigung bei Angriffen 9 Logdaten müssen auch in anderen Analysekomponenten verwertbar sein (Korrelation) 10 Einfacher Betrieb und Unterhalt Semesterarbeit, R.Caspar, FHZH 28/62

29 13.3. Übersicht der bekannten Produkte Die Systeme, welche auf dem Markt erhältlich sind, werden kurz aufgelistet und erläutert. etrust Detection v ( früher Session Wall-3)?? Plattform: Win9x/2000/NT?? Signaturen: ca. 360 Signaturen?? Netzwerkanalyzer : Ja?? Verteilte Umgebung : Ja?? Eigene Signaturen : Ja?? Preis : $ 8755 Workgroup Edition (5000 Session) e Trust Detection von Computer Associates, ist ein Netzwerk Analyzer, welcher den Netzwerkverkehr snifft, überprüft, logt und Alarm schlägt. Es ist ebenso möglich, den Verkehr und insbesonders URL s zu blocken. Dies alles in Echtzeit. Die Stärke liegt sicher im Erkennen von ActiveX, Java-Applets und Viren, sowie die gängigsten Angriffe auf Windowsplattformen. e Trust verfügt über ein Webinterface, welches einem erlaubt, alle Aktivitäten zu überwachen. In der Enterprise Version, unterstützt es auch mehrere Agents, und kann mehrere lokale Netzwerksegmente überwachen. Es kann Ethernet, Token Ring und FDDI analysieren. Fazit: - Es ist gut für Windows, aber nicht für Unix/Linux geeignet - Stark für Webapplikationen - Auf kleinere Umgebungen ausgerichtet EnGarde T-Sight 1.2?? Plattform: Windows 2000/NT?? Signaturen: keine Angaben?? Netzwerkanalyzer : Nein?? Verteilte Umgebung : Nein?? Eigene Signaturen : Ja?? Preis : ab $ 1500 / C-Klasse Die Firma EnGarde hat mit der University of California zusammen, dieses Tool entwickelt. Es kann nur Ethernetnetzwerke analysieren und prüft jeweils nur die Pakete, welche für den eigenen Hosts bestimmt sind. Ausserdem ist T-Sight für grösseren Verkehr auf dem jeweiligen Hosts ungeeignet. Da es schnell dazu kommt, Pakete zu verwerfen und es riesige Log-Files generiert. Dazu kommt noch, dass es nur die Protokolle Telnet, DNS, Rlogin, Rsh, FTP, HTTP, SMTP und Finger erkennt. Es ist ein Produkt für Heimnetzwerke und Unternehmen mit kleinen LAN s, auf denen nur wenig Datenverkehr herrscht. Semesterarbeit, R.Caspar, FHZH 29/62

30 Der Preis hängt von der Anzahl IP- Adressen des Netzwerkes ab. Es startet bei $1 500 für eine C-Klasse und $3 500 für eine B-Klasse. Eine unlimitierte Lizenz kostet $ Fazit: - Nur beschränkte Protokolle werden unterstützt - Nicht geeignet für grosse Netzwerke - Es konnte keine Angaben über die Signaturen gemacht werden Snort 1.8?? Plattform: Linux, Unix und Windows NT/XP?? Signaturen: > 1500?? Netzwerkanalyzer : Ja?? Verteilte Umgebung : möglich?? Eigene Signaturen : Ja?? Preis : freeware Snort ist ein Open Source Produkt, welches einem erlaubt, bezüglich den Anschaffungskosten, einige Einsparungen zu tätigen. Falls man kommerziellen Support wünscht, kann man diesen bei Silicon Defense erhalten. Snort bietet einen sehr hohen Datendurchsatz. Es gilt als Leightweight Intrusion Detection System. Es bietet selbst keine Graphische Benutzeroberfläche an, doch mit Acid von Cert oder Snortsnarf von Silicon Defense und Demarc, gibt es genügend Auswahl. Ein grosser Vorteil von Snort ist die grosse Community im Internet. Welche neue Signaturen innerhalb von wenigen Stunden im Internet gratis veröffentlichen und einem erlauben diese zu implementieren. Die Flexibilität von Snort erlaubt es einem auch sehr einfach eigene Rules zu schreiben. Bis dato bietet Snort Datenbankunterstützung für Oracle, MySQL, PostgreSQL oder ODBC. Fazit: - Ein IDS, welches auf sehr vielen Plattformen zur Verfügung steht - Gute Anzahl von Signaturen und sehr flexibel um eigene zu schreiben - Mit den diversen Open Source Tools, sicherlich eines der stärksten Tools Secure IDS 2.5 Cisco (früher NetRanger)?? Plattform: Unix?? Signaturen: mehrere hunderte?? Netzwerkanalyzer : Ja?? Verteilte Umgebung : möglich?? Eigene Signaturen : Ja?? Preis : $ SecureIDS ist ein netzwerkbasiertes IDS-System, welches aus dem Sensor und dem Director besteht. Der Sensor wird komplett mit Hardware und Software geliefert und Semesterarbeit, R.Caspar, FHZH 30/62

31 läuft auf Sun Solaris. Er wird an einem Netzwerkpunkt angeschlossen und überwacht dort den ganzen TCP/IP Verkehr. Dieser kann von 56 kb/s bis 100MB/s reichen. Es werden Ethernet, Fast Ethernet, FDDI oder Token Ring unterstützt. Mit dem Director konfiguriert man die Sensoren, logt und analysiert die Ereignisse. Er kann auf HP-UC, SUN Solaris oder AIX Systemen installiert werden und benötigt HP OpenView oder NetView (bei AIX). Die Kommunikation zwischen den Sensoren und dem Director erfolgt verschlüsselt über eine separate Serielle Schnittstelle. Das Secure IDS hat eine grosse Standarddatenbank mit Regeln und ermöglicht es einem, diese einfach und schnell mit eigenen Regeln zu ergänzen. Fazit: - Der Preis beim Secure IDS kann bei grosser Umgebung sehr schnell ansteigen (bis $25 000/Sensor) - Kann sehr gut in ein Cisco Netzwerk integriert werden. Er kann direkt in den Switch eingebaut werden - dadurch sehr hohe Performance möglich - Kollerationstools für das Secure IDS sind nur schwer erhältlich Dragon 6.0 Intrusion Detection von Enterasys Networks?? Plattform: Solaris, Red Hat?? Signaturen: > 3000?? Netzwerkanalyzer : Ja und Hostbasiert?? Verteilte Umgebung : Ja?? Eigene Signaturen : Ja?? Preis : Appliance $ 20'000, Software $ Das IDS wurde in drei Teilen entwickelt: - Dragon Sensor; überprüft den Netzwerkverkehr - Dragon Squire; überwacht den jeweiligen Host - Dragon Server; hier werden Alerts geloggt Das Dragon IDS ist skaliert aufgebaut. Es ist möglich bei einem einzelnen Sensor mit integriertem Monitoring zu starten, oder eine verteilte Umgebung aufzubauen. Diese besteht aus einem Enterprise Management Server und bis zu 100 Sensoren welche verwaltet werden können. Das System beinhaltet eine sehr grosse Anzahl von bekannten Signaturen, welche aber auch selbst weiter ausgebaut werden kann. Das IDS selbst, ist als Appliance oder auch nur als Software erhältlich. Der Appliance kann unter Solaris oder Red Hat betrieben werden. Der Enterprise Management Server ist unter Windows 2k/NT/XP, Solaris oder Red Hat erhältlich. Der Hostbasierte teil, ist für Solaris, HP-UX und Windows NT/2000/XP, sowie für Red Hat (7.2 und 7.3) verfügbar. Fazit: - Ein IDS, welches auf sehr vielen Plattformen zur Verfügung steht - Gute Anzahl von Signaturen - Unterstützt Enterprise Lösungen mit einem zentralen Management Server Semesterarbeit, R.Caspar, FHZH 31/62

32 SecureNet Pro Version von Mime Star?? Plattform: Red Hat Linux 6.x?? Signaturen: > 300?? Netzwerkanalyzer : Ja?? Verteilte Umgebung : Ja?? Eigene Signaturen : Ja?? Preis : SecureNet Pro 1 Pack Lizenz $ SecureNet Pro 5 Pack Lizenz $ SecureNet Pro ist ein Enterprise Netzwerk Monitoring und IDS System. Es analysiert und rekonstruiert alle TCP/IP Aktivitäten in einem Netzwerk auf FastEthernet oder FDDI. Es kann volle IP Packete defragmentieren und TCP Session reassembly in Echtzeit. Die Hauptstärken liegen in den höheren Protokollen(HTTP, FTP, Finger, SMTP, Rlogin, TFTP, POP3, NNTP, RPC, NetBIOS, SMB). Eine eigene Script Sprache erlaubt es einem, eigene Signaturen zu schreiben. Beim Enterprise Management System, ist die Verbindung zu den Sensoren verschlüsselt. Auf dem Management System, können die Reports mit den gewählten Details, in den Formaten Text, HTML und CSV generiert werden. Fazit: - Ein gutes IDS für eine Enterprise Umgebung - Es ist im Vergleich mit anderen recht teuer - Die Anzahl der vorhandenen Signaturen ist sehr beschränkt Real Secure 7.0 von ISS?? Plattform: o Sensor: Windows 2000, RedHat 7.2; o Management 6.6: Windows NT/2000?? Signaturen: > 1000?? Netzwerkanalyzer : Ja?? Verteilte Umgebung : Ja?? Eigene Signaturen : Eigene und Snort Signaturen?? Preis : $ / Sensor, $ 13'000 Management Auch Real Secure ist aufgeteilt in ein Management System und Sensoren. Der Sensor ist auch, als Appliance, auf der gesamten Nokia IP XXx Plattform erhältlich. Es hat eine gute Performance für 10/100 MBit Netzwerke (Ethernet, TokenRing, FDDI). Die Version 7.0 unterstützt auch Snort Syntax und erlaubt es, eigene Signaturen zu schreiben. Real Secure kann auf Angriffe reagieren, in dem es die Session zwischen den Systemen beendet. Es kann eine senden, oder ein SNMP Trap absetzen. Es Semesterarbeit, R.Caspar, FHZH 32/62

33 besteht auch die Möglichkeit mittels OPSEC, direkt die Firewall Checkpoint zu steuern und etwas zu blocken. Die Verbindung zwischen den Systemen, ist stark RSA (1024 Bit) verschlüsselt. Fazit: - Bietet eine anständige Anzahl Signaturen - Hat neu die Möglichkeit Snort Signaturen einzubinden - Sehr teuer für eine grösser Umgebung Anmerkung: Es gibt noch weitere Produkte auf dem Markt, einige davon ganz neu, andere schon länger. Ein paar davon sind nun nahe dem end of life oder wurden durch Firmen, welche selbst Intrusion Detection Produkte haben, aufgekauft und dort integriert. Darum ist diese Auflistung der Produkte nicht als vollständig anzusehen. Semesterarbeit, R.Caspar, FHZH 33/62

34 13.4. Bewertung; Stufe 1 Da man auf der Suche nach einem Produkt ist, welches in die gegebene Infrastruktur passt und auch nur das Ziel hat, ein Netzwerkbasiertes Intrusion Detection zu implementieren, sind diese Hauptkriterien zu bewerten. Bevor genauere Details analysiert werden. Kriterien > Produkte Plattform Solaris/Linux ~ 100 % Erkennung auf Fast Ethernet Art Host/Netzwerk Weitere Bewertung etrust Intrusion Detection Nein Nein Netzwerk Nein EnGard T-Sight Nein Nein Host Nein Snort Ja Ja Netzwerk Ja Secure IDS Cisco Dragon Intrusion Detection Unix Ja Netzwerk Ja Ja Ja beides Ja SecureNet Pro Linux Ja Netzwerk Ja RealSecure 5.0 Sensor Linux Bewertung; Stufe 2 Ja Netzwerk ja Schwerpunkt Gewicht ung Snort Secure IDS Cisco Dragon Secure Net Real Secure Robustheit Erkennbare Angriffe Signaturdb /Erweiterbarkeit Systemarchitekt./ Skalierbarkeit Reaktion Management Daten Korrelation Konfiguration Performance (~100MB) Echtzeit Systemanforderung Support Dokumentation Preis/Leistung Wartungskosten Total Punkte Rangierung Semesterarbeit, R.Caspar, FHZH 34/62

35 14. Implementation des Systems Hier werden alle Punkte aufgeführt, welche es benötigt, um das Intrusion Detection System in das gegebene Netzwerk einzubinden. Wie es zu konfigurieren ist und wie man es verwalten kann Vorbemerkung Das System soll so skaliert implementiert werden, dass es einfach ausgebaut werden kann. Dies gilt sowohl für die Hardware, sowie Software aber auch für das Management der kompletten Infrastruktur Benötigte Hardware Da fast nur Sun Hardware eingesetzt wird, haben wir die Hardware Anforderungen auf Unix Systeme angepasst. Managementstation: Die Managementstation, ist ein Server mit genügend CPU Leistung und genügend Diskkapazität. Da man die Alerts über einen längeren Zeitraum aufbewahren möchte. Produkt Kosten Sun E220 mit Ultra SPARC MHz $ A 1000 Disk Array für E220; 12 x 18 Gbyte $ Sensor: Die Sensoren benötigen nicht extrem CPU Leistung, sondern einfach eine mittlere Leistung auf FastEthernet. Dann empfehlen wir, eine Sun Netra V120 einzusetzen. Produkt Kosten Netra V120 mit 1 GB Ram 2x 40 GB $ Software Die ausgewählte Lösung mit Snort, besteht aus folgenden Komponenten: Sensor Kosten Betriebsystem Solaris 2.8 Bestandteil Snort Version 2.0 Freeware Snortcenter Agent 1.0-RC1 for Snort 2.0 Freeware Semesterarbeit, R.Caspar, FHZH 35/62

36 Managementstation Betriebsystem Solaris 2.8 Bestandteil MySQL Version 4.0 Freeware Apache Version Freeware Acid Version Visualisierung der Alerts Freeware Snortcenter v0.9.6b23 Version 1.0-RC1 for Snort 2.0 Management Tool von Snort, für das Ruleset und die verschiedenen Sensoren Freeware Installation der Managementstation Setup des Betriebssystems Die Grundinstallation der Managementstation, sowie die der Sensoren ist die selbe. Das Setup der Maschinen sieht wie folgt aus: Partitionierung: partitioning explicit filesys rootdisk.s swap filesys rootdisk.s /var logging filesys rootdisk.s0 free / logging # Remove Sun Perl pkgrm SUNWpl5u SUNWpl5v Das logging steht für Journaling File System, welches für jede Partition aktiviert werden muss. # RAID Stuff /usr/lib/osa/bin/raidutil -c c1t2d0 -i /usr/lib/osa/bin/raidutil -c c1t2d0 -l 5 -n 0 -s 0 -r fast -g 10,20,11,21,12,22,13,23,14,24 /usr/lib/osa/bin/raidutil -c c1t2d0 -h 15,25 /usr/lib/osa/bin/rm6 mkdir /usr/local/nagios groupadd nagios groupadd mysql useradd -g nagios -d /usr/local/nagios/ nagios useradd -g mysql mysql # cd /usr/local/ssl/lib # ln -s libcrypto.so libcrypto.so # ln -s libssl.so libssl.so mkdir /usr/local/src cd /usr/local/src wget wget wget wget ftp://sunsite.cnlab-switch.ch/mirror/mysql/downloads/mysql-3.23/mysql tar.gz wget wget wget Semesterarbeit, R.Caspar, FHZH 36/62

37 wget wget wget wget wget wget wget wget wget wget wget wget tar xvfz acid-0.9.6b23.tar.gz tar xvfz adodb330.tgz tar xvfz apache_ tar.gz tar xvfz curl tar.gz tar xvfz jpgraph-1.11.tar.gz tar xvfz libnet.tar.gz tar xvfz libpcap tar.gz tar xvfz mod_ssl tar.gz tar xvfz mysql tar.gz tar xvfz openssl-0.9.7a.tar.gz tar xvfz php tar.gz tar xvfz phpmyadmin php.tar.gz tar xvfz phplot tar.gz tar xvfz snort tar.gz.tar tar xvfz snortcenter-v0.9.6.tar.gz tar xvfz gd tar.gz tar xvfz freetype tar.gz tar xvfz libpng tar.gz tar xvfz jpegsrc.v6b.tar.gz tar xvfz libnet.tar.gz mv /usr/ccs/bin/make /usr/ccs/bin/_make ln -s /usr/local/bin/make /usr/local/bin/gmake ln -s /usr/local/bin/perl /usr/bin/perl cd /usr/local/src/mysql /configure --help./configure --prefix=/usr/local/mysql make make install ln -s /usr/local/mysql / /usr/local/mysql cd /usr/local/src/jpeg-6b/./configure --help./configure --prefix=/usr/local/ make make install make install-headers cd /usr/local/src/freetype /configure --help./configure --prefix=/usr/local/ make /usr/local/bin/make /usr/local/bin/make install Semesterarbeit, R.Caspar, FHZH 37/62

38 cd /usr/local/src/libpng cp scripts/makefile.solaris Makefile make make install cd /usr/local/src/gd make clean make make install cd /usr/local/src/curl /configure --help./configure --enable-http --enable-ftp --enable-telnet --enable-file --with-ssl=/usr/local/ssl make make install curl cd /usr/local/src/openssl-0.9.7a./configure solaris-sparcv8-gcc --openssldir=/usr/local/openssl-0.9.7a make make instal ln -s /usr/local/openssl-0.9.7a/ /usr/local/openssl cd /usr/local/src/mod_ssl /configure --with-apache=../apache_ with-ssl=/usr/local/ssl/ --prefix=/usr/local/apache / -- enable-shared=ssl --enable-module=ssl --enable-module=so --enable-rule=shared_core cd /usr/local/src/php /configure --prefix=/usr/local/php with-mysql=/usr/local/mysql --with-xml --withapache=../apache_ with-curl=/usr/local/ --with-gd --enable-track-vars --with-zlib=/usr/ --withopenssl=/usr/local/ssl/ make make install /usr/local/src/apache_ /configure --with-layout=apache --prefix=/usr/local/apache / --activatemodule=src/modules/php4/libphp4.a --enable-shared=ssl --enable-module=so --enable-module=most - -enable-shared=max --enable-rule=shared_core make make certificate TYPE=custom make install ln -s /usr/local/apache /usr/local/apache cd /usr/local/mysql./mysql_install_db chown -R mysql var/ cd /usr/local/mysql ; /usr/local/mysql /bin/safe_mysqld & Anschliessendes Hardening Das nun installierte System wird mittels JASS (gehört zu Solaris Security Toolkit) geharded. Dies bedeutet, dass alle für die Sicherheit relevanten Änderungen am System vorgenommen werden. Dies sind unter anderem, das Abschalten aller nicht benötigen Dienste unter inetd.conf, löschen von Standard Accounts und viele weitere Anpassungen. Semesterarbeit, R.Caspar, FHZH 38/62

39 14.6. Installation des Sensors pkgrm SUNWpl5u SUNWpl5v mkdir /usr/local/nagios mkdir /usr/local/snort groupadd nagios groupadd snort useradd -g nagios -d /usr/local/nagios/ nagios useradd -g snort -d /usr/local/snort snort scp snort.tar :~ scp nagios_client.tar :~ scp snortcenter-agent-v0.1.6.tar.gz :~ tar xvfz snort.tgz -C /usr/local /usr/bin/rm -r /usr/local/snort/sensor tar xvfz snortcenter-agent-v0.1.6.tar.gz -C /usr/local/snort chown -R snort:snort /usr/local/snort/ ln -s /usr/local/snort/lib/libmysqlclient.a /usr/lib/libmysqlclient.a ln -s /usr/local/snort/lib/libmysqlclient.la /usr/lib/libmysqlclient.la ln -s /usr/local/snort/lib/libmysqlclient.so /usr/lib/libmysqlclient.so ln -s /usr/local/snort/lib/libmysqlclient.so.10 /usr/lib/libmysqlclient.so.10 ln -s /usr/local/snort/lib/libmysqlclient.so /usr/lib/libmysqlclient.so mkdir /var/log/snort chown -R snort:snort /var/log/snort cd /usr/local/snort/sensor./setup.sh ifconfig dmfe1 plumb echo "$HOSTNAME-dmfe1" > /etc/hostname.dmfe1 touch /etc/hostname.dmfe1 cp /home/snort/snortcenter-agent-v0.1.6.tar.gz /usr/local/snort/ tar xvfz snortcenter-agent-v0.1.6.tar.gz tar xvf nagios_client.tar -C /usr/local/ chown -R nagios:nagios /usr/local/nagios cd /usr/local/nagios mv S81nrpe /etc/rc2.d/ chown root:root /etc/rc2.d/s81nrpe chmod 744 /etc/rc2.d/s81nrpe chmod 770 snort/ chown snort:root snort/ --prefix=/usr/local/ --prefix=/usr/local/snort/ make make install --prefix=/usr/local/snort --with-mysql=../mysql /include/ -with-libpcap-includes=/usr/local/snort/include/ --with-libpcaplibraries=/usr/local/snort/lib/ --enable-flexresp./configure --prefix=/usr/local/snort --with-mysql=../mysql /include/ -with-libpcapincludes=/usr/local/snort/include/ --with-libpcap-libraries=/usr/local/snort/lib/ Semesterarbeit, R.Caspar, FHZH 39/62

40 --prefix=/usr/local/snort/ make mkdir /var/log/snort tar xvfz snortcenter-agent-v0.1.6.tar.gz cp -r sensor/ /usr/local/snort cd /usr/local/snort/sensor./setup snortcenter agent: user: sncenter passwd: XXXXX ln -s /usr/local/snort/lib/libmysqlclient.a /usr/lib/libmysqlclient.a ln -s /usr/local/snort/lib/libmysqlclient.la /usr/lib/libmysqlclient.la ln -s /usr/local/snort/lib/libmysqlclient.so /usr/lib/libmysqlclient.so ln -s /usr/local/snort/lib/libmysqlclient.so.10 /usr/lib/libmysqlclient.so.10 ln -s /usr/local/snort/lib/libmysqlclient.so /usr/lib/libmysqlclient.so chown -R snort:root /usr/local/snort chown -R snort:root /var/log/snort ifconfig dmfe1 plumb cat /etc/rc2.d/s75static-routes #!/bin/sh #ident " # Add static routes /usr/sbin/route add net netmask /usr/sbin/route add net netmask root@sens1:rc2.d]# cat S99snort #!/bin/sh # # Stop and start snortcenter # /usr/local/bin/perl /usr/local/snort/sensor/miniserv.pl /usr/local/snort/sensor/conf/miniserv.conf /usr/local/snort/bin/snort -D -i dmfe1 -o -u snort -g snort -c /usr/local/snort/sensor/rules #eof Semesterarbeit, R.Caspar, FHZH 40/62

41 14.7. Initialisieren der Datenbank Damit Snort mit einer MySQL Datenbank läuft, benötigt es einige Tabellen, damit Snort dann auch richtig funktionieren kann. Beim Einsatz des Visualisierungstools Acid, benötigt es noch zusätzliche Felder. Für die Erstellung der Tabellen und Felder, hat es im Paket von Acid ein Script, welches gleich alle Tabellen mit den entsprechenden Attributen erzeugt, so dass es nicht von Hand gemacht werden muss. Abbildung 2 Snort Database Übersicht Setup von Snortcenter Herunterladen von SnortCenter: Snortcenter wird dazu verwendet, um die Sensoren mit allen benötigten Konfigurationen (wie Signaturen etc.) zu verwalten. Es bietet einem die Möglichkeit, eine verteilte Umgebung zu verwalten. Um Snortcenter auf der Managementstation betreiben zu können, werden folgende Produkte benötigt, welche schon vorgängig installiert wurden.?? Als WebServer wird Apache benötigt?? Datenbank MySQL PHP ADODB curl Binary (kompiliert mit SSL, wenn SSL gewünscht)?? OpenSSL Library (wenn Snortcenter mit SSL gewünscht) Semesterarbeit, R.Caspar, FHZH 41/62

42 Nun kann Snortcenter installiert werden. Um Snortcenter betreiben zu können, benötigt es auch eine Tabelle in MySQL, diese wird wie folgt angelegt, dazu existiert auch schon ein Script. Bevor man das Script ausführt, sollte das File config.php, angepasst werden. $DBlib_path = "./adodb/"; $curl_path = ""; $DBtype = "mysql"; $DB_dbname = "snortcenter"; $DB_host = "localhost"; $DB_user = "root"; $DB_password = ""; $DB_port = ""; $hidden_key_num = "236785"; Befehl: echo "CREATE DATABASE snortcenter;" mysql -u root p Achtung: select, insert, update, delete muss auf der Datenbank zugelassen sein. mysql -u root snortcenter < snortcenter_db.mysql Sensor Agent Nachdem die Managementstation erfolgreich installiert wurde, kann man sich an den Sensor wenden. Alle Sensoren werden zentral mittels Snortcenter verwaltet. Die Kommunikation kann sowohl ohne SSL wie auch mit SSL, eingestellt werden. Zu empfehlen ist natürlich mit SSL, wie auch wir es verwenden. Die nötigen Softwarekomponenten, um Snortcenter auf dem Sensor laufen zu lassen, wurden schon bei der Einrichtung des Sensor installiert mittels: cd /usr/local/snort/sensor./setup.sh 15. Vorbereitung vor der ersten Inbetriebnahme Zuerst muss man sich auf der Managementstation, bei Snortcenter, anmelden. Dazu können User Accounts eingerichtet werden (Default gibt es einen Admin Account) Semesterarbeit, R.Caspar, FHZH 42/62

43 Abbildung 3 Login Maske Snortcenter Sensoren definieren Abbildung 4 Erstellen eines neuen Sensors Zur Konfiguration der Sensoren, benötigt es folgendes: - Sensorname - IP Adresse / Port - Username - Passwort - Agent Typ (mit oder ohne SSL) - Interface Name (welches überwacht wird) Diese Informationen müssen auch bei der Softwareinstallation des Agents, identisch angegeben werden. Die IP Adresse, Port, Username, Passwort und mit oder ohne SSL, sind Einstellungen welche benötigt werden, damit die Managementstation mit dem Sensor Agent kommunizieren kann. Zusätzlich kann noch ein Snort Start Befehl mitgegeben werden. Die später definierten Default Rules, können ebenfalls aktiviert werden. Semesterarbeit, R.Caspar, FHZH 43/62

44 15.2. Netze definieren Abbildung 5 Definieren der Variablen Damit jeder Sensor weiss, für welche Netze er zuständig ist, resp. für was er seine Signaturen anwenden muss, müssen diverse Variablen erstellt werden. Welche dann den Sensoren zugewiesen werden. Beispiele: var HOME_NET [ /24] var Ext_NET [any] var http [ /32, /32, /32 ] Semesterarbeit, R.Caspar, FHZH 44/62

45 15.3. Signatur Management Abbildung 6 Signatur Management mit Snortcenter Alle Signaturen, welche für Snort verfügbar sind, sind in diesem Tool ersichtlich. Die Struktur der Signaturverwaltung sieht wie folgt aus: Default Signaturen: Hier können alle Signaturen ausgewählt werden, welche den neuen Sensoren, resp. bestehenden Sensoren zugewiesen werden. Die Signaturen können auch global über alle Sensoren verändert werden. Signaturen pro Sensor: Jeder Sensor hat seine eigene Signaturverwaltung. Somit ist es sehr einfach, Signaturen pro Sensor zu aktivieren resp. deaktivieren. Zudem bietet einem das Tool, pro Sensor, eine Gesamtübersicht aller Signatur-Kategorien an. In dieser sieht man wie viele Signaturen, der einzelnen Kategorien, aktiv sind. Somit erhält man eine sehr gute Übersicht über alle Signaturen. Semesterarbeit, R.Caspar, FHZH 45/62

46 Abbildung 7 Übersicht der verschiedenen Signatur Kategorien Semesterarbeit, R.Caspar, FHZH 46/62

47 15.4. Eigene Signaturen erstellen Eine der grossen Stärken von Snort ist es, dass man sehr einfach eigene Signaturen schreiben kann. Es ist ein wichtiger Punkt, denn einige Protokolle und Applikationen die man überwachen möchte, sind nicht mit den vorhandenen Signaturen abgedeckt und somit muss man eigene Signaturen schreiben können. Snortcenter bietet einem hier eine Hilfestellung. Mittels einer Eingabemaske kann man die Signatur erstellen und muss sich nicht mit dem Syntax von Snort auskennen. Diese nun selbst erstellten Signaturen, kann man dann den entsprechenden Sensoren zuweisen. Abbildung 8 Eigene Signaturen über Snortcenter erstellen Semesterarbeit, R.Caspar, FHZH 47/62

48 15.5. Übersicht Snortcenter Im Hauptfenster von Snortcenter, bekommt man eine Übersicht über alle Sensoren. Ob die Managementstation mit diesen auch kommunizieren kann, und ob Snort auch aktiv ist. Zudem unterstützt der Agent auf dem Sensor, die Überwachung der Prozessor-, Memoryund Diskauslastung. Aus diesem Menü ist es auch möglich, Snort zu starten, stoppen oder sich eine aktuelle Konfiguration des gesamten Sensors anzeigen zu lassen. Abbildung 9 Snort Management Hauptübersicht Semesterarbeit, R.Caspar, FHZH 48/62

49 15.6. Auswertung der Alert Snort legt seine gesammelten Daten normalerweise als File in einer Verzeichnisstruktur ab. Wir haben Snort so konfiguriert, dass es die Daten zusätzlich in eine MySQL Datenbank exportiert, welche auf der zentralen Managementstation installiert ist. Auf der Managementstation haben wir das Kollerationstool ACID installiert. Es gibt diverse solcher Freeware Tools für Snort, welche alle Ihre kleinen Vor- und Nachteile haben. ACID ermöglicht es einem, eine Übersicht über die angefallenen Alerts zu erlangen. Man hat diverse Möglichkeiten um an die gewünschten Informationen zu gelangen. Sei dies über eine spezielle Signatur oder eine einzelne IP Adresse oder über ganze Protokolle. Abbildung 10 ACID Hauptübersicht Semesterarbeit, R.Caspar, FHZH 49/62

50 Abbildung 11 Auflistung aller Klassen von angefallenen Alerts In folgender Graphik sieht man die einzelnen Alerts, von wo das sie ausgegangen sind, auf welches System es erfolgte. Man hat eine eindeutige ID, mit welcher man mehr Information über den Angriff in Erfahrung bringen kann. Semesterarbeit, R.Caspar, FHZH 50/62

51 Abbildung 12 Beispiele von Alerts Semesterarbeit, R.Caspar, FHZH 51/62

52 16. Gefundene Erkenntnisse Einführung Es hat sich gezeigt, dass die Integration eines Intrusion Detection System, in ein Netzwerk der Grösse eines ISP s nicht einfach ist. Ein Verkehrsaufkommen von gesamt (über alle zu überwachende Netzwerke) von > 1Gigabit, sowie die rund 600 System welche eine grosse Anzahl von verschiedenen Servicen anbieten, erschweren die Integration und eine sinnvolle Nutzung. Eine sinnvolle Integration, lässt sich nur mittels einem IDS Loadbalancer realisieren. Dieser gewährleistet einem eine viel grössere Flexibilität. Eine Evaluation eines geeigneten Loadbalancer, ist nicht Bestandteil dieser Semesterarbeit, und würde auch den Rahmen sprengen. Das hier integrierte IDS System, welches aus einem Sensor und einer Managementstation besteht, wurde so aufgebaut, dass es zwecks Skalierbarkeit sehr einfach in eine Umgebung mit einem Loadbalancer migriert werden kann. Dieses Migrationszenario wird später noch erläutert, anhand eines Produktes von einem der führender Hersteller im IDS Loadbalancer Umfeld. Dies jedoch, ohne die Gewissheit zu haben, dass dieses Produkt für den Anwendungszweck wirklich das beste ist Auftretende Probleme Die Integration von Snort, in eine grössere Netzwerkinfrastruktur, bringt Probleme mit sich, auf welche ich während der Arbeit gestossen bin. Anfallender Verkehr: - Anfallender Verkehr zu gross - Anzahl/Vielzahl zu schützender Services zu gross - Anfallende Alerts Trotz einer verteilten Umgebung, mit mehreren möglichen Sensoren und einer zentralen Managementstation, hat sich gezeigt, dass der anfallende Verkehr, pro Sensor, viel zu gross ist. In gewissen Zonen, welche meistens eine C-Klasse repräsentiert, sind bis zu 200 Server zu finden und mindest so viele Services. Der Hauptverkehr (ca. 50 %) wird alleine durch den Mailverkehr erzeugt. Der Rest setzt sich aus diversen Servicen zusammen (Hauptanteil dort http). Durch den anfallenden Verkehr, traten Probleme auf. Der Sensor konnte nicht mehr loggen oder stürzte sogar ab, was wohl auf eine schlechte Programmierung der Software zurück zuführen ist. Weiter ergibt sich noch folgendes Problem, wenn der gesamte Verkehr dieser Zone (welcher an einen Anschlusspunkt gespiegelt wird) die Grenze von 100 Mbit übersteigt, würde sogar der Switch die restlichen Pakte verwerfen. Für diese Problematik muss eine Lösung gesucht werden, um das IDS in Zukunft sinnvoll(er) nutzen zu können. Semesterarbeit, R.Caspar, FHZH 52/62

53 Anzahl Services: Der Sensor ist jetzt für eine ganze Zone mit allen darin enthaltenen Services verantwortlich. Dies hat zur Folge, dass sehr viele Signaturen auf diesem Sensor aktiv sein müssen. Was den Sensor sehr viel an Performance kostet. Eine grosse Anzahl von Alerts, welche auch in die Datenbank übertragen werden müssen, sowie der anfallende Verkehr, bringen Snort immer wieder zum Absturz. Anmerkung: Diese Probleme sind bekannt und es gibt auch einige Bugfixes, welche versuchen die Probleme zu beheben (vor allem das Übertragen in die Datenbank). Bei jeder neuen Version von Snort, wird die Grösse des möglichen zu analysierenden Verkehrs, ständig verbessert. Anfallende Alerts: Mit der Vielzahl von Systemen und den damit verbundenen Servicen, ergibt sich eine grosse Menge von möglichen aktiven Signaturen. Daraus erfolgt das sich extrem viele Alerts einstellen, welche zu verifizieren sind, ob es sich nicht um false postive handelt. Die grosse Anzahl von Alerts bringen mit sich, dass die Datenbank schnell langsam wird und die Auswertung dadurch erschwert wird. Zusätzlich macht eine zu grosse Anzahl Alerts es schwierig, die wirklichen Alerts von den false positiv zu unterscheiden. Auch hier muss eine sinnvolle Lösung gefunden werden. 17. Migration in eine skalierbare/sinnvolle Infrastruktur Ausgangslage Bei normalen Lösungen war es so, dass pro zu schützende Zone ein Sensor den gesamten Verkehr erhält, und diesen analysiert. Es hat sich jedoch gezeigt, dass dies in einer grossen Umgebung, einige Probleme mit sich bringt, welche das IDS unbrauchbar machen. Hier soll aufgezeigt werden wie dieses Problem gelöst werden kann Lösungsansatz Der bestmögliche Ansatz, aus Sicht der Skalierbarkeit, ist ein Loadbalancer. Es gibt diverse Hersteller, welche Loadbalancer, insbesonders IDS Loadbalancer herstellen. Eine komplette Evaluation des besten Loadbalancer würde den Rahmen hier sprengen. Deshalb habe ich nach kurzer Analyse, einen Ausgewählt und mit diesem versucht die bestehende Umgebung auf eine skalierbare Lösung mit Loadbalancer zu portieren. Kosten: Die Kosten für einen Loadbalancer, wie den Radware Fireproof, belaufen sich auf ca. $25'000. Dadurch wird es möglich bei zukünftigen Sensoren Geld zu sparen. Semesterarbeit, R.Caspar, FHZH 53/62

54 17.3. Integration mit einem Loadbalancer (Fireproof) Bei der Installation ohne einen Loadbalancer, hat man einen Sensor, welcher für eine Zone zuständig ist. Dies bedeutet, das man auf den Netzwerk Switchen das Rspan (wegen Redundanz der Switchen) einschalten muss, um den gesamten Verkehr an einem Anschlusspunkt abnehmen zu können. Diese Funktion erhöht aber die Last des Switches und es kann pro Switch nur einmal ein Rspan eingerichtet werden. Benutzt man das normale Span, kann man mehrere solcher einrichten, und diverse VLans auf verschiedene Anschlusspunkte Spiegeln. Diese Verbesserung kann man nur mit dem Loadbalancer durchführen. Auf jedem Switch wird das lokale Span eingerichtet und von diesem Anschlusspunkt verbindet man dann auf den Loadbalancer. Die Sensoren, welche gedacht waren pro Zone anzuschliessen, werden jetzt alle direkt am Loadbalancer angeschlossen. Um das grosse Verkehrsaufkommen bewältigen zu können, bildet man nun sogenannte Cluster Objekte, welche dann jeweils einen oder mehrere Services repräsentieren. Beispiele sind: HTTP, SMTP, POP3 Auf dem Loadbalancer, welcher nun den gesamten Verkehr bekommt (> 1000Mbit), kann man nun den Verkehr, anhand der Cluster aufteilen, und auf die einzelnen Sensoren verteilen. Ein Cluster Objekt, welches alleine schon viel Verkehr hat, kann mehrere Sensoren beinhalten und man kann beliebige Host diesem Cluster hinzufügen. Der Loadbalancer teilt dann den Verkehr auf die einzelnen Hosts auf. Somit ist es gewährleistet, dass man bei steigendem Verkehr, stets eine einfache Möglichkeit hat dem gerecht zu werden. Man kann einfach einen neuen Host hinzufügen und diesen dem entsprechenden Cluster zuweisen Übersicht Fireproof Der Fireproof besitzt 5 x Gigabit und 16 x 100 Mbit Interfaces, welche einem sehr viel Flexibilität lassen, beim anschliessen der einzelnen Zonen und der Sensoren. Semesterarbeit, R.Caspar, FHZH 54/62

55 Abbildung 13 Frontansicht Fireproof Abbildung 14 Übersicht der Cluster Objekte Änderung des Signatur Management Diese neue Topologie zieht es natürlich mit sich, dass sich auch das Signatur Management stark ändert. Mussten vorher pro Zone noch unzählige Signaturen aktiv sein, weil in jeder Zone diverse Services aktiv waren, benötigt man jetzt nur noch die entsprechenden Klassen welchen den Cluster Gruppen entsprechen. Somit reduziert man, für den Sensor, die Anzahl der Services (http, smtp etc.), was auch die Anzahl der Signaturen stark vermindert. Dies hat auch Einfluss auf die Auslastung. Da man natürlich nicht für jeden Service eine eigene Gruppe und einen dedizierten Sensor installieren kann, erstellt man für die übrigen Services eine gemeinsame Gruppe und gemeinsame Sensoren, wo dann eine grössere Anzahl von Signaturen zugewiesen sind. Was jedoch bei dem anfallenden Verkehr, nicht so sehr belastend ist. Semesterarbeit, R.Caspar, FHZH 55/62