Elementare Sicherheitsmaßnahmen:

Transkript

1 Elementare Sicherheitsmaßnahmen: Firewalls und Netz-Zugriff Florian Prester Volkmar Scharf RRZE

2 Motivation Angriffe und Angriffsarten kennen Schwachstellen analysieren Maßnahmen ergreifen Sicherung der Systeme Durchführen von Netzwerkanalysen Verhalten im Angriffsfall Notwendigkeit geeigneter Werkzeuge Aber ich muss doch an meine Daten! Sicherheit durch Unauffälligkeit reicht nicht!

3 Überblick Angriffe Schwachstellen Maßnahmen Sicherung von Systemen Netzwerkanalysen Erkennen von Angriffen Verhalten im Angriffsfall Was bringt VPN Zusammenfassung

4 Angriffe (I) Wer? Script-Kiddies und Hacker/Kriminelle mit Grundlagenwissen Warum? Ausspionieren von lokalen Daten Ablage von urheberrechtlich geschützten oder strafbaren Daten Demonstration von Fähigkeiten/persönlichem Ehrgeiz Nutzung von sonst nicht zugänglichen Ressourcen Beschaffung von Informationen zur Wirtschaftskriminalität/(Industrie-)Spionage Wie? (Distributed)Denial of Service Angriffe Viren, Trojaner, Würmer Informationslecks: Spezifisches Angreifen von Schwachstellen (Scans zum Entdecken von Sicherheitslücken nmap) Remote Ausführung von beliebigem Code (Programmfehler, Bsp. Buffer Overflow ) Einbrüche durch gehackte/bekannte Passworte Florian.Prester@rrze.uni-erlangen.de 4

5 Angriffe (II) Methodik: Wie geht ein Angreifer vor? Feststellen des IP-Adressraums (Footprinting) Absuche nach Schwachstellen (Scanning) Suche nach Nutzernamen, freigegebenen Verzeichnissen (Enumeration) Erlangen von Benutzerrechten auf Systemen (Gaining Access) Installation von Malware (Viren, Trojaner, Rootkits) Erhalten von Root-Rechten (Escalating priviledge) Versuch über Standard -Logins (Beispiel: administrator,.)

6 Angriffe (III) Zugriff auf Nachbarsysteme (Pilfering) Zunächst: Infos über System/Zugänge zu anderen Systemen sammeln Bsp: Implementation eines Sniffers Schalten des Rechners in promiscuous mode (zu erkennen in /etc/var/messages) Spuren beseitigen (Covering tracks) Spuren in Log-Files löschen System-Binaries (ps, netstat, ) durch Rootkits ersetzen (automatisierte Tools, die Angreifer verdecken, Bsp.: lrk4) Hintertüren schaffen (Creating Backdoors) (Distributed) Denial of Service Attacken (DDos) Florian.Prester@rrze.uni-erlangen.de 6

7 Schwachstellen (I) Benutzer installiert seine Software selber Angreifbare Systeme Systeme werden nicht gepatched Benutzerkennungen ohne Passwörter Kein Virenschutz Keine Einschränkung der erreichbaren Dienste (Mail, ) Verwendung unsicherer (unverschlüsselter) Programme (telnet, login) Möglichkeiten, Systemfunktionalität zu schützen, werden nicht immer genutzt (Unix: TCP-Wrapper) Florian.Prester@rrze.uni-erlangen.de 7

8 Schwachstellen (II) Authentifizierung/Berechtigungen Nutzer ist Sicherheitsrisiko Nr. 1 Typische Passwörter: Username, Vorname, Name des Hundes/der Katze, Passwörter können erraten werden Brute Force: Durchsuchung des gesamten Schlüsselraumes Brute force is a trial and error method used by application programs to decode encrypted data through exhaustive effort (using brute force) rather than employing intellectual strategies. A brute force cracking application proceeds through all possible combinations of legal characters in sequence. Brute force is considered to be an infallible, although time-consuming, approach Florian.Prester@rrze.uni-erlangen.de 8

9 Maßnahmen Systeme sichern Angriffe erkennen (Bsp.: Rechner ist ungewöhnlich langsam) Untersuchen von Log-Dateien Netzwerkanalyse Werkzeuge kennen und anwenden, die auch Angreifer verwenden!!!anwendung nur lokal im eigenen Bereich!! Scannen von Ports und Rechnern Erkennen von Schwachstellen Monitoring von Netzwerkverkehr automatisierte Sicherheitstools, um Schwachstellen zu erkennen Zur Erkennung von Angriffen: Installation von Intrusion Detection Systemen

10 Systeme (I) Systeme sichern durch Benutzerverhalten Optimal: Benutzer installiert keine Software Sensibilisieren: Software aus dem Internet birgt Risiken Verwendung sicherer Programme Systemfunktionalität verbergen Systeme schwerer angreifbar machen Systeme (automatisch) patchen (Code Red: 18. Juni 2001 wurde Warnung über Schwachstelle verbreitet, 17. Juli wurde vor Virus erstmalig gewarnt) Keine Benutzeraccounts ohne Passwörter Virenschutz Einschränkung der erreichbaren Dienste Überwachung der Systeme Paketfilter/Firewall

11 Systeme (II) Verwendung sicherer Programme Verwendung von Programmen/Protokolle mit starker Verschlüsselung (Geheimhaltung des Schlüssels!) (Bsp.: SSL, SSH) Systemfunktionalität verbergen *nix: TCP-Wrapper Einschränkung der erreichbaren Dienste: s. Hinweise vom RRZE: Arbeitshilfen

12 Systeme (III) Überwachung der Systeme Monitoring (Audit) Die Nutzung soll dokumentiert werden Verletzungen der Regeln sollen dokumentiert werden Wirkung der Regeln soll geprüft werden Unregelmäßigkeiten und Änderungen sollen erkennbar sein Informationen sollen verlässlich sein Untersuchen von Logs: Optimale Lösung: dedizierter Log-Server Pattern Matching: Meist Suche nach bestimmten Schwachstellen (Aktuelle Exploits: Betriebssystem-Funktionen: *NIX: Last letzter Login-Versuch von.. Windows Login-Monitoring über Registry aktivieren

13 Systeme (IV) Paketfilter/Personal Firewalls Verbergen von Diensten Implementation auf Routern oder Rechnern mit spezieller Software verwenden Informationen zum Filtern von Paketen in Schicht 3/4 der TCP/IP- Protokollfamilie (Quell- und Zieladresse, Portnummern) Keine Überprüfung der IP/TCP/UDP Payload Keine Informationsveränderungen

14 Systeme (V) Paketfilter/Personal Firewalls f. Reduktion der Angriffsfläche Erkennen von Angriffsversuchen (Logging!) Bieten Schutz für verwundbare Dienste und Protokolle Sind auf Kontrolle durch den Administrator angewiesen Benötigen evtl. viele Ressourcen Bieten keinen Schutz, nur erhöhte Sicherheit

15 Systeme (VI) Paketfilter/Personal Firewalls ff.: Realisierung: Voraussetzung: Protokolle müssen bekannt sein!

16 Protokolle TCP/IP-Schichtenmodell ist älter und einfacher als das ISO-OSI- Referenzmodell: Application Transport Network Link telnet, ftp, http TCP, UDP IP, ICMP, IPv6 Ethernet

17 Protokolle IPv4 Aufbau des IPv4-Headers VERS HLEN Service Type Total Length Identification FGS Fragment Offset Time To Live Protocol Header Checksum Source IP Address Destination IP Address IP Options Padding Data

18 Protokolle IPv4 Bedeutung der Felder: VERS: Versionsnummer (z.zt. 4) HLEN: Länge des Paket-Headers in 32 Bit-Worten Total Length: Länge des ges. Paketes in Bytes (max ) Identification: eindeutige Kennung eines Paketes FGS: (Flags) legen fest, ob ein Paket fragmentiert werden darf, etc. Fragment Offset: Offset des akt. Fragments in Vielfachen von 8 Bytes Time To Live (TTL): maximale Lebensdauer eines Paketes; wird von jedem Router um 1 erniedrigt; wenn TTL=0, wird das Paket verworfen und eine Fehlermeldung (ICMP) an den Absender geschickt Protocol: Kennung für das Protokoll der übergeordneten Schicht (TCP=6, UDP=17) Header Checksum: Prüfsumme für den Paket-Header Source IP Address: Absenderadresse Destination IP Address: Zieladresse IP Options: Optionen Data: Anwendungsdaten Florian.Prester@rrze.uni-erlangen.de 18

19 Protokolle TCP Aufbau eines TCP-Paketes HLEN Source Port Destination Port Sequence Number Acknowledge Number Reserved Code Bits Window Checksum Urgent Pointer Options Padding Data

20 Protokolle TCP Source Port / Destination Port: Prozeßidentifikation auf Quell- und Zielrechner. Sequence Number / Acknowledge Number: dienen der Flußkontrolle HLEN: Länge des Headers in 32 Bit-Worten Window: aktuelle Fenstergröße bei der Datenübertragung Checksum: Prüfsumme (beinhaltet auch einen Teil des IP-Headers) Urgent Pointer: dient zur Übertragung von beschleunigten Daten Florian.Prester@rrze.uni-erlangen.de 20

21 Protokolle UDP UDP Header Source Port Length Destination Port Checksum Source/Destination Port-Nummer Checksum über das Paket Länge des UDP-Paketes

22 Systeme (VI) Paketfilter/Personel Firewalls f.: Realisierung: Voraussetzung: Protokolle müssen bekannt sein! Kommunikationsbeziehungen müssen bekannt sein: Asynchroner Betrieb, der In-traffic von Out-traffic unterscheidet

23 Receive SYN + ACK segment Rechner 1 Rechner 2 Send SYN seq=x Verbindungsaufbau Receive SYN segment Send SYN seq=y, ACK x+1 Send ACK y+1 Send Packet x+1 Receive ACK x+2 Send FIN seq=x Receive ACK segment Receive FIN + ACK segment Send ACK y +1 Datenübertragung Verbindungsabbau Receive ACK segment Receive Packet x+1 Send ACK x+2 Receive FIN segment Send ACK x +1 Inform Application Send FIN ACK x +1 Receive ACK segment Florian.Prester@rrze.uni-erlangen.de 23

24 Systeme (VI) Paketfilter/Personal Firewalls f.: Realisierung: Voraussetzung: Protokolle müssen bekannt sein! Kommunikationsbeziehungen müssen bekannt sein: Asynchroner Betrieb, der in-traffic von out-traffic unterscheidet Positivlisten sind zu bevorzugen (einzelne Dienste werden erlaubt) Stateful: verwenden zusätzlich Zustandsinformationen der Verbindung

25 Systeme (VII) Beispiel (Cisco): ip access-list extended <nr> permit <protocol> <rule> deny <protocol> <rule> ip access-list extended 142 permit icmp any any echo-request permit icmp any any echo-reply deny icmp any any permit tcp any host eq telnet permit tcp host any eq telnet deny ip any any

26 Systeme (VIII) Paketfilter/Personel Firewalls ff.: Grenzen: Paketfilter lösen nicht das Insiderproblem Paketfilter können die Vertraulichkeit nicht gewährleisten Paketfilter beheben keine Fehler in der Implementierung zugelassener Dienste Kein Application Gateway (benötigt geringere Ressourcen) Sind nur so sicher wie die Regeln, die sie beschreiben

27 Systeme (IX) Paketfilter/Personal Firewalls ff.: Problem: Dienste wechseln Portnummern (Netmeeting, NFS, P2P..) Vorgehensweise Sicherheitsregeln aufstellen (Security Policy) Filterregeln erstellen, implementieren und testen Dokumentation!

28 Systeme (X) *NIX: NET-Filter: Microsoft: 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. Nur Filtern von Ports, keine IP-Adressen Absicherung von ganzen Subnetzen nur durch Paketfilter in den Routern (vom RRZE) ( >Internet ->AUP)

29 Systeme (XI) Probleme? -> JA!!! Personal Firewalls sind immer mächtiger geworden und müssen daher sorgfältig administriert werden! Das RRZE unterstützt keine Personal Firewalls WLAN kollidiert des Öfteren mit Personal Firewalls. Das heißt aber nicht, dass man keine Firewall einsetzen soll! Sondern dass man sich damit beschäftigen muß!

30 Netzwerkanalyse Netzwerkanalyse ermöglicht Offenbarung von unsicheren Diensten (Port-Scan) Informationen über die Systeme Monitoring von aufgebauten Verbindungen (Aufspüren von Eindringlingen) Erkennung fehlender Patches fehlerhafter Konfiguration Automatische Werkzeuge zum Entdecken von Sicherheitslücken aber: Genaue Analyse der Ergebnisse ist erforderlich Nur im eigenen Bereich!

31 Netzwerkanalyse (Scanning) Portscans Oft Zuteilung bestimmter Ports zu bestimmten Diensten (muss nicht sein!) Portnummern: Erkennen von allen Ports, die nicht durch Personal Firewalls geschützt Was erreichbar sein soll, ist auch sichtbar Bsp.: nmap: Portscanner, der auch Betriebssystem erkennen kann Public domain für alle Betriebssysteme Kommandozeilen-Werkzeug aber auch graphische Oberfläche Root-/Administrator-Rechte notwendig

32 Netzwerkanalyse (NMAP) nmap Host discovery Port scanning OS fingerprinting nmap Optionen: -v: verbose -s: Scanning -sp: Ping scanning: Senden von ICMP echo requests -ss: Senden von TCP-Pings mit gesetztem SYN Bit (nur mit Root-Rechten!): SYN ACK: Port horcht RST: Port geschlossen -su: UDP scans: Welche UDP Ports sind offen? ICMP Port unreachable: Port ist geschlossen

33 Netzwerkanalyse (NMAP II) nmap Optionen f. -O: Versuch, Betriebssystem, Uptime,.. festzustellen -p <nr>-<nr>: Abgefragte Portnummern -g <nr>: Portnummer der Source setzen -P0: Hosts werden vor Port scanning nicht angepingt Beispiel: Prüfen, ob in einem Subnetz SMTP- Server antworten nmap ss p x.x/ Florian.Prester@rrze.uni-erlangen.de 33

34 Netzwerkanalyse (NMAP III) nmap O ss v x.x.x.x Starting nmap 3.27 ( ) at :01 CEST Interesting ports on x.rrze.uni-erlangen.de (x.x.x.x): (The 1617 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 587/tcp open submission 1023/tcp open netvenuechat 6000/tcp open X11 Remote OS guesses: FreeBSD PRERELEASE, FreeBSD 5.0- RELEASE (x86) Uptime days (since Mon Jun 16 16:57: ) Nmap run completed -- 1 IP address (1 host up) scanned in seconds Florian.Prester@rrze.uni-erlangen.de 34

35 Netzwerkanalyse (NMAP IV) x> nmap sp y (Ausgabe von tcpdump auf Rechner y (nmap läuft auf Rechner x)) 15:50: x.rrze.uni-erlangen.de >y.rrze.uni-erlangen.de: icmp: echo request 15:50: x.rrze.uni-erlangen.de > y.rrze.uni-erlangen.de. ack win :50: y.rrze.uni-erlangen.de > x.rrze.uni-erlangen.de: icmp: echo reply 15:50: y.rrze.uni-erlangen.de.http > x.rrze.uni-erlangen.de.39254: R : (0) win 0 x> nmap ss p25 y. 15:50: x.rrze.uni-erlangen.de >y.rrze.uni-erlangen.de.smtp: S : (0) win :50: y.rrze.uni-erlangen.de.smtp > x.rrze.uni-erlangen.de.39232: S : (0) ack win <mss 1460> (DF) 15:50: x.rrze.uni-erlangen.de > y.rrze.uni-erlangen.de.smtp: R : (0) win 0 (DF) Florian.Prester@rrze.uni-erlangen.de 35

36 Netzwerkanalyse (NMAP V) x> nmap ss p 25 y Starting nmap 3.27 ( ) at :45 CEST The 1 scanned port on y.rrze.uni-erlangen.de ( z.z) is: closed Nmap run completed -- 1 IP address (1 host up) scanned in seconds Ausgabe von tcpdump: 15:50: x.rrze.uni-erlangen.de >y.rrze.uni-erlangen.de: icmp: echo request 15:50: x.rrze.uni-erlangen.de > y.rrze.uni-erlangen.de. ack win :50: y.rrze.uni-erlangen.de > x.rrze.uni-erlangen.de: icmp: echo reply 15:50: y.rrze.uni-erlangen.de.http > x.rrze.uni-erlangen.de.39254: R : (0) win 0 15:50: x.rrze.uni-erlangen.de >y.rrze.uni-erlangen.de.smtp: S : (0) win :50: y.rrze.uni-erlangen.de.smtp > x.rrze.uni-erlangen.de.39232: R 0:0(0) ack win Florian.Prester@rrze.uni-erlangen.de 36

37 Netzwerkanalyse (NMAP VI) Analyse der Ergebnisse von nmap! Ports können geschlossen, offen und filtered sein erfolgreiche Verbindung ICMP Port unreachable Verbindung abgelehnt (RST) keine Antwort Firewall blockiert TCP - Port offen geschlossen geschlossen geschlossen filtered UDP - Port - geschlossen - offen filtered Florian.Prester@rrze.uni-erlangen.de 37

38 Netzwerkanalyse (System) OS-Fingerprint (Ergebnis kann Hinweis liefern) Suspekte Rechner vor Ort überprüfen Zählt geöffnete Ports auf: Unix / Windows NT/2000/XP: netstat -an Welcher Prozess hält welchen Port offen? Windows NT/2000/XP: fport ( fport.html) Unix: lsof ( Florian.Prester@rrze.uni-erlangen.de 38

39 Netzwerkanalyse (Verkehr) Sniffing Passives Abhören des Netzwerks nach Schlüsselinformationen Anschluss ans Netzwerkmedium oder Installation auf Zielmaschine bzw. als Gateway Authentifizierungsdaten (Port 23 (telnet), Port 21 (ftp)) Programme: Wireshark (Open Source): Tcpdump: snoop (Solaris) Erkennung von Sniffern: ifconfig (*NIX): Erkennen ob Rechner im promiscuous Mode Latenzzeiten beobachten!

40 Netzwerkanalyse (Verkehr) Snoop Capture und analysieren von Netzwerkverkehr Ausgabe gemäß RFC1761 snoop x.rrze.uni-erlangen.de Using device /dev/hme (promiscuous mode) x.rrze.uni-erlangen.de -> y.rrze.uni-erlangen.de ICMP Echo request (ID: 768 Sequence number: 50433) y.rrze.uni-erlangen.de -> x.rrze.uni-erlangen.de ICMP Echo reply (ID: 768 Sequence number: 50433) x.rrze.uni-erlangen.de -> y.rrze.uni-erlangen.de ICMP Echo request (ID: 768 Sequence number: 50689) y.rrze.uni-erlangen.de -> x.rrze.uni-erlangen.de ICMP Echo reply (ID: 768 Sequence number: 50689) x.rrze.uni-erlangen.de -> y.rrze.uni-erlangen.de ICMP Echo request (ID: 768 Sequence number: 50945) y.rrze.uni-erlangen.de -> x.rrze.uni-erlangen.de ICMP Echo reply (ID: 768 Sequence number: 50945) x.rrze.uni-erlangen.de -> y.rrze.uni-erlangen.de ICMP Echo request (ID: 768 Sequence number: 51201) y.rrze.uni-erlangen.de -> x.rrze.uni-erlangen.de ICMP Echo reply (ID: 768 Sequence number: 51201) x.rrze.uni-erlangen.de -> y.rrze.uni-erlangen.de TCP D=22 S=1097 Ack= Seq= Len=48 Win=16864 y.rrze.uni-erlangen.de -> x.rrze.uni-erlangen.de TCP D=1097 S=22 Ack= Seq= Len=80 Win=

41 Netzwerkanalyse (IDS) Snort ( IDS-Software Untersucht Header und Payload (jedes Feld) Flexible Handhabung von Signaturen Bereits große Menge an Regeln vorhanden, neue erscheinen unmittelbar, nachdem Exploits bekannt Bekannte Probleme: False Positives Administrativer Aufwand

42 Netzwerk Was gehört zum zum Netzwerk? Alles was eine IP-Adresse hat! Was hat eine IP-Adresse? Eigentlich alles! Drucker Fax Accesspoints DSL-Router Modem Rechner

43 Mein Netzwerk ist doch egal Wenn zuhause über ADSL, ISDN oder Modem eine Verbindung mit dem Internet hergestellt wird, sind alle bis auf das Gateway durch NAT geschützt. Was ist ein Gateway GW? Der Rechner, der die Verbindung aufbaut. Was ist NAT? Network Address Translation: Ausgehende Verbindungen werden abgefangen, und der Absender (IP:PORT) durch die des GW ersetzt. Eingehender Verkehr wird nur weitergeleitet, wenn eine Verbindung besteht und das Paket dazu paßt

44 Aber ohne Namen!? Wie wollen DIE denn wissen, wer und wo ich bin? Wollen DIE nicht! Sie wollen nur auf eine IP-Adresse, und diese wird meist zufällig ausgewählt. Oder: Irgendwann ist auch ihre Adresse bei einem Netzwerk-Scan an der Reihe! Haben Sie einen Access-Point?

45 Verhalten im Angriffsfall Keine Panik! Vorbereitet sein Abschalten des Systems oder vom Netzwerk trennen zuhause: DSL-Modem, Router Information des Sicherheitsteams im RRZE Sicherung des Datenbestandes Anweisungen des RRZE befolgen Neuinstallation bzw. Patchen & Virenschutz

46 Und wie komme ich an meine Daten?

47 Externer Zugriff Verschlüsselter und authentifizierter Zugriff: SSH SSL, https, sftp Ich habe aber Windows! Und ausserdem muss ich arbeiten! Lösung: VPN

48 VPN Netzwerkzugriff Virtual Private Network: VPN wird verwendet um eine virtuelle Netzwerkverbindung zwischen 2 Systemen auf zu bauen. LAN A INTERNET VPN LAN B Florian.Prester@rrze.uni-erlangen.de 48

49 VPN (1) Ja und? Umgehen der FW! Fremde Rechner mit gleichen Rechten wie lokale Rechner! LAN A INTERNET VPN LAN B Florian.Prester@rrze.uni-erlangen.de 49

50 VPN (2) Vorteil: Umgehen der FW! Fremde Rechner mit gleichen Rechten wie lokale Rechner! LAN A INTERNET VPN LAN B Florian.Prester@rrze.uni-erlangen.de 50

51 VPN (3) -> sorgfältige Administration ist nötig! LAN A INTERNET VPN LAN B Florian.Prester@rrze.uni-erlangen.de 51

52 VPN: Details Technik: IP-Sec SSL-VPN Netztypen: Bridged Routed Firewall: IPsec-Traffic: Inernet Security Association and KeyManagement Protocol (UDP 500) Authentication Header Protocol Encapsulating Security Payload SSL-VPN UDP/TCP-Verkehr

53 VPN: Probleme? IP-Sec: Schwer zu administrieren: to complicated to be secure! IPSec & NAT NAT-T: IPSec über UDP RFC: 3947 und 3948 SSL-VPN: Eigentlich keine Konfiguration von fremden Systemen Fremdes Netzwerk unbekannt

54 VPN: Was bringt s? Zugriff auf das Netzwerk und seine Teilnehmer Authentifizierung & Authorisierung Username Passwort Zertifikate Firewall hat keine Löcher Sperren auf Nutzerebene Zugriff aus bekanntem LAN

55 Zusammenfassung (I) Typische Fehler: Keine Pflege der Systeme Dummy- sowie alte Benutzerzugänge Veraltetet Software mit Fehlern Keine regelmäßige Kontrolle der Logs Unverschlüsseltes Lagern bzw. Übertragen wichtiger Daten Blindes Vertrauen in kompromittierte Systeme Prävention Regelmäßig (automatisches) Patchen Reduzierung der angebotenen Services Passwörter und Logging Einsatz von Scannern auf Rechnern in eigenen Netz- Bereichen Regelmäßige Kontrolle der Logfiles Werkzeuge zur Erhöhung der Sicherheit wie ssh, Personal Firewalls, Letztes Mittel: Maschine vom Netz

56 Zusammenfassung (II) Sicherheit in Erlangen: Unterstützung bei der Konfiguration der Systeme durch das RRZE Bereitstellung von Antiviren-Software Virenerkennung und Beseitigung automatisierte Verfahren Automatisches Einspielen von Patches (SUN: Wartungsvertrag) Erkennung von Scans Sicherung des Systems selber Sperrung aller Klartextdienste (Zugang beispielsweise nur per SSH) Häufige Updates

57 Zusammenfassung (III) Sicherheit in Erlangen f.: Sperrung kritischer Ports am Aussenrouter zum Wissenschaftsnetz Firewall-Regeln können auf Routern der FAU implementiert werden Werden ausschließlich vom RRZE gepflegt Subnetzbetreiber muss Schutzbedarf und Kommunikationsbeziehungen ermitteln: Eigene, dezentrale Lösungen an der FAU nicht erlaubt: Beratung durch Volkmar Scharf (mailto:

58 Literatur ->Sicherheit Ryan Russel et al. Die Hacker-Bibel mitp-verlag/bonn, 2002 Network Intrusion Detection Stephen Northcutt, Judy Novak, New Riders,

59 Fragen & Antworten Vielen Dank für Ihre Aufmerksamkeit Fragen:

60 Studien- & Diplomarbeiten Interesse an Netzwerksicherheit? Noch keine Studien- oder Diplomarbeit oder Interesse and einer Hiwi-Stelle? Anfragen an: