Einführungsvortrag Rechner-Sicherheit und Firewalls

für Netz- und EDV-Beauftragte

Netzfort 19.02.2002

joachim.peeck@urz.uni-heidelberg.de

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.

3

"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

4

Themen

1. Was ist "Sicherheit"

2. Gefahren aus dem Netz

3. Möglichkeiten und Mühen einer "Firewall"

4. Bemerkungen zum Schluss

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

6

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

7

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.

8

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

9

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.

10

1.4 Wer sollte sich um Sicherheit sorgen / bemühen?

securitas

System-admin

Nutzer Netz-admin

11

Nutzer

1.4.1 Wer sollte sich um Sicherheit sorgen / bemühen?

securitas

System-admin

Netz-admin

12

1.4.2 Wer sollte sich um Sicherheit sorgen / bemühen?

securitas

System-admin

Netz-admin

secu ritas

13

1.4.3 Wer sollte sich um Sicherheit sorgen / bemühen?

securitas

System-admin

Netz-admin

ritassecu

14

1.4.4 Wer sollte sich um Sicherheit sorgen / bemühen?

System-admin

Netz-admin

ritas

secu

15

1.4.5 Wer sollte sich um Sicherheit sorgen / bemühen?

System-admin

Netz-admin

ritas

secu

16

1.4.6 Wer sollte sich also um Sicherheit bemühen?

securitas

System-admin

Nutzer Netz-admin

17

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

18

2. Gefahren aus dem Netz

• Gefahren für Endsysteme/Clients

• Gefahren für Server

• Gefahren beim Datenaustausch

19

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“

20

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...)

21

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

22

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

23

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...• Was kann passieren...• Vergleich: Autofahren, Wand, Zündschüssel• todo...

24

2.5 URZ Security-Website

• www.urz.uni-heidelberg.de/Security

25

Kurze Pause?

26

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

27

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

28

3.2 Bestandteile einer Firewall

• Bedrohungsanalyse / Risikoabschätzung• Policy / Notfallplan• NAT etc.• Paketfilter• Proxies /Application-Level-Firewalls• regelmäßige Administration• regelmäßige Revision

29

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?

30

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...)– wie lästig darf Sicherheit sein? (Abschaltung von Active-X/Java,

Proxy-Nutzung)

• was geschieht, wenn (doch) etwas passiert ist?– wie kann ich das feststellen?– wer wird informiert? was ist zu tun?...

31

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

32

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)

33

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

34

3.2.4 Paketfilter

• Einfacher Paketfilter (L4)– TCP/UDP-Ports – /etc/services: well-known-ports– ICMP Typ/Code

• "intelligente" Paketfilter (L4/5)

35

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):

36

3.2.4.2 /etc/servicesftp-data 20/tcp

ftp 21/tcp

telnet 23/tcp

smtp 25/tcp mail

domain 53/tcp nameserver # name-domain server

domain 53/udp nameserver

pop 109/tcp postoffice

pop2 109/tcp # Post Office

pop3 110/tcp postoffice

portmap 111/tcp

portmap 111/udp

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

snmp 161/udp snmp

snmp-trap 162/udp snmp•gibts also auch bei Windows...

•siehe auch IANA/ICANN

37

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

38

3.2.4.4 Filterliste - Prinzip 2! in - was darf vom Subnetz in die Welt:

!

! Stufe 1: Clienten greifen auf URZ/Uni-Server zu

! 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 deny ip any any log

39

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

40

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),

aixtermX (urz-Dialogserver)

• 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

41

3.3 Architektur / Pla(t)zierung im Netz

• Netzwerk mit direktem Internet-Anschluss

• Netzwerk mit Grenznetz

• Netzwerk mit DMZ

42

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

43

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)

44

Com puter

Com puter

Com puter

W orkstation

Laptop

Interner Server

Internet

InnererRouter

Inneres N etz(H ausnetz)

In ternet

ÄußererRouter

G renznetz(perim eter network)

D M Z (de-m ilita rized zone)

Kom m unikations-ServerBastion Host

Proxy

3.3.3 Netzwerk mit DMZ

Paketfilter Paketfilter

ProxyApplication-Level-FW

dediziert

45

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.4 Netzwerk mit „FW-Server“

Paketfilter Paketfilter

ProxyApplication-Level-FW

dediziert

Zusammenlegen verschiedener FW-Komponenten in einem Gerät

Problematisch im Kompromittierungsfall

46

3.4 Was kann eine Firewall nicht sichern?

• Nutzerverhalten– nur was vorhersehbar ist, kann abgefangen werden

• Das interne Netz vor Angriffen von „innerhalb“– was passiert, wenn ein Rechner gehackt ist...

• 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

47

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

48

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

49

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...

50

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!) ...

51

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: • nur der neue VPN-Server mit Cisco-Client ist Ipsec-verschlüsselt• das alte PPTP-VPN ist unverschlüsselt, diente 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

52

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

53

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... • Literatur:

– Chapman/Zwicky: Einrichten von Internet-Firewalls (URZ: II9603), O‘Reilly 1996– „anonymous“: hacker‘s guide (URZ: DZ9901), Markt&Technik 1999

• Hersteller, Produkte– Linux Iptables/Ipchains, Cisco Pix/VPN3000, Checkpoint FW1, Nokia, Genua, WatchGuard,

security-academy...– Bitte nichts ohne Absprache mit / Zustimmung durch das URZ kaufen

ENDE

Vielen Dank für das Interesse!

Bitte füllen Sie den Fragebogen aus.

joachim.peeck@urz.uni-heidelberg.de