Urz-Instituts-Firewall Netzfort 19.03.2002 [email protected].

Urz-Instituts-Firewall

Netzfort 19.03.2002

[email protected]

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

HD-Net

br2-urz

Institu tsnetz

Institu tsnetz A

Institu tsnetz X

InternetBelW ü

BelW ü-Routerhe1

PaketfilterFirewall

PaketfilterFirewall

Universitäts-Firewall

Institu tsnetz B

Institu tsnetz Y

PaketfilterFirewall

1.2.1 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


! SMB nach aussen gesperrt


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


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


!

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

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

http://www.urz.uni-heidelberg.de/Security/







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

17

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)

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

20

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

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

3.1.1 Strikte Accesslisteaccess-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-lizenz-proxy

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 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-lizenz-proxy



!

access-list 114 deny ip any any

25

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

Institu tsnetz

HD-Net

br2-urz

Institu tsnetz X

InternetBelW ü

BelW ü-Routerhe1

PaketfilterFirewall


Institu tsnetz B

Institu tsnetz Y

PaketfilterFirewall

ServerClient

PaketfilterFirewall

Server IP-Adressen:x.x.x.240 bis x.x.x.254

3.2.1 Stufe 1

27

3.2.2 IP-Adressen Stufe 1

Damit die Paketfilter subnetzunabhängig konfiguriert werden können, müssen Server und Netzkomponenten bestimmte Hostadressen haben.

Netz-komponenten

ServerClients

1 15 31 224 240 25420050

28

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.

29

3.3.1 Server Stufe 1b

• Zuordnung/Beschränkung: IP-Adressen - Dienste– .240-.243 http– .244+.245 DNS– .246+.247 Mail (SMTP, POP..) innerhalb Uni– .248+.249 LAN innerhalb Uni– .250+.251 „seltene Dienste“ (welche?)– .252-.254 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:

– 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

HD-Net

br2-urz

Institu tsnetz X

InternetBelW ü

BelW ü-Routerhe1

PaketfilterFirewall


Institu tsnetz B

Institu tsnetz Y

PaketfilterFirewall

ServerClient

PaketfilterFirewall

Proxy-Netz

Proxyserver:Vom URZ oder Institut administriert.

3.4.1 Stufe 2

32

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ü

33

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"/>



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

34

3.5.2 Logfiles• Rohdaten der Router > grep > sort > guniq

1 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

1 Mar 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
















1 Mar 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

1 Mar 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

1 Mar 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

1 Mar 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






35

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%

• KorrelationenSourceIPDestPort 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%

36

3.5.4 Scanservice

• Urz: – Mail an Net-Bugs@urz (W. Schrimm)– Nmap– Nessus (Vorsicht!)

• BelWü:– was ist „von außen“ sichtbar?– bis auf weiteres Mail an Net-Bugs@urz

37

3.6 Änderungen• Öffnung weiterer Ports:

– Mail an Net-Bugs@urz...– 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:

– Bedrohungsanalyse/ Policy/ Notfallplan– haben alle relevanten Rechner Datensicherung?– haben alle Rechner Virenschutz mit Aktualisierung?

• Mail an Net-Bugs@urz– 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, ???

ENDE

Vielen Dank für das Interesse!

Bitte füllen Sie den Fragebogen aus.

[email protected]

Date post:	05-Apr-2015
Category:	Documents
Upload:	adalhard-rathsack
View:	117 times
Download:	1 times

Urz-Instituts-Firewall Netzfort 19.03.2002 [email protected].

Documents