33
Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT- Sicherheitsforum 06.02.2003 1 Matthias Ruckdäschel RRZE [email protected] [email protected] http://www.rrze.uni-erlangen.de IT-Sicherheitsforum Sicherheitswerkzeuge im Netzwerk

1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE [email protected]

Embed Size (px)

Citation preview

Page 1: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

1

Matthias RuckdäschelRRZE

[email protected]@RRZE.uni-erlangen.de

http://www.rrze.uni-erlangen.de

IT-SicherheitsforumSicherheitswerkzeuge im Netzwerk

Page 2: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

2

Übersicht

• Netzwerkanalyse– Port-Scans– Rechner-Analyse– Netzwerk-Überwachung

• Netzwerk- und Rechnersicherheit (Firewall)– Paketfilter– Application Gateway– Personal Firewall

Page 3: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

3

Ziel des Vortrags

• Schnelles Erkennen von Eindringlingen und Schwachstellen mit einfach Mitteln

• Grenzen der Netzwerkanalyse aufzeigen

• Mögliche Schutzmaßnahmen erläutern

• Nicht: Detaillierte forensische Analyse von Rechnern bzw. Netzwerkverbindungen

Page 4: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

4

Grundlagen der IT-Sicherheit

• Eigene Systeme und deren (normales) Verhalten (sehr) gut kennen!

• Auf Auffälligkeiten konzentrieren, z.B.:– Rechner ist unerwartet langsam

– Festplatte ist aus unerklärlichen Gründen voll

• Das Naheliegende zuerst überprüfen

• Ruhig bleiben; Panik verursacht Fehler

• Vorbereitet sein!

Page 5: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

5

Absicherung von Systemen

• Deinstallieren• Abschalten• Konfigurieren• Patchen• Virenschutz• Benutzerverhalten:

– Optimal: Benutzer installieren keine Software

– Mindestanforderung: Schulung der Benutzer: Software aus dem Internet birgt Risiken

Bei Beachtung dieser Maßnahmen sind über 99% aller „Hacks“ vermeidbar!

Page 6: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

6

Denkweise von Hackern

• Warum wird ein Rechner gehackt?1. Script-Kiddies

2. Verschleierung von Spuren

3. Ablage von urheberechtlich geschützten oder strafbaren Daten

4. Ausspionieren von lokalen Daten

• Für die Punkte 1-3 gilt:– Hacker will möglichst wenig Aufwand

– Einfache Schutzmaßnahmen sind meist ausreichend!

Page 7: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

7

Spionage von Daten

• Schützenswerte Daten:– Prüfungen (Lösungen / Ergebnisse)

– Forschungsergebnisse, Patente

– Industrieprojekte

– Mitarbeiter- und Finanzdaten

– u.v.m

• Schützenswerte Daten sind durch Standardmaßnahmen nicht ausreichend geschützt.

• Beratung durch das RRZE

Page 8: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

8

• Angriffe auf schützenswerte Daten sind selten, bleiben aber oft „im Rauschen“ verborgen:

Missbrauch durchInsider

„Standard-Hacks“

Verdeckung von Angriffen

Spionage durchExterne

„Standard-Hacks“

Missbrauch durchInsider

Spionage durchExterne

Page 9: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

9

Standard-Hacks

• Knacken einfacher / fehlender Passworte

• Ausnutzen von bekannten Schwachstellen

• Trojaner über Mail / IRC verschickt oder versteckt in Software (z.B. gehackte Spiele, etc.)

Bei Standard-Hacks wird oftmals keine Energie in die Verschleierung gesteckt: Kompromittierte Rechner sind leicht zu erkennen!

Page 10: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

10

Netzwerkanalyse

• Datenschutz beachten!

• Nur im eigenen Bereich erlaubt!

• Schwierig bei gezielter Verschleierung

• Motivation:– Schwachstellen erkennen:

• Fehlende Patches

• Mangelhafte Konfiguration

• Fremde Software (Filesharing-Tools, Serv-U)

– Missbrauch / Eindringlinge erkennen

Page 11: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

11

Möglichkeiten der Netzanalyse

• Port-Scan– Suche nach Diensten, die über das Netz erreichbar sind.

• Rechner-Scan– Versuch, über das Netz zusätzliche Informationen über

die Konfiguration eines Rechner zu erhalten

• Netzwerk-Monitoring– Überwachung und Analyse von Verbindungen

Page 12: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

12

Port-Scans

• Grundsätzlich:Jedes Programm auf einem Rechner, welches Verbindungen von außen akzeptieren soll, muss vorher einen Port öffnen (Status: Listening).

• Offene Ports können erkannt werden.Ausnahme: Personal Firewall / Paket-Filter

• Was erreichbar sein soll, ist auch sichtbar.

• Problem: Manche Ports werden erst unter bestimmten Bedingungen aktiviert.

Page 13: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

13

Port-Scans: Was?

• Unterscheidung TCP/UDP

• Welche Ports?– Gezielt auf einzelne Ports– „Well-Known“-Ports– Port-Range (theoretisch 1-65535)

• Vorsicht: kein strikter Zusammenhang zwischen Port und zugehörigen Dienst!

Page 14: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

14

Port-Scans: Womit?

• Freeware Port-Scanner: NMAP– http://www.nmap.org– Verfügbar als Source-Code für Unix / Linux

und Windows– Windowsversion in Entwicklung– Ursprünglich Kommandozeilen-Tool– Graphische Oberfläche verfügbar– Benötigt lokale root / Adminstrator-Rechte

Page 15: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

15

Erkennen des Port-Status

• Das Verhalten des Rechners auf eingehende Pakete hängt vom Betriebssystem, IP-Stack und den Applikationen ab.

• Ausgabe von NMAP unterliegt bestimmten Annahmen:

TCP - Port UDP - Port

erfolgreiche Verbindung offen ---

ICMP „Port unreachable“ geschlossen geschlossen

Verbindung abgelehnt (RST) geschlossen ---

keine Antwort geschlossen offen

Page 16: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

16

Port-Scan: Analyse

• OS-Fingerprint (Ergebnis kann Hinweis liefern)

• Suspekte Rechner vor Ort überprüfen– Listet geöffnete Ports:

• Unix / Windows NT/2000/XP: „netstat -an“– Welcher Prozess hält welchen Port offen?

• Windows NT/2000/XP: „fport“ (http://www.foundstone.com/knowledge/proddesc/fport.html)

• Unix: lsof(http://freshmeat.net/projects/lsof/)

– Interessant sind Ports mit Status „LISTENING“

Page 17: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

17

Port-Scan: Analyse

• Verbergen von Diensten / Ports (übers Netz und lokal) möglich

• Lokale Analyse potentiell kompromittierter Rechner fragwürdig.

• Bei Verdacht auf „tiefes“ Eindringen ins Betriebssystem muss der Zugriff auf die Festplatte durch ein anderes Betriebssystem erfolgen.

Page 18: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

18

Rechner-Analyse

• Reaktion eines Rechners beim Ansprechen eines Ports.

• Test-Pakete an bestimmte Ports setzen und Reaktion beobachten.

• OS-Fingerprints

• Analyse von Schwachstellen(fehlende Patches / mangelhafte Konfiguration)

Page 19: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

19

Rechner Analyse: Womit?

• Freeware-Scanner NESSUS:– http://www.nessus.org– Zweiteilig:

• Server („Daemon“) auf Unix• Client auf Unix oder Windows 32

– Setzt auf NMAP auf– Enthält viele vorgefertigte „Plugins“– Skript-Sprache zum Ergänzen eigener Plugins

• „Save-Checks“ einschalten, andernfalls sind Störungen an Rechnern möglich!

Page 20: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

20

Rechner Analyse: Auwertung

• Auswertung der Nessus-Ergebnisse:– Einstufung der Wichtigkeit fragwürdig

– Wissen über gescannte Rechner ist nötig

– Oftmals Fehlalarm, Ergebnisse verifizieren

– Ergebnisse können in Datenbank gespeichert werden

– Vergleich zu früheren Ergebnissen oder gleicher Rechner Konfiguration möglich und sinnvoll.

Kein EDV-TÜV: Negatives Ergebnis bedeutet nicht, dass der Rechner sicher ist!

Page 21: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

21

Zusammenfassung zu Scans

• Nur im eigenen Bereich scannen

• „Versehentliche“ Fehlkonfiguration oder weltweit verfügbare Dienste leicht zu erkennen

• Verschleierung am lokalen Rechner möglich!→ Falsche Sicherheit?

Matthias Ruckdäschel
Page 22: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

22

Netzwerk-Monitoring

• Aufzeichnung aller Verbindungsdaten am Gateway-Rechner oder durch „Schnüffeln“ im Netz.

• Vorteil: Es werden alle Verbindungen erfasst

• Sehr gut bei konkretem Verdacht oder zur Verfolgung von bekannten Missbrauchsfällen

• Die Bestimmungen des Datenschutzes sind zu beachten!

• Problem:Bandbreite / Geschwindigkeit des Rechners

Page 23: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

23

Monitoring: Analyse

• Sehr großes Datenvolumen(„Nadel im Heuhaufen“)

• Unterscheidung:• Versuchter Verbindungsaufbau

• Erfolgreicher Verbindungsaufbau

• Datenvolumen

• Analyse sehr schwierig Intrusion Detection System

Page 24: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

24

Schutzmaßnahmen im Netz

• Für Rechner mit sensiblen Daten sinderweiterte Schutzmaßnahmen nötig.

• Am einzelnen Rechner:–Personal Firewall –Paket Filter

• Im gesamten Netzwerk (Firewall)–Paket Filter–Application Gateway

Page 25: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

25

Philosophie des Filterns

• Negativ-ListeEinzelne Dienste / Rechner werden geschützt– Leichter zu konfigurieren

– Nicht so sicher wie Positiv-Liste

• Positiv-ListeErlaubte Verbindungen werden explizit konfiguriert– Exakte Konfiguration ist schwierig

– Auf Rückkanal achten

Page 26: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

26

Grundsätzliches

• Genaue Kenntnis der Kommunikationsbeziehungen notwendig

• Ausnahmen reduzieren („Schweizer Käse“)

• Vorsicht bei oberflächiger Konfiguration (trügerische Sicherheit)

• Paketfilter schützen nur bedingt vor lokalen Benutzern und eingeschleppten Viren.

Page 27: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

27

Paketfilter

• Verbietet / Erlaubt bestimmte Ports und / oder IP-Bereiche

• Eingehende Antworten werden durchgelassen:– Statless Filter– Statefull Filter (besser, aber mehr Ressourcen nötig)

• Benötigt geringere Resourcen als App. Gateway

• Kann Multicast erlauben(wichtig für Multimedia-Anwendungen)

Page 28: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

28

Paketfilter an der FAU

• Können auf Routern der FAU implementiert werden

• Werden ausschließlich vom RRZE gepflegt

• Subnetzbetreiber muss Schutzbedarf und Kommunikationsbeziehungen ermitteln:http://www.rrze.uni-erlangen.de/security/handbuch

• Beratung durch Volkmar Scharf(mailto: [email protected])

• Eigene, dezentrale Lösungen an der FAU nicht erlaubt: http://www.rrze.uni-erlangen.de/netze/aup.html

Page 29: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

29

Application Gateway

• Eigenes Modul für jede Anwendung nötig (z.B. http, ftp, smtp, pop,...)

• Widerspruch zu End-To-End-Verschlüsselung

• Evtl. Umsetzung der IP-Adressen(Network Address Translation)

• Benötigt ausreichend CPU-Ressourcen

• Exakte Konfiguration schwierig

• Vor Einsatz mit RRZE absprechen

Page 30: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

30

Personal Firewall

• Paket Filter

• Läuft auf dem jeweiligen Rechner

• Leicht zu konfigurieren bei privaten Rechnern.

• Integration im Uni-Netz (Zugang zu Servern, …) aufwendiger

• Schwierige Konfiguration bei Verwendung auf Servern

• Schützt nur bedingt vor lokalen Benutzern und Trojanern

Page 31: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

31

Beispiele für Personal Firewall

• Tiny Personal Firewall (kostenpflichtig):http://www.tinysoftware.com

• Zone Alarm:– Grundversion kostenlos für private Nutzung– Kostenpflichtig für den Einsatz an der Uni– http://www.zonelabs.com

Page 32: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

32

Integrierte Windows Firewall

• Ab Windows 2000: TCP/IP Filtering– Konfiguration gültig pro Rechner

• Ab Windows XP: Internet Connection Firewall– Konfiguration gültig pro Netzwerkkarte

• Vorsicht: Firewall wird (manchmal) bei der Installation von MS-Zusatzprodukten (z.B. IIS) automatisch umkonfiguriert.

• Kein Filtern von ausgehenden Verbindungen(z.B. Spyware)

• Nur Filtern von Ports, keine IP-Adressen

Page 33: 1 Matthias Ruckdäschel Regionales RechenZentrum Erlangen IT-Sicherheitsforum 06.02.2003 Matthias Ruckdäschel RRZE Matthias.Ruckdaeschel@RRZE.uni-erlangen.de

Matthias RuckdäschelRegionales RechenZentrum Erlangen

IT-Sicherheitsforum06.02.2003

33

Literatur

• Schnelle Suche nach potentiellen Eindringlingen (Windows, Unix):http://www.psionic.com/papers/FastForensics.pdf