universität heidelberg rechenzentrum joachim peeck rechner-sicherheit und firewalls 1...
Post on 05-Apr-2015
110 Views
Preview:
TRANSCRIPT
Universität HeidelbergRechenzentrumJoachim Peeck
Rechner-Sicherheit und Firewalls 1
Einführungsvortrag Rechner-Sicherheit und Firewalls
für Netz- und EDV-Beauftragte
Netzfort 12.12.2000
joachim.peeck@urz.uni-heidelberg.de
Universität HeidelbergRechenzentrumJoachim Peeck
Rechner-Sicherheit und Firewalls 2
Ziele des Vortrages
• Einführung für Anfänger in dem Gebiet• Vorbereitung auf die Vorstellung und Diskussion
des uniweiten Sicherheits-Konzeptes• Eine Firewall und auch rechnerseitige
Maßnahmen sind nicht alleinseligmachend• Letztlich bleibt eine Verantwortung beim Nutzer• Es ist auch eine Aufgabe des Netzbeauftragten,
dafür zu sorgen, dass jeder Nutzer diese kennt.
Rechner-Sicherheit und Firewalls 3Universität HeidelbergRechenzentrumJoachim Peeck
"Disclaimer"
• dieser Vortrag soll nur der Übersicht dienen• nicht, dass dies alles Ansprüche oder
Anforderungen sind oder auch nur werden sollten• an einer Uni sind viele der im Vortrag erwähnten
Punkte hinderlich und/oder unnötig,• führen zur Verärgerung von Nutzern,• und sind auch schwierig zu administrieren
Universität HeidelbergRechenzentrumJoachim Peeck
Rechner-Sicherheit und Firewalls 4
Themen
1. Was ist "Sicherheit"
2. Gefahren aus dem Netz
3. Möglichkeiten und Mühen einer "Firewall"
4. Bemerkungen zum Schluss
Universität HeidelbergRechenzentrumJoachim Peeck
Rechner-Sicherheit und Firewalls 5
1. Was ist Sicherheit?
• Definition
• Sicherheit der Hardware
• Sicherheit der Software und Daten
• Sicherheit der Kommunikation
• Wer sollte sich um Sicherheit bemühen
• Sicherheits-Prinzipien / Policy
Rechner-Sicherheit und Firewalls 6Universität HeidelbergRechenzentrumJoachim Peeck
1.1 Sicherheit
• Def. (jp): in Erfahrung gegründetes und sich bestätigendes Gefühl, von gewissen Gefahren nicht vorrangig getroffen zu werden– mathematisch „sicher“ (p=1) ist hier nicht angebracht...
• Abgrenzung zu – Risiko: Produkt aus Eintreffenswahrscheinlichkeit und
Schadenshöhe
– Gefahr: schädigendes Ereignis, das mit nichtverschwindender Wahrscheinlichkeit eintreffen kann
Rechner-Sicherheit und Firewalls 7Universität HeidelbergRechenzentrumJoachim Peeck
1.1 Sicherheit der Hardware
• Gefahr: – Verlust der Geräte, Software und Daten– Schaden durch Nicht-Verfügbarkeit
• Sichern durch:– kontrollierten Zugang zum Rechner und anderen
Komponenten– Befestigen von Rechnern und Komponenten bei
Aufstellung an öffentlich zugänglichen Orten– Besondere Sicherung/Überwachung von PC-Pools,
Server-Räumen, PC-Werkstatt etc.
Rechner-Sicherheit und Firewalls 8Universität HeidelbergRechenzentrumJoachim Peeck
1.2 Sicherheit der Software und Daten
• Gefahren/Schäden: Verlust von...– arbeitszeitintensiver Rechner-Installation
– arbeitszeitintensiven/seltenen/wichtigen/vertraulichen Daten auf dem Rechner
– Plattenplatz, Rechnerzeit, etc.
• Sichern durch:– Kennwortvergabe / sichere Kennwörter / Schulung...
– Datensicherung / ADSM (RAID/Disketten...)
– Antivirenschutz / McAffee
– Deaktivierung fataler Automatismen (im Browser etc.)
– Verschlüsselung (nur bei ganz geheimen Daten, sonst lieber nicht)
– weitere Maßnahmen siehe unten
Rechner-Sicherheit und Firewalls 9Universität HeidelbergRechenzentrumJoachim Peeck
1.3 Sicherheit der Kommunikation
• Echtheit/Authentizität des Urhebers und des Gegenübers– digitale Unterschrift/Key, Zertifikate, Sicherung/Verschlüsselung
von Kennwörtern
– Die Protagonisten: Alice, Bob, Charly...
• Unverfälschtheit/integrity– Prüfsummenverfahren/Hashing
• Vertraulichkeit/privacy– Verschlüsselung von Kennwörtern und/oder Daten, ssh/spop/simap
• Verfügbarkeit von Kommunikation und Rechnern
• Guter Ruf, etc.
Rechner-Sicherheit und Firewalls 10Universität HeidelbergRechenzentrumJoachim Peeck
1.4 Wer sollte sich um Sicherheit sorgen / bemühen?
securitas
System-admin
Nutzer Netz-admin
Rechner-Sicherheit und Firewalls 11Universität HeidelbergRechenzentrumJoachim Peeck
Nutzer
1.4.1 Wer sollte sich um Sicherheit sorgen / bemühen?
securitas
System-admin
Netz-admin
Rechner-Sicherheit und Firewalls 12Universität HeidelbergRechenzentrumJoachim Peeck
1.4.2 Wer sollte sich um Sicherheit sorgen / bemühen?
securitas
System-admin
Netz-admin
secu ritas
Rechner-Sicherheit und Firewalls 13Universität HeidelbergRechenzentrumJoachim Peeck
1.4.3 Wer sollte sich um Sicherheit sorgen / bemühen?
securitas
System-admin
Netz-admin
ritassecu
Rechner-Sicherheit und Firewalls 14Universität HeidelbergRechenzentrumJoachim Peeck
1.4.4 Wer sollte sich um Sicherheit sorgen / bemühen?
System-admin
Netz-admin
ritas
secu
Rechner-Sicherheit und Firewalls 15Universität HeidelbergRechenzentrumJoachim Peeck
1.4.5 Wer sollte sich um Sicherheit sorgen / bemühen?
System-admin
Netz-admin
ritas
secu
Rechner-Sicherheit und Firewalls 16Universität HeidelbergRechenzentrumJoachim Peeck
1.4.6 Wer sollte sich also um Sicherheit bemühen?
securitas
System-admin
Nutzer Netz-admin
Rechner-Sicherheit und Firewalls 17Universität HeidelbergRechenzentrumJoachim Peeck
1.5 Sicherheits-"Prinzipien"• minimale Zugriffsrechte ("nur soviel wie nötig")• mehrschichtige Verteidigung (nicht auf nur eine Maßnahme
vertrauen) • Passierstellen einrichten (aber: single point of failure)• einschränkende Grundhaltung ("alles ist verboten, was nicht
ausdrücklich erlaubt ist")• minimale, dafür effektive verwaltbare und durchschaubare
Maßnahmen ("nur soviel wie nötig“)• Policy: der Versuch, einen für die eigene Einrichtung
angemessenen Satz von (Schutz-) Zielen und (grundsätzlichen) Regeln für Sicherheit zusammenzustellen
Universität HeidelbergRechenzentrumJoachim Peeck
Rechner-Sicherheit und Firewalls 18
2. Gefahren aus dem Netz
• Gefahren für Endsysteme/Clients
• Gefahren für Server
• Gefahren beim Datenaustausch
Rechner-Sicherheit und Firewalls 19Universität HeidelbergRechenzentrumJoachim Peeck
2.1 Gefahren a.d.N. für Endsysteme
• Fehlkonfiguration– „versehentlich“ installierte Serverdienste, die ungeschützt daliegen (IIS, Netbios-Shares...)
• Netzwerk-Betriebssystem-Schwächen– offenliegende Registrierung, Systemdaten, die hinausposaunt werden, automatisch sich ladende
Fremdprogramme etc.
• Nutzer lädt Virus/Trojaner (malicious code)– der liest Passwörter im System oder im Netz (sniffing) mit
– löscht Dateien, versendet Mails oder anderes
– ILOVEYOU etc., Microsoft-Vorfall???
• Wie begegne ich diesen Gefahren?– Nutzerverhalten: wissen, wo man surft, was man lädt und was der nächste Klick auf dem eigenen
Rechner bewirkt / bewirken kannDies ist die einzige Maßnahme, die bei neuen/unbekannten Gefahren wirksam hilft!!!
– Datensicherung/Datenvorhaltung: einfaches Neueinspielen nach Vorfall
– lokaler Virenscanner
– Zentralisierte Verwaltung: möglichst wenig Rechte für den Nutzer, Programme zentral Einspielen, Patches/Service-Packs auch für Endsysteme etc.
– Firewall mit Mail- und Virenscanner als „Oberaufsicht“
Rechner-Sicherheit und Firewalls 20Universität HeidelbergRechenzentrumJoachim Peeck
2.2 Gefahren a.d.N. für Server• Hacker/Cracker erreicht Dienst-Account auf Server
– unsichere Dienste (i.d.R. buffer overflow)– zu viele Dienste mit root-Rechten...
• Server wird außer Dienst gesetzt (DoS, denial-of-service)
• Netzwerk-Scans, Robots, unsichere Konfiguration– z. B. lesbare cgi-Scripte mit Kennwörten...
• Vermindern der Gefahren durch– Zuverlässige Systemadministration
• Patches einspielen• Logbuchauswertung, Rechnerprüfung (Tripwire), IDS (Intrusion-Detection-
System)
– Dienstebeschränkung (Admin, TCP-Wrapper, Firewall)– Nutzerverhalten (IRC-Server sind häufiges Attackenziel...)
Rechner-Sicherheit und Firewalls 21Universität HeidelbergRechenzentrumJoachim Peeck
2.2.1 Gefahren a.d.N. für Server
• Beispiel einer DoS-Attacke, um andere Aktivität in den Logbüchern zu vertuschen:
aus: Asterix, Bd.VI: Tour de France
Rechner-Sicherheit und Firewalls 22Universität HeidelbergRechenzentrumJoachim Peeck
2.3 Gefahren beim Datenaustausch
• Abhören von Passwörtern und/oder Daten (sniffing, hijacking)– Netz physikalisch sichern: Datenverteiler, LWL...
– Protokolle mit verschlüsselten Passwörtern und Anti-Spoofing-Mechanismen verwenden
• Spam-Mail/Datenpaket-Verschickung im fremden Namen (spoofing)– oder mit fremder IP-Adresse
– oder Verfälschung fremder Daten
– sichern durch: Echtheitsnachweis
• Vortäuschen eines erwünschten Servers (spoofing, hijacking)– Erhalten von Kreditkartennummern
– sichern durch: entsprechende Protokolle, Konfiguration der Endsysteme, Schulung der Nutzer
Rechner-Sicherheit und Firewalls 23Universität HeidelbergRechenzentrumJoachim Peeck
2.4 Stichpunkte für Nutzerschulung
• Schulung, Information, Appell an Selbstdisziplin• Verschlüsselung, Authentifizierung, digitale
Signatur• Was passiert im Internet, wenn ich klicke...• Was passiert auf meinem Rechner...• Vergleich: Autofahren, Zündschüssel• todo...
Universität HeidelbergRechenzentrumJoachim Peeck
Rechner-Sicherheit und Firewalls 24
3. Möglichkeiten und Mühen einer "Firewall"
• Was ist eine Firewall• Bestandteile einer Firewall /
Wie arbeitet eine Firewall• Firewall-Architektur /
Pla(t)zierung im Netz• Was kann eine Firewall nicht sichern• Weitere Maßnahmen
Rechner-Sicherheit und Firewalls 25Universität HeidelbergRechenzentrumJoachim Peeck
3.1 Was ist ein/e Firewall
• „Brandschutzmauer“ - mögliche Ziele:– Abtrennung (mindestens) eines "inneren" Netzes vom Internet
– Verstecken der Rechner vor bestimmten Daten-Paketen
– Vermindern von Administrationsfehlern durch Beschränkung der Dienste
– Logging/Protokollierung von Zugriffen
– Zentrale Zugangskontrolle / -Beschränkung
• Firewall: – Ansammlung von Maßnahmen, die diese Ziele unterstützen
– das kann für kleine oder einheitliche Netze „eine Kiste“ bedeuten
– kann aber auch auf anderen Wegen erreicht werden
Rechner-Sicherheit und Firewalls 26Universität HeidelbergRechenzentrumJoachim Peeck
3.2 Bestandteile einer Firewall
• Bedrohungsanalyse / Risikoabschätzung• Policy / Notfallplan• NAT etc.• Paketfilter• Proxies /Application-Level-Firewalls• regelmäßige Administration• regelmäßige Revision
Rechner-Sicherheit und Firewalls 27Universität HeidelbergRechenzentrumJoachim Peeck
3.2.1 Bedrohungsanalyse und Risikoabschätzung
• Gefahren: siehe Bemerkungen oben• welcher konkrete Schaden kann entstehen?• wie hoch ist der Aufwand zur Beseitigung des
Schadens?• wie hoch sind Folgeschäden, z. B. durch
Unbenutzbarkeit der Rechner etc.?• wie hoch darf der Aufwand zur „Sicherheit“ sein?
Rechner-Sicherheit und Firewalls 28Universität HeidelbergRechenzentrumJoachim Peeck
3.2.2 Policy / Notfallplan
• wie teilt sich der Aufwand für Sicherheit in einzelne Maßnahmen auf?– wer entscheidet, welche Maßnahmen durchgeführt
werden, wer setzt diese durch und wie?
– whitelist-Problematik: ich weiß, was meine Nutzer dürfen; Richtlinien dazu? (real, HBCI...)
• was geschieht, wenn (doch) etwas passiert ist?– wie kann ich das feststellen?
– wer wird informiert? was ist zu tun?...
Rechner-Sicherheit und Firewalls 29Universität HeidelbergRechenzentrumJoachim Peeck
3.2.2.1 Gefahren bei falscher Policy
• Tresortür am Pappkarton (ganz schön teuer...)• Haustür offen lassen, weil ja die Gartentür
„gesichert“ ist• Schlüsselbund liegt unter der Fußmatte, weil man
so viele Schlüssel nicht bei sich tragen will
Rechner-Sicherheit und Firewalls 30Universität HeidelbergRechenzentrumJoachim Peeck
3.2.3.0 OSI-7-Schichten-Modell
Layer1: Physical
Layer2: Data Link
Layer3: Network
Layer4: Transport
Layer5: Session
Layer6: Presentation
Layer7: Application
Layer8: Benutzer
Layer0: Mechanik
Anwendungsschichten(ftp, telnet, smtp, http, smb, ...)
}}
Protokollschichten(TCP/IP, IPX/SPX, Netbios...)
Physikalische Schichten(Ethernet, FDDI, Token Ring)
}
Zusätzliche Schichten(zur Fehlersuche)
Rechner-Sicherheit und Firewalls 31Universität HeidelbergRechenzentrumJoachim Peeck
3.2.3 NAT etc.• vorbereitend: Osi-Modell/Datenpaket• technisches Grundprinzip:
– Verstecken der Rechner/Dienste
• „security heavy“: Reales Privates Netzwerk (L0:-)• Network Address Translation: Umsetzung von IP-Adressen
(L3)– one-to-one– many-to-many– many-to-one/Masquerading: nur eine Adresse wird nach außen
sichtbar– ursprünglich: Erweiterung des Adressraumes
Rechner-Sicherheit und Firewalls 32Universität HeidelbergRechenzentrumJoachim Peeck
3.2.4 Paketfilter
• Einfacher Paketfilter (L4)– TCP/UDP-Ports – /etc/services: well-known-ports– ICMP Typ/Code
• "intelligente" Paketfilter (L4/5)
Rechner-Sicherheit und Firewalls 33Universität HeidelbergRechenzentrumJoachim Peeck
3.2.4.1 TCP/UDP-PortsL2: MAC8+14 Bytes
L3: IP>=64 Bytes
L4: TCP-Port8-64 Bytes
L5-7: Anwendung
Benutzerdaten
•Source-Port: auf diesem rechner-internen Anschluss „lauscht“ der Absender des Paketes (d. i. ein Prozess) auf die Antwort
•Destination Port: auf diesem Anschluss erwartet der Absender, dass der Zielrechner das Paket weiterverarbeiten kann, d.h. es gibt auf dem Zielrechner einen Prozess, dem die Daten des Paketes übergeben und von dem diese weiterverarbeitet werden
•Serverdienst: ständiges Offenhalten eines Ports für eine bestimmte Funktion/Protokoll/Anwendung, z.B.
•80/tcp: http (httpd, z.B. apache)•23/tcp: telnet (telnetd via inetd)•53/udp: dns (named, z.B. bind)•137/udp: netbios
L2: MAC4 Bytes
Ein Datenpaket (frame):
Rechner-Sicherheit und Firewalls 34Universität HeidelbergRechenzentrumJoachim Peeck
3.2.4.2 /etc/services# Copyright (c) 1995 Microsoft Corp.
#
# Diese Datei enth„lt die Anschluánummern (Port Numbers) fr bekannte�# Dienste gem„á RFC 1060 (Assigned Numbers).
# Bearbeiten Sie diese Datei mit einem ASCII-Editor.
#
# Format:
#
# <Dienstname> <Anschluánummer>/<Protokoll> [Alias...] [#<Kommentar>]
#
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
qotd 17/udp quote
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail
...
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
nameserver 53/tcp domain # name-domain server
nameserver 53/udp domain
...
pop 109/tcp postoffice
pop2 109/tcp # Post Office
pop3 110/tcp postoffice
portmap 111/tcp
portmap 111/udp
sunrpc 111/tcp
sunrpc 111/udp
auth 113/tcp authentication
sftp 115/tcp
path 117/tcp
uucp-path 117/tcp
nntp 119/tcp usenet # Network News Transfer
ntp 123/udp ntpd ntp # network time protocol (exp)
nbname 137/udp
nbdatagram 138/udp
nbsession 139/tcp
NeWS 144/tcp news
sgmp 153/udp sgmp
tcprepo 158/tcp repository # PCMAIL
snmp 161/udp snmp
snmp-trap 162/udp snmp
print-srv 170/tcp # network PostScript
...
•gibts also auch bei Windows...
•siehe auch IANA/ICANN (Link todo)
Rechner-Sicherheit und Firewalls 35Universität HeidelbergRechenzentrumJoachim Peeck
3.2.4.3 Filterliste - Prinzip 1
! in - was darf vom Subnetz in die Welt:
!
! Stufe 1: Clienten greifen auf URZ/Uni-Server zu
access-list 153 permit udp any gt 1023 129.206.100.126 0.0.0.1 eq 53 ! dns
access-list 153 permit tcp any gt 1023 host www-proxy.uni-heidelberg.de eq 8080 !http
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq 25 ! smtp
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq pop3 ! pop3
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq 995 ! spop
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq 143 ! imap2
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq 993 ! simap
access-list 153 permit tcp any gt 1023 129.206.0.0 0.0.255.255 eq 113 ! auth ins urz
access-list 153 permit udp any eq 123 129.206.0.0 0.0.255.255 eq 123 ! ntp ins urz/uni
Rechner-Sicherheit und Firewalls 36Universität HeidelbergRechenzentrumJoachim Peeck
3.2.4.4 Filterliste - Prinzip 2! in - was darf vom Subnetz in die Welt:
!
! Stufe 1: Clienten greifen auf URZ/Uni-Server zu
access-list 153 permit udp any gt 1023 129.206.100.126 0.0.0.1 eq 53 ! dns
access-list 153 permit tcp any gt 1023 host www-proxy.uni-heidelberg.de eq 8080 !http
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq 25 ! smtp
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq pop3 ! pop3
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq 995 ! spop
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq 143 ! imap2
access-list 153 permit tcp any gt 1023 host popix.urz.uni-heidelberg.de eq 993 ! simap
access-list 153 permit tcp any gt 1023 129.206.0.0 0.0.255.255 eq 113 ! auth ins urz
access-list 153 permit udp any eq 123 129.206.0.0 0.0.255.255 eq 123 ! ntp ins urz/uni
!! Stufe 2: lokale unsichere "Clienten"/Netzwerk-Protokolle
! Stufe 2b: verschluesselte Clienten-Protokolle weltweit
! Stufe 2s: lokale Serverdienste
!
! Stufe 3: weltweite unsichere Clienten-Protokolle
! Stufe 3s: weltweite Serverdienste
!
access-list 153 deny ip any any log
!
!
! out - was darf in das Subnetz:!
! Stufe 1: zugriff auf lokale server, verschluesselte Clienten-Protokolle
access-list 154 permit udp 129.206.100.126 0.0.0.1 eq 53 any gt 1023 ! dns 126+127
access-list 154 permit udp 129.206.210.127 0.0.0.0 eq 53 any gt 1023 ! dns 127
access-list 154 permit tcp host www-proxy.uni-heidelberg.de eq 8080 any gt 1023 established ! http
access-list 154 permit tcp host popix.urz.uni-heidelberg.de eq 25 any gt 1023 established ! smtp
access-list 154 permit tcp host popix.urz.uni-heidelberg.de eq pop3 any gt 1023 established ! pop3
access-list 154 permit tcp host popix.urz.uni-heidelberg.de eq 995 any gt 1023 established ! spop
access-list 154 permit tcp host popix.urz.uni-heidelberg.de eq 143 any gt 1023 established ! imap2
access-list 154 permit tcp host popix.urz.uni-heidelberg.de eq 993 any gt 1023 established ! simap
...
access-list 154 deny ip any any log
Rechner-Sicherheit und Firewalls 37Universität HeidelbergRechenzentrumJoachim Peeck
3.2.4.5 „stateful“• „statischer“ Paketfilter vs. Verbindungskontrolle:
– für einfachen Paketfilter nur bei TCP erkennbar
– nicht bei UDP (z. B. DNS) oder ICMP (Typ/Code: 8/0 echo request, 0/0 echo reply - ping)
– auch bei TCP nur gesetztes ACK-Bit
– „glauben wir das“? echte Kontrolle der Verbindung ist besser
• Lösung:– „stateful inspection“, dynamische (reflexive) Paketfilterung
– Firewall merkt sich zu jeder „Verbindung“ den „Zustand“
– überwacht u. a. durch Timeouts, explizite Authentifizierung
– nur solche Pakete, deren Verbindungsaufbau-Paket erlaubt war und deren „state“ noch „offen“ ist, kommen durch
– weniger Aufwand, mehr Effekt
Rechner-Sicherheit und Firewalls 38Universität HeidelbergRechenzentrumJoachim Peeck
3.2.5 Proxying• Proxy (auch: Gateway, Gatekeeper):
– „naher“ Server, der ferne Anfragen durchführt und zwischenspeichert– http (https ohne proxy?) mit/ohne Verstecken der Source-Informationen– ftp, telnet, rlogin, X11, archie, gopher– längst nicht für alle Dienste möglich
• am URZ: – www-proxy (caching-only), relay (mail-proxy), vpnsrv („DNS-proxy“), videosrv (streaming-
proxy)
• Application-Level-Firewall– Filterung/Manipulation von Informationen aus Anwendungs-Protokollen (L5-7)– z.B. http-URL, smtp-Email-Adressen, -Betreff, -Anhangs-Datei– Problemzone Überwachung...
• begleitende Konfiguration nötig– im Client: Proxy-Angaben, SOCKS, Winsock (MS-Proxy)– im Paketfilter oder Netz:
• Verbindungen nur durch Proxy hindurch, direkte Verbindungen verbieten
– Bastion-Host im Grenznetz: • öffentliche Server auslagern, im lokalen Netz nur Clients
Rechner-Sicherheit und Firewalls 39Universität HeidelbergRechenzentrumJoachim Peeck
3.3 Architektur / Pla(t)zierung im Netz
• Netzwerk mit direktem Internet-Anschluss
• Netzwerk mit Grenznetz
• Netzwerk mit DMZ
Rechner-Sicherheit und Firewalls 40Universität HeidelbergRechenzentrumJoachim Peeck
3.3.1 Netzwerk mit Internet
Com puter
Com puter
Com puter
W orkstation
Laptop
Server
Internet
InnererRouter
Inneres N etz(H ausnetz)
In ternet
Paketfilter
Proxy
Firewall(dediziert)
Passierstelle
Rechner-Sicherheit und Firewalls 41Universität HeidelbergRechenzentrumJoachim Peeck
3.3.2 Netzwerk mit Grenznetz
Com puter
Com puter
Com puter
W orkstation
Laptop
Server
Internet
InnererRouter
Inneres N etz(H ausnetz)
In ternet
ÄußererRouter
G renznetz(perim eter)
Paketfilter Paketfilter
Bastion-HostF irewall
(dediziert)
Rechner-Sicherheit und Firewalls 42Universität HeidelbergRechenzentrumJoachim Peeck
Computer
Computer
Computer
W orkstation
Laptop
In te rne rS erve r
Internet
Inne re rR ou te r
Inneres N etz(H ausnetz)
In te rne t
Ä uß ere rR ou te r
G renznetz(perim eter ne twork)
D M Z (de-m ilita rized zone)
K om m un ika tions-S erve r
B as tion H os tP roxy
3.3.3 Netzwerk mit DMZ
Paketfilter Paketfilter
ProxyApplication-Level-FW
dediziert
Zusammenlegen verschiedener FW-Komponenten in einem Gerät
Problematisch im Kompromittierungsfall
Rechner-Sicherheit und Firewalls 43Universität HeidelbergRechenzentrumJoachim Peeck
3.4 Was kann eine Firewall nicht sichern?
• Nutzerverhalten– nur was vorhersehbar ist, kann abgefangen werden
• Das interne Netz vor Angriffen von „innerhalb“
• Umgehung der Firewall– Tunnel, Dial-Out/In, Disketten etc.
• Benötigte Serverdienste sind offen und damit angreifbar
• Das Netz „vor“ der Firewall– Vortäuschen, Abhören dort etc. -> andere Maßnahmen nötig
• Kann einen selbst nicht vor Arbeit und Ärger sichern – Beispiel URZ-Mailfirewall: vorher - nachher
Rechner-Sicherheit und Firewalls 44Universität HeidelbergRechenzentrumJoachim Peeck
3.5 Weitere mögliche/nötige Maßnahmen
• Weitere Maßnahmen zum Betrieb
• Das große Aber
• Weitere Maßnahmen zur Sicherheit der Kommunikation via Internet
Rechner-Sicherheit und Firewalls 45Universität HeidelbergRechenzentrumJoachim Peeck
3.5.1 Weitere Maßnahmen zum Betrieb einer Firewall
• ständige Kontrolle der Logbücher/Protokolle
• ständige Aktualisierung und Backup der Konfiguration
• ständige Aktualisierung der Firewall-Software und des zugrundeliegenden Betriebssystems
• externe Revision / „Security Audit“
• Nutzerschulung (Beispiel aus der Beratung)
• „Zertifizierung“: mindestens drei Schichten von 2 unabhängigen Herstellern, z. B. PF-ALF-PF
Rechner-Sicherheit und Firewalls 46Universität HeidelbergRechenzentrumJoachim Peeck
3.5.1.1 Bei eigener Firewall
• intensive Betreuung und Administration erforderlich, sonst sinnlos!
• gute selbst angelegte Dokumentation erforderlich
• separate Hardware an separatem Ort
• nur minimale Software- und Dienste-Ausstattung des FW-Rechners
• ohne Policy und Bedrohungsanalyse keine Befürwortung durch URZ
• keine Unterstützung in der Administration durch das URZ
• keine Netzwerkunterstützung, wenn nicht voller IP-Zugang zu den Netzkomponenten
• bei Verbindungsproblemen muss das Institut sagen, wo das Problem liegt, das URZ kann die Konfigurationsprobleme der Firewall nicht erkennen...
• Zukunftsfähig? Fast-Ethernet / Gigabit Ethernet...
Rechner-Sicherheit und Firewalls 47Universität HeidelbergRechenzentrumJoachim Peeck
3.5.2 Aber:Das Internet basiert auf Zugänglichkeit und
Erreichbarkeit • nicht mehr direkte Erreichbarkeit bereitet Probleme
• Fehlersuche viel schwieriger, z. T. unmöglich
• Verstecken der Rechner heißt nicht: kein DNS-Eintrag ;-)
• neue Dienste nur mit Aufwand und/oder zusätzlichen Problemen
• manche Dienste funktionieren nicht mehr unter bestimmten Sicherheitskonfigurationen, z. B. ftp, portmapper, ...
• Verwaltungsaufwand für Betrieb und Instandhaltung– neue Ports einpflegen
– Logbücher kontrollieren
– Information von Benutzern und anderen Beteiligten über Angriffe, Sperrungen, Maßnahmen (allein schon das Herausfinden der Email-Adresse...)
– Beschwerden (daher unbedingt Policy vorab!) ...
Rechner-Sicherheit und Firewalls 48Universität HeidelbergRechenzentrumJoachim Peeck
3.5.3 Weitere Maßnahmen• Verstecken der Information: Verschlüsseln
– ssh (Kennwörter)– https, spop, simap, ssl (Kennwörter, Daten?)– aktuelle Mailclienten / pgp etc. (Kennwörter, Daten)– IPSec/VPN (Daten);
ACHTUNG:
• z. B. URZ-VPN ist unverschlüsselt, dient anderem Zweck
• Bitte keine Tunnel ohne Absprache mit/Zustimmung durch das URZ, diese Dienste sind sonst nicht garantiert
• Tunnel umgehen eventuelle Firewall-Kontrollen!
• Wir empfehlen: – Kennwörter über fremde Netze nur verschlüsselt– bei wichtigen Daten die Unverfälschtheit und Herkunft sicherstellen– bei vertraulichen Daten verschlüsseln
Rechner-Sicherheit und Firewalls 49Universität HeidelbergRechenzentrumJoachim Peeck
3.6 Fazit: Zum Firewall-Einsatz im Institut
• Wenn das URZ einen Paketfilter in verschiedenen Varianten anbietet,
• dann braucht der Netzbeauftragte lediglich im Institut darauf hinwirken, dass die von ihm präferierte Policy abgesegnet wird und
• kann sich dann darauf konzentrieren, seine Nutzer in der Policy zu schulen, z. B.– sichere von den Nutzern selbst gewählte Passwörter
– sichere/verschlüsselte Passwort-Übermittlung über fremde Netze
– Verhalten im Netz (Email, Chat, Web-Browsing mit Nachdenken...)
– Datensicherung
– Virenschutz
– Aktualisierung der Serverdienste und Workstation-Programme
– Beschränkung der Dienste
• Wer schon die obigen Punkte zeitlich nicht leisten kann oder will, der wird sich mit dem Einrichten einer Instituts-eigenen Firewall zwar dem Anschein größerer Sicherheit hingeben, ohne diese jedoch effektiv zu erreichen
Universität HeidelbergRechenzentrumJoachim Peeck
Rechner-Sicherheit und Firewalls 50
4. Bemerkungen zum Schluss• Mailliste security@urz:
– Sicherheitshinweise von • CERT (Computer Emergency Response Team)
• diversen Herstellern (IBM, sun, hp, sgi, Linux-Distributoren)
– Aufnahme in Liste: Mail an michael.hebgen@urz
• web-urz > Netz > Netzbetrieb > Netzadmin > Computer Network Security– Sammlung wichtiger Dokumente und Links zum Thema Sicherheit
– neue Seite für Endnutzer ist in Arbeit...
• Datensicherheitsbehörde (BSI, ...), Hersteller...
• Literaturhinweis:– Chapman/Zwicky: Einrichten von Internet-Firewalls (URZ: II9603), O‘Reilly 1996
• Hersteller, Produkte– Cisco Pix, Checkpoint FW1, Nokia, Genua, WatchGuard, security-academy...
– Bitte nichts ohne Absprache mit / Zustimmung durch das URZ kaufen
Universität HeidelbergRechenzentrumJoachim Peeck
Rechner-Sicherheit und Firewalls 51
ENDE
Vielen Dank für das Interesse!
joachim.peeck@urz.uni-heidelberg.de
top related