Urz-Instituts-Firewall
Netzfort 19.03.2002
[email protected]
Ziele des Vortrages
•
•
•
•
Bericht über getroffene Maßnahmen
Vorstellung und Diskussion der Accesslisten
Werbung für die Urz-Instituts-Firewall
Motivation der Netzbeauftragten, sich eine Policy
fürs eigene Institut zu notieren
2
"Disclaimer"
• „Sicherheit“ ist nicht allein mit den hier
beschriebenen Maßnahmen zu erreichen:
die eigenen Rechner/Server sollten stets so
gut es geht gepflegt sein
• Keine Verkaufsveranstaltung ;-)
3
Themen
1. Firewalls im HD-Net
2. „Geglückte“ Angriffe im HD-Net
3. Urz-Instituts-Firewall
4. Weitere Schritte
4
1. Firewalls im HD-Net
•
•
•
•
•
•
•
Uplink BelWü
Uni-Firewall: rz-unihd/br2-urz
Application-Level: Mailfirewall
Schutz gewisser URZ-Server
Instituts-eigene Firewalls
Urz-Instituts-Firewall
Urz-Firewall-Informationen
5
1.1 Uplink BelWü
• seit Herbst 2001 Sperrung von „Lan“Protokollen
• seit März 2001 Sperrung von „Peer-topeer“-Protokollen
– Grund: hohe Kosten der volumenabhängig
abgerechneten Transatlantik-Verbindung
6
1.2 Uni-Firewall
• Derzeit Blacklist
• Sperrung von „Lan“-Protokollen: jeweils nach
aktueller Sicherheitswarnung (ToDo?)
• Paketfilter für die Mail-Firewall
• seit Herbst 2001: Giga-BelWü-Anbindung mit
Router br2-urz, geplant rz-unihd
• FDDI-Ring über rz-cisco und br-urz angebunden
• Schutz Netzkomponenten (IP <= .15)
• „Honeypot“-Netze für IDS
• Sperrung von „Scannern“
• Filter gegen IP-Adress-Spoofing
7
1.2.1 Uni-Firewall
Internet
BelWü
BelWü-Router
he1
UniversitätsFirewall
Paketfilter
Firewall
br2-urz
Institutsnetz B
HD-Net
Institutsnetz
Paketfilter
Firewall
Institutsnetz A
Paketfilter
Firewall
Institutsnetz X
Institutsnetz Y
8
1.2.2 gefilterte Protokolle
! wg. Microsoft UPnP-Problem (Port 1900 und 5000) gesperrt
access-list 103 deny udp any any eq 1900 access-list 103 deny tcp any any eq 1900
access-list 103 deny udp any any eq 5000 access-list 103 deny tcp any any eq 5000
! SMB nach aussen gesperrt
access-list 103 deny udp any any eq 135 access-list 103 deny tcp any any eq 135
access-list 103 deny udp any any range 137 139 access-list 103 deny tcp any any range 137 139
access-list 103 deny tcp any any eq 445
! ncp
access-list 103 deny tcp any any eq 524
! SNMP Sperrung, SNMP:
access-list 103 deny udp any any range 161 162 access-list 103 deny tcp any any range 161 162
access-list 103 deny udp any any eq 199 access-list 103 deny tcp any any eq 199
access-list 103 deny udp any any eq 391 access-list 103 deny tcp any any eq 391
access-list 103 deny tcp any any eq 1993 ! cdp access-list 103 deny udp any any eq 1993 ! cdp
! rdp wegen Checkpoint
access-list 103 deny udp any any eq 259
! dtspcd wegen CDE
access-list 103 deny tcp any any eq 6112
!
9
1.3 Mail-Firewall
• seit Dezember 2001: Virenfilter McAffee
Auswirkung auf Urz-Relays:
– statt Redundanz nun Load-sharing nötig
– Umzug des Spam-Erkennungs-Mechanismus
auf separate Maschine nötig
• immer noch konnten ungepflegte Mailer
spammen, daher
– Instituts-Mailserver als Angebot (zentrale
Pflege, dezentrale Administration)
– weitere Redundanz-/ Fallback-Mechanismen
sinnvoll
10
1.4 Urz-Server
• (bislang noch wenige) Paketfilter
• Ziel: zweistufig
• erst seit kurzem technisch möglich
(Lastprobleme mit br-urz)
11
1.5 Institutseigene Firewalls
• solche gibt es
• keine Hilfestellung etc. möglich
12
1.6 Urz-Instituts-Firewall
• Basistechnik Paketfilter - Whitelist
• mehrere „Stufen“:
– Dabei versucht die Stufen-Einteilung,
verschiedene Aspekte von Sicherheit auf
vergleichbarem Niveau zu vereinbaren
• später mehr
13
1.7 Urz-Firewall-Informationen
• Öffentlich
– www.urz > Angebote > Sicherheit...
www.urz.uni-heidelberg.de/Security
– www.urz > Netz > Netzbetrieb > Firewalls
www.urz.uni-heidelberg.de/Netzdienste/firewall
• Nur für EDV-/Netzbeauftragte etc.
– Netzfort-Verzeichnis
– Mailliste [email protected]:
• Sicherheitshinweise von
– CERT (Computer Emergency Response Team)
– diversen Herstellern (IBM, sun, hp, sgi, Linux-Distributoren)
• Aufnahme in Liste: Mail an [email protected]
14
2. „Geglückte“ Angriffe
•
•
•
•
•
Code Red
Nimda
ssh-Exploit
Cross-platform-Wurm sadmind/IIS
Ausblick
15
2.1 Code Red
• Webserver-Wurm
• am 19. Juli 2001: 250.000 Systeme in 9 Stunden
befallen!
• datumsabhängiges Verhalten des Wurms
• Variationen des Mechanismus: Code Red II et al.
• auch "home systems" (cable/DSL/always-on) ins
Blickfeld gerückt
• Firewall: kann bei „internen“ Servern helfen
16
2.2 Nimda
• Verbreitung über:
–
–
–
–
–
Client-Client: E-Mail-Virus
Client-Client: freigegebene Verzeichnisse
Client-Webserver: IIS-Exploit
Webserver-Client: kompromittierte Webseiten
Guest-Account, Share C frei für „Jeder“, Infizieren von
.exe etc., Registry, System.Ini, ...
• www.cert.dfn.de/infoserv/dsb/dsb-2001-01.html
• „andauernde Gefahr“ (Zusammen mit Code Red):
– Port 80-Scans monatelang Spitzenreiter...
– wenige Minuten am Netz genügten, um ein
ungepatchtes System zu infizieren
• Firewall: langsamere Ausbreitung (je nach Stufe)
17
2.3 ssh-Exploits
• ssh: secure shell
• „sicher“ heisst: verschlüsselt, nicht abhörbar
• auf vielen Workstations nicht nur als Client,
sondern auch als Serverdienst installiert
• der Serverdienst war (ist!) angreifbar
• schlug insbesondere in Linux-/Unix-lastigen
Netzen zu
• ssh-Trojaner hört Passwörter ab
• Firewall: zunächst(!) „nur“ Server gefährdet
18
2.3.1 ssh-Exploit
Date:
Fri, 14 Dec 2001 08:55:26 +0100
Subject:
[Advisory] Angriffe auf Secure Shell Daemons - CA-2001-35
To: [email protected]
Dem CERT/CC (IN-2001-12) und dem DFN-CERT werden seit einiger Zeit
verstaerkt Scans nach SSH Installationen gemeldet. Im Gefolge dieser
Scans kommt es haeufig zu Angriffen, bei denen Rootkits installiert
werden, welche das Verhalten von Systemprogrammen (ps, ls, netstat,
etc.) modifizieren. Zusaetzlich werden trojanisierte Versionen der SSH
und Scantools installiert.
Die Gefahr besteht insbesondere darin, dass auch sonst nicht
angreifbare Systeme, wie Firewalls oder Intrusion Detection Systeme,
die sonst keine offenen Ports anbieten, von der Problematik betroffen
sein koennen.
19
2.4 Cross-platform-Wurm
• Technik mit Zukunft?
• Wurde damals nicht (bewusst) im HD-Net gesichtet
Date:
Tue, 8 May 2001 11:24:44 +0200
Subject:
[Advisory][MS][Sun] sadmind/IIS Worm - CA-2001-11
To: Multiple recipients of list SECURITY
<[email protected]>
Beschrieben wird ein neuartiger Wurm-Virus namens "sadmind/IIS", der
sich auf Sun Solaris Systemen einnistet, um von dort aus Systeme mit
dem "Internet Information Server" (IIS) von Microsoft zu attackieren.
Die "Arbeit" des Wurms gliedert sich in 2 Phasen:
Phase 1. Befall des Solaris-Systems
Phase 2. Angriff auf IIS-Systeme
20
2.5 Ausblick: Angriffe
• Neue Features = Neuer Code = Neue Fehler
möglich
• Mehr Linux-Viren/Würmer, weil es immer
verbreiteter und einfacher zu installieren und
bedienen wird
• Cross-Platform-Viren/Würmer:
wenn der Linux-Server ge-crackt wird, sind auch
die Windows-Clients gefährdet und umgekehrt...
• neue Generationen im Sommer, wenn
Ferienzeit...
21
3. Urz-Instituts-Firewall
•
•
•
•
•
•
•
Bestandteile einer „Firewall“
Filterliste Stufe 1
Vorstellung Stufe 1b
Vorstellung Stufe 2
Implementierung
Änderungen
Probleme
22
3.1 Bestandteile einer Firewall
• Bedrohungsanalyse / Risikoabschätzung /
Policy / Notfallplan
• (NAT) / Paketfilter
• Proxies / Application-Level-Firewalls
• regelmäßige Nutzerschulung
• regelmäßige Administration
• regelmäßige Revision
23
3.1.1 Strikte Accessliste
access-list 113 permit ip 129.206.xx.240 0.0.0.15 any ! server
access-list 113 permit tcp 129.206.0.0 0.0.255.255 any eq 443 ! https
access-list 113 permit tcp 129.206.0.0 0.0.255.255 any eq 563 ! https
access-list 113 permit tcp 129.206.0.0 0.0.255.255 host 129.206.149.102 eq 3299 ! sap-clients
access-list 113 permit tcp 129.206.0.0 0.0.255.255 host www-cache.ub.uni-heidelberg.de eq 8080 ! ub-lizenzproxy
access-list 113 permit ip 129.206.0.1 0.0.0.15 129.206.100.160 0.0.0.7 ! netz
access-list 113 permit ip 129.206.0.1 0.0.0.15 129.206.218.0 0.0.0.255 ! netz
!
access-list 113 deny ip any any
access-list 114 permit ip any 129.206.xx.240 0.0.0.15 ! server
access-list 114 permit tcp any eq 443
129.206.0.0 0.0.255.255 established ! https
access-list 114 permit tcp any eq 563
129.206.0.0 0.0.255.255 established ! https
access-list 114 permit tcp host 129.206.149.102 eq 3299
129.206.0.0 0.0.255.255 ! sap-clients
access-list 114 permit tcp host www-cache.ub.uni-heidelberg.de eq 8080 129.206.0.0 0.0.255.255 ! ub-lizenzproxy
access-list 114 permit ip 129.206.100.160 0.0.0.7 129.206.0.1 0.0.255.15 ! netz
access-list 114 permit ip 129.206.218.0 0.0.0.255 129.206.0.1 0.0.255.15 ! netz
!
access-list 114 deny ip any any
24
3.2 Paketfilter „Stufe 1“
• Filter-Policy:
– Clienten dürfen über viele Protokolle direkt ins Internet,
insbesondere auch Standard-Protokolle
– Server liegen ab .240, alle Ports (außer denen der UniFirewall) frei
• Vorteile:
– direkter Internet-Zugang für Clients
• Risiken:
– z.T. direkte Angriffe auf Serverdienste bei Clients
– und Servern möglich
– „ungefilterte“ Mail/Webinhalte etc.
25
Internet
BelWü
3.2.1 Stufe 1
BelWü-Router
he1
UniversitätsFirewall
Paketfilter
Firewall
br2-urz
Institutsnetz B
HD-Net
Institutsnetz
Paketfilter
Firewall
Paketfilter
Firewall
Client
Server
Server IP-Adressen:
x.x.x.240 bis x.x.x.254
Institutsnetz X
Institutsnetz Y
26
3.2.2 IP-Adressen Stufe 1
Damit die Paketfilter subnetzunabhängig konfiguriert werden können,
müssen Server und Netzkomponenten bestimmte Hostadressen
haben.
1
15
31
Netzkomponenten
50
200
Clients
224
240
254
Server
27
3.3 „Stufe 1b“
• Filter-Policy:
– Clienten dürfen über viele Protokolle direkt ins Internet,
die Standard-Protokolle sollten über Proxies (lokal oder
Urz) abgedeckt werden. Keine direkten Port-Zugänge
von außerhalb der Uni (kein ssh etc. für Clients)
– Server liegen ab .240, bestimmte IP-Adressen haben
nur bestimmte Serverports offen
• Vorteile:
– weiter direkter Internet-Zugang für Clients mit
Spezialanwendungen
• Risiken:
– direkte Angriffe auf wenige offene Serverdienste
– „ungefilterte“ Mail/Webinhalte etc.
28
3.3.1 Server Stufe 1b
• Zuordnung/Beschränkung: IP-Adressen - Dienste
–
–
–
–
–
–
.240-.243
.244+.245
.246+.247
.248+.249
.250+.251
.252-.254
http
DNS
Mail (SMTP, POP..) innerhalb Uni
LAN innerhalb Uni
„seltene Dienste“ (welche?)
ohne weitere Sperrung
• Der Server arbeitet dann mit mehreren IP-Adressen
– evtl. problematisch für TLS (SSL), evtl. mehrere Zertifikate nötig
– ssh? für Verwaltung über Urz-Proxies gehen... (Minimierung der
Dienste)
29
• Filter-Policy:
3.4 „Stufe 2“
– Clienten dürfen nur ans URZ bzw. uniweite
Servernetze, und zu definierten nicht-Standard-Servern
bzw. Ports ausserhalb
– Internet-Server stehen außerhalb des InstitutsHausnetzes, z.B. werden URZ-Serverdienste genutzt
• Vorteile gegenüber 1b:
– ein gehackter Internet-Dienst bedroht nicht das
Hausnetz
– lokale Server (mit User-Passwörtern) weniger bedroht
• Risiken:
– „ungefilterte“ Mail/Webinhalte etc.
– Serverdienste bleiben dennoch bedroht
30
Internet
BelWü
3.4.1 Stufe 2
BelWü-Router
he1
UniversitätsFirewall
Proxyserver:
Vom URZ
oder Institut
administriert.
Paketfilter
Firewall
br2-urz
Institutsnetz B
HD-Net
Paketfilter
Firewall
Proxy-Netz
Paketfilter
Firewall
Client
Server
Institutsnetz X
Institutsnetz Y
31
3.5 Implementierung
• XML-Eingabedatei
– Accesslisten als Ausgabe
– Vereinheitlichung der Eigenschaften
– Verminderung von Fehlern und Doppelt-Tippen
– Automatische Dokumentation (ToDo)
•
•
•
•
Einspielen in alle Router
Zusendung der Logfiles / IDS
Erzeugung/Zusendung von Logreports
Scan-Service am Urz / bei BelWü
32
3.5.1 XML-Eingabedatei
<serverlist stufe="B C D" type="WWW-Proxy(8080)">
<entry server="host www-proxy.uni-heidelberg.de"/>
<entry server="host www-proxy.uni-heidelberg.de"/>
<entry server="host ab1.ub.uni-heidelberg.de"/>
<entry server="host zr17.ub.uni-heidelberg.de"/>
<!-- -->
<entry prot="tcp " cport="gt 1023" sport="eq 8080" comment="http-proxy"/>
</serverlist>
<clients stufe="B C D" scope="urz" comment="weitere URZ/Uni-Server">
<entry prot="tcp " cport="gt 1023" server="129.206.119.0 0.0.0.255" sport="range 1500 1509"
undumgekehrt="1" comment="adsm"/>
<entry prot="tcp " cport="gt 1023" server="129.206.119.0 0.0.0.255" sport="eq 1521" comment="Oracle"/>
<!-- die folgenden Eintraege sollten noch konsolidiert/verkleinert/eingeschraenkt werden -->
<entry prot="udp " cport="gt 122" server="urz" sport="eq 123" comment="ntp, ports eq123+gt1023"/>
<entry prot="tcp " cport="gt 1023" server="urz" sport="eq 37" comment="time"/>
<entry prot="icmp" cport="
" server="urz" sport="
" comment="icmp"/>
</clients>
<clients stufe="B C" scope="uni" comment="uni-interne unsichere Clienten/Netzwerk-Protokolle">
<entry prot="tcp " cport="gt 1023"
server="uni" sport="eq 23" comment="telnet"/>
<entry prot="tcp " cport="gt 1"
server="uni" sport="eq 3389" comment="Win Terminal Server"/>
</clients>
33
3.5.2 Logfiles
• Rohdaten der Router > grep > sort > guniq
1
1
2
1
1
1
1
2
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
8 03:37:05 cr-unipla.hd-net.uni-heidelberg.de 873113: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.224.142.86(3909) -> 147.142.201.233(80), 1 packet
8 03:42:10 cr-unipla.hd-net.uni-heidelberg.de 873117: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.224.142.86(3909) -> 147.142.201.233(80), 2 packets
8 03:32:46 cr-unipla.hd-net.uni-heidelberg.de 873109: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.228.136.191(1896) -> 147.142.201.125(80), 1 packet
8 22:04:28 cr-unipla.hd-net.uni-heidelberg.de 874765: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.248.152.27(2764) -> 147.142.201.108(80), 1 packet
8 22:09:34 cr-unipla.hd-net.uni-heidelberg.de 874777: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.248.152.27(2764) -> 147.142.201.108(80), 2 packets
8 14:26:48 cr-unipla.hd-net.uni-heidelberg.de 874031: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.251.56.85(4742) -> 147.142.201.102(80), 1 packet
8 14:32:25 cr-unipla.hd-net.uni-heidelberg.de 874038: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.251.56.85(4742) -> 147.142.201.102(80), 2 packets
8 16:07:14 cr-unipla.hd-net.uni-heidelberg.de 874162: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.254.135.210(40501) -> 147.142.201.230(80), 1 packet
8 21:30:17 cr-unipla.hd-net.uni-heidelberg.de 874710: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.254.135.210(5194) -> 147.142.201.94(80), 1 packet
8 21:35:33 cr-unipla.hd-net.uni-heidelberg.de 874722: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.254.135.210(5194) -> 147.142.201.94(80), 2 packets
8 22:38:40 cr-unipla.hd-net.uni-heidelberg.de 874816: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.65.222.55(2901) -> 147.142.201.57(80), 1 packet
8 22:44:35 cr-unipla.hd-net.uni-heidelberg.de 874828: %SEC-6-IPACCESSLOGP: list 154 denied tcp 12.65.222.55(2901) -> 147.142.201.57(80), 2 packets
8 18:31:27 cr-unipla.hd-net.uni-heidelberg.de 874419: %SEC-6-IPACCESSLOGP: list 154 denied tcp 128.186.116.219(1721) -> 147.142.201.84(80), 1 packet
8 18:36:29 cr-unipla.hd-net.uni-heidelberg.de 874428: %SEC-6-IPACCESSLOGP: list 154 denied tcp 128.186.116.219(1721) -> 147.142.201.84(80), 2 packets
8 10:43:20 cr-unipla.hd-net.uni-heidelberg.de 873681: %SEC-6-IPACCESSLOGP: list 154 denied tcp 128.208.250.164(1163) -> 147.142.201.185(80), 2 packets
8 07:57:54 cr-unipla.hd-net.uni-heidelberg.de 873410: %SEC-6-IPACCESSLOGP: list 154 denied tcp 129.128.9.178(2174) -> 147.142.201.116(80), 1 packet
8 08:03:16 cr-unipla.hd-net.uni-heidelberg.de 873415: %SEC-6-IPACCESSLOGP: list 154 denied tcp 129.128.9.178(2174) -> 147.142.201.116(80), 2 packets
8 10:07:45 cr-unipla.hd-net.uni-heidelberg.de 873615: %SEC-6-IPACCESSLOGP: list 154 permitted tcp 129.206.100.126(53) -> 147.142.201.241(42077), 1 packet
8 10:13:19 cr-unipla.hd-net.uni-heidelberg.de 873624: %SEC-6-IPACCESSLOGP: list 154 permitted tcp 129.206.100.126(53) -> 147.142.201.241(42077), 5 packets
8 16:32:34 cr-unipla.hd-net.uni-heidelberg.de 874229: %SEC-6-IPACCESSLOGDP: list 154 permitted icmp 129.206.119.10 -> 147.142.201.251 (3/3), 1 packet
8 16:38:27 cr-unipla.hd-net.uni-heidelberg.de 874237: %SEC-6-IPACCESSLOGDP: list 154 permitted icmp 129.206.119.10 -> 147.142.201.251 (3/3), 3 packets
8 09:21:30 cr-unipla.hd-net.uni-heidelberg.de 873529: %SEC-6-IPACCESSLOGP: list 154 permitted tcp 129.206.85.25(8084) -> 147.142.201.253(2771), 1 packet
8 09:21:37 cr-unipla.hd-net.uni-heidelberg.de 873531: %SEC-6-IPACCESSLOGP: list 154 permitted tcp 129.206.85.25(8084) -> 147.142.201.253(2771), 4 packets
8 09:21:33 cr-unipla.hd-net.uni-heidelberg.de 873530: %SEC-6-IPACCESSLOGP: list 154 permitted tcp 129.206.85.25(8084) -> 147.142.201.253(2773), 1 packet
8 09:22:22 cr-unipla.hd-net.uni-heidelberg.de 873532: %SEC-6-IPACCESSLOGP: list 154 permitted tcp 129.206.85.25(8084) -> 147.142.201.253(2776), 4 packets
8 09:22:40 cr-unipla.hd-net.uni-heidelberg.de 873533: %SEC-6-IPACCESSLOGP: list 154 permitted tcp 129.206.85.25(8084) -> 147.142.201.253(2779), 4 packet
34
3.5.3 Logreport
• „Informationsverdichtung“
SourceIP
Records
================================
63.209.18.60
203 5.64%
80.8.16.156
94 2.61%
147.46.162.114
57 1.58%
147.46.113.246
47 1.31%
• Korrelationen
SourceIPDestPort
Records
============================================
80.8.16.156:80
94 2.61%
147.46.162.114:80
57 1.58%
147.46.113.246:80
47 1.31%
147.140.239.74:80
41 1.14%
147.32.201.72:80
39 1.08%
192.44.243.18:80
32 0.89%
148.235.4.244:80
29 0.81%
147.83.85.184:80
28 0.78%
62.110.46.186:111
26 0.72%
35
3.5.4 Scanservice
• Urz:
– Mail an [email protected] (W. Schrimm)
– Nmap
– Nessus (Vorsicht!)
• BelWü:
– was ist „von außen“ sichtbar?
– bis auf weiteres Mail an [email protected]
36
3.6 Änderungen
• Öffnung weiterer Ports:
– Mail an [email protected]..
– Stufe 1 (Erweiterung „leicht“ möglich):
• Net-Bugs entscheiden
• Info-Mail an Netzfort
– Stufe 2 (nur non-Standard direkt):
• genauso? oder nur wenn kein Protest?
• Andere Firewall-Stufe:
– mindestens per Mail an Net-Bugs
– besser schriftlich
• Wie bei Bedrohungen reagieren?
– http, ssh? Uni-Firewall? Urz-Instituts-Firewalls?
37
3.7 Probleme
• Institute mit mehreren Subnetzen:
– i.d.R. ungehinderter Datenverkehr intern erwünscht
– eventuell Netze nach Netzlast trennen
• Mehrere Institute an einem Port
– Einigung erforderlich
– Ausblick: mit neuem Backbone je Institutsnetz möglich
• Alles nur „Fummelware“?
– selbstgeschriebene Skripten / kein GUI
– kein NAT / keine „state aware“ Filterung
– keine „content“ Filterung
• No warranty:
– we hope our service can be useful...
– bei Problemen kann es sein, dass die Accessliste auch ohne
Ankündigung vorübergehend abgeschaltet wird
38
4. Weitere Schritte
• Im Institut:
– Bedrohungsanalyse/ Policy/ Notfallplan
– haben alle relevanten Rechner Datensicherung?
– haben alle Rechner Virenschutz mit Aktualisierung?
• Mail an [email protected]
– Besprechung (evtl. reicht auch telefonisch)
– Vorarbeiten: Server verlegen, Proxies eintragen
– Termin für „Einschalten“
• Zeit für Logbuchauswertung nehmen
– bis klar ist, was „normal“ ist
– wir arbeiten daran, die Logfiles auf „Relevantes“ zu
minimieren
39
4.1 Zum Schluss
• Fragen?
• Diskussion?
• Bitte um Rückmeldung, auch per Mail
• Nächste Netzfort-Veranstaltung
– nachdem die Vorträge und die angekündigte
FW-Doku im Web stehen
– voraussichtlich erst Mai/Juni
– Themen VPN / Laptop-Netz / Funklan, neuer
Backbone, ???
40
ENDE
Vielen Dank für das Interesse!
Bitte füllen Sie den Fragebogen aus.
[email protected]

Präsentationsquelle herunterladen