5. Infrastruktur und Sicherheit. Vorlesung Betrieb Komplexer IT-Systeme (BKITS)

Transkript

1 5. Infrastruktur und Sicherheit Vorlesung Betrieb Komplexer IT-Systeme (BKITS)

2 Einführung Bislang: Betrachtung des System-Aspekts in BKITS Identity Management: Konzepte und Systeme Verzeichnisdienste und DNS Single-Sign On Hier: Betrachtung des Infrastruktur-Aspekts Erst durch Netzwerke bringt man Rechner zusammen Ungebrochener Trend zu höheren Bandbreiten Breitbandige Versorgung selbst im privaten Bereich Weite Spanne von Standard-Systemen im Massenmarkt bis hin zu Spezialnetzwerk, z.b. in Rechen-Clustern Offenes System mit zahlreichen Herstellern und Protokollen Aber auch: Risiko durch Angriffe aus dem Netzwerk Matthias Hovestadt - BKITS 4-2

3 5.1 Protokolle und Schichten Internet erweckt Illusion eines homogenen Netzwerks Alle Komponenten scheinen nahtlos ineinander zu greifen Jeder Computer kann Daten an jeden anderen Computer senden Internet ist ein virtuelles Netzwerk Kommunikationssystem ist abstrakt Illusion des einheitlichen Netzwerks entspricht nicht der Wirklichkeit Matthias Hovestadt - BKITS 4-3

4 Kommunikation der Schichten Anwendung Darstellung Sitzung Transport Vermi7lung Sicherung Anwendung Darstellung Sitzung Transport Vermi7lung Sicherung Bitübertragung Matthias Hovestadt - BKITS 4-4

5 Internetworking Protokolle Für Internetworking wurde viele Protokollfamilien entwickelt Name der häufigsten: TCP/IP Protocols Beginn der Entwicklung in den 1970er Jahren Im Rahmen von ARPA (Advanced Research Projects Agency) Erste Nutzer: US-Militär Mitte der 1980er: Weitere Förderung durch NSF Weitere Entwicklung von TCP/IP Realisation eines großen Internet zum Test der Protokollfamilie TCP/IP führte zur modernen Computerwelt Internetworking als allgemeines Prinzip zur Kommunikation Proprietäre Netzwerk-Produkte wurden Internetworking-fähig Einheitliches und übergreifendes Addressierungsschema Matthias Hovestadt - BKITS 4-5

6 Hierarchie der IP-Adressen Internet-Adresse besteht aus 32 Bit Beispiel eines Rechners im CIT: Bzw: Adresse gliedert sich in zwei Teile Präfix: identifiziert das physische Netzwerk Werden global verwaltet Suffix: identifiziert den Rechner in diesem Netzwerk Können lokale verwaltet werden Größe des Präfix variabel, bestimmt Länge des Suffix Matthias Hovestadt - BKITS 4-6

7 IP-Adressklassen Design sieht 3 Adressklassen vor Klasse wird durch die ersten vier Bits der Adresse bestimmt Separate Klasse für Multicast A 0 7 Bit Präfix 24 Bit Suffix B Bit Präfix 16 Bit Suffix C Bit Präfix 8 Bit Suffix D MulHcast- Adresse E Reserviert Beispiel des CIT-Rechners: Adresse aus B-Klasse-Netz: 2 Bit Typ, 14 Bit Präfix, 16 Bit Suffix Matthias Hovestadt - BKITS 4-7

8 Knapper Adressraum Netzklasse bestimmt Anzahl Netze und Anzahl Hosts: Klasse Bit Prefix Max. Anzahl Netze Bit Suffix Max. Anzahl Hosts A B C Netzwerk-Adressen sind ein knappes Gut Erschöpfung war für Mitte der 1990er Jahre prognostiziert Aufschub u.a. durch Network Address Translation (NAT) 2011 wurde letzter freier Adressblock vergeben Ausweg: Einführung von IPv6 mit 128 Bit langen Adressen Matthias Hovestadt - BKITS 4-8

9 Subnetz- und klassenlose Adressierung Probleme mit klassenbasierter Adressierung Viele Adressen eines Netzes blieben ungenutzt Erschöpfung des Adressraums drohte Entwicklung von zwei neuen Mechanismen Mitte 1990er Subnetz-Adressierung und Klassenlose Adressierung Grundgedanke: Aufteilung von Prefix/Suffix an beliebiger Stelle Beispiel: Klasse C Netzwerk mit 9 Knoten Klasse C bietet 8 Bit für Suffix (256 Knoten) 9 Knoten brauchen jedoch nur 4 Bit als Suffix Lösung: Aufteilung der Klasse C Adresse 16 Netze mit 24 Bit Prefix und Platz für 16 Knoten Matthias Hovestadt - BKITS 4-9

10 Netzmaske Vorteil klassenloser Adressierung: Bessere Nutzung des vorhandenen Adressraums Nachteil klassenloser Adressierung: Trennung von Präfix und Suffix nicht mehr offensichtlich Trennung an beliebiger Stelle möglich Lösung: Die Netzmaske Bit-Vektor, der den Teil des Präfix bestimmt Verknüpfung mit Adresse durch logisches UND Präfix ist Matthias Hovestadt - BKITS 4-10

11 Class Inter Domain Routing (CIDR) Neue Notation in CIDR Angabe der Netzmaske durch Suffix an Adresse Beispiel: /16 Netzmaske: Die ersten 16 Bit gesetzt = CIDR bringt größere Flexibilität Klassisch: Netz C hat starre 8 Bit für Host-Adresse CIDR: Unterteilung in mehrere kleinere Netze Z.B /28, /28, Verfügbare Hostadressen Erste Adresse Netzwerk, letzte Adresse Broadcast-Adresse Verbleiben in /28 Netz somit 14 Adressen für Hosts Matthias Hovestadt - BKITS 4-11

12 Address Resolution Protocol (ARP) C fragt nach Hardware-Adresse zu gegebener IP-Adresse A B C D E Anfrage erreicht alle Hosts im Netzwerk A B C D E Rechner E hat angefragte IP-Adresse und antwortet an C A B C D E C kennt nun die Hardware-Adresse von E und kann senden Matthias Hovestadt - BKITS 4-12

13 5.2 Sicherheit, Security und Safety Universaldienst als Selbstverständlichkeit: Das Internet Rechner sind über Netzwerke verbunden Benutzer mit Zugriff auf weltweit verteilte Informationsquellen Angebotene Dienste weltweit abrufbar Vernetzung birgt auch Gefahren Abhängigkeit: Arbeitsfähigkeit setzt funktionierende Infrastruktur voraus Komplexität: Schwer zu überblickendes Geflecht von Abhängigkeiten, Unzahl zu überwachender Einzelkomponenten Angreifbarkeit: Viele Angriffspunkte aufgrund Komplexität, Schwerwiegende Konsequenzen bei erfolgreichem Angriff Matthias Hovestadt - BKITS 4-13

14 Schutz Potentielle Angriffsziele Infrastruktur: Server und Arbeitsplätze Kontrolle der Ressourcen durch Dritte (Backdoors, ) Daten: Dokumente, Tabellen, Veränderung oder Löschung von Informationen Reputation Diskreditierung des Unternehmens, Vertrauensverlust Schutzziele Vertraulichkeit: keine unauthorisierte Kenntnisnahme Integrität: keine unauthorisierte (und unbemerkte) Modifikation Verfügbarkeit: keine unauthorisierte Vorenthaltung von Ressourcen Zurechenbarkeit: Verursacher von Aktionen sind ermittelbar Matthias Hovestadt - BKITS 4-14

15 Angriff Der schlimmste Fall: Der Angreifer zerstört das System, löscht alle Daten Aber: Ist dies wirklich der schlimmste Fall? Nachteil: Datenverlust, Zeitverlust Vorteil: Leicht zu entdecken Versteckte Angriffe System scheint auf den ersten Blick normal zu funktionieren System steht jedoch unter fremder Kontrolle Potentiell viel Zeit zur Schädigung bis zur Entdeckung Unerkannte Modifikation von Dokumenten Ausspähung der Infrastruktur für neue Angriffe Zeitpunkt der Infektion nur schwer nachzuvollziehen Matthias Hovestadt - BKITS 4-15

16 Erste Möglichkeit: Präventive Mechanismen Klassischer Weg des Schutzes von IT-Infrastrukturen Vertraulichkeit: Verschlüsselung, Zugangskontrolle, Firewalls Integrität: Zugangskontrolle, digitale Signaturen Verfügbarkeit: Redundante Auslegung von Ressourcen Zurechenbarkeit: digitale Signaturen, Protokollierung Nur begrenztes Schutzpotential Kein Schutz vor missbräuchlichen Aktionen authorisierter Nutzer Kein Schutz vor fehlerhaft implementierter Software Kein Schutz vor Konfigurationsfehlern Kein Schutz vor Dummheit der Benutzer Ergänzung um weitere Mechanismen notwendig Anzahl der Angriffe wächst jährlich um mehr als 50% Matthias Hovestadt - BKITS 4-16

17 Zweite Möglichkeit: Reaktive Mechanismen Situation: Angriff ist bereits erfolgt Ziele reaktiver Mechanismen: Erkennung von Angriffen Identifizierung von Angreifern Bestrafung der Verantwortlichen Abschreckung weiterer Angreifer Schutz der Infrastruktur vor Ausbreitung des Angriffs Eindämmung der negativen Folgen des Angriffs Voraussetzung: Zuverlässige Erkennung von Angriffen Mittel der Wahl: Intrusion Detection Systeme (IDS) Matthias Hovestadt - BKITS 4-17

18 Angriffsmethoden Einbruch Ziel: Erlangung von Nutzerrechten auf dem System Vielfältige Arten, z.b. Social Attack: Ausnutzen persönlicher Verbindungen Password Attacke: Raten des Passwords mit Wörterbuch Nutzen von Fehlern im System Lahmlegen eines Dienstes Ziel: Verhinderung der Nutzung der Infrastruktur Formen: Denial of Service, -Bombe, Informationsdiebstahl Aber auch: Unfälle und Dummheit Matthias Hovestadt - BKITS 4-18

19 Safety und Security Unterschiedliche Aspekte in der Sicherheit Definition Safety: Schutz der Umgebung vor einem Objekt Schutz interner Rechner vor extern erreichbaren Systemen Definition Security: Schutz des Objekts vor der Umgebung Schutz von zentralen Servern vor inneren Angriffen Schutz vor Angriffen aus dem externen Netz Matthias Hovestadt - BKITS 4-19

20 Strategien (1/4) Minimale Zugriffsrechte Grundlegendste Sicherheitsstrategie Jedes Objekt erhält nur absolut notwendige Rechte Benutzer, Dienste, (Administratoren eingeschlossen) Konzept auch in Paket-Filter Firewalls anwendbar Verkleinerung von Angriffsfläche und Konsequenzen Zentrales Problem: Schwierige Realisierung Mehrschichtige Verteidigung Aufbau mehrerer Verteidigungsringe, statt eines einzelnen Kombination unterschiedlicher Verteidigungstypen Firewall, Rechnersicherung, Personalschulung, Reihenschaltung von Firewalls zur Funktionskontrolle Matthias Hovestadt - BKITS 4-20

21 Strategien (2/4) Enge Passierstelle Zugang zu System oder Infrastruktur über nur einen Punkt Besondere Absicherung, erhöhter Aufwand und größtmögliche Sorgfalt bei der Sicherung dieser Passierstelle Passierstelle darf nicht umgangen werden können Das schwächste Glied Ein einzelner unsicherer Dienst genügt zur Kompromittierung des gesamten Systems Angreifer werden versuchen diesen Dienst zu finden Fokus: Monitoring der Infrastruktur, Erkennung von Schwachstellen Aber auch: Aktive Suche nach Schwachstellen Matthias Hovestadt - BKITS 4-21

22 Strategien (3/4): Fehlersicherheit Sicherheit muss auch bei Fehler in einem System innerhalb der Abwehrkette gewährleistet bleiben Beispiel: Schutz des Netzes bei Ausfall der Firewall Es muss der Fehlerfall angenommen werden Wichtig: Einschränkende Grundhaltung Alles, was nicht erlaubt ist, ist verboten Rechte müssen explizit gewährt werden Problem: Notwendige Rechte schwer zu verwalten Daher oft freizügige Grundhaltung ( Alles, was nicht explizit verboten ist, ist erlaubt ) Matthias Hovestadt - BKITS 4-22

23 Strategien (4/4): Beteiligung aller Personen Mensch als schwächstes Glied nicht unüblich Installation von Software aus dem Internet Öffnen von obskuren -Anhängen Ignorieren von Fehlermeldungen oder Auffälligkeiten Wahl unsicherer Passworte Password-Notizen unter der Tastatur Umgehung von Firewall-Systemen Mitarbeit an Sicherheit freiwillig oder erzwungen Zwang resultiert häufig in der Umgehung der Regeln z.b: Zwang zur wöchentlichen Wahl eines neuen Passworts Freiwillige Mitarbeit deutlich effektiver Aufklärung der Mitarbeiter notwendig Matthias Hovestadt - BKITS 4-23

24 5.3 Aufbau sicherer Infrastruktur Einfachstes Element: Router (Überwachungsrouter) Austausch von Paketdaten zwischen zwei Netzen Regelwerk zur Definition von erlaubtem Austausch Positiv-Liste ( Was darf passieren? ) Negativ-Liste ( Was darf nicht passieren? ) z.b.: Quell-/Ziel-IP-Adresse/Port, Protokoll, Ziel: Überwachung des Netzes auf Paket-Ebene Internet Internes Netz Überwachungsrouter Matthias Hovestadt - BKITS 4-24

25 Proxy-Dienste Überwachungsrouter arbeiten nur auf Paket-Ebene Inhalt der Kommunikation kann nicht gesteuert werden Lösung: Proxy-Dienste Routing der Kommunikation auf Applikationsebene Für den Benutzer üblicherweise transparent Server sieht Proxy-Host als Benutzer Externer Server Internet Überwachungsrouter mit Proxy-Server Internes Netz Matthias Hovestadt - BKITS 4-25

26 Bastion Host im internen Netz Extern erreichbarer Rechner im internen Netz Kann auch von internen Rechnern aus angesprochen werden Jedoch kein Routing für interne Rechner Strikte Filterregeln im Überwachungsrouter Bastion Host einzig erreichbares System Filterung meist auf Ebene von Paket-Filterung Beispiel: Proxy-Dienste auf Bastion-Host Internet Interner Host darf nicht direkt auf das Internet zugreifen Internes Netz Überwachungsrouter Matthias Hovestadt - BKITS 4-26

27 Bastion Host im Grenznetz Bastion Host ist primäres Angriffsziel Schutz auf Host-Ebene u.u. nicht ausreichend Bei erfolgreichem Angriff direkter Angriff auf interne Knoten möglich Daher: Isolierung des Bastion Hosts in Grenznetz Zusätzliche Schutzschicht für interne Infrastruktur Angreifer muss zusätzlich noch den inneren Router überwinden Kein Sniffing von internen Paketen im Grenznetz Vertrauliche Kommunikation nur im int. Netz Grenznetz (perimeter network) Internes Netz Bastion Host Innerer Router Internet Äußerer Router Matthias Hovestadt - BKITS 4-27

28 Bastion Host, innerer und äußerer Router Exponiertes System des Unternehmens Anlaufstelle für Verbindungen aus der Außenwelt Z.B. für Dienste wie: SMTP-Server, DNS-Server, Web-Server Proxy-Dienste für das interne Netz Einsatz von gehärtetem Betriebssystem Innerer Router (Choke Router) Letzter Schutzwall vor dem internen Netz Trägt die Hauptlast der Paketfilterung Individuelle Regelsätze für Paketfilterung notwendig (z.b. DNS) Äußerer Router (Access Router) Üblich: Freie Kommunikation aus Grenznetz in das externe Netz Grobe Vorfilterung des eingehendes Netzwerk-Verkehrs Blockierung von externen Paketen mit internen IP-Adressen Matthias Hovestadt - BKITS 4-28

29 Zweistufiger Angriff DOS-Attacke gegen Rechner A Beispiel: Fälschung von IP-Adressen Pakete mit gefälschter IP-Adresse an Rechner B Ziel: Ausnutzung des Vertrauensverhältnisses zwischen A und B Ablauf des Angriffs Rechner B hält Request für authentisch und antwortet Rechner A kann wg. DOS-Angriff nicht reagieren Angreifer muss Kommunikation blind führen! Internet Grenznetz (perimeter network) Internes Netz Bastion Host Innerer Router Vertrauen Äußerer Router Matthias Hovestadt - BKITS 4-29

30 Mehrere Bastion-Hosts im Grenznetz Grenznetz ist vollwertiges Netz Bereitstellung einer Service-Infrastruktur Einsatz mehrerer Bastion-Hosts sinnvoll Redundanz (z.b. MX-Record für SMTP), Performanz, Separation von Diensten für interne und externe Nutzer Höhere Sicherheit Trennung von Diensten Fehler in einem Dienst führt nicht zur Kompromittierung aller Dienste Internet Grenznetz (perimeter network) Internes Netz Bastion Host Innerer Router Bastion Host Äußerer Router Matthias Hovestadt - BKITS 4-30

31 Bastion Host im Grenznetz Zusammenlegung von innerem/äußeren Router möglich Anbindung der Netze über verschiedenen Schnittstellen Zusammenfassung aller Regelsätze auf einem Gerät Router muss ausreichende Flexibilität aufweisen Lösung ist möglich, aber problematisch Erfolgreicher Angriff auf Router öffnet sofort das interne Netz Keine Ausfallsicherheit bzw. Fehlertoleranz Internet Grenznetz (perimeter network) Internes Netz Bastion Host Innerer/ äußerer Router Matthias Hovestadt - BKITS 4-31

32 Bastion Host als äußerer Router Bastion-Host als Multi-Homed Rechner Mehrere Netzwerk-Schnittstellen für unterschiedliche Rechner Bastion-Host übernimmt Aufgaben des äußeren Routers Filterung der Pakete gemäß definierter Regelsätze Problem: Sicherheit Bastion Host durch direkte Anbindung angreifbarer Bei Ausfall nicht mehr von int. Netz aus erreichbar Grenznetz (perimeter network) Internes Netz Innerer Router Bastion Host Internet Matthias Hovestadt - BKITS 4-32

33 Bastion Host als innerer Router Gefährliche Konfiguration Bastion Host und äußerer Router mit unterschiedlicher Funktion Wichtig: Bastion Host darf internes Netz nicht belauschen Innerer Router hat Schutzfunktion für internes Netz Zusammenlegung macht internes Netz verwundbar Bastion-Host von Extern angreifbar Bei erfolgreichem Angriff Vollzugriff auf internes Netz (z.b. für Sniffing von Datenpaketen, ) Grenznetz (perimeter network) Internes Netz Bastion Host Internet Äußerer Router Matthias Hovestadt - BKITS 4-33

34 Einsatz mehrerer innerer Router Gefährliche Konfiguration Routing: Dynamisches Routing könnte interne Pakete in das Grenznetz transportieren Wartung: Schwierige Wartung beider Router, Gefahr von Inkonsistenzen im Regelwerk der beiden Router Mögliche Lösung: Unterschiedliche Grenznetze Eigener äußerer Router je Grenznetz Internet Grenznetz (perimeter network) Internes Netz Bastion Host Innerer Router Innerer Router Äußerer Router Matthias Hovestadt - BKITS 4-34

35 Einsatz mehrerer äußerer Router Einsatz mehrerer äußerer Router ist unkritisch Gefahr für Angriff verdoppelt, aber internes Netz bleibt geschützt Höhere Redundanz (Ausfall eines äußeren Routers) Wichtig: Gleiche Sicherheitsstufe bei beiden Anbindungen Führt eine Anbindung zu Partner-Unternehmen, so sollten diese Pakete nicht im Grenznetz erlauscht werden können Internet Lösung: mehrere Grenznetze Partnernetz Äußerer Router Grenznetz (perimeter network) Internes Netz Innerer Router Bastion Host Äußerer Router Matthias Hovestadt - BKITS 4-35

36 5.4 Network-based Intrusion Detection Systeme Firewall-Systeme nicht unüberwindbar Angriffe auf Fehler im System selbst Fehler in der Konfiguration des Systems Falsches Verhalten eines Benutzers Erfolgreicher Angriff muss schnellstmöglich erkannt werden Mittel der Wahl: Intrusion Detection Systeme Angreifer kann evtl. noch identifiziert werden Ausmaß des Schadens kann eingedämmt werden Kann als Mittel zur Abschreckung dienen Liefert Informationen über den Weg des Eindringens Ggf. Anpassung der Firewall-Regeln Matthias Hovestadt - BKITS 4-36

37 Funktionsweise Grundannahme von IDS: Das Verhalten des Angreifers weicht messbar von dem Verhalten eines normalen Benutzers ab Schwierige Abwägung Enge Definition des normalen Verhaltens führt zu Fehlalarmen Allzu schwammige Definition macht Ergreifung unmöglich Notwendig Sammeln von Informationen über normales Systemverhalten Bestimmung von Grenzwerten Ziel: Erkennung eines Angriffs Matthias Hovestadt - BKITS 4-37

38 Audit Records Datengrundlage für IDS Aufzeichnung des Benutzerverhaltens Datenquelle Betriebssystem Nutzung aller vom Betriebssystem aufgezeichneten Informationen Problem: nicht alle relevanten Informationen werden bereitgestellt Datenquelle Monitoring Installation spezieller Monitoring Software Protokollierung aller Benutzeraktivitäten, beliebig feingranular Problem: Zusätzlicher Aufwand Datenfelder eines Audit Records variieren je nach System Typisch: Zeitstempel, Benutzername, Aktion, Objekt, Fehlercode, Liste genutzter Ressourcen Matthias Hovestadt - BKITS 4-38

39 Beispiel für Audit Record Befehl: cp ~/passwd.mod /etc/passwd Generierte Audit Records: Timestamp User AcHon Object Error maho Execute cp maho Read ~/passwd.mod maho Write /etc/passwd 1 Hier: Aufteilung der Operation in mehrere Audit Records Kontrollierter Zugriff auf Objekte als schützenswerte Elemente Niedrige Komplexitätsstufe bei Protokollierung Einfache Definition von Regeln pro Audit Record möglich Matthias Hovestadt - BKITS 4-39

40 Ansätze (1/2): Statistische Anomalieerkennung Erkennung von Anomalien im Benutzerverhalten Basiert auf einem statistischen Ansatz Grundlage: Datenmaterial über Verhalten regulärer Nutzer Nutzung statistischer Modelle zur Erkennung von Missbrauch Auf Basis von statischen oder adaptiven Grenzwerten Auf Basis von Profilen: Definition von Profilen, die auf verschiedene Benutzergruppen zugeschnitten werden können Vorteil: Passt sich auf Nutzerverhalten an Nachteil: Korrektheit der Grenzwerte ist kritisch Matthias Hovestadt - BKITS 4-40

41 Ansätze (2/2): Regelbasierte Erkennung Erkennung von regelwidrigem Verhalten Basiert auf festgelegtem Regelsatz Beschreibung der normalen Systemnutzung in Regeln Erkennung von Anomalien: Abweichungen vom normalen Nutzerprofil Erkennung von Eindringlingen: Suche nach auffälligem Verhalten Vorteile: Überprüfbare Kommunikationsmuster Nachteil: Fehlende Dynamik und Adaptivität, fragliche Vollständigkeit des Regelwerks Matthias Hovestadt - BKITS 4-41

42 5.5 Honey Pot Erste Verteidigungslinie: Firewall Abschottung und Separierung der Netze Ziel: Internes Netz vor Angriffen schützen Überschaubares Problem: wie ist die Firewall zu konfigurieren? Zweite Verteidigungslinie: Intrusion Detection Systeme Erkennung von Eindringlingen und System-Missbrauch Ziel: Frühzeitige Erkennung, um Schaden zu minimieren Großes Problem: Wie sehen Angriffe aus? Dritte Verteidigungslinie: Honey Pots Erlernen von Angriffsmustern Leichtere Identifikation von Angreifern Matthias Hovestadt - BKITS 4-42

43 Grundidee Status Quo: Netzwerk als Angriffsziel Netzwerk ist statisch im Internet erreichbar Angreifer kann sich Zeitpunkt des Angriffs aussuchen Verteidiger kann sich schlecht vorbereiten Ziel: Erhöhung der Chancen zur erfolgreichen Verteidigung Aufdeckung eines Angriffs Entschlüsselung eines Angriffs Ergreifung von Gegenmaßnahmen Matthias Hovestadt - BKITS 4-43

44 Die Versuchung des Honigtopfs Idee: Auslegen eines Köders für potentielle Angreifer System bietet reguläre Dienste im Netz an Keinerlei wertvolle Daten oder Dienste vorhanden System wird niemals von regulären Nutzern kontaktiert Angreifer kann nicht zwischen einem echtem System und dem Honey Pot unterscheiden Angreifer sucht im Netz blind nach Systemen für Angriff Angreifer wird auf angebotene Dienste stoßen Honey Pot als präpariertes System Monitoring Software protokolliert alle Zugriffe Alarmierung der Administratoren über erfolgten Angriff Dynamische Rekonfiguration der Firewall Matthias Hovestadt - BKITS 4-44

45 Honey Pot Typen (1/2): Low Interaction Honey Pot System bildet lediglich Systemdienste nach Anbieten eines FTP- oder Web-Dienstes Originaler Systemdienst wird lediglich nachgebildet Ziel sind automatisch geführte Angriffe Probleme: Begrenzter Informationsgewinn Originaler Dienst hat ggf. anderes Verhalten Für den versierten menschlichen Angreifer erkennbar Verhalten des Honey Pots unterscheidet sich vom org. System Low Interaction Honey Pot haben daher Charakteristik eines Intrusion Detection Systems Wenn Dienst angesprochen wird, ist ein Angreifer im Netz. Matthias Hovestadt - BKITS 4-45

46 Beispiel für Low Interaction Honey Pot Open Source System: honeyd Emulation von populären Systemdiensten Arbeitsweise Beobachtung des Netzwerks Kennt die Adressen aller realen Systeme Wird Zugriff auf ungenutzte IP-Adresse beobachtet, antwortet honeyd dem Angreifer unter Angabe jener IP-Adresse In dünn besetzten Netzen sehr hohe Erkennungswahrscheinlichkeit Virtueller Honey Pot honeyd Server Reale Hosts Matthias Hovestadt - BKITS 4-46

47 Honey Pot Typen (2/2): High Interaction Honey Pot Honey Pot ist vollständiger Server Komplettes Betriebssystem mit allen Serverdiensten vorhanden Einsatz der originalen Serverdienste Ziel: Lernen von manuell geführten Angriffen auf System Der Angreifer muss das angegriffene Ziel für wertvoll erachten Beobachtung der Aktionen des Angreifers auf dem System Ausführung des Systems in virtueller Umgebung Ausführung spezieller Software im System Kernel-Erweiterung Sebek, die alle User-Space Aktionen protokolliert und von Kernel-Space aus an Logger sendet Problem: Aufwändige Installation Matthias Hovestadt - BKITS 4-47

48 5.6 Host-based Intrusion Detection Allgemeines Problem: Erkennung IT-Infrastruktur bleibt trotz aller Absicherungen angreifbar Angriff muss frühestmöglich erkannt werden Bislang lediglich externe Elemente Firewall zur Abschottung interner Netze Gesicherte Bastion Hosts ggf. mit gehärtetem Betriebssystem Honey Pot versucht Falle aufzustellen Erkennung eines Angriffs auf ein System Aufgabe von Hostbased Intrusion Detection System (HIDS) Matthias Hovestadt - BKITS 4-48

49 Überwachung der Dateien Situation: Ein Angreifer konnte erfolgreich eindringen Hat Benutzerrechte erlangt und bewegt sich im System Grundidee: Ein Angreifer verändert bei seinem Angriff Dateien auf dem lokalen Host Veränderungen von Systemkonfiguration, Z.B. um späteres erneutes Eindringen zu ermöglichen Dateien werden nicht durch Normalbetrieb geändert Ziel: Erkennung dieser Veränderungen Zahlreiche Systeme verfügbar: TripWire, AIDE, Matthias Hovestadt - BKITS 4-49

50 Zweistufiger Ablauf Schritt 1: Aufbau der Datenbank Analyse des Dateisystems Bildung von Prüfsummen relevanter Dateien Systemdateien, Konfiguration, Speicherung der Prüfsummen in Datenbank Schritt 2: Analyse des System Erneute Bildung von Prüfsummen relevanter Dateien Abgleich der Prüfsumme mit Datenbank Matthias Hovestadt - BKITS 4-50

51 Hase und Igel Intrusion Detection kann Einbrüche melden, aber Ausbleiben einer Einbruchsmeldung ist keine Entwarnung Systeme wie TripWire melden Änderungen an Dateien aber was passiert, wenn Dateien nicht geändert werden? Systeme wie chkrootkit durchsuchen z.b. den Speicher aber es werden nur bekannte Rootkits gefunden Fazit: Erkennung eines Einbruchs nicht trivial Unterstreicht Bedeutung einer sorgfältigen möglichst sicheren Systemkonfiguration Matthias Hovestadt - BKITS 4-51

52 5.7 System Monitoring Ziel: Bereitstellung eines zuverlässigen Dienstes Stichwort: Hochverfügbarkeit (99%, 99.9%, 99.99%, ) Bislang betrachtet: Externe Faktoren Angriff durch Eindringling, Denial of Service Nun im Fokus: Interne Faktoren Ausfall einzelner Komponenten innerhalb der Infrastruktur Z.B. Ausfall eines Servers oder eines Netzwerk-Routers Probleme: Gegenseitige Abhängigkeiten aufgrund komplexer Infrastruktur Beurteilung des Systemzustands Matthias Hovestadt - BKITS 4-52

53 Manuelle vs. Automatische Überprüfung Ansatz 1: Manuelle Überprüfung Administrator kennt Aufbau und Komponenten der Infrastruktur Periodische Überprüfung der Funktionalität Probleme Skalierbarkeit (Anzahl Systeme als auch Anzahl Parameter) Zuverlässigkeit (Interpretation der Daten) Ansatz 2: Automatische Überprüfung Zentralisierte Überprüfung der Infrastruktur Auswertung der Messdaten gemäß Konfiguration Durchführung von Aktionen zur Alarmierung Senden von Nachrichten, SMS, Matthias Hovestadt - BKITS 4-53

54 Nagios Open Source System für Netzwerk Monitoring Kontinuierliche Entwicklung seit 1999 Komponenten Sammlung diverser Überwachungsmodule Überwachung von Komponenten (Hosts) Überwachung von Diensten (SSH, HTTP, ) Überwachung von Systemen (CPU-Temp, freier Speicher,..) Sammlung beliebig erweiterbar Einsatz in heterogenen Umgebungen möglich Zentraler Nagios-Server Auswertung und Durchführung von Aktionen Ausfallsicherheit durch Failover-Server Visualisierung durch Web-Oberfläche Matthias Hovestadt - BKITS 4-54

55 Überwachung von Netzen Matthias Hovestadt - BKITS 4-55

56 Grafische Präsentation der Monitoring Daten Matthias Hovestadt - BKITS 4-56

57 Literatur Netze Douglas E. Corner: Computernetzwerke und Internets, Pearson Studium, 2003 Firewall Elisabeth Zwicky: Einrichten von Internet Firewalls, O Reilly, 2001 Security William Stallings: Cryptography and Network Security: Principles and Practises, Prentice Hall, 2002 Monitoring Wolfgang Barth: Nagios, System- und Netzwerk-Monitoring, Open Source Press, 2005 Matthias Hovestadt - BKITS 3-57