Der Blast-o-Mat. Intrusion handling an der RWTH Aachen. Jens Hektor, Jan Göbel Rechen- und Kommunikationszentrum RWTH Aachen

Transkript

1 Der Blast-o-Mat Intrusion handling an der RWTH Aachen Jens Hektor, Jan Göbel Rechen- und Kommunikationszentrum RWTH Aachen [hektor

2 Agenda Lokale Gegebenheiten und Motivation Administratoren und mobile Nutzer Einfache Sensorik (Portscans) und Aktionen Erweiterte Sensorik (Spammer) und fortgeschrittene Sensorik (Honeypots) Geschichte, Zahlen und Ausblick

3 Das Netz der RWTH ca. 500 Einrichtungen, 300 Gebäude 3 Class-B Netze ca. 550 Endgerätenetze, Ansprechpartner bekannt ca. 60 Cisco- und 50 Linux-Router Zentral verwaltete Firewall Internetuplink ca. 60 Cisco-ACL Filter zentral ca. 50 Linux-Firewall dezentral Policy Outgoing weitgehendst offen, Incoming Serverdienste gefiltert

4 Motivation Sommer 2003: Beobachtung vereinzelter Portscans botverseuchter Rechner Später in 2003: W32/Blaster Analyse: zunächst Firewalllogs später: Sniffen am Backbone nach TCP/SYN Reaktion: Benachrichtigen der Administratoren bzw. Nutzer (VPN, Modem- u. ISDN-Einwahl) Im Wiederholungsfalle: Sperren IP oder Account Nach 4 Wochen Blaster: s DAS WILL MAN NICHT HÄNDISCH MACHEN!

5 Netzdatenbank Entstanden aus der Domain-Ansprechpartnerliste (Guido Bunsen, RZ RWTH) Derzeit XML-Format, synchron mit Routing gepflegt Netz, Maske, Vlan-Nummer, Institutskennziffer Ansprechpartner (Name, Telefon, ) MORV: Managed on Router (Vlan) Zugriff in Zukunft via WHOIS (A. Neumann, RZ RWTH) Information an den Admin bringen Automatisierung (IP -> adresse) Standardisierung der Abfrage Pflege, Dokumentation der Daten

6 Mobile Nutzer VPN oder Modem- bzw. ISDN-Einwahl Logs des Authentifizierungs- oder Accountingservers Radius früher mit radlast jetzt mit MySQL Backend zum Loggen (Thomas Böttcher, RZ RWTH) Sehr kritisch bzgl. der Zeitstempel Nutzerdatenbank (Identity Management) zum Ermitteln der adressen (P. Schmitz, M. Schraad, RZ RWTH) Sperren eines Accounts Aufbewahrungsfristen der AA Daten IM Datenzugriff proprietär

7 Sensorik I: Portscans SPAN (Mirror) am zentralen Router 180s samplen, danach Auswertung Nur TCP/SYN interessanter Ports Whitelisting z.b. für Mailserver Schwellwert: 50 kontaktete Hosts RWTH: 3 Gbit/s Peak Raten am Backbone Verlorene Pakete sind kein Problem tcpdump -l -n -nn -i eth3 -q -tt ( port 22 or port 25 or port 135 or port 139 or port 445 or port 1433 or port 4899 or port 5000 or port 6129) && tcp[tcpflags] & (tcp-syn tcp-ack) == tcp-syn

8 Und es hat b-o-m gemacht PGP signierte an Administrator/Nutzer Ausschnitte aus den Logs angehängt Hinweise auf Updates, Virenscanner und hilfreiche Webseiten, Helpdesk Institutsnetze: sofortige Sperrung der IP Mobile Nutzer: Warnung, nach 20 Minuten Kick, nach 3 Kicks Sperren des Accounts Von Administratoren begrüßt Mobile Nutzer lesen nicht ihre RWTH Gelegentlich positive Reaktionen der Endnutzer Allgemein akzeptiertes Verfahren

9 Und Action I: Sperren von IPs Skript generiert Anti-Spoofing ACLs Routing Information via SNMP Include-Files zum Firewallen Skript zum Einfügen und Entfernen von Sperrungen Extended IP access list in.vlan deny ip host any Python Skript zum Upload auf Ciscos: Login(!), TFTP 20 permit tcp any any established 30 deny ip any deny ip any deny ip any deny ip any deny ip any deny ip host any 90 deny ip host any 100 permit ip any 110 permit igmp any any 120 permit gre any any 130 permit pim any any 140 permit udp any deny ip any any log-input

10 Und Action II: Kicken aus dem VPN Cisco VPN-Konzentratoren 3000er Serie: SNMP Finden der IP in: Schreiben des Wertes 6 auf Cisco ASA: Login (!), configure mode, Kommando clear crypto ipsec sa peer <IP> Cisco 6500er IPsec modul: kicken unzuverlässig Hallo? Standardisierung?

11 SPAM? It's so easy! 2006: Portscans sind out, SPAM ist in! Spammer sind auch nicht wesentlich anders Der Payload enthält wechselnde FROM: Erkennung: Scan auf TCP/25 triggert Analyse des Payload Whitelisten von regulären Servern Feb 22 20:30:36 noc99 BlastoMat v4[7010]: Used Senders: '']

12 Hmm, lecker: Honeypots Simulierte Honeypots mit Nepenthes in 24 /28er Netzen (Jan Göbel, RZ RWTH) Vorteil: keine false positives Vorteil: capturing durch simulierten Malwaredownload Virenscannertests Analyse in Sandboxen kleiner Nachteil: der Payload muß den Honeypot treffen Feine Sensorik, hoher Informationsgewinn Spuren zu den Verursachern und in deren Infrastruktur

13 Geschichte, Zahlen : V1 150 Zeilen Shellcode (Detektion, Benachrichtigung) 2004: V2 850 Zeilen kommentiert und strukturiert 2005: V3 Python, ca Zeilen, Kicken von Nutzern (Gert Menke) 2006: V4 Python, ca 4600 Zeilen Sperren, Nepenthes, Spam Detektion Datenbankgestützte asynchrone Kommunikation (Diplomarbeit Jan Göbel, jetzt RZ RWTH) Versendete s (Sperrungen) 2003: 1500(70) 2004: 5400(950) 2005: 4300(880) 2006: 2700(300)

14 Versendete Benachrichtigungen

15 Zusammenfassung Intrusion detection sehr fokussiert: Anomalien (Portscans), Signaturen (SPAM) Honeypot basiert Intrusion prevention (?) - jenseits des Marketing Intrusion handling! Benachrichtigungen an die Betreiber der Problemmaschinen Im praktischen Einsatz seit > 3 Jahren

16 Danke an die Kollegen im RZ für die vielen kleinen Helferlein... und ans Auditorium Fragen?