Urz-Instituts-Firewall

Präsentation zum Thema: "Urz-Instituts-Firewall"—  Präsentation transkript:

1 Urz-Instituts-Firewall
Netzfort

2 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

3 "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 ;-)

4 Themen 1. Firewalls im HD-Net 2. „Geglückte“ Angriffe im HD-Net
3. Urz-Instituts-Firewall 4. Weitere Schritte

5 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

6 1.1 Uplink BelWü seit Herbst 2001 Sperrung von „Lan“-Protokollen
seit März 2001 Sperrung von „Peer-to-peer“-Protokollen Grund: hohe Kosten der volumenabhängig abgerechneten Transatlantik-Verbindung

7 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

8 Uni-Firewall

9 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 access-list 103 deny tcp any any range 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 access-list 103 deny tcp any any range 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 ! cdp access-list 103 deny udp any any eq ! 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 !

10 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

11 1.4 Urz-Server (bislang noch wenige) Paketfilter Ziel: zweistufig
erst seit kurzem technisch möglich (Lastprobleme mit br-urz)

12 1.5 Institutseigene Firewalls
solche gibt es keine Hilfestellung etc. möglich

13 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

14 1.7 Urz-Firewall-Informationen
Öffentlich > Angebote > Sicherheit... > Netz > Netzbetrieb > Firewalls Nur für EDV-/Netzbeauftragte etc. Netzfort-Verzeichnis Mailliste Sicherheitshinweise von CERT (Computer Emergency Response Team) diversen Herstellern (IBM, sun, hp, sgi, Linux-Distributoren) Aufnahme in Liste: Mail an

15 2. „Geglückte“ Angriffe Code Red Nimda ssh-Exploit
Cross-platform-Wurm sadmind/IIS Ausblick

16 2.1 Code Red Webserver-Wurm
am 19. Juli 2001: 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

17 2.2 Nimda Verbreitung über:
Client-Client: -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, ... „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)

18 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

19 2.3.1 ssh-Exploit Date: Fri, 14 Dec 2001 08:55:26 +0100
Subject: [Advisory] Angriffe auf Secure Shell Daemons - CA To: Dem CERT/CC (IN ) 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.

20 2.4 Cross-platform-Wurm Technik mit Zukunft?
Wurde damals nicht (bewusst) im HD-Net gesichtet Date: Tue, 8 May :24: Subject: [Advisory][MS][Sun] sadmind/IIS Worm - CA To: Multiple recipients of list SECURITY 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

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

22 3. Urz-Instituts-Firewall
Bestandteile einer „Firewall“ Filterliste Stufe 1 Vorstellung Stufe 1b Vorstellung Stufe 2 Implementierung Änderungen Probleme

23 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

24 Strikte Accessliste access-list 113 permit ip xx any ! server access-list 113 permit tcp any eq 443 ! https access-list 113 permit tcp any eq 563 ! https access-list 113 permit tcp host eq ! sap-clients access-list 113 permit tcp host www-cache.ub.uni-heidelberg.de eq ! ub-lizenz-proxy access-list 113 permit ip ! netz access-list 113 permit ip ! netz ! access-list 113 deny ip any any access-list 114 permit ip any xx ! server access-list 114 permit tcp any eq established ! https access-list 114 permit tcp any eq established ! https access-list 114 permit tcp host eq ! sap-clients access-list 114 permit tcp host www-cache.ub.uni-heidelberg.de eq ! ub-lizenz-proxy access-list 114 permit ip ! netz access-list 114 permit ip ! netz access-list 114 deny ip any any

25 3.2 Paketfilter „Stufe 1“ Filter-Policy: Vorteile: Risiken:
Clienten dürfen über viele Protokolle direkt ins Internet, insbesondere auch Standard-Protokolle Server liegen ab .240, alle Ports (außer denen der Uni-Firewall) 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.

26 Stufe 1 Server IP-Adressen: x.x.x.240 bis x.x.x.254

27 3.2.2 IP-Adressen Stufe 1 Netz- komponenten Clients Server
Damit die Paketfilter subnetzunabhängig konfiguriert werden können, müssen Server und Netzkomponenten bestimmte Hostadressen haben. 1 15 31 50 200 224 240 254 Netz- komponenten Clients Server

28 3.3 „Stufe 1b“ Filter-Policy: Vorteile: Risiken:
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.

29 3.3.1 Server Stufe 1b Zuordnung/Beschränkung: IP-Adressen - Dienste
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)

30 3.4 „Stufe 2“ Filter-Policy: Vorteile gegenüber 1b: Risiken:
Clienten dürfen nur ans URZ bzw. uniweite Servernetze, und zu definierten nicht-Standard-Servern bzw. Ports ausserhalb Internet-Server stehen außerhalb des Instituts-Hausnetzes, 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

31 Stufe 2 Proxyserver: Vom URZ oder Institut administriert.

32 3.5 Implementierung XML-Eingabedatei Einspielen in alle Router
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ü

33 XML-Eingabedatei <serverlist stufe="B C D" type="WWW-Proxy(8080)"> <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=" " sport="range " undumgekehrt="1" comment="adsm"/> <entry prot="tcp " cport="gt 1023" server=" " 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"/>

34 3.5.2 Logfiles Rohdaten der Router > grep > sort > guniq
1 Mar 8 03:37:05 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (3909) -> (80), 1 packet 1 Mar 8 03:42:10 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (3909) -> (80), 2 packets 2 Mar 8 03:32:46 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (1896) -> (80), 1 packet 1 Mar 8 22:04:28 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (2764) -> (80), 1 packet 1 Mar 8 22:09:34 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (2764) -> (80), 2 packets 1 Mar 8 14:26:48 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (4742) -> (80), 1 packet 1 Mar 8 14:32:25 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (4742) -> (80), 2 packets 2 Mar 8 16:07:14 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (40501) -> (80), 1 packet 1 Mar 8 21:30:17 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (5194) -> (80), 1 packet 1 Mar 8 21:35:33 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (5194) -> (80), 2 packets 1 Mar 8 22:38:40 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (2901) -> (80), 1 packet 1 Mar 8 22:44:35 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (2901) -> (80), 2 packets 1 Mar 8 18:31:27 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (1721) -> (80), 1 packet 1 Mar 8 18:36:29 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (1721) -> (80), 2 packets 1 Mar 8 10:43:20 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (1163) -> (80), 2 packets 1 Mar 8 07:57:54 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (2174) -> (80), 1 packet 1 Mar 8 08:03:16 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 denied tcp (2174) -> (80), 2 packets 1 Mar 8 10:07:45 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 permitted tcp (53) -> (42077), 1 packet 1 Mar 8 10:13:19 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 permitted tcp (53) -> (42077), 5 packets 1 Mar 8 16:32:34 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGDP: list 154 permitted icmp > (3/3), 1 packet 1 Mar 8 16:38:27 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGDP: list 154 permitted icmp > (3/3), 3 packets 1 Mar 8 09:21:30 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 permitted tcp (8084) -> (2771), 1 packet 1 Mar 8 09:21:37 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 permitted tcp (8084) -> (2771), 4 packets 1 Mar 8 09:21:33 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 permitted tcp (8084) -> (2773), 1 packet 1 Mar 8 09:22:22 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 permitted tcp (8084) -> (2776), 4 packets 1 Mar 8 09:22:40 cr-unipla.hd-net.uni-heidelberg.de : %SEC-6-IPACCESSLOGP: list 154 permitted tcp (8084) -> (2779), 4 packet

35 3.5.3 Logreport „Informationsverdichtung“ Korrelationen
SourceIP Records ================================ % % % % Korrelationen SourceIPDestPort Records ============================================ : % : % : % : % : % : % : % : % : %

36 3.5.4 Scanservice Urz: BelWü: Mail an Net-Bugs@urz (W. Schrimm) Nmap
Nessus (Vorsicht!) BelWü: was ist „von außen“ sichtbar? bis auf weiteres Mail an

37 3.6 Änderungen Öffnung weiterer Ports: Andere Firewall-Stufe:
Mail an 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?

38 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

39 4. Weitere Schritte Im Institut: Mail an Net-Bugs@urz
Bedrohungsanalyse/ Policy/ Notfallplan haben alle relevanten Rechner Datensicherung? haben alle Rechner Virenschutz mit Aktualisierung? Mail an 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

40 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, ???

41 Vielen Dank für das Interesse! Bitte füllen Sie den Fragebogen aus.
ENDE Vielen Dank für das Interesse! Bitte füllen Sie den Fragebogen aus.