Studie
“Gesicherte Verbindung von Computernetzen mit Hilfe einer Firewall”
Andreas Bonnard1 Christian Wolff1 SIEMENS AG Zentralabteilung Technik ZT IK 3
im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik München, 1997
1
Andreas Bonnard und Christian Wolff sind Mitarbeiter des Fachzentrums Sicherheit der Zentralabteilung Technik der Siemens AG in München. Sie sind erreichbar unter: Andreas Bonnard, Siemens AG, ZT IK 3, 81730 München, e-mail:
[email protected], Telefon +49-89-636 43307, Fax +49-89-636 48000 Christian Wolff, Siemens AG, ZT IK 3, 81730 München, e-mail:
[email protected], Telefon +49-89-636 48917, Fax +49-89-636 48000
SIEMENS
Ziele der Studie
INHALTSVERZEICHNIS
1
ZIELE DER STUDIE ....................................................................................................................................9
2
EINFÜHRUNG IN DIE FIREWALL-PROBLEMATIK.........................................................................10
3
BEDROHUNGSANALYSE DER PROTOKOLLE..................................................................................11 3.1 INTERNET-PROTOCOL (IP) ......................................................................................................................11 3.1.1 Einsatzumgebung ...........................................................................................................................11 3.1.2 Dienste von IP................................................................................................................................11 3.1.3 Adressen und Adreßtabellen ..........................................................................................................12 3.1.4 Schematischer Ablauf.....................................................................................................................13 3.1.4.1 3.1.4.2
IP/ULP Primitive ....................................................................................................................................... 14 IP/SNP Primitive ....................................................................................................................................... 14
3.1.5 Protokolldatenstruktur...................................................................................................................15 3.1.6 Sicherheitsbedrohungen.................................................................................................................15 3.1.7 Filterungsmöglichkeiten ................................................................................................................17 3.1.8 Zusammenfassung ..........................................................................................................................17 3.2 INTERNET PROTOCOL VERSION 6 (IPV6) ................................................................................................17 3.2.1 Protokollbeschreibung...................................................................................................................17 3.2.1.1 Einsatzumgebung....................................................................................................................................... 17 3.2.1.1.1 Sicherheitsmerkmale ........................................................................................................................... 17 3.2.1.1.1.1 Authentication Header (AH) ....................................................................................................... 18 3.2.1.1.1.2 Encapsulating Security Payload (ESP)........................................................................................ 18 3.2.1.1.2 Erweiterte Routing- und Adressierungsfähigkeiten............................................................................. 19 3.2.1.1.3 IPv6-Adressierung............................................................................................................................... 19 3.2.1.1.4 IPv6-Routing....................................................................................................................................... 19 3.2.1.1.5 Vereinfachung des Header-Formats .................................................................................................... 19 3.2.1.1.6 Verbesserte Unterstützung von Erweiterungen und Optionen ............................................................ 19 3.2.1.1.7 Quality of Service (QoS)..................................................................................................................... 20 3.2.1.2 Protokolldatenstruktur ............................................................................................................................... 20 3.2.1.3 Sicherheitsbedrohungen............................................................................................................................. 21 3.2.1.4 Filterungsmöglichkeiten ............................................................................................................................ 21 3.2.1.5 Zusammenfassung...................................................................................................................................... 21
3.2.2
IPv6 und Firewalls.........................................................................................................................21
3.2.2.1 Ansätze zur Kombination von Firewalls mit IPSec ................................................................................... 23 3.2.2.1.1 Virtual Private Networks (VPNs) ....................................................................................................... 23 3.2.2.1.2 Paketfilter und IPSec........................................................................................................................... 23 3.2.2.1.3 Applikationsfilter und IPSec ............................................................................................................... 24 3.2.2.1.4 Key-Management für IPSec ................................................................................................................ 24 3.2.2.1.5 Key-Management und Firewalls ......................................................................................................... 24 3.2.2.1.6 Schlüsselverteilung in VPNs am Beispiel X.509 ................................................................................ 25 3.2.2.1.6.1 X.509 Simple Authentication ...................................................................................................... 25 3.2.2.1.6.2 X.509 Strong Authentication....................................................................................................... 26 3.2.2.1.6.3 X.509 Key Management.............................................................................................................. 27 3.2.2.1.6.4 Auswirkungen auf Firewalls........................................................................................................ 28 3.2.2.2 Alternativen zu IPSec in Bezug auf Firewalls............................................................................................ 28 3.2.2.2.1 Transport Layer Security (TLS) .......................................................................................................... 28 3.2.2.2.2 Authenticated Firewall Traversal Protocol (AFT)............................................................................... 28
3.2.3 3.2.3.1 3.2.3.2
Konzeptionelle Unterschiede Intranet - Internet............................................................................28 Szenario VPN mit TLS/SSL und IPSec..................................................................................................... 28 Szenario kaskadiertes Intranet mit TLS/SSL und IPSec ............................................................................ 29
3.2.4 Anforderungen an Firewalls in zukünftigen Szenarien bezüglich IPSec .......................................30 3.2.5 Fazit ...............................................................................................................................................31 3.3 INTERNET CONTROL MESSAGE PROTOCOL (ICMP) ................................................................................31 3.3.1 Einsatzumgebung ...........................................................................................................................31 3.3.2 Dienste von ICMP..........................................................................................................................32 3.3.3 Protokolldatenstruktur...................................................................................................................33 3.3.4 Sicherheitsbedrohungen.................................................................................................................33 3.3.5 Filterungsmöglichkeiten ................................................................................................................34 3.3.6 Zusammenfassung ..........................................................................................................................34
Seite 2
Firewall-Studie
11.09.97
SIEMENS
Internet-Protocol (IP )
3.4 TRANSMISSION CONTROL PROTOCOL (TCP)...........................................................................................35 3.4.1 Einsatzumgebung ...........................................................................................................................35 3.4.2 Schematischer Ablauf.....................................................................................................................35 3.4.3 Steuerkommandos ..........................................................................................................................36 3.4.4 Dienste von TCP ............................................................................................................................37 3.4.5 Protokolldatenstruktur...................................................................................................................38 3.4.6 Sicherheitsbedrohungen.................................................................................................................39 3.4.7 Filterungsmöglichkeiten ................................................................................................................40 3.4.8 Zusammenfassung ..........................................................................................................................40 3.5 USER DATAGRAM PROTOCOL (UDP)......................................................................................................40 3.5.1 Einsatzumgebung ...........................................................................................................................40 3.5.2 Schematischer Ablauf.....................................................................................................................40 3.5.3 Steuerkommandos ..........................................................................................................................41 3.5.4 Protokolldatenstruktur...................................................................................................................41 3.5.5 Sicherheitsbedrohungen.................................................................................................................42 3.5.6 Filterungsmöglichkeiten ................................................................................................................42 3.5.7 Zusammenfassung ..........................................................................................................................43 3.6 DOMAIN NAME SYSTEM (DNS) ..............................................................................................................43 3.6.1 Einsatzumgebung ...........................................................................................................................43 3.6.2 Schematischer Ablauf.....................................................................................................................43 3.6.3 Protokolldatenstruktur...................................................................................................................45 3.6.4 Sicherheitsbedrohungen.................................................................................................................46 3.6.5 Filterungsmöglichkeiten ................................................................................................................47 3.6.6 Zusammenfassung ..........................................................................................................................49 3.7 ADDRESS RESOLUTION PROTOCOL (ARP) ..............................................................................................49 3.7.1 Einsatzumgebung ...........................................................................................................................49 3.7.2 Sicherheitsbedrohungen.................................................................................................................49 3.7.3 Filterungsmöglichkeiten ................................................................................................................49 3.7.4 Zusammenfassung ..........................................................................................................................49 3.8 EINFÜHRUNG ROUTING ...........................................................................................................................50 3.8.1 Routing Information Protocol (RIP) ..............................................................................................51 3.8.1.1 3.8.1.2 3.8.1.3 3.8.1.4 3.8.1.5 3.8.1.6
3.8.2 3.8.2.1 3.8.2.2 3.8.2.3 3.8.2.4 3.8.2.5 3.8.2.6
3.8.3 3.8.3.1 3.8.3.2 3.8.3.3 3.8.3.4 3.8.3.5
Einsatzumgebung....................................................................................................................................... 51 Schematischer Ablauf ................................................................................................................................ 51 Protokolldatenstruktur ............................................................................................................................... 51 Sicherheitsbedrohungen............................................................................................................................. 52 Filterungsmöglichkeiten ............................................................................................................................ 52 Zusammenfassung...................................................................................................................................... 53
Border Gateway Protocol (BGP)...................................................................................................53 Einsatzumgebung....................................................................................................................................... 53 Schematischer Ablauf ................................................................................................................................ 53 Attribute..................................................................................................................................................... 54 Protokolldatenstruktur ............................................................................................................................... 54 Sicherheitsbedrohungen/Filterungsmöglichkeiten ..................................................................................... 54 Zusammenfassung...................................................................................................................................... 55
Open Shortest Path First (OSPF) ..................................................................................................55 Einsatzumgebung....................................................................................................................................... 55 Schematischer Ablauf ................................................................................................................................ 55 Protokolldatenstruktur ............................................................................................................................... 55 Sicherheitsbedrohungen............................................................................................................................. 56 Zusammenfassung...................................................................................................................................... 57
3.9 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) ..........................................................................57 3.9.1 Einsatzumgebung ...........................................................................................................................57 3.9.2 Sicherheitsbedrohungen.................................................................................................................57 3.9.3 Filterungsmöglichkeiten ................................................................................................................57 3.9.4 Zusammenfassung ..........................................................................................................................58 3.10 NETWORK INFORMATION SYSTEM (NIS) ................................................................................................59 3.10.1 Einsatzumgebung ...........................................................................................................................59 3.10.2 Schematischer Ablauf.....................................................................................................................59 3.10.3 Steuerkommandos ..........................................................................................................................60 3.10.4 Protokolldatenstruktur...................................................................................................................60 3.10.5 Sicherheitsbedrohungen.................................................................................................................60
11.09.97
Firewall-Studie
Seite 3
SIEMENS
Ziele der Studie
3.10.6 Filterungsmöglichkeiten ................................................................................................................60 3.10.7 Zusammenfassung ..........................................................................................................................60 3.11 NIS+.......................................................................................................................................................60 3.11.1 Einsatzumgebung ...........................................................................................................................60 3.11.2 Schematischer Ablauf.....................................................................................................................60 3.11.3 Steuerkommandos ..........................................................................................................................61 3.11.4 Sicherheitsbedrohungen und Filterungsmöglichkeiten..................................................................61 3.11.5 Zusammenfassung ..........................................................................................................................62 3.12 FILE TRANSFER PROTOCOL (FTP) ..........................................................................................................62 3.12.1 Einsatzumgebung ...........................................................................................................................62 3.12.2 Schematischer Ablauf.....................................................................................................................62 3.12.3 Steuerkommandos ..........................................................................................................................63 3.12.3.1 3.12.3.2
Datentypen ............................................................................................................................................ 64 Reihenfolge der Operationen in einer FTP-Session .............................................................................. 64
3.12.4 Sicherheitsbedrohungen.................................................................................................................65 3.12.5 Filterungsmöglichkeiten ................................................................................................................66 3.12.6 Zusammenfassung ..........................................................................................................................67 3.13 TRIVIAL FILE TRANSFER PROTOCOL (TFTP) ..........................................................................................67 3.13.1 Einsatzumgebung ...........................................................................................................................67 3.13.2 Sicherheitsbedrohungen.................................................................................................................67 3.13.3 Filterungsmöglichkeiten ................................................................................................................68 3.13.4 Zusammenfassung ..........................................................................................................................68 3.14 FILE SERVICE PROTOCOL (FSP)..............................................................................................................68 3.14.1 Einsatzumgebung ...........................................................................................................................68 3.14.2 Sicherheitsbedrohungen.................................................................................................................68 3.14.3 Filterungsmöglichkeiten ................................................................................................................68 3.14.4 Zusammenfassung ..........................................................................................................................68 3.15 GOPHER ...............................................................................................................................................68 3.15.1 Einsatzumgebung ...........................................................................................................................68 3.15.2 Sicherheitsbedrohungen.................................................................................................................68 3.15.3 Filterungsmöglichkeiten ................................................................................................................69 3.15.4 Zusammenfassung ..........................................................................................................................69 3.16 HYPER TEXT TRANSFER PROTOCOL (HTTP)..........................................................................................69 3.16.1 Einsatzumgebung ...........................................................................................................................69 3.16.2 Steuerkommandos / schematischer Ablauf.....................................................................................69 3.16.3 Protokolldatenstruktur...................................................................................................................69 3.16.4 Sicherheitsbedrohungen.................................................................................................................70 3.16.5 Filterungsmöglichkeiten ................................................................................................................71 3.16.6 Zusammenfassung ..........................................................................................................................71 3.17 SECURE HYPER TEXT TRANSFER PROTOCOL (S-HTTP).........................................................................71 3.17.1 Einsatzumgebung ...........................................................................................................................71 3.17.2 Schematischer Ablauf.....................................................................................................................72 3.17.3 Steuerkommandos ..........................................................................................................................73 3.17.4 Protokolldatenstruktur...................................................................................................................73 3.17.5 Sicherheitsbedrohungen.................................................................................................................73 3.17.6 Interaktion mit Firewalls ...............................................................................................................73 3.17.7 Filterungsmöglichkeiten ................................................................................................................74 3.17.8 Zusammenfassung ..........................................................................................................................74 3.18 SECURE SOCKET LAYER (SSL) ...............................................................................................................74 3.18.1 Einsatzumgebung ...........................................................................................................................74 3.18.2 Schematischer Ablauf.....................................................................................................................74 3.18.3 Steuerkommandos ..........................................................................................................................76 3.18.4 Protokolldatenstruktur...................................................................................................................76 3.18.5 Sicherheitsbedrohungen.................................................................................................................77 3.18.6 Interaktion mit Firewalls ...............................................................................................................77 3.18.7 Filterungsmöglichkeiten ................................................................................................................77 3.18.8 Zusammenfassung ..........................................................................................................................77 3.19 INTERNET RELAY CHAT (IRC)................................................................................................................78 3.19.1 Einsatzumgebung ...........................................................................................................................78 3.19.2 Schematischer Ablauf.....................................................................................................................78 Seite 4
Firewall-Studie
11.09.97
SIEMENS
Internet-Protocol (IP )
3.19.3 Steuerkommandos ..........................................................................................................................78 3.19.4 Sicherheitsbedrohungen.................................................................................................................79 3.19.5 Filterungsmöglichkeiten ................................................................................................................79 3.19.6 Zusammenfassung ..........................................................................................................................80 3.20 LINE PRINTER SPOOLER (LPR).................................................................................................................81 3.20.1 Einsatzumgebung ...........................................................................................................................81 3.20.2 Filterungsmöglichkeiten ................................................................................................................81 3.21 NETWORK FILE SYSTEM (NFS)...............................................................................................................81 3.21.1 Einsatzumgebung ...........................................................................................................................81 3.21.2 Sicherheitsbedrohungen.................................................................................................................81 3.21.3 Filterungsmöglichkeiten ................................................................................................................82 3.21.4 Zusammenfassung ..........................................................................................................................82 3.22 NETWORK TIME PROTOCOL (NTP).........................................................................................................82 3.22.1 Einsatzumgebung ...........................................................................................................................82 3.22.2 Sicherheitsbedrohungen.................................................................................................................82 3.22.3 Filterungsmöglichkeiten ................................................................................................................82 3.22.4 Zusammenfassung ..........................................................................................................................83 3.23 NETWORK NEWS TRANSFER PROTOCOL (NNTP) ...................................................................................83 3.23.1 Einsatzumgebung ...........................................................................................................................83 3.23.2 Schematischer Ablauf.....................................................................................................................83 3.23.3 Steuerkommandos ..........................................................................................................................84 3.23.4 Protokolldatenstruktur...................................................................................................................85 3.23.5 Sicherheitsbedrohungen.................................................................................................................85 3.23.6 Filterungsmöglichkeiten ................................................................................................................85 3.23.7 Zusammenfassung ..........................................................................................................................86 3.24 POST OFFICE PROTOCOL (POP) ..............................................................................................................86 3.24.1 Einsatzumgebung ...........................................................................................................................86 3.24.2 Filterungsmöglichkeiten ................................................................................................................86 3.25 SIMPLE MAIL TRANSFER PROTOCOL (SMTP) .........................................................................................87 3.25.1 Einsatzumgebung ...........................................................................................................................87 3.25.2 Schematischer Ablauf.....................................................................................................................87 3.25.2.1
Nachrichtenformat................................................................................................................................. 87
3.25.3 Steuerkommandos ..........................................................................................................................89 3.25.4 Sicherheitsbedrohungen.................................................................................................................90 3.25.5 Filterungsmöglichkeiten ................................................................................................................91 3.25.6 Zusammenfassung ..........................................................................................................................91 3.26 TELNET ...................................................................................................................................................91 3.26.1 Einsatzumgebung ...........................................................................................................................91 3.26.2 Schematischer Ablauf.....................................................................................................................92 3.26.3 Steuerkommandos ..........................................................................................................................92 3.26.4 Protokolldatenstruktur...................................................................................................................92 3.26.5 Sicherheitsbedrohungen.................................................................................................................93 3.26.6 Filterungsmöglichkeiten ................................................................................................................93 3.26.7 Zusammenfassung ..........................................................................................................................93 3.27 WIDE AREA INFORMATION SERVER (WAIS) ..........................................................................................94 3.27.1 Einsatzumgebung ...........................................................................................................................94 3.27.2 Schematischer Ablauf.....................................................................................................................94 3.27.3 Steuerkommandos ..........................................................................................................................94 3.27.4 Sicherheitsbedrohungen.................................................................................................................94 3.27.5 Filterungsmöglichkeiten ................................................................................................................95 3.27.6 Zusammenfassung ..........................................................................................................................95 3.28 R-DIENSTE ..............................................................................................................................................95 3.28.1 Einsatzumgebung ...........................................................................................................................95 3.28.2 Schematischer Ablauf.....................................................................................................................95 3.28.3 Sicherheitsbedrohungen.................................................................................................................96 3.28.4 Filterungsmöglichkeiten ................................................................................................................97 3.28.5 Zusammenfassung ..........................................................................................................................98 3.29 REMOTE PROCEDURE CALL (RPC) .........................................................................................................98 3.29.1 Einsatzumgebung ...........................................................................................................................98 3.29.2 Protokolldatenstruktur...................................................................................................................98 11.09.97
Firewall-Studie
Seite 5
SIEMENS
Ziele der Studie
3.29.3 Steuerkommandos ..........................................................................................................................98 3.29.4 Filterungsmöglichkeiten ................................................................................................................99 3.29.5 Sicherheitsbedrohungen.................................................................................................................99 3.29.6 Zusammenfassung ..........................................................................................................................99 3.30 UNIX TO UNIX COPY PROTOCOL (UUCP) ...............................................................................................99 3.30.1 Einsatzumgebung ...........................................................................................................................99 3.30.2 Sicherheitsbedrohungen.................................................................................................................99 3.30.3 Filterungsmöglichkeiten ..............................................................................................................100 3.30.4 Zusammenfassung ........................................................................................................................100 3.31 X11 ......................................................................................................................................................100 3.31.1 Einsatzumgebung .........................................................................................................................100 3.31.2 Schematischer Ablauf...................................................................................................................100 3.31.3 Steuerkommandos ........................................................................................................................101 3.31.4 Protokolldatenstruktur.................................................................................................................101 3.31.5 Sicherheitsbedrohungen...............................................................................................................102 3.31.6 Filterungsmöglichkeiten ..............................................................................................................102 3.31.7 Zusammenfassung ........................................................................................................................103 3.31.8 Schutzmechanismen für X-Verbindungen über eine Firewall......................................................103 3.31.9 Verteilte Anwendungen unter X11 [Pfaff 96] ..............................................................................104 3.31.9.1 3.31.9.2 3.31.9.3 3.31.9.4
3.31.10 3.31.10.1 3.31.10.2 3.31.10.3 3.31.10.4
3.31.11 3.31.11.1 3.31.11.2 3.31.11.3 3.31.11.4
Verteilte Anwendungen....................................................................................................................... 104 Sicherheitserfordernisse ...................................................................................................................... 105 Sicherheitsdienste................................................................................................................................ 105 Empfehlungen für verteilte X-Anwendungen in Bezug auf Firewalls ................................................. 106
Videoübertragung ....................................................................................................................106 Schematischer Aufbau......................................................................................................................... 106 Sicherheitsbedrohungen ...................................................................................................................... 107 Filterungsmöglichkeiten ...................................................................................................................... 107 Schutzmechanismen ............................................................................................................................ 107
Sicherer Dokumentenserver .....................................................................................................108 Schematischer Aufbau......................................................................................................................... 108 Sicherheitsbedrohungen ...................................................................................................................... 108 Filterungsmöglichkeiten ...................................................................................................................... 108 Schutzmechanismen ............................................................................................................................ 108
3.32 MUTIPURPOSE INTERNET MAIL EXTENSIONS (MIME)..........................................................................109 3.32.1 Einsatzumgebung .........................................................................................................................109 3.32.2 Protokolldatenstruktur.................................................................................................................109 3.32.3 Sicherheitsbedrohungen...............................................................................................................110 3.32.4 Filterungsmöglichkeiten ..............................................................................................................110 3.32.5 Zusammenfassung ........................................................................................................................110 3.33 JAVA .....................................................................................................................................................110 3.33.1 Java Programmiersprache...........................................................................................................111 3.33.2 Java Virtual Machine...................................................................................................................111 3.33.3 Ausführungsumgebung.................................................................................................................111 3.33.4 Sicherheitsbedrohungen...............................................................................................................111 3.33.5 Das Java Sicherheitsmodell .........................................................................................................112 3.33.6 Java und Firewalls.......................................................................................................................113 3.33.7 Ein Angriff auf Firewalls mittels Java .........................................................................................113 3.34 ACTIVEX ..............................................................................................................................................114 3.34.1 Sicherheitsbedrohungen...............................................................................................................114 3.34.2 Sicherheitsmerkmale ....................................................................................................................114 3.34.2.1 3.34.2.2
ActiveX im Internet............................................................................................................................. 114 ActiveX im Intranet............................................................................................................................. 114
3.34.3 Filterungsmöglichkeiten ..............................................................................................................115 3.35 ÜBERSICHTSMATRIX - BEDROHUNGEN / GEGENMAßNAHMEN ..............................................................116 4
FIREWALL - ARCHITEKTUREN .........................................................................................................120 4.1 PAKETFILTER ........................................................................................................................................120 4.1.1 Statische Paketfilter .....................................................................................................................120 4.1.2 Dynamische oder kontextabhängige Paketfilter ..........................................................................122 4.2 APPLIKATIONSFILTER ODER BASTION-HOST .........................................................................................122 4.2.1 Dedizierte Application-Proxies....................................................................................................124
Seite 6
Firewall-Studie
11.09.97
SIEMENS
Internet-Protocol (IP )
4.2.2 Circuit-Level-Gateways ...............................................................................................................124 4.3 ÜBERWACHTER APPLIKATIONSFILTER (SCREENED SUBNET) ................................................................124 4.4 SCHUTZKONZEPT FÜR BEHÖRDLICHE NETZE .........................................................................................126 4.5 ÜBERSICHT VOR- UND NACHTEILE DER EINZELNEN KONZEPTE ............................................................126 4.6 ZUSAMMENFASSENDE EMPFEHLUNG FÜR EIN KONZEPT .......................................................................126 5
SICHERHEITSANFORDERUNGEN AN INTERNET-FIREWALLS ................................................128 5.1 BISHERIGE SICHERHEITSANFORDERUNGEN AN INTERNET-FIREWALLS DES BSI ....................................128 5.1.1 Forderungen zur Abwehr von Angriffen auf die Firewall-Anordnung ........................................128 5.1.2 Forderungen zur Abwehr von Angriffen aus dem Internet auf das zu sichernde Netz.................129 5.1.2.1 5.1.2.2
Obligatorische Forderungen..................................................................................................................... 129 Zusätzliche Forderung bei Verwendung von Filtern auf der Ebene drei (IP) und vier (TCP, UDP) ....... 130
5.2 ZUSÄTZLICHE SICHERHEITSANFORDERUNGEN AN INTERNET-FIREWALLS .............................................131 5.2.1 Paket-Filterung / Regelimplementierung.....................................................................................131 5.2.2 Abwendung von Standardangriffen..............................................................................................133 5.2.3 Administration .............................................................................................................................134 5.2.4 Verschlüsselung/Authentisierung.................................................................................................134 5.2.5 Sonstige Anfordungen ..................................................................................................................135 5.3 ZUSÄTZLICHE FUNKTIONEN DER PRODUKTE .........................................................................................135 5.3.1 Filterung und Proxyauswahl........................................................................................................135 5.3.2 Protokollierung / Alarmierung.....................................................................................................136 5.3.3 Plattform ......................................................................................................................................136 5.3.4 Authentisierung ............................................................................................................................136 5.3.5 Sonstige Merkmale.......................................................................................................................136 5.4 ZUKÜNFTIGE SICHERHEITSANFORDERUNGEN AN INTERNET-FIREWALLS ..............................................136 5.4.1 Ausführbarer Code.......................................................................................................................136 5.4.2 VPN / Sicherungsdienste / Key Management...............................................................................137 5.4.3 Sonstige Anforderungen...............................................................................................................137 6
TEST AUSGEWÄHLTER FIREWALLPRODUKTE ...........................................................................138 6.1 TEST AUF ERFÜLLUNG DER SICHERHEITSANFORDERUNGEN..................................................................138 6.1.1 AltaVista Firewall 97 der Firma Digital Equipment Corporation (D) ........................................139 6.1.2 Eagle Version 4.0 der Firma Raptor (D)+(P) .............................................................................142 6.1.3 FireWall-1 Version 3.0 der Firma Checkpoint (D)+(P) ..............................................................146 6.1.4 Gauntlet Version 3.2 der Firma TIS (D)+(P) ..............................................................................150 6.1.5 KarlBridge Version 2.0 der Firma KarlNet (D)...........................................................................154 6.1.6 KryptoWall Version 2.0 der Firma KryptoKom (D) ....................................................................157 6.1.7 PIX Firewall Version Rev 4.0 der Firma Cisco Systems (D) .......................................................161 6.1.8 Sidewinder Version 3.1 der Firma Secure Computing Corporation (D) .....................................165 6.1.9 TIS Internet Firewall Toolkit Version 2.0 der Firma Trusted Information Systems (D)..............168 6.1.10 Testübersicht ................................................................................................................................171 6.2 PENETRATIONSTEST ..............................................................................................................................182 6.2.1 Analysetopologie..........................................................................................................................182 6.2.2 Beschreibung der Angriffe ...........................................................................................................183 6.2.2.1 Manuell durchgeführte Angriffe .............................................................................................................. 183 6.2.2.2 Angriffe des ISS-Safesuite....................................................................................................................... 184 6.2.2.2.1 Angriffe des ISS-Safesuite auf die Firewall ...................................................................................... 184 6.2.2.2.2 Angriffe des ISS-Safesuite auf einen Host hinter der Firewall.......................................................... 184
6.2.3 6.2.3.1 6.2.3.2 6.2.3.3 6.2.3.4
6.3
Ergebnisse des Penetrationstests .................................................................................................185 Eagle Version 4.0 der Firma Raptor Systems .......................................................................................... 185 FireWall-1 Version 3.0 der Firma Checkpoint ........................................................................................ 187 Gauntlet Version 3.2 der Firma Trusted Information Systems................................................................. 189 Analyse-Übersicht.................................................................................................................................... 191
PREIS - LEISTUNGSÜBERSICHT ..............................................................................................................193
7
ABKÜRZUNGSVERZEICHNIS..............................................................................................................194
8
LITERATUR..............................................................................................................................................197
9
ANHANG....................................................................................................................................................199
11.09.97
Firewall-Studie
Seite 7
SIEMENS
Ziele der Studie
ABBILDUNGSVERZEICHNIS ABBILDUNG 1:DER TCP / IP- PROTOKOLLSTACK .............................................................................................11 ABBILDUNG 2: DAS IP-ADREßFORMAT .............................................................................................................13 ABBILDUNG 3: DIE IP-PRIMITIVE ......................................................................................................................14 ABBILDUNG 4: DAS IP-DATAGRAMM ...............................................................................................................15 ABBILDUNG 5: DAS FORMAT DES IPV6-HEADERS ............................................................................................20 ABBILDUNG 6: AUTHENTICATION HEADER DES IPV6-PROTOKOLLS..................................................................20 ABBILDUNG 7: ENCAPSULATING SECURITY PAYLOAD DES IPV6-PROTOKOLLS .................................................21 ABBILDUNG 8: KAPSELUNG VON IPV6 IN IPV6 .................................................................................................25 ABBILDUNG 9: X.509 SIMPLE AUTHENTICATION ..............................................................................................26 ABBILDUNG 10: X.509 STRONG AUTHENTICATION ...........................................................................................26 ABBILDUNG 11: X.509 KEY MANAGEMENT .....................................................................................................27 ABBILDUNG 12: X.509 ZERTIFIZIERUNGSHIERARCHIE ......................................................................................27 ABBILDUNG 13: VPN MIT TLS/SSL UND IPSEC ...............................................................................................29 ABBILDUNG 14: KASKADIERTES INTRANET MIT TLS/SSL UND IPSEC ..............................................................30 ABBILDUNG 15: KAPSELUNG VON NUTZDATEN IN SSL UND IPSEC ..................................................................30 ABBILDUNG 16: ICMP-DIENSTE .......................................................................................................................33 ABBILDUNG 17: DAS FORMAT EINER ICMP-NACHRICHT .................................................................................33 ABBILDUNG 18: ABLAUF EINER TCP-SITZUNG .................................................................................................36 ABBILDUNG 19: DAS TCP-SEGMENT (PDU) ....................................................................................................38 ABBILDUNG 20: UDP-MULTIPLEXING ..............................................................................................................41 ABBILDUNG 21: FORMAT EINER UDP-NACHRICHT ...........................................................................................42 ABBILDUNG 22: KONZEPT VON DNS ................................................................................................................44 ABBILDUNG 23: STRUKTUR DER NAMENSAUFLÖSUNG......................................................................................45 ABBILDUNG 24: FORMAT DER RESOURCE RECORDS .........................................................................................46 ABBILDUNG 25: FORMAT DER DNS-NACHRICHTEN..........................................................................................46 ABBILDUNG 26: DAS RIP-NACHRICHTENFORMAT ............................................................................................52 ABBILDUNG 27: HEADER DER OSPF-DATENPAKETE ........................................................................................56 ABBILDUNG 28: SYSTEM-LISTEN IN NIS+.........................................................................................................61 ABBILDUNG 29: DAS FTP-MODELL ..................................................................................................................62 ABBILDUNG 30: FTP-THIRD-PARTY-TRANSFER ...............................................................................................63 ABBILDUNG 31: INTEGRATION VON SSL IM PROTOKOLLSTACK AM BEISPIEL HTTP ........................................75 ABBILDUNG 32: PROTOKOLLÜBERSICHT SSLV3 MIT SERVERAUTHENTISIERUNG .............................................76 ABBILDUNG 33: SSL-DATAGRAMM-STRUKTUR................................................................................................76 ABBILDUNG 34: DIE PUSH-METHODE ...............................................................................................................84 ABBILDUNG 35: DIE PULL-METHODE ...............................................................................................................84 ABBILDUNG 36: DAS SMTP-MODELL ..............................................................................................................87 ABBILDUNG 37: EINE SMTP-MAIL-TRANSAKTION ...........................................................................................89 ABBILDUNG 38: AUSHANDLUNG VON OPTIONEN IN TELNET .............................................................................92 ABBILDUNG 39: FORMAT DER TELNET-BEFEHLE ..............................................................................................93 ABBILDUNG 40: WAIS-KOMPONENTEN ...........................................................................................................94 ABBILDUNG 41: KONZEPT VON X11 ...............................................................................................................101 ABBILDUNG 42: NACHRICHTENFORMAT VON X11 ..........................................................................................101 ABBILDUNG 43: X-APPLICATION-LEVEL-PROXY ............................................................................................103 ABBILDUNG 44: APPLICATION SHARING SZENARIO .........................................................................................104 ABBILDUNG 45 : SCHEMA FÜR VIDEOKONFERENZEN ......................................................................................107 ABBILDUNG 46: SICHERER DOKUMENTENSERVER ..........................................................................................108 ABBILDUNG 47: PAKETFILTER ........................................................................................................................121 ABBILDUNG 48: BASTION-HOST .....................................................................................................................123 ABBILDUNG 49: ÜBERWACHTER BASTION-HOST ............................................................................................125 ABBILDUNG 50: ANALYSE-LABOR ..................................................................................................................182
Seite 8
Firewall-Studie
11.09.97
SIEMENS
Internet-Protocol (IP )
1 Ziele der Studie Die vorliegende Studie "Gesicherte Verbindung von Computernetzen mit Hilfe einer Firewall" entstand im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) bei der Zentralabteilung Technik der Siemens AG in München. Grundlage war der Vertrag zwischen dem BSI und der Siemens AG vom 06.03.1997. Der Auftrag umfaßte drei Arbeitspakete: • Technische Beschreibung und Bedrohungsanalyse der wichtigsten Internetprotokolle inklusive Empfehlung, wie die identifizierten Bedrohungen durch den Einsatz einer Firewall verhindert werden können. • Untersuchung einer Auswahl derzeit erhältlicher Produkte auf Erfüllung der im ersten Teil und der vom BSI identifizierten notwendigen Leistungsmerkmale. • Angabe von zukünftig notwendigen Leistungsmerkmalen im Hinblick auf den Einsatz von IPv6 und abschließende Preis-Leistungsübersicht. Ein besonderer Schwerpunkt wurde gelegt auf die Aspekte: • IPv6 in Verbindung mit Firewalls und • Bedrohungen durch ausführbaren Code und
11.09.97
Firewall-Studie
Seite 9
SIEMENS
Einführung in die Firewall-Problematik
2 Einführung in die Firewall-Problematik Eine Firewall ist eine Schutzmaßnahme, um den Übergang zwischen zwei Rechnernetzen abzusichern. Durch technische und administrative Maßnahmen muß zugleich dafür gesorgt werden, daß jede Kommunikation zwischen den beiden Netzen über die Firewall geführt wird. Ziel dieser Maßnahme ist es im Standardfall, das interne Netz (normalerweise das Netz des Betreibers, der auch die Firewall installiert) vor Angriffen aus dem externen Netz zu schützen sowie unerwünschten Datenabfluß vom internen in das externe Netz zu verhindern. Extern steht dabei im allgemeinen für die Kommunikationszugänge in den WAN-Bereich [Munzert, Wolff 96]. Es kann aber auch bei Intranets für die weniger geschützten Bereiche innerhalb eines Unternehmensoder Behördennetzes stehen. Bei einem Testnetz kann eine Firewall auch das äußere Netz vor dem inneren Netz schützen. Der Schutz des inneren Netzes wird erreicht, indem unsichere Dienste durch die Firewall (sowohl von außen nach innen als auch umgekehrt, falls gewünscht) oder aber durch zusätzliche Maßnahmen abgesichert werden (z. B. Verschlüsselung). Zugriffskontrolle und Auditing sorgen zusätzlich dafür, daß das Prinzip der minimalen Rechte durchgesetzt wird und Angriffe durch entsprechende Protokollierung erkannt werden [Ellermann 93]. Firewall-Systeme sollen folgende Anforderungen erfüllen: • • •
• •
Jeglicher Datenverkehr von innen nach außen (und umgekehrt) läuft über die Firewall. Nur autorisierter Verkehr darf die Firewall passieren. Welcher Verkehr autorisiert ist, wird in einer Sicherheitspolitik definiert. Die Firewall selbst ist gegen Angriffe weitestgehend resistent. Daher darf nach Möglichkeit nur fehlerfreie Software eingesetzt werden. Da jedes Programm aber potentiell Sicherheitslücken enthalten kann, dürfen nur die unbedingt notwendigen Programme auf der Firewall installiert werden. Dies bedeutet insbesondere, daß auf der Firewall weder graphische Oberflächen zur Verfügung stehen, noch daß gewöhnliche Benutzer Login-Möglichkeiten dort haben. Alles was nicht ausdrücklich erlaubt ist, wird von der Firewall abgewiesen. Die Firewall darf nur über einen vertrauenswürdigen Pfad administrierbar sein.
Seite 10
Firewall-Studie
11.09.97
SIEMENS
Internet-Protocol (IP )
3 Bedrohungsanalyse der Protokolle Im folgenden werden die wichtigsten Protokolle der Vermittlungs- und Transportschicht bezüglich Einsatzumgebung, schematischem Ablauf, Steuerkommandos, Protokolldatenstruktur, Sicherheitsbedrohungen und Filterungsmöglichkeiten durch Firewalls beschrieben. Die für das jeweilige Protokoll wichtigsten Bedrohungen und die möglichen Gegenmaßnahmen sind am Ende der Beschreibung tabellarisch zusammengefaßt. Abbildung 1 zeigt eine Übersicht des Protokollstacks auf Basis TCP/IP. Nach den Vermittlungs- und Transportprotokollen werden Routing- und Netzmanagement-Protokolle behandelt. Anschließend werden die übrigen Anwendungsprotokolle untersucht.
Applikation
Applikation
Applikation
TCP
UDP
Anwendungsschicht
ICMP
Transportschicht
IP Vermittlungsschicht
Übertragungs- und physikalische Schichten Abbildung 1:Der TCP / IP- Protokollstack
3.1 Internet-Protocol (IP2) 3.1.1 Einsatzumgebung Das Internet-Protokoll ist ein verbindungsloses Protokoll und erlaubt somit den Austausch von Daten zwischen zwei Knoten3 ohne vorherigen Verbindungsaufbau. IP macht die darunterliegenden Schichten für die Transportschicht unsichtbar. Dies ermöglicht den Anschluß mehrerer verschiedener Typen von Netzen an ein IP-Gateway. IP setzt nicht voraus, daß das darunterliegende Netz Fehlererkennung ausführt. Ferner verfügt es nicht über Verläßlichkeits- oder Flußsteuerungsmechanismen. Die meisten dieser Probleme gibt IP an die nächsthöhere Schicht - die Transportschicht - ab. 3.1.2 Dienste von IP IP bietet den darüberliegenden Schichten folgende Dienste an: Check-Routine für Internet-Header. Erhält ein Knoten ein Datagramm, so prüft er anhand des Headers den Datentyp. Handelt es sich um ein Internet-Datagramm, so reicht er das Datagramm zur Internet-HeaderCheck-Routine weiter. Andernfalls wird das Datagramm verworfen. Diese testet den Header nach folgenden Kriterien: 2
IP steht hier für Internet Protocol Version 4 Sofern eine genauere Unterscheidung nicht notwendig ist, werden im folgenden Rechner, IP-Module, Gateways, Hosts, etc. als Knoten bezeichnet.
3
11.09.97
Firewall-Studie
Seite 11
SIEMENS
• • • • •
Bedrohungsanalyse der Protokolle
Ist die Länge des IP-Headers korrekt? Ist die IP-Versionsnummer korrekt? Ist die IP-Nachrichtenlänge gültig? Ist die IP-Header-Prüfsumme gültig? Ist der Wert im Time-to-Live Feld ungleich Null?
Werden die Tests nicht bestanden, so wird das Datagramm verworfen. Andernfalls wird die IP-Zieladresse untersucht, um festzustellen, ob das Datagramm für diesen oder für einen anderen Knoten bestimmt ist. Ist es nicht für diesen Knoten bestimmt, so wird es zur IP-Forwarding-Routine weitergereicht. IP-Source-Routing. Source-Routing ermöglicht einem Protokoll höherer Schicht, die Routingmethode zu bestimmen. Das Protokoll höherer Schicht hat die Möglichkeit, der IP-Schicht eine Liste von IP-Adressen zu übergeben. Diese Liste enthält die Zwischenknoten (auch Hops genannt), die während eines Routingvorganges durchlaufen werden müssen. Die letzte Adresse auf der Liste ist die Zieladresse des letzten Hops vor dem Zielknoten. Erhält die Vermittlungsschicht ein Datagramm, so benutzt es die Adresse im Source-RoutingFeld, um den nächsten Zwischenknoten zu bestimmen. Aus Sicherheitssicht soll IP-Source-Routing nicht verwendet werden, da ansonsten ein Angreifer über Pakete jedem Router mitteilen kann, auf welche Weise er zu routen hat. IP-Default-Routing. Das Gegenteil zu Source-Routing ist Default-Routing, bei dem dem Router überlassen wird, auf welchem Weg er ein Paket routen möchte. Routing-Operations. Ein IP-Knoten trifft Routing-Entscheidungen anhand der sogenannten Routing-Liste. Befindet sich der Zielknoten in einem anderen Netz, so muß der IP-Knoten entscheiden, wie zu dem anderen Netz geroutet werden soll. Jeder Knoten unterhält dazu eine Routing-Tabelle, die den nächsten Knoten auf dem Weg zum Zielknoten bestimmt. Diese Routing-Tabellen können statisch oder dynamisch sein. IP ermöglicht zwei Arten des Routings: loose routing und strict routing (siehe Abschnitt 3.8). Route-Recording. Bei dieser Option muß jeder Knoten, der ein Datagramm empfängt, seine Adresse der Routing-Tabelle hinzufügen. Somit kann der Weg eines Datagramms zurückverfolgt werden. Time-Stamp. Überquert ein Datagramm einen Knoten, so kann es mit einem Zeitstempel versehen werden. Somit kann der Netzmanager überprüfen, wie lange ein Knoten zur Bearbeitung des Datagramms benötigt hat. Fragmentation and Reassembly. Ist ein IP-Paket größer als der maximal transfer unit (MTU)-Eintrag, des Netzes, das das Paket überquert, so wird dieses Paket fragmentiert und am Ende wieder in der ursprünglichen Reihenfolge zusammengesetzt. 3.1.3 Adressen und Adreßtabellen Das Format der IP-Adressen der IP-Version 4 ist in Abbildung 2 [Black 95] dargestellt. Es werden 32-bit Adressen verwendet, um einen Knoten und das Netz, an das der Knoten angeschlossen ist, zu identifizieren. Somit ist IP-Adresse = Netzadresse + Knotenadresse. IP-Adressen besitzen vier Formate (Klasse A, Klasse B, Klasse C, Klasse D). Diese Klassen unterscheiden sich in der Anzahl der Hosts, die man an dieses Netz anschließen kann: Klasse A: 224 Knoten Klasse B: 216 Knoten Klasse C: 28 Knoten Klasse D ist für multicasting reserviert
Seite 12
Firewall-Studie
11.09.97
SIEMENS
Internet-Protocol (IP ) Class A 0
Local address (24 bits)
Network (7 bits)
Class B 10
Local address (16 bits)
Network (14 bits)
Class C 110
Network (21 bits)
Local address (8 bits)
Class D (Multicast format) 1110
Multicast address (28 bits)
Future format 11110
Future use
Abbildung 2: Das IP-Adreßformat Ein Netzknoten kann mehrere IP-Adressen haben. Das Internet Activities Board (IAB) hat in [RFC 1213] die Definition einer IP-Adreßtabelle veröffentlicht (siehe Tabelle 1 [Black 95]). Sie besteht aus fünf Spalten und beliebig vielen Zeilen. Jede Zeile gehört zu einer IP-Adresse eines Knotens. • • • • •
Adresse beinhaltet die IP-Adresse des Interfaces dieser Zeile. If-Index beinhaltet die Interfacenummer (I/O-Portnummer) der Verbindung zum Subnetz dieser Zeile. Netzmaske beschreibt die Subnetzmaske, die zur IP-Adresse der ersten Spalte gehört. Broadcast-Adresse beinhaltet den Wert des am wenigsten signifikanten Bits in der IP-BroadcastAdresse. maximale Größe eines Datagramms stellt die maximale Größe des Datagramms dar, die von diesem Knoten verarbeitet werden kann.
IP-Adreßtabelle
Adresse
If-Index
Netzmaske
BroadcastAdresse
maximale Größe des Datagramms
Adresse Eintrag 1 Adresse Eintrag 2 Adresse Eintrag n Tabelle 1: IP-Adreß-Tabelle 3.1.4 Schematischer Ablauf IP kommuniziert mit der Transport- und der Übertragungsschicht nach dem Prinzip der Primitive. Im folgenden werden die Servicedefinitionen und -Primitive von IP zu ULP (upper layer protocol) und von IP zu SNP (subnet protocol) beschrieben.
11.09.97
Firewall-Studie
Seite 13
SIEMENS
Bedrohungsanalyse der Protokolle
3.1.4.1 IP/ULP Primitive IP und ULP bieten gegenseitig ihre Dienste über folgende Primitive an: Das übertragende ULP verwendet das Primitiv SEND, um Daten an IP zu übermitteln. Im Gegensatz dazu verwendet IP das Primitiv DELIVER, um dem Ziel-ULP Daten zu übertragen. Diese Dienstedefinition mit Primitiven ist sehr abstrakt gehalten, um Anpassungen für das jeweilige Betriebssystem des Knotens zu ermöglichen. Die Beziehung zwischen IP und ULP ist in Abbildung 3 [Black 95] dargestellt. Dabei sendet Knoten A Daten an Knoten B. Die Pfeile verlaufen umgekehrt, falls B Daten an A sendet. Die Parameter, die mit den Primitiven verbunden sind, informieren das ULP und IP über die Operation, die das ULP verlangt (SEND) bzw. die von IP ausgeführt wird (RECV).
Abbildung 3: Die IP-Primitive 3.1.4.2 IP/SNP Primitive Die Primitive zwischen IP und dem Subnetwork Access Protocol (SNAP) sind ähnlich zu den IP/ULP Primitiven. Wie Abbildung 3 zeigt, sind auch hier zwei Primitive für die IP/SNP-Operation involviert. Das Primitiv SNP_SEND wird von IP benutzt, um einen Dienst von SNP zu initiieren; das Primitiv SNP_DELIVER wird von SNP benutzt, um ein Datagramm an IP zu liefern.
Seite 14
Firewall-Studie
11.09.97
SIEMENS
Internet-Protocol (IP )
3.1.5 Protokolldatenstruktur Die Felder eines IP-Datagramms sind in Abbildung 4 [Black 95] dargestellt. Version identifiziert die Version von IP. Header Length beinhaltet 4 Bits, die die Länge des Datagramm-Headers anzeigen. Die Länge wird in 32Bit-Worten gemessen. Üblicherweise besitzt ein Header ohne Quality of Service (QoS)-Option 20 Oktets4. In diesem Fall ist der Wert im Längenfeld 5. Mit dem Feld Type of Service (ToS) kann man mehrere QoS-Funktionen identifizieren, und zwar transit delay, throughput, precedence und reliability [Black 95]. Total Length spezifiziert die Gesamtlänge des IP-Datagramms. Es wird in Oktets gemessen und beinhaltet die Länge des Headers und der Daten. IP subtrahiert das Header Length-Feld vom Total Length-Feld, um die Länge der Daten zu berechnen. Über die Headerfelder Identifier, Flags und Fragmentation Offset steuert IP die DatagrammFragmentierung und -Reassemblierung. Das Feld Identifier identifiziert Fragmente des Datagramms eindeutig. Das Feld Flag zeigt an, ob das Datagramm fragmentiert werden kann. Das Feld Fragmentation Offset gibt die relative Position des Fragments zum Originaldatagramm an. Der Time-to-Live (TTL)-Parameter enthält die Anzahl der Router, die noch überquert werden dürfen. Bei jeder Routerüberquerung wird dieser Wert um eins dekrementiert. Ist der Wert 0, so wird das Paket entweder vom Router akzeptiert oder verworfen. Das Feld Protocol identifiziert das über dem Internet-Protokoll liegende Protokoll, welches das Datagramm am Zielknoten empfängt. Mit der Header Checksum kann man eine Veränderung im Header erkennen. Allerdings wird diese Überprüfung nicht auf die Nutzdaten angewendet. Der zu verwendende Algorithmus ist nicht spezifiziert und kann vom darüberliegenden Protokoll gewählt werden. Ein IP-Datagramm beinhaltet zwei Adressen. Diese heißen Source Address und Destination Address und sind die Internetadressen des Quell- bzw. Zielknotens. Das Feld Options identifiziert mehrere zusätzliche Dienste. Padding wird benutzt, um sicherzustellen, daß die Länge des Datagramm-Headers ein ganzzahliges Vielfaches von 32 Bit beträgt. Schließlich beinhaltet das Feld Data die eigentlichen Benutzerdaten. IP schreibt vor, daß die Länge des Datenfelds und des Headers zusammen 65.535 Oktets nicht überschreitet (siehe Abschnitt Ping-to-Death (3.3)). Header Length (4)
Version (4)5 Type of Service (8) Total Length (16) Identifier (16) Flags (3)
Fragment Offset (13) Time to Live (8) Protocol (8) Header Checksum (16) Source Address (32) Destination Address (32) Options and Padding (variabel) Data (variabel)
Abbildung 4: Das IP-Datagramm 3.1.6 Sicherheitsbedrohungen Angriff: IP-Spoofing Bedrohung: Maskerade, Eindringen Eine Gefahr, die dem Internet-Protokoll droht, ist die des IP-Spoofings [CERT-Advisory CA-95:01]. Unter IP-Spoofing versteht man das Fälschen der Senderadresse in einem IP-Paket. Dabei werden zunächst mittels Sniffing-Tools IP-Adressen ermittelt, deren zugehörige Knoten berechtigt sind, gewisse Dienste zu nutzen. Wird bei der Prüfung, ob jemand berechtigt ist, diesen Dienst zu nutzen, als einziges Authentisierungsmerkmal die IP-Adresse benutzt, so führt eine Fälschung der Senderadresse zum Erfolg. IP-Spoofing bildet somit
4
Oktets = Bytes ist die Anzahl der Bits im Feld
5(n)
11.09.97
Firewall-Studie
Seite 15
SIEMENS
Bedrohungsanalyse der Protokolle
die Grundlage zahlreicher Angriffe. IP-Spoofing kann durch starke Authentisierungsmechanismen6 verhindert werden. Zum Beispiel sind folgende Dienste durch IP-Spoofing verwundbar: • • •
RPC & NFS BSD UNIX “r” - Befehle X Windows
Auf IP-Spoofing bauen die Angriffe Hijacking (siehe Abschnitt 3.4) und SYN-Flooding (siehe Abschnitt 3.4) auf. Angriff: IP-Source-Routing Bedrohung: Maskerade Beim IP-Source-Routing bestimmt der Quellknoten die Route eines Pakets im Internet. Der Zielknoten benutzt für seine Antwort die angegebene Route für den Rückweg. Der Quellknoten kann somit Antworten auf einen beliebigen Knoten umleiten. Jeder beliebige Zwischenknoten kann weitere für den Zielhost nicht sichtbare Umleitungen vornehmen. Ein Angreifer kann in diesem Fall jede gewünschte IP-Source-Adresse vorspiegeln [Bellovin 89]. Daher sollten alle Pakete, die IP-Source-Routing-Informationen enthalten, abgewiesen werden. Angriff: Fragmentation Attack Bedrohung: Eindringen Der Fragmentierungsangriff zielt darauf ab, die Implementierung der IP-Fragmentierung derart auszunutzen, daß Filterregeln von Paketfiltern nicht auf die fragmentierten IP-Pakete passen und somit diese Fragmente durchgelassen werden. Im [RFC 1858] wird der Tiny Fragment Attack beschrieben. Dabei zerlegt der Angreifer seine Nutzdaten (z.B. TCP-Pakete) in sehr kleine Fragmente. Dadurch wird z.B. ein TCP-Header auf mehrere Fragmente aufgeteilt und kann daher von statischen Paketfiltern nicht analysiert werden. Eine Filterung aufgrund von Regeln, die z.B. den TCP-Header betreffen, ist nicht mehr möglich. Als Gegenmaßnahme sollten Implementierungen von Paketfiltern verwendet werden, bei denen die Länge des Tiny Fragments nicht verändert werden kann. Ein zweiter Angriff, der die IP-Fragmentierung ausnutzt, ist der sogenannte Overlapping Fragment Attack [RFC 1858]. Die derzeitige Internet-Protokoll-Spezifikation [RFC 791] beschreibt einen Reassemblierungsalgorithmus, der neue Fragmente produziert und dabei jeden überlappenden Teil der zuvor erhaltenen Fragmente überschreibt. Wird ein solcher Algorithmus angewendet, so könnte ein Angreifer eine Folge von Paketen konstruieren, in denen das erste Fragment (mit einem Offset der Länge Null) harmlose Daten beinhaltet (und dadurch von einem Paketfilter weitergeleitet werden kann). Ein beliebiges nachfolgendes Paket mit einem Offset, der größer als Null ist, könnte TCP-Header-Informationen (z.B. destination port) überlappen. Diese würden durch den Algorithmus modifiziert (überschrieben) werden. Dieses zweite Paket wird von vielen Paketfiltern nicht gefiltert. Gegenmaßnahme hierzu ist, Paketfilter zu verwenden, die ein Minimum an Fragment-Offset für Fragmente verlangen. Angriff: Tunneln Bedrohung: Eindringen Durch die Fragmentierung von IP-Paketen existiert wenig Information, auf die man eine Filterentscheidung basieren kann, denn bis auf das erste Fragment besitzen die Fragmente keine Portnummern. Besitzt ein Angreifer einen Komplizen im zu schützenden Bereich, so können Fragmente ohne Portnummern zum Tunneln einer Firewall verwendet werden. Das erste Fragment beinhaltet zwar die Portnummer und kann entsprechend gefiltert werden. Wird dies nicht weitergeleitet, so ist das Paket im Inneren unvollständig, und die übrigen Fragmente werden schließlich vom Zielknoten verworfen. Ist der Zielknoten allerdings im Besitz eines Komplizen des Angreifers, so kann dieser die Fragmente zusammensetzen. Analog kann der Komplize im zu schützenden Bereich gefälschte Fragmente ohne Portnummern erstellen, die vom externen Komplizen auf einer äußeren Maschine zusammengesetzt werden können. Um diesen drohenden Infomationsverlust abzuwenden, sollten also Fragmente ohne Portnummern von innen nach außen und umgekehrt bereits an der Firewall 6
Es wird häufig unterschieden zwischen einfacher und starker Authentisierung. Bei einfacher Authentisierung wird z.B. ein Paßwort im Klartext übertragen und ist somit nicht vor Mithören geschützt. Bei starker Authentisierung besteht ein Schutz gegen Abhören und spätere Maskerade z.B. durch Einmalpaßwörter oder Challenge and Response Verfahren.
Seite 16
Firewall-Studie
11.09.97
SIEMENS
Internet Protocol Version 6 (IPv6)
verworfen oder dort zusammengesetzt und überprüft werden. Dies ist mit zustandsabhängigen Filtern bzw. Paketfiltern, die Kontext speichern können, realisierbar. 3.1.7 Filterungsmöglichkeiten Um IP-Spoofing abzuwehren, sollten Paketfilter von außen kommende Pakete, die interne Adressen als Absender angegeben haben, abweisen. Ferner sollten Dienste, deren Authentisierungskriterium IP-Adressen sind, gesperrt oder restriktiv behandelt werden. Mit der derzeitigen Implementierung des Internet-Protokolls ist es nicht möglich, Pakete vollständig zu eliminieren, die durch IP-Spoofing entstanden sind. Die Bedrohung durch IP-Spoofing kann lediglich reduziert werden. Ausgehende Pakete, die als Quelladresse keine interne Adresse besitzen, sollten ebenfalls abgewiesen werden [Cheswick, Bellovin 94]. Somit wäre z.B. eine Zurückverfolgung von TCP-SYN-Attacken möglich, falls alle Netzprovider dies befolgten. 3.1.8 Zusammenfassung Protokoll IP
Angriff IP-Spoofing
Bedrohung Maskerade, Eindringen
IP
IP-Source Routing
Maskerade
IP
IP-Tiny Fragment
Eindringen
IP
IP-Overlapping Fragment
Eindringen
IP
Tunneln der Firewall
Informationsverlust
Gegenmaßnahme Abweisen von externen Datagrammen mit internen IP-Adressen. Abweisen von ausgehenden Paketen, die als Quelladresse keine interne Adresse besitzen. Blocken von externen Datagrammen mit internen IP-Adressen, Blocken von IP-Source-RoutingInformationen Paketfilter verwenden, die eine Mindestgröße an Fragmentlänge verlangen Paketfilter verwenden, die ein Minimum für ein Fragment-Offset vorschreiben Verwenden von dynamischen Filtern
3.2 Internet Protocol Version 6 (IPv6) 3.2.1 Protokollbeschreibung 3.2.1.1 Einsatzumgebung IPv6 (Internet Protocol Version 6) ist die neue Version des Internet Protokolls und soll IPv4 ablösen. Bewährte Funktionen von IPv4 wurden übernommen und nicht praktikable Funktionen in IPv6 nicht übernommen oder durch neue ersetzt. Die Änderungen zu IPv4 lassen sich in folgende Kategorien einteilen: 3.2.1.1.1 Sicherheitsmerkmale7 Mit der zunehmenden Verbreitung des Internet und seiner Nutzung für kommerzielle Zwecke ist sowohl bei den Anbietern als auch bei den Nutzern das Bewußtsein für die Notwendigkeit geeigneter Sicherungsmaßnahmen gestiegen. Diesen Anforderungen trägt die Internet Engineering Task Force (IETF), die für die Erarbeitung von Internet-Standards zuständig ist, dadurch Rechnung, daß sie eine eigene Security Area unterhält. Im Rahmen der Standardisierung von IPv6 wurde in der Security Area eine Arbeitsgruppe mit dem Titel IP Security Protocol (IPSec) gegründet. Ziel dieser Arbeitsgruppe ist die Entwicklung eines in das InternetProtokoll zu integrierenden Sicherheitsprotokolls. IPSec definiert Protokolle, deren Sicherungsdienste der Struktur eines IPv6-Paketes entsprechend durch zwei zusätzliche Header, den ‘IP Authentication Header’ (AH) und den Header ‘IP Encapsulating Security Payload’ (ESP) realisiert werden. Das Format dieser Header ist unabhängig von den verwendeten kryptographischen Algorithmen. Es erlaubt die Integration der Header in Datagramme des Internet-Protokolls der heute eingesetzten Version 4 sowie der neuen Version 6. Die Header können je nach angefordertem Dienst einzeln oder gemeinsam in einem IP-Datagramm auftreten. Die Sicherheitsmechanismen IPSec schützen IPv6 und die 7
Grundlage der weiteren Ausführungen sind die RFCs 1825, 1826 und 1827. Diese werden derzeit überarbeitet und sollen als neue RFCs erscheinen. Wo möglich, wird auf aktuelle Diskussionspunkte hingewiesen.
11.09.97
Firewall-Studie
Seite 17
SIEMENS
Bedrohungsanalyse der Protokolle
darüberliegenden Protokolle. Protokolle, die IP nicht verwenden oder unterhalb der Schicht drei liegen, werden nicht durch IPSec geschützt. 3.2.1.1.1.1 Authentication Header (AH) Mit dem Authentication Header können auf der IP-Datagrammebene die Dienste verbindungslose8 Integrität und Authentizität des Datenursprungs angeboten werden. Optional kann durch die Verwendung von Sequenznummern ein Schutz gegen das Wiedereinspielen von Datagrammen erreicht werden. Der Authentication Header trägt einen Integrity Check Value (ICV), der über die zu schützenden Felder des IP-Paketes berechnet wird. Der Authentication Header bietet die Möglichkeit, auch in Ländern, in denen Verschlüsselung von Datenverkehr nicht oder nur eingeschränkt erlaubt ist, einer Sicherung des Datenverkehrs bezüglich Integrität und Authentizität auf IP-Ebene. Desweiteren dürfte der Export von US-Implementierungen des InternetProtokolls, die nur AH und nicht ESP unterstützen, den Exportbeschränkungen nicht unterliegen. Um Interoperabilität gewährleisten zu können, wird eine Menge von Algorithmen vorgeschrieben werden, die als Mindestumfang implementiert werden müssen. In den RFCs 1825-1829 und 1851-52 ist der AH mit dem Keyed MD5 und Keyed SHA-1 spezifiziert. Als Internet-Drafts sind AH mit HMAC-MD5 und HMAC-SHA1 veröffentlicht [Data82 97]. Die Grundlagen dieses Konzepts stammen aus den Entwicklungen zu SNMPv2 (3.9). Durch den AH werden IP-Spoofing und viele darauf aufbauende Angriffe vereitelt. 3.2.1.1.1.2 Encapsulating Security Payload (ESP) Der ESP-Header ermöglicht die Dienste Vertraulichkeit, Authentizität des Datenursprungs und verbindungslose Integrität. Wie im Fall des Authentication Headers kann optional mit Sequenznummern ein Schutz gegen das Wiedereinspielen von Datagrammen erreicht werden. Durch die ESP werden die zu schützenden Daten eingekapselt und, falls Vertraulichkeit vereinbart ist, unter Verwendung symmetrischer Algorithmen verschlüsselt. Soll mit der ESP lediglich Integrität geschützt werden, wird an das Datagramm ein ICV-Feld angehängt, das einen über die eingekapselten Felder berechneten ICV enthält. Im Gegensatz zu IPv4 wird der ICV von IPv6 kryptographisch berechnet. Falls Vertraulichkeit und Integrität gewünscht sind, wird der ICV über das verschlüsselte ESP-Paket berechnet. Die nicht eingekapselten Felder eines IP-Paketes (wie z.B. der IP-Header) werden durch den ESP nicht geschützt. Der vorgeschriebene Mindestumfang an Verschlüsselungsalgorithmen besteht aus dem Data Encryption Standard im Cipher Block Chaining Mode (DES-CBC) [RFC 1829] und dem Triple DES [Data82 97]. In [Bellovin 96] wurden einige Angriffe gegen ESP demonstriert, die nur möglich sind, weil DES-CBC nicht für die Sicherstellung der Authentizität und Integrität geeignet ist. Daher soll in der nächsten Revision des ESP-Standards auch die Integrität und Authentizität der übertragenen Daten gewährleistet werden. Beide Header (AH und ESP) können im Transport- oder im Tunnel-Modus betrieben werden. In ersterem wird im wesentlichen das im IP-Datagramm enthaltene Paket einer höheren Schicht (z.B. TCP, UDP) geschützt. In diesem Fall wird die ESP vor das zu sichernde Datum plaziert. Somit umfassen im TransportModus die verschlüsselten Nutzdaten ein vollständiges Datagramm der Transportschicht. Der Tunnel-Modus schützt das vollständige IP-Paket inkl. aller Headerinformationen. Hierzu wird das mit AH bzw. ESP gesicherte Paket in ein neues IP-Paket gekapselt. Dem gesamten IP-Datagramm wird also ein neuer IP-Header vorangestellt, an Hand dessen ein Router oder eine Firewall verschlüsselte Pakete verteilen kann. Durch AH und ESP9 wird es möglich, einen gesicherten Kommunikationskanal zwischen Sender und Empfänger aufzubauen. Jedoch nützt dieser Kanal wenig, wenn der Kommunikationspartner nicht authentifiziert werden kann. Diese Authentisierung erfordert eine globale Infrastruktur, in der alle Kommunikationspartner mit ihren Public-Keys registriert sind. Diese Anforderung ist jedoch nicht spezifisch für IPSec - beispielsweise ist sie auch für die Absicherung von Electronic-Mail und HTTP notwendig. Für die Aushandlung eines Verfahrens und den Austausch eines Schlüssels wird ein Key-ManagementProtokoll benötigt. Bei der Größe des Internets sind manuelle Verfahren zur Verteilung der Schlüssel offensichtlich nicht verwendbar. Die Arbeiten zur Entwicklung eines Key-Management-Protokolls sind noch nicht abgeschlossen.
8
Hier wird die Integrität jedes einzelnen IP-Paketes gewährleistet, nicht jedoch die Integrität eines Zusammenhangs der Pakete (z.B. Reihenfolge). 9 Bisher sind lediglich die Datentransferaspekte der zukünftigen Internet-Sicherheitsmechanismen durch die RFCs 1825-1829 festgelegt. Diese RFCs sind derzeit als 'Proposed Standards' eingestuft. Seite 18
Firewall-Studie
11.09.97
SIEMENS
Internet Protocol Version 6 (IPv6)
Basis für die IPv6-Sicherungsdienste ist das Konzept der Security Association. Eine Security Association beschreibt alle Parameter, die zur Sicherung einer Kommunikation zweier Teilnehmer notwendig sind (beispielsweise Schlüssel, Lebensdauer, zu verwendende Mechanismen). In jedem der beiden Elemente (Authentication Header und Encapsulating Security Payload) ist ein sogenannter Security Parameters Index (SPI) integriert, der die aktuelle Security Assocation beschreibt. Sender und Empfänger vergeben eigene SPIs für die Security Association. Dies bedeutet, daß ein Datenpaket stets den vom Empfänger gewählten Index tragen muß, um korrekt verarbeitet zu werden. Eine Association gilt immer nur für eine Kommunikationsrichtung, so daß eine sichere Kommunikation zwischen zwei Knoten durch zwei Security Associations festgelegt wird. Es ist vorgesehen, daß eine Association nicht nur auf Knoten-Ebene, sondern auch auf Applikations- bzw. Userebene eingerichtet werden kann. Zwei Applikationen auf einem Knoten können also durchaus unterschiedliche Associations verwenden, um mit einem anderen Knoten zu kommunizieren. 3.2.1.1.2 Erweiterte Routing- und Adressierungsfähigkeiten Die Größe der IP-Adresse ist in IPv6 von 32 Bits auf 128 Bits erhöht worden. Dadurch können mehr Ebenen in der Adreßhierarchie und eine größere Zahl an adressierbaren Knoten gehandhabt werden. Ein neuer Adreßtyp (die sogenannte anycast address) wurde definiert. Bei diesem Adreßtyp wird ein Paket an einen Knoten aus einer angegebenen Menge von Knoten gesendet. Welcher Knoten das Paket erhält, bleibt dem Router überlassen. 3.2.1.1.3 IPv6-Adressierung IPv6-Adressen sind 128 Bits lang und identifizieren einzelne Knoten bzw. Interfaces von Knoten oder Mengen von Knoten. Dabei sind IPv6-Adressen aller Typen wie in IPv4 Interfaces zugeordnet. IPv6 unterscheidet drei Typen von Adressen: • •
•
Unicast. Ein Identifikator für ein einzelnes Interface. Anycast. Ein Identifikator für eine Menge von Interfaces (üblicherweise gehören diese zu verschiedenen Knoten). Ein Paket, das an eine Anycast-Adresse gesendet wurde, wird zum nächstliegenden (je nach Abstandsmetrik des Routingprotokolls) Interface aus dieser Menge von Interfaces gesendet. Multicast. Ein Identifikator für eine Menge von Interfaces (üblicherweise gehören diese zu verschiedenen Knoten). Ein Paket, das an eine Multicast-Adresse gesendet wurde, wird an alle Interfaces gesendet, die durch diese Adresse identifiziert werden. In IPv6 existieren im Gegensatz zu IPv4 keine Broadcast-Adressen.
3.2.1.1.4 IPv6-Routing Mit kleinen Erweiterungen können alle IPv4-Routing-Protokolle, wie z.B. OSPF (3.8.3) oder RIP (3.8.1) verwendet werden, um IPv6 zu routen. IPv6 enthält aber auch Routing-Erweiterungen, die mächtige neue Routingfunktionalitäten unterstützen wie zum Beispiel: • • •
Providerauswahl (basierend auf Leistung, Kosten, etc.) Hostmobilität (Routen zum aktuellen Standort) Automatische Readressierung (Routen zur neuen Adresse)
Wie bei den IPv4-Optionen Loose Source Routing und Record Route Option kann man angeben, welche Zwischenknoten durchlaufen werden sollen, bzw. herausfinden, welche Zwischenknoten auf dem Rückweg durchlaufen werden sollen. 3.2.1.1.5 Vereinfachung des Header-Formats Einige Headerfelder von IPv4 sind weggefallen oder wurden als optional eingestuft, um den Aufwand für das Behandeln der Datenpakete zu reduzieren. Obwohl die IPv6-Adressen viermal so lang sind wie die von IPv4, ist der IPv6-Header nur doppelt so groß wie der Header von IPv4.
3.2.1.1.6 Verbesserte Unterstützung von Erweiterungen und Optionen IPv6-Optionen werden in IPv6 durch getrennte Erweiterungsheader unterstützt. Diese sind zwischen dem IPv6-Header und dem Transportschicht-Header eines Paketes plaziert. Router untersuchen nur diejenigen
11.09.97
Firewall-Studie
Seite 19
SIEMENS
Bedrohungsanalyse der Protokolle
IPv6-Erweiterungsheader, die für sie interessant sind. Dadurch wird eine wesentliche Verbesserung der Routerperformanz erreicht. Im Gegensatz dazu werden bei IPv4 alle Headerinformationen von allen Routern untersucht, obwohl sie für einen gegebenen Router eventuell irrelevant sind. 3.2.1.1.7 Quality of Service (QoS) Damit der Sender Paketen besondere Merkmale bezüglich ihrer Handhabung mitgeben kann, wurden neue QoS-Parameter hinzugefügt. Über sogenannte Flow Labels wird Routern mitgeteilt, wie die Pakete zu behandeln sind. Beispiele sind non-default service oder real-time service. Über ein Resource Reservation Protocol wird diese Information den Routern übermittelt. 3.2.1.2 Protokolldatenstruktur Abbildung 5 zeigt das Format eines IPv6-Headers. Dabei bedeuten • • • • • •
Ver(sion) Prio(ritiy) FlowLabel Payload Length Next Hdr Hop Limit
• Source Address • Destination Address Ver (4)
Versionsnummer des Protokolls, Prioritätswert, geforderter QoS, Länge der Payload in Oktets, identifziert den Typ des unmittelbar folgenden Headers, Wird durch jeden Knoten, der das Paket weiterreicht, um 1 dekrementiert. Ist der Wert 0, so wird das Paket nicht weitergeleitet. Absenderadresse, Zieladresse
Prio (4) Payload Length (16)
Flow Label (24) Next Hdr (8)
Hop Limit (8)
Source Address (128) Destination Address (128)
Abbildung 5: Das Format des IPv6-Headers Die Struktur des Authentication Headers ist in Abbildung 6 dargestellt. Der Authentication Header ist einer von mehreren Extension-Headers (z.B. Hop-by-Hop-Routing) des IPv6; seine Plazierung innerhalb des Paketes ist nicht genau vorgeschrieben. Somit zeigt Abbildung 6Abbildung 6 einen möglichen Aufbau eines IPv6-Datagramms mit Authentication Header. Neben einem Pointer auf den nachfolgenden Header und dem SPI enthält der Header sog. Authentication Data - ein Integrity Check Value über das vollständige IP-Datagramm (die Felder, die im Netz geändert werden, und das Authentication-Data-Feld werden bei der Berechnung des ICV mit Null vorbesetzt). (i) IPv6-Beispiel mit Authentication Header IPv6 Header
Hop-by-Hop-Routing
Auth Header
Others
Upper Protocol (e.g. TCP)
(ii) Authentication Header Syntax Next Header (8)
Length (8) Security Parameters Index (32) Authentication Data (variable number of 32 bit words)
Reserved (16)
Abbildung 6: Authentication Header des IPv6-Protokolls Der ESP-Header (siehe Abbildung 7) kann an einer beliebigen Stelle zwischen IPv6-Header und den verschlüsselten Nutzdaten plaziert werden. Der ESP-Header besteht aus einem verschlüsselten und einem unverschlüsselten Teil. Er umfaßt die SPI sowie das sog. Opaque Transform Data-Feld, das Daten enthält, die von dem in der Security Association vereinbarten Mechanismus (inklusive Algorithmus) für ESP zur Verarbeitung benötigt werden (z.B. Sequenznummer, Initialisierungsvektor). Die verschlüsselten Daten umfassen den verschlüsselten Headeranteil der ESP sowie die verschlüsselten Nutzdaten. Letztere umfassen je nach Modus entweder ein vollständiges IP-Datagramm oder ein vollständiges Datagramm der Transportschicht. Seite 20
Firewall-Studie
11.09.97
SIEMENS
Internet Protocol Version 6 (IPv6)
(i) IPv6-Beispiel mit Encapsulating Security Payload IPv6 Header
Other IPv6 Headers
ESP Header
Encrypted Data
(ii) ESP-Header Security Parameter Index (32) Opaque Transform Data (variable length)
Abbildung 7: Encapsulating Security Payload des IPv6-Protokolls 3.2.1.3 Sicherheitsbedrohungen Verwendet man bei der Verschlüsselung im ESP einen reinen Cipher-Block-Chaining-Algorithmus ohne Integritätsschutz, so sind Replay-Attacken möglich, indem man abgehörte verschlüsselte Daten erneut einspielt. [Bellovin 96]. Aus diesem Grund sollte zumindest für sensitive Anwendungen sowohl Integrität als auch Vertraulichkeit (z.B. AH + ESP) verwendet werden. Neue ESP-Mechanismen, die Integrität und Vertraulichkeit gewährleisten, sind in der IETF in Diskussion. Haben mehrere Knoten Zugriff auf eine Security Association mit einem Zielknoten, so kann der empfangende Knoten lediglich überprüfen, ob das Paket von einem dieser Knoten gesendet wurde. Er kann aber nicht mit Sicherheit feststellen, von welchem dieser Systeme das Paket stammt. Ähnliches gilt, wenn ein empfangendes System nicht überprüft, ob die für ein Paket verwendete Security Association zu der angegebenen SourceAdresse des Pakets paßt. Dann kann nämlich das empfangende System nicht überprüfen, ob die angegebene Source-Adresse des Pakets gültig ist. Wenn zum Beispiel die Sender A und B jeweils ihre eigene eindeutige Security Association mit dem Zielrechner D haben, und B seine gültige Security Association mit D verwendet, allerdings als Source-Adresse die Adresse von A angibt, dann muß D glauben, daß das Paket von A kommt, es sei denn D verifiziert, daß die angegebene Source-Adresse zur verwendeten Security Association paßt. 3.2.1.4 Filterungsmöglichkeiten Die Filterungsmöglichkeiten von IPv6 entsprechen denen von IPv4 mit der Einschränkung, daß im Falle der Verwendung des ESP im Tunnel-Modus keine Kontrolle der Transportschicht-Pakete mehr möglich ist. ESP verhindert allerdings IP-Spoofing und somit die darauf aufbauenden Angriffe. 3.2.1.5 Zusammenfassung Protokoll IPv6
Angriff IP-Spoofing
Bedrohung Maskerade, Eindringen
IPv6
IP-Source Routing
Maskerade
IPv6
IP-Tiny Fragment
Eindringen
IPv6
IP-Overlapping Fragment
Eindringen
IPv6
Tunneln der Firewall
Informationsverlust
Gegenmaßnahme Abweisen von externen Datagrammen mit internen IP-Adressen, Verschlüsselung mit ESP Blocken von externen Datagrammen mit internen IP-Adressen Paketfilter verwenden, die eine Mindestgröße an Fragmentlänge verlangen Paketfilter verwenden, die ein Minimum für ein Fragment-Offset vorschreiben Verwenden von dynamischen Filtern
3.2.2 IPv6 und Firewalls Das Ziel der Ende-zu-Ende-Sicherungsdienste von IPv6 ist die Bereitstellung eines sicheren Kanals zwischen Knoten bzw. Applikationen. Bei ESP-Diensten, die Vertraulichkeit bieten, entsteht ein Konflikt mit den heute eingesetzten Firewalls:
11.09.97
Firewall-Studie
Seite 21
SIEMENS
Bedrohungsanalyse der Protokolle
Mittels Firewalls werden z.B. bei Firmen, Behörden oder Organisationen interne IP-Netze (Intranet) am Netzübergang zum Internet gegen unbefugten Zugriff geschützt. Diese Firewalls basieren auf einer Paketfilterung, welche die IP- und TCP-Header der eintreffenden Datenpakete analysiert. Es werden nur solche Pakete von außen nach innen oder umgekehrt durchgereicht, die explizit vorgegebenen Regeln genügen. Diese Regeln werden anhand von IP-Adressen, Port-Nummern und TCP-Header-Flags spezifiziert. Wird mit IPSecESP die Vertraulichkeit der Anwendungsdaten geschützt, so entsteht durch die Tatsache, daß die TCP-Header nicht mehr im Klartext vorliegen, ein grundlegendes Problem. Solche Pakete werden von heutigen Firewalls weder von innen nach außen noch umgekehrt durchgelassen, sondern schlicht verworfen. Da die Flußrichtung der Pakete ein wesentliches Filterungsmerkmal für Firewalls ist, kann nicht einfach auf die Analyse des TCPHeaders verzichtet werden. Durch den Einsatz von IPv6 ist die Abschottung eines Intranets gegen ein Internet jedoch allein nicht möglich, da die Zugriffskontrolle in die Endgeräte verlagert wird. Firewalls werden also in diesem Szenario auch in Zukunft nötig sein, insbesondere um die folgenden Schwachstellen zu beheben oder zumindest zu verringern: Fehler in Server-Implementationen. In großen LANs existieren oft noch Rechner, auf denen alte Versionen der Software mit bekannten Sicherheitslücken laufen (z.B. alte sendmail-Versionen). Durch den Einsatz von Firewalls können Zugriffe auf Server eingeschränkt oder ganz abgelehnt werden. Administrations-Fehler. In großen Intranets ist die sichere Administration aller Rechner eine sehr aufwendige Arbeit. Insbesondere sind einzelne Rechner, auf die alle Rechner mehr oder weniger ungehindert zugreifen können, keine Seltenheit. Auch das Einspielen von wichtigen Patches zum Schließen von Sicherheitslücken in Implementationen wird oft vernachläßigt. Diese Probleme werden durch IPSec nicht gelöst. Durch IPSec wird das Problem eher noch verschärft, da die Gefahr besteht, daß Administratoren, die mit den Konzepten von IPSec nicht vertraut sind, die IPSec-Sicherheitsergänzungen falsch konfigurieren. Benutzer-Fehlverhalten. IPSec unterbindet nicht das Fehlverhalten von Benutzern z.B. die Weitergabe eines Paßworts an Dritte oder der Einsatz schwacher Paßwörter. Login-Versuche, die auf der Kenntnis eines Paßworts basieren, können durch den Einsatz von Firewalls unterbunden werden. Sniffer-Angriffe. Firewalls, die interne Netze von externen abschotten, können Sniffer-Angriffe abwehren. Die Kommunikation innerhalb der LANs wird jedoch bei VPNs nicht durch Verschlüsselung geschützt. Indem man IPv6 bereits in den Hosts - den Endpunkten der Kommunikation - einsetzt, können weiterhin Sniffer-Angriffe auch in den Teil-LANs der VPNs vermieden werden. Somit ist weiterhin trotz IPSec der Einsatz von Firewalls sinnvoll. Durch eine geeignete Kombination von IPSec-Sicherungsmechanismen und Firewalls kann die Sicherheit sogar verbessert werden. Hierbei muß insbesondere beachtet werden, daß beim Einsatz eines ESP zur Sicherung der Kommunikation zwischen Knoten Daten (z.B. TCP-Ports) verschlüsselt übertragen werden, die dann von einem eingesetzten Firewall nicht mehr für die Zugriffskontrolle herangezogen werden können. Um dies zu vermeiden, bieten sich folgende Möglichkeiten an: • Sollen ESP-Vertraulichkeitsdienste mit einer Firewall-Infrastruktur heutigen Zuschnitts (d.h. die Zulässigkeit von Verbindungen zwischen Intranet- und Internet-Hosts wird an der Netzgrenze einer Organisation überprüft) betrieben werden, so muß sichergestellt sein, daß die Firewalls den TCP-Header prüfen können. Dazu müssen sie im Besitz des Schlüsselmaterials sein, wodurch eine echte Ende-zu-EndeSicherheit - etwa zwischen einem Client im Intranet und einem Server im Internet - nicht unterstützt werden kann. • Soll hingegen eine echte Ende-zu-Ende-Verschlüsselung mit IPv6-ESP realisiert werden, so müssen vorhandene Firewalls getunnelt werden und verlieren dadurch ihre eigentliche Funktionalität. Durch dieses Vorgehen wird die Überprüfung der Zulässigkeit von Ressourcenzugriffen von der zentral administrierbaren Netzgrenze auf interne Maschinen verlagert. Dies ermöglicht zwar Ende-zu-EndeSicherungsdienste, erfordert aber einen Umbruch in der Sicherheitspolitik von Firmen und Organisationen. Dieser muß einerseits akzeptiert und andererseits administrativ bewältigt werden. • Eine Mischform der beiden beschriebenen Alternativen in Abhängigkeit von Benutzern würde bedeuten, daß vertrauenswürdige Benutzer die Firewall mittels IPSec tunneln dürfen, wohingegen Daten nicht vertrauenswürdiger Benutzer an der Firewall abgewiesen werden, sofern sie verschlüsselt sind bzw. der Sicherheitspolitik nicht entsprechen.
Seite 22
Firewall-Studie
11.09.97
SIEMENS
Internet Protocol Version 6 (IPv6)
3.2.2.1 Ansätze zur Kombination von Firewalls mit IPSec Bei den IPSec-Implementierungen sollte zwischen Host- und Routerimplementierung unterschieden werden: • Das Einsatzszenario für Hostimplementierungen sind Ende-zu-Ende-Sicherungsdienste. Dies bedeutet, daß sichere Kommunikationskanäle zwischen den eigentlichen Endpunkten der Kommunikationsbeziehung (Endsystem bzw. Anwendungen) aufgebaut werden. • Virtual Private Networks (VPN) sind wichtige Anwendungen für Routerimplementierungen. Diese Einsatzform der IPSec-Dienste ermöglicht den anwendungsunabhängigen Schutz von InternetVerbindungen (etwa die Sicherung der Verbindung zweier privater LANs über eine öffentliche Netzstrecke). 3.2.2.1.1 Virtual Private Networks (VPNs) Seit geraumer Zeit bieten Firewall-Hersteller die Möglichkeit an, Datenverkehr zwischen Firewalls zu verschlüsseln. Allerdings fehlte bislang ein Standard für die Kommunikation zwischen Firewalls, so daß proprietäre Lösungen lediglich die Verschlüsselung zwischen zwei gleichartigen Firewalls erlaubten. Der Aufbau eines VPN verlangte daher, im gesamten Netz Firewalls desselben Herstellers einzusetzen. Da Netze über nationale Grenzen hinweg installiert werden, kommt die Problematik der rechtlichen Beschränkungen beim Einsatz von Verschlüsselung hinzu. Durch die Verabschiedung eines gemeinsamen Standards - IPv6 - können in Zukunft Firewalls verschiedener Hersteller zu VPNs verknüpft werden. Diese VPNs sind insbesondere für die Absicherung von Intranets großer Organisationen oder Firmen von enormer Bedeutung. Durch IPv6 ist also die Interoperabilität von Firewalls verschiedener Hersteller möglich. Der Einsatz von ESP im Tunnel-Modus in Kombination mit AH hat dieselben Eigenschaften wie Verfahren, die bisher von Firewalls angeboten wurden. Kommerzielle IPv6Implementierungen in Firewalls für den Aufbau von VPNs sind bereits verfügbar (siehe Abschnitt 6). Zu beachten ist weiterhin, daß alle Firewalls in einem VPN derselben Sicherheitspolitik unterliegen müssen. Andernfalls kann eine stärkere Sicherheitspolitik einer Firewall durch eine andere Firewall untergraben werden. Gelingt es dem Angreifer eine "schwache" Firewall zu überwinden, so steht ihm das gesamte VPN zur Verfügung. Die Hersteller von Produkten für Netzwerke und Firewalls verfolgen aktiv die Standardisierungsarbeiten zu IPSec. Daher ist davon auszugehen, daß VPNs die erste Hauptanwendung der IP-Sicherungsdienste bilden werden. 3.2.2.1.2 Paketfilter und IPSec Paketfilter (siehe Abschnitt 4.1) können bei IPv6 lediglich prüfen, ob die IPSec-Header - AH und ESP - vorhanden sind. Indem Pakete ohne diese Header abgewiesen werden, kann man erzwingen, daß IPSec eingesetzt wird. Konkret kann erzwungen werden, daß die gesamte Kommmunikation mit dem Internet mittels AH und/oder ESP geschützt wird. Die Auswertung des Inhaltes der AH oder ESP ist dann Aufgabe des Zielknotens. Probleme, die beim Einsatz einer Firewall auftreten, die lediglich aus Paketfiltern bestehen, sind: • • •
•
Der Paketfilter muß darauf vertrauen, daß der Zielrechner im LAN die Informationen im AH überprüft und nur solche akzeptiert, die korrekte Informationen enthalten. Die Verwendung schwacher Schlüssel kann durch einen Paketfilter nicht verhindert werden. Sofern ESP zur Verschlüsselung eingesetzt wird, hat der Paketfilter keinen Zugriff mehr auf UDPbzw. TCP-Portnummern. Diese Nummern werden jedoch bisher für die Zugriffskontrolle eingesetzt. Die Information, an welchen Port, und damit an welchen Service ein Paket gesendet werden soll, steht erst wieder nach der Entschlüsselung im Zielrechner zur Verfügung. Paketfilter können nicht zwischen ESP im Transport-Modus und ESP im Tunnel-Modus unterscheiden. Da im Tunnel-Modus im ESP vollständige IP-Datagramme enthalten sind, die nach dem Entschlüsseln an den eigentlichen Zielrechner weitergeleitet werden, kann ein Paketfilter noch nicht einmal feststellen, welche Knoten miteinander kommunizieren.
Wenn Paketfilter neben der reinen Existenz des AH auch die Informationen im AH überprüfen, wird die Abhängigkeit von der Sicherheit des Zielrechners im LAN verringert. Gefälschte Pakete erkennt der Paketfilter und kann sie abweisen. Auch die Verwendung schwacher Schlüssel könnte bereits auf der Ebene der Paket-
11.09.97
Firewall-Studie
Seite 23
SIEMENS
Bedrohungsanalyse der Protokolle
filter erkannt und vermieden werden. Voraussetzung dazu ist, daß der Paketfilter die verwendeten Schlüssel kennt. Dies ist insbesondere dann der Fall, wenn er selbst Security Association mit dem Zielknoten aufbaut. 3.2.2.1.3 Applikationsfilter und IPSec Die Integration von IPv6 in einen Applikationsfilter (siehe Abschnitt 4.2) erfordert ebenfalls, daß eine durch IPSec abgesicherte Verbindung zum Applikationsfilter und von dort eine zweite, unabhängige Verbindung zum Empfänger aufgebaut wird. Die auf dem Applikationsfilter installierten Applikationen bzw. Proxies führen Authentisierung, Zugriffskontrolle und Audit durch. Damit die Leistungsfähigkeit der internen und externen Netze nicht durch mangelnden Durchsatz eines Applikationsfilters insbesondere beim Einsatz kryptographischer Verfahren beeinträchtigt wird, können entweder durch spezielle Hardware kryptographische Verfahren beschleunigt oder mehrere Bastion-Hosts zur Lastteilung parallel installiert werden. Bereits heute wird die parallele Installation von mehreren Bastion-Hosts verfolgt, um eine Lastverteilung zu erreichen und den Durchsatz der Firewall zu erhöhen. Durch den Einsatz von IPSec kann eine bei sensitiven Anwendungen notwendige Authentisierung (z.B. mittels Einmalpaßwörter) entfallen. Anstatt einer einmaligen Authentisierung am Beginn einer Verbindung sichert der Authentication-Header bei allen Paketen einer Verbindung die Authentizität. Aufgrund der generellen Diskrepanz der Ansätze von Firewalls und IPv6 werden Firewalls weiterhin dafür eingesetzt werden, Intranets vom Internet abzuschirmen. Mittels Firewalls werden VPNs geknüpft werden, wobei die Kommunikation zwischen den Firewalls durch die Sicherungsdienste IPSec von IPv6 geschützt werden wird. 3.2.2.1.4 Key-Management für IPSec Die IPSec-Arbeitsgruppe hat sich zum Ziel gesetzt, neben den Sicherheitsprotokollen auch ein ‘Internet Key Management Protokoll’ (IKMP) zu spezifizieren, das die Einrichtung von Security Associations übernimmt. Nach Diskussion mehrerer Vorschläge hat sich die Arbeitsgruppe für ISAKMP/Oakley entschieden. ISAKMP [MSST 96] steht für ‘Internet Security Association and Key Management Protocol’ und definiert ein Kommunikationsprotokoll, d.h. Prozeduren und Paketformate für den Aufbau von Security Associations unabhängig von eingesetzten Authentisierungsprotokollen, Mechanismen und Algorithmen. Das Protokoll ist in der Applikationsschicht angesiedelt und kann jedes Sicherheitsprotokoll unterstützen, das Security Associations verwendet. Die im IKMP einzusetzenden Authentisierungs- und Schlüsselvereinbarungsprotokolle werden von Oakley [Orman 96] definiert. Oakley spezifiziert mehrere Aushandlungsprotokolle, die auf dem DiffieHellmann-Protokoll basieren. Public-Key-Zertifikate können beispielsweise im DNS [Atkinson 97] oder in X.509 Directory Service (siehe Abschnitt 3.2.2.1.6) gespeichert werden. Dabei sind Schlüssel, die gemäß der durch Oakley spezifizierten Methode erzeugt wurden, unabhängig von allen zuvor generierten Schlüsseln, so daß es einem Angreifer nicht hilft, einen zuvor ausgehandelten Schlüssel zu bestimmen und daraus die Sitzungsschlüssel abzuleiten. Beide Protokolle sind generisch aufgebaut, so daß sie nicht nur InternetlayerSecurity-Associations, sondern auch Security Associations für RIPv2, OSPFv2, die Transportschicht und vielleicht sogar tiefere Schichten wie ATM verwalten können. 3.2.2.1.5 Key-Management und Firewalls Die Problematik der Ende-zu-Ende-Authentisierung im Zusammenhang mit dem Einsatz von Firewalls besteht darin, daß die Firewall als Zwischenknoten die Authentizität eines externen Nutzers überprüfen können muß, um zu entscheiden, ob die Daten des Nutzers die Firewall passieren dürfen. Folgende Lösungen dieses Problems sind denkbar:
Seite 24
•
Das Key-Management-Protokoll kann derart erweitert werden, daß der Paketfilter den für die Generierung des AH verwendeten Schlüssel bei einem der Kommunikationspartner erfragen kann. Ein negativer Seiteneffekt ist, daß dadurch der Paketfilter nicht nur die gewünschte Kontrolle des AH ausführen, sondern auch Pakete mit korrektem AH erstellen kann. Der Empfänger kann nicht mehr unterscheiden, ob es sich um ein Paket des vermeintlichen Senders oder um ein gefälschtes Paket des Paketfilters handelt. Diese Lösung ist daher nicht empfehlenswert.
•
Vereinbart der Sender mit dem Paketfilter einen eigenen Schlüssel, so ist der Paketfilter nicht mehr direkt in der Lage, Pakete zu fälschen. Generiert und sendet der Sender ein Paket an den Firewall-Studie
11.09.97
SIEMENS
Internet Protocol Version 6 (IPv6) Empfänger, so weist der Paketfilter dieses ab und fordert zuerst den Sender auf, mit dem Paketfilter einen Schlüssel zu vereinbaren. Anschließend kann der Sender IP-Datagramme mit AH generieren, die für den Paketfilter kontrollierbar sind. In diese Datagramme eingekapselt sind die IP-Datagramme für den eigentlichen Empfänger (siehe Abbildung 8). Nach der Überprüfung des ersten AH trennt der Paketfilter den Teil des Paketes ab, der für das Endgerät bestimmt ist, und reicht den Inhalt an den eigentlichen Empfänger weiter. Nachteil dieser Lösung ist, daß zusätzliche Authentication-Header nur zusammen mit zusätzlichen IP-Headern hinzugefügt werden können. Insbesondere, wenn auf dem Weg vom Sender zum Empfänger mehrere Firewalls zu überqueren sind, kann die Anzahl der Header sehr groß werden. Die Länge einer Header-Information beträgt 512 Bits (ein IPv6 Header ist 320 Bits lang, die Länge eines AH beträgt 192 Bits). Damit diese Lösung nicht zum Flaschenhals in der Performanz wird, sollte sie nur bei einer geringen Anzahl von zu überquerenden Firewalls eingesetzt werden. IPv6 Header
A H
IPv6 Header
A H
Nutzerdaten
Abbildung 8: Kapselung von IPv6 in IPv6 •
Die Verwendung von asymmetrischen kryptographischen Verfahren zur Berechnung des Authentication Headers ist zwar in der Spezifikation des Authentication Headers vorgesehen. Bei digitalen Signaturen kann jeder, der im Besitz des öffentlichen Schlüssels ist, den Authentication Header überprüfen, aber nur der Sender mit dem dazugehörenden geheimen Schlüssel kann den Authentication Header erzeugen. Da allerdings Signatur-Verfahren wesentlich mehr Rechenaufwand als symmetrische Verfahren benötigen, ist der Einsatz von asymmetrischen Verfahren eher unwahrscheinlich. Ferner benötigt ein Paketfilter auch bei den asymmetrischen Verfahren Zeit, um den öffentlichen Schlüssel zu erfahren und zu authentifizieren. Bei einer großen Anzahl von Verbindungen, die durch einen Paketfilter aufgebaut werden können, kann das Key-Management zu Performanzproblemen führen.
3.2.2.1.6 Schlüsselverteilung in VPNs am Beispiel X.509 Der ITU-T Standard X.509 [ITU_T 93] definiert skalierbare Authentifizierungsprotokolle zwischen Benutzern von Paßwort-Methoden bis hin zu Public-Key-Verfahren. Benutzer können hierbei z.B. Client und Server sein, insbesondere aber auch Firewalls in einem VPN. Der X.509-Standard unterscheidet dabei zwischen • Simple Authentication (geschützte Paßwort-Authentikation) und • Strong Authentication (Public-Key Authentikation) Ursprünglich ist das X.509-Protokoll für den Einsatz und den Schutz verteilter Datenbanken (DirectoryService) definiert worden. Es ist aber von diesem Kontext unabhängig und wird auch in anderen Umgebungen verwendet. 3.2.2.1.6.1 X.509 Simple Authentication Die "X.509-Simple-Authentication" stellt eine Erweiterung der Paßwort-Authentikation dar. Gegenüber der herkömmlichen Paßwort-Authentikation bietet sie bei der Übertragung einen Schutz des Paßwortes gegen unberechtigte Kenntnisnahme und Wiedereinspielen. Durch eine Einweg-Verschlüsselung von Benutzernamen und Benutzerpaßwort wird erreicht, daß die Paßwortdaten nicht im Klartext über das Netz gehen. Zum Schutz des Datenelementes vor unberechtigtem Wiedereinspielen werden zusätzlich die aktuelle Zeit sowie eine Zufallszahl hinzugefügt und einer weiteren Einwegverschlüsselung unterzogen.
11.09.97
Firewall-Studie
Seite 25
SIEMENS
Bedrohungsanalyse der Protokolle Ausgangssystem Name
N Oneway Function
Password
Time
T
Rand
Shared Data
R
Network
Oneway Function
Protected Password
P
Shared Data
N T
expired ?
Oneway Function
Network
R
OK
? P
Zielsystem
Abbildung 9: X.509 Simple Authentication Auf dem Zielsystem werden die übertragenen Daten in folgender Weise verifiziert. Die angegebene Zeit wird auf den festgelegten Gültigkeitszeitraum hin überprüft. Um Wiedereinspielversuche zu erkennen, wird der empfangene Authentikationstoken mit allen Token verglichen, die im erlaubten Gültigkeitszeitraum eingegangenen sind. Danach werden die gespeicherten Authentikationsdaten (shared data) in gleicher Weise wie auf dem Ausgangssystem einwegverschlüsselt und mit den übertragenen Authentikationsdaten verglichen. Stimmen beide überein, so ist der Benutzer authentifiziert. 3.2.2.1.6.2 X.509 Strong Authentication Die "X.509 Strong Authentication" basiert auf der Public-Key-Kryptographie. Es existiert dabei für jeden Benutzer ein kryptographisches Schlüsselpaar, bestehend aus einem privaten und einem öffentlichen Schlüssel. Ausgangssystem Name
N Time
Private Key
T
Rand R Asym. Crypto
Alg
Signature
Network
A S
Certificate
N T Network
. expired ?
?
valid
Public Key
R A
Asym. Crypto
S
?
OK
Zielsystem
Abbildung 10: X.509 Strong Authentication
Seite 26
Firewall-Studie
11.09.97
SIEMENS
Internet Protocol Version 6 (IPv6)
Bei der Strong Authentication werden die Authentikationsdaten mit dem privaten Schlüssel des Benutzers digital unterschrieben. Das Zielsystem verifiziert mittels öffentlichem Schlüssel die digitale Unterschrift und stellt so die Echtheit der Daten und die Identität des Benutzers fest. Um ein unberechtigtes Wiedereinspielen des Authentikationstokens zu verhindern, wird ebenfalls eine Kombination aus Zeitstempel und Zufallszahl angewendet. Die Überprüfung dieser Daten erfolgt analog zur Simple Authentication. 3.2.2.1.6.3 X.509 Key Management Die Benutzerverwaltung und die Erstellung des Schlüsselmaterials wird von einer Zertifizierungsinstanz (CA) vorgenommen, deren Existenz X.509 voraussetzt. Diese generiert in einem z.B. durch Oakley [Orman 96] spezifizierten vertrauenswürdigen Prozeß das Schlüsselpaar für den Benutzer. Der private Schlüssel wird dem Benutzer in geschützter Weise (z.B. auf Chipkarte) ausgehändigt. Der öffentliche Schlüssel wird zusammen mit der Benutzeridentität, der Gültigkeitsdauer, sowie weiteren Sicherheitsparametern von der Zertifizierungsinstanz digital unterschrieben und als Public Key Zertifikat im System hinterlegt. Dieses Zertifikat ist aufgrund der Signatur fälschungssicher und kann deshalb ohne Sicherheitsrisiko veröffentlicht werden. Zertifizierungsinstanz (CA)
Zertifikat User Name Validity Public Key ...
Private Key
CA Signatur
Verifikation
Signatur Private Key bleibt immer im Besitz des Benutzers
Zertifikat kann ohne Sicherheitsrisiko veröffentlicht werden
Abbildung 11: X.509 Key Management Für die Verifikation von Authentifizierungsinformation werden nur signierte Public Key Zertifikate akzeptiert. Der Ursprung und die Korrektheit des Zertifikates kann durch die digitale Unterschrift jederzeit überprüft werden. Der Eintrag des Benutzernamens in das Zertifikat ermöglicht eine vertrauenswürdige Kopplung des Schlüssels mit der Benutzeridentität. Das genormte Datenformat [ITU_T 93], [ITU_T 95] der X.509Zertifikate erlaubt die system- und herstellerübergreifende Verwendung der Schlüsselinformation. In einer Sicherheitsdomäne können mehrere Zertifizierungsinstanzen existieren. Die einzelnen Zertifizierungsinstanzen lassen sich dabei hierarchisch anordnen, so daß sich auch komplexe Strukturen, wie sie z.B. in Firmen- oder Behördennetzen auftreten, modellieren lassen. Die oberste Zertifizierungsinstanz wird "Root CA" genannt. Aus den Zertifikaten der Hierarchie lassen sich Zertifizierungspfade bilden, die vom Benutzer bis zur Root CA reichen. Vertrauen zwei Benutzer der gleichen CA, so können deren Zertifizierungspfade lückenlos über alle Hierarchien verifiziert werden.
Z
i t if er
zie
s ng ru
Ce rt
Benutzer A
a pf
d Ce rt
Ce rt
Root-CA Untergeordnete CAs
Ce rt
Ce rt
Ce rt
Benutzer B
...
Benutzerzertifikate
Benutzer X
Gemeinsamer Vertrauenspunkt zwischen Benutzer A und X
Abbildung 12: X.509 Zertifizierungshierarchie
11.09.97
Firewall-Studie
Seite 27
SIEMENS
Bedrohungsanalyse der Protokolle
3.2.2.1.6.4 Auswirkungen auf Firewalls Die X.509-Struktur kann von Firewalls insbesondere in VPNs oder kaskadierten Intranets für folgende Szenarien verwendet werden: • • •
Um sich über das standardisierte Strong Authentication Protokoll gegenseitig zu authentifizieren. Um mit dem Directory Service Public-Key-Zertifikate zu speichern oder darauf zuzugreifen. Um mittels X.509 eine Zertifizierungshierarchie aufzubauen und diese zur Kommunikation mit einer Zertifizierungsinstanz zu verwenden.
Alle drei Szenarien bieten sich insbesondere dann an, wenn bereits eine X.509-Struktur implementiert bzw. vorhanden ist und diese lediglich auf Firewalls ausgedehnt werden muß. Da X.509 standardisiert ist, kann dessen Einsatz auch auf das Schlüsselmanagement, die Authentisierung und das zur Verfügung stellen von Public-Key-Zertifikaten für externe Benutzer (wie z.B. Joint-Venture-Partner) erweitert werden. 3.2.2.2 Alternativen zu IPSec in Bezug auf Firewalls 3.2.2.2.1 Transport Layer Security (TLS) Neben der IPSec-Arbeitsgruppe wurde bei IETF die Transport Layer Security - Arbeitsgruppe (TLS) gegründet. Diese spezifiziert ein Sicherheitsprotokoll, das zwischen TCP und beliebigen Anwendungsprotokollen angesiedelt ist (das sog. TLS-Protokoll). Das TLS-Protokoll basiert auf dem SSL-Protokoll (siehe Abschnitt 3.18). Im Gegensatz zu IPSec-AH und -ESP umfassen TLS und SSL das Key-Management. Für sichere HTTP-, SMTP-, NNTP-, FTP- und POP3-Dienste über TLS sind bei der Internet Assigned Numbers Authority (IANA) bereits Portnummern reserviert. Aufgrund der Einbettung des Sicherheitsprotokolls oberhalb des Transportsystems läßt sich der Firewall-Übergang für Ende-zu-Ende-Dienste bei TLS auf Anwendungsebene lösen: Das SSL-Protokoll realisiert mittels der entsprechenden HTTP-Funktionalität Ende-zu-EndeSicherungsdienste im WWW über Firewallgrenzen hinweg. Diese Funktionalität kann durch den Einsatz von TLS auch für andere Anwendungsprotokolle zur Verfügung gestellt werden. Sowohl IPSec/IKMP als auch TLS realisieren sichere Kommunikationskanäle im Internet. Die Kommunikation zwischen Anwendungen im Internet kann aber auch durch geeignete Sicherheitsmechanismen auf Applikationsebene (z.B. PGP, S-MIME) gesichert werden. Da alle drei Ansätze in Abhängigkeit der jeweiligen Kommunikationssituation und der gestellten Sicherheitsanforderungen Vor- und Nachteile aufweisen, ist es unwahrscheinlich, daß einer dieser Ansätze sich gegen alle anderen durchsetzen wird. Auf absehbare Zeit ist von einer Koexistenz auszugehen. 3.2.2.2.2 Authenticated Firewall Traversal Protocol (AFT) Die AFT-Arbeitsgruppe des IETF entwickelt einen auf dem SOCKS Version 5-Protokoll [RFC 1928] basierenden Internet-Standard, anhand dessen eine allgemeine Authentisierungsumgebung auf Anwendungsschicht spezifiziert wird, um damit Internet Firewalls überqueren zu können. Zusätzlich zu diesem Überquerungsprotokoll definiert die Arbeitsgruppe folgende grundlegenden Authentisierungsmethoden, die ebenfalls als Internet-Draft veröffentlicht sind [Data82 97]: • Challenge-Handshake Authentication Protocol (CHAP) • Challenge-Response Authentication Method (CRAM) 3.2.3 Konzeptionelle Unterschiede Intranet - Internet Der zukünftige Einsatz von Firewalls wird geprägt von Joint Ventures und Kooperationen mehrerer Firmen, Organisationen und Behörden. Daraus resultiert die Notwendigkeit von VPNs und zusätzlich geschützten Teilnetzen innerhalb eines Intranets (sogenannte kaskadierte Intranets). Beide Szenarien lassen sich weder durch Firewalls, noch durch IPSec oder TLS/SSL alleine absichern. Hier ist die Kombination aller drei Sicherheitsmechanismen notwendig. 3.2.3.1 Szenario VPN mit TLS/SSL und IPSec In Abbildung 13 verbinden zwei Firewalls zwei voneinander unabhängige Intranets zu einem VPN, indem die Kommunikation der beiden Firewalls mit den Sicherheitsmechanismen IPSec bezüglich Integrität, Authentizität und Vertraulichkeit geschützt ist. Schützt man die Kommunikation zwischen Hosts innerhalb des Intra-
Seite 28
Firewall-Studie
11.09.97
SIEMENS
Internet Protocol Version 6 (IPv6)
nets und deren Firewall mittels TLS/SSL, so kann die Firewall den socket10 im TCP-Header durch einen (nach Möglichkeit dynamischen) Paketfilter filtern. Da nämlich TLS/SSL oberhalb der Tranportschicht angesiedelt ist, liegt der TCP-Header im SSL-Format im Klartext vor. Der Firewall ist es nicht möglich, Pakete zu fälschen, da sie in die Security Association zwischen Host A im Intranet A und Host B im Intranet B nicht eingebunden ist. Die Firewall A kapselt das TLS/SSL-Datenpaket in das IPv6-Format und sichert die Kommunikation (insbesondere gegen IP-Spoofing) mittels AH und ESP. Die Firewall B entkapselt das Datenpaket, entschlüsselt die ESP und überprüft den AH auf Integrität und Authentizität. Anschließend überprüft Firewall B den nun im Klartext vorliegenden TCP-Header daraufhin, ob die implementierte Sicherheitspolitik eine Kommunikation zwischen Host A und Host B erlaubt. Ist dies der Fall, so reicht es die immer noch durch TLS/SSL geschützten Nutzdaten an Host B weiter. Dieser kann die Nutzdaten entschlüsseln und auf Integrität und Authentizität überprüfen, da Host B mit Host A eine Security Association definiert hat (siehe Abbildung 15). Für dieses Szenario sind also Firewalls mit dynamischem Paketfilter erforderlich, die IPSec unterstützen, um die sich u.U. ändernden Parameter der Security Association speichern zu können. Sollten die Firewalls in die Security Association zwischen Host A und Host B integriert sein, so ist es möglich mittels eines Applikationsfilters nur bestimmte Dienste zuzulassen. Hier ist jedoch die Fälschung von Paketen durch die Firewall technisch realisierbar. Daher ist das Integrieren der Firewall in die Security Association zu empfehlen, wenn die Vertrauenswürdigkeit der Firewalls selbst Teil der Sicherheitspolitik ist. Internet Intranet A
Intranet B
HostA
HostB
TLS / SSL
TL S
/S
S TL
SL
FWA S TL
/S
IPSEC
/S
SL
FWB
SL
Host
Abbildung 13: VPN mit TLS/SSL und IPSec 3.2.3.2 Szenario kaskadiertes Intranet mit TLS/SSL und IPSec In Abbildung 14 ist Intranet B Teil des Intranets A. Die Sicherheitspolitik sieht vor, das Intranet B vor dem Intranet A zu schützen. Die Kommunikation zwischen den einzelnen Hosts ist wie im obigen VPN-Szenario durch TLS/SSL, die Kommunikation zwischen den Firewalls durch IPSec geschützt. Wie oben beschrieben, haben die Firewalls die Möglichkeit durch dynamische Paketfilter die TCP-Header zu überprüfen, ohne selbst Teil der Security Associations zu sein. Kaskadierte Intranets zeichnen sich dadurch aus, daß das Intranet B durch zwei Firewalls geschützt ist. Sofern es die Sicherheitspolitik vorsieht, kann man daher Firewall B als vertrauenswürdig betrachten, so daß diese Teil der Security Association zwischen Host A und Host B sein kann. Dadurch kann die Kommunikation zwischen Host A und Host B durch Applikationsfilter zusätzlich auf bestimmte Dienste eingeschränkt werden kann. Die Kommunikation zwischen einem Host im Internet und Host B kann durch TLS/SSL über beide Firewalls mit den Mechnanismen dynamischer Paketfilter geschützt und kontrolliert werden. Für kaskadierte Intranets ist folgende Anforderung an Firewalls notwendig: Ist eine Firewall nicht Teil einer SSL-Security-Association zwischen zwei Hosts und ergibt die Prüfung des dynamischen Paketfilters der Firewall, daß die Kommunikation dieser beiden Hosts erlaubt ist, so darf die sich anschließende Kontrolle durch einen implementierten Applikationsfilter nicht die Pakete verwerfen (wie bisher üblich). 10
Das Quadrupel (IP-Quelladresse, IP-Zieladresse, IP-Quellport, IP-Zielport) wird als socket bezeichnet.
11.09.97
Firewall-Studie
Seite 29
SIEMENS
Bedrohungsanalyse der Protokolle
Host
Internet S TL
SL /S
FWA Intranet A IPSEC
S TL
SL /S
HostA TL S
/S
SL
TLS / SSL
FWB
Intranet B
HostB
Abbildung 14: Kaskadiertes Intranet mit TLS/SSL und IPSec
Nutzdaten
TCPHeader
SSL
AH
ESPHeader
IPv6Header
ESP
IPSEC
Abbildung 15: Kapselung von Nutzdaten in SSL und IPSec
3.2.4 Anforderungen an Firewalls in zukünftigen Szenarien bezüglich IPSec Aufgrund der Tatsache, daß IPSec-Sicherungsdienste, ohne mit derzeitigen Sicherheitspolitiken zu kollidieren, sich sehr gut dafür eignen, VPNs zu knüpfen, werden die IPSec-Sicherungsdienste wohl zunächst hauptsächlich in Sicherung der Kanäle auf öffentlichen Netzen zwischen den Firewalls eines VPNs dienen. Innerhalb der einzelnen Teil-LANs kann der Kommunikationskanal entweder über anwendungsorientierte Sicherheitsmechanismen oder mit TLS / SSL geschützt werden. Letzteres hat den Vorteil, daß TLS/SSL für das
Seite 30
Firewall-Studie
11.09.97
SIEMENS
Internet Control Message Protocol (ICMP)
Key-Management sorgt und über Firewalls innerhalb des Teil-LANs oder auch über Firewalls, die die TeilLANs zu VPNs verknüpfen einsetzbar ist. Aus (3.2.3) resultieren folgende zukünftige Anforderungen an Firewalls: • • • • • •
Unterstützen der Kommunikation mit einer Zertifizierungsstelle Implementierung des Key-Managements von ISAKMP/Oakley Implementierung der Sicherungsdienste von IPSec. Unterstützung von TLS/SSL dynamische Paketfilterung11 Die Möglichkeit des Öffnens des Applikationsfilters für TLS/SSL-verschlüsselte Pakete, die den Paketfilter überwunden haben. • Ausreichend Performanz bezüglich Verschlüsselung und Datendurchsatz 3.2.5 Fazit • • • • •
IPSec-Dienste werden derzeit implementiert. Erste Implementierungen sind erhältlich. Dienstschnittstellen zu einem sicherheitserweiterten TCP/IP-Stack werden Funktionen anbieten, die es Anwendungen erlauben, von den IPSec-Diensten zu profitieren. Solche Schnittstellen sind derzeit noch nicht spezifiziert. Eine geeignete Key-Management-Infrastruktur mit Protokollen, Zertifikaten und Zertifizierungsautoritäten muß standardisiert, realisiert und etabliert werden, um IPSec-Dienste weltweit auf breiter Basis im Internet einsetzen zu können. Das Konzept der IP Encapsulating Security Payload verlangt Änderungen an der Administration von Netzübergängen. Die heutige Internet-Struktur, die durch den Einsatz von Firewalls geprägt ist, steht dem Einsatz von IPv6-Sicherheitsmechanismen zur Sicherung der Ende-zu-Ende-Kommunikation entgegen. Sinnvoll eingesetzt werden können die IPv6-Sicherungsdienste in der heutigen Netzstruktur in VPNs, um die sichere Verbindung lokaler Firmennetze über das Internet zu gewährleisten.
3.3 Internet Control Message Protocol (ICMP) 3.3.1 Einsatzumgebung Das Internet Control Message Protocol [RFC 792] hat als Protokoll der Transportschicht die Aufgabe, Fehler- und Diagnoseinformationen für IP zu transportieren. Es wird intern von IP, TCP oder UDP angestoßen und verarbeitet. Auf der Benutzerebene kann es durch den Befehl ping angesprochen werden. Es kommt zum Einsatz, wenn • • •
Datagramme nicht ausgeliefert werden können, ein Gateway Datenverkehr über eine kürzere Route leitet oder ein Gateway nicht genügend Pufferkapazität besitzt, um eine Protocol Data Unit (PDU) zu halten und weiterzuleiten.
Mit Hilfe von ICMP wird der Host benachrichtigt, wenn ein Empfänger nicht erreichbar ist. Ferner verwaltet oder erstellt ICMP eine zeitkritische Nachricht, falls die Lebensdauer eines Datagramms ausläuft. Außerdem führt es gewisse Editorfunktionen aus, um zu bestimmen, ob der IP-Header fehlerhaft oder unverständlich ist. Die wesentlichen Eigenschaften von ICMP sind: • • • •
IP verpackt die ICMP-Dateneinheiten in IP-Datagramme, um sie übers Internet zu transportieren. IP verwendet ICMP, um Fehlermeldungen zu generieren. ICMP macht IP nicht verläßlich. Es hat lediglich die Funktion, Fehler mitzuteilen. ICMP berichtet über Fehler in IP-Datagrammen, jedoch nicht in ICMP-Dateneinheiten selbst. Andernfalls wären Endlosschleifen in der Fehlermitteilung möglich. Werden IP-fragmentierte Datagramme verwendet, so berichtet ICMP nur über Fehler des ersten empfangenen Fragments des Datagramms.
•
11
Damit die Parameter einer Security Association gespeichert werden können.
11.09.97
Firewall-Studie
Seite 31
SIEMENS
Bedrohungsanalyse der Protokolle
3.3.2 Dienste von ICMP ICMP bietet als Dienstleistung Fehler- und Statusmeldungen an. Abbildung 16 [Black 95] zeigt eine Übersicht dieser Meldungen. Im folgenden werden diese erläutert: Time Exceeded. Dieser Dienst wird ausgelöst, wenn der angegebene Zeitwert eines IP-Datagramms abgelaufen ist und der Rechner dieses Datagramm verworfen hat. Parameter Unintelligible. Der Zielhost kann diesen Dienst ansprechen, falls er Probleme hat, einen Teil eines IP-Headers zu bearbeiten. Destination Unreachable. Dieser Dienst wird von einem Gateway oder dem Zielhost benutzt, falls das Gateway das in der IP-Zieladresse angegebene Netzwerk oder der Zielhost ein Protokoll höherer Schicht oder einen Port auf diesem Host nicht erreichen kann. Das Codefeld hat dabei die Werte 0 = Netz nicht erreichbar 1 = Host nicht erreichbar 2 = Protokoll nicht verfügbar 3 = Port nicht verfügbar 4 = Fragmentierung benötigt 5 = Quellroute fehlgeschlagen Dabei sendet ein Gateway die Codes 0, 1, 4 oder 5; ein Host sendet die Codes 2 oder 3. Source Quench. Dieser Dienst bietet eine einfache Form der Flußsteuerung durch ein Gateway und wird benutzt, wenn eine Maschine unzureichenden Pufferplatz hat, um ankommende Nachrichten zu speichern. Wird dadurch ein Datagramm fallengelassen, so sendet das Gateway die Nachricht Source Quench zu demjenigen Host, der die Nachricht erstellt hat. Dabei hat diese Nachricht dieselbe Wirkung wie das Format “receive not ready (RNR)” in vielen anderen Protokollen. Sie wirkt wie eine Aufforderung an den übertragenden Host, die Anzahl der Datagramme, die zum Zielhost gesendet werden, zu reduzieren. Der Dienst unterstützt also Flußsteuerung im Internet. Echo Request und Reply. Dieser Dienst ist wertvoll, um den Zustand eines Netzes oder Internets zu bestimmen. Er kann zu jeder IP-Adresse gesendet werden, also auch zu einem Gateway. Der Empfänger wird aufgefordert, dem Absender zu antworten. Bleibt die Antwort aus, so weiß der Absender, daß Unregelmäßigkeiten aufgetreten sind. Dieser Dienst kann auch dazu benutzt werden, zu erkennen, ob ein Host aktiv und verfügbar ist. In manchen Systemen heißt dieser Dienst ping. Dazu sendet ping ein ICMP-Datenpaket mit der Adresse des Zielhosts und dem IP-Adreßfeld. Wenn der Zielhost aktiv ist, sendet er ein echo reply zum Quellhost. Redirect. Dieser Dienst wird von Gateways benutzt. Die ICMP-Nachricht wird zum Quellhost gesendet und zeigt an, daß eine bessere Route verfügbar ist. Timestamp. Mit dem Zeitstempeldienst können Hosts oder Gateways Verspätungen im Datenverkehr erkennen. Information Request und Information Reply. Durch diesen Dienst kann ein Host die IP-Adresse des Netzes bestimmen, mit dem er verbunden ist. Dieser Dienst wurde aber weitgehend durch das Protokoll Reverse Address Resolution Protocol (RARP) ersetzt. AdressMask. Mit diesem Dienst kann ein Host die benutzte Subnetzmaske auf dem Netz des Hosts ermitteln.
Seite 32
Firewall-Studie
11.09.97
SIEMENS
Internet Control Message Protocol (ICMP)
ICMP Services
Time Exceeded
Destination Unreachable
Parameter Unintelligible
Echo
Source Quench
Timestamp
Redirect
Address Mask
Abbildung 16: ICMP-Dienste 3.3.3 Protokolldatenstruktur Das Format der ICMP-Nachrichten ist in Abbildung 17 [Black 95] dargestellt. ICMP-Nachrichten werden im Benutzerteil der IP-Datagramme befördert. Das Protokollfeld im IP-Header wird auf 1 gesetzt, um den Gebrauch von ICMP zu signalisieren. Alle ICMP-Nachrichten beinhalten drei Felder: • • •
das Typfeld, um den Typ der Nachricht anzugeben, das Codefeld, um den Typ der Fehler- oder Statusinformation zu beschreiben, ein Prüfsummenfeld.
Ferner beinhaltet die ICMP-Nachricht den Internet-Header und die ersten 64 Bits des IP-Paketes, das die ICMP-Nachricht verursacht hat. IP Header Typ (8) Code (8) Prüfsumme (16) nicht genutzte Parameter (32) Information (variabel)
Abbildung 17: Das Format einer ICMP-Nachricht 3.3.4 Sicherheitsbedrohungen Angriff: Time-to-Live-Exceeded, Redirect, Destination Unreachable Bedrohung: Denial-of-Service Grundsätzlich versenden einige ICMP-Implementierungen unnötige Status- und Fehlermeldungen, was zu einem erhöhten Datenverkehrsaufkommen führt. Viele ICMP-Nachrichten, die einen Host erreichen, sind nur für eine bestimmte Verbindung relevant oder durch ein bestimmtes Paket ausgelöst. In diesen Fällen finden sich der IP-Header und die ersten 64 Bit des IPRumpfes wieder. Dies soll die Auswirkungen der ICMP-Nachricht begrenzen. So sollte sich eine Redirectoder Destination Unreachable-Nachricht lediglich auf eine bestimmte Verbindung beziehen. Jedoch nutzen alte ICMP-Implementierungen diese zusätzliche Information nicht. Werden solche Nachrichten empfangen, so wirken sie auf alle Verbindungen zwischen den beteiligten Hosts. Dies gilt selbst dann, wenn die Nachricht
11.09.97
Firewall-Studie
Seite 33
SIEMENS
Bedrohungsanalyse der Protokolle
durch eine Firewall erzeugt wurde, die den Verkehr auf dem gewünschten Zielport filtert. Eine Firewall sollte daher vermeiden, ICMP-Nachrichten zu erzeugen, die möglicherweise bestehende, legitime Verbindungen mit der Quelle des Paketes abbrechen. Es existieren sogar Programme die mit Hilfe von ICMP-Nachrichten Verbindungen kappen. Die Meldung Time to Live Exceeded eignet sich ebenfalls für eine Denial-of-ServiceAttacke [Bellovin 89]. Angriff: Ping-to-death Bedrohung: Denial-of-Service Sendet ein Angreifer ein ICMP-Paket mit einer Größe des Nutzdatenpaketes von mindestens 65.510 Bytes ab, so wird dies fragmentiert und zum Opfer gesendet. Auf Opferseite werden die Fragmente wieder zusammengesetzt. Inklusive des ping-Headers ergibt dies eine Länge von mehr als 65.535 Bytes. Dies führt bei TreiberImplementierungen, die einen Overflow nicht abfangen, zu einem Systemabsturz [CA-96:26]. Angriff: Redirect Bedrohung: Eindringen Die Meldung Redirect wird ausgesandt, wenn ein Gateway erkennt, daß das Paket direkt an ein anderes Gateway geschickt werden kann, also bisher ein Umweg benutzt wurde. Der kürzere Weg wird dann in die Routing-Tabelle des Absenders eingetragen. Dieses kann mißbraucht werden, um unerwünschte Routen zu konfigurieren und dadurch in Systeme eindringen zu können. Nur Hosts (also Endsysteme), niemals jedoch Router sollten Redirect-Nachrichten glauben schenken, und auch nur dann, wenn sie von einem Router im lokalen Netz stammen. Eine Firewall sollte sicherstellen, daß die Meldungen Redirect und Destination Unreachable nicht durch die Filter gelassen werden. Bei den anderen Meldungen ist abzuwägen, ob die nach außen gelieferte Information für einen Angriff mißbraucht werden kann. 3.3.5 Filterungsmöglichkeiten ICMP-Pakete enthalten keine Quell- und Ziel-Portnummern und auch kein ACK-Bit, sondern ein einzelnes Feld für den ICMP-Meldungstyp. Somit ist keine Basis für eine Filterung vorhanden. Daher sollten ICMPPakete abgewiesen werden. Ist dies nicht gewünscht, so kann man an Hand des ICMP-Meldungstyps ICMPPakete ausfiltern. Die folgende Tabelle enthält einige gebräuchliche ICMP-Meldungstypen mit Empfehlungen, wie diese behandelt werden sollten [Chapman, Zwicky 96]. Meldungstyp 0 3
Bedeutung Echo Reply Destination Unreachable
4 5
Source Quench Redirect
8 11 12
Echo Request Time Exceeded Parameter Problem
Bemerkung Antwort auf ping Kann unter anderem bedeuten, daß Rechner, Netz oder Port nicht erreichbar sind. Sollte abgewiesen werden. Sollte erlaubt werden. Sollte abgewiesen werden, vor allem von Routern innerhalb der Firewall. Sollte erlaubt werden. Sollte erlaubt werden. Probleme mit einem Paket-Header. Sollte erlaubt werden.
Tabelle 2: ICMP-Meldungen
3.3.6 Zusammenfassung Protokoll ICMP ICMP
Angriff Time-to-Live Exceeded Destination Unreachable
Bedrohung Denial-of-Service Denial-of-Service
ICMP
Redirect
Eindringen
ICMP
Ping-to-death
Denial-of-Service
Seite 34
Firewall-Studie
Gegenmaßnahme Authentisierung Verwendung neuerer ICMPImplementierungen, Filtern von Destination Unreachable durch Firewall Authentisierung, Hosts sollen Redirect von lokalen Routern trauen, Router sollen Redirect abweisen. Filtern von Redirect durch Firewall IP-Treiber verwenden, die Overflows abfangen.
11.09.97
SIEMENS
Transmission Control Protocol (TCP)
3.4 Transmission Control Protocol (TCP) 3.4.1 Einsatzumgebung Das Transmission Control Protocol [RFC 793] ist ein verbindungsorientiertes Protokoll der Transportschicht. TCP wurde für IP entwickelt. Da IP verbindungslos ist, werden die Aufgaben Verläßlichkeit, Flußsteuerung, Öffnen und Schließen sowie Kontrolle der Reihenfolge TCP überlassen. Die Korrektheit der Übertragung wird durch Sequenznummern, Prüfsummenbildung mit Empfangsbestätigung, Quittung mit Zeitüberwachung und einer Segmentübertragungswiederholung nach Quittungszeitablauf sichergestellt. Dabei werden alle übermittelten Bytes, inklusive Anforderung von Verbindungsaufbau und -abbau gezählt. Alle TCP-Pakete, außer dem allerersten einer Sitzung, enthalten eine Quittungsnummer, welche die Laufnummer des letzten in Folge korrekt empfangenen Pakets zurückgibt. Der Header enthält u.a. zwei 16-Bit-Portnummern, die zur Identifikation der Kommunikationsendpunkte dienen und die zum Teil über eine standardisierte Zuordnung (well-known-ports) mit den Diensten der Anwendungsschicht verbunden sind. Das erste bei einem Verbindungsaufbau übertragene Paket ist i.d.R. das einzige, welches ohne ein gesetztes Bestätigungsflag (ACK) übertragen wird. Auf diese Weise ist eine Unterscheidung zwischen Verbindungsaufbau- und Datenübertragungsphase möglich. Somit können Paketfilter eingehenden Verkehr erkennen und filtern (s.u.). Obwohl TCP für IP entwickelt wurde, kann TCP mit kleinen Modifikationen auch auf anderen verbindungslosen Protokollen, wie zum Beispiel CLNP (Connectionless Network Protocol) auftreten. Viele Anwendungsprotokolle (z.B. FTP oder SMTP) verlassen sich auf die Dienste von TCP. 3.4.2 Schematischer Ablauf Jede TCP-Nachricht enthält das Quadrupel
. Durch diese Kombination aus Quell- und Zielsystem und jeweiligen Port-Nummern wird die Nachricht eindeutig einer bestimmten Verbindung zugeordnet. Es ist nicht nur erlaubt, sondern durchaus üblich, mehrere verschiedene Verbindungen über die gleiche lokale Portnummer abzuwickeln. Solange sich ein Element des Quadrupels von den restlichen Elementen unterscheidet, gibt es keine Probleme. Server-Prozesse, die einen Dienst über TCP anbieten, erwarten Pakete an bestimmten Portnummern. Dies wird TCP-listen genannt. Server-Ports haben aus historischen Gründen niedrige Nummern, da der BSDKernel zu Beginn davon ausging, daß privilegierte Ports nur von privilegierten Superusern benutzt würden. Diese Übereinkunft wird allerdings nicht immer eingehalten, was zu Sicherheitsproblemen führen kann (s.u.). Ein Port im Listen-Modus stellt in gewissem Sinn eine halboffene Verbindung dar: Nur Serversystem und Serverport sind bekannt (genaugenommen muß selbst die Zielsystemadresse nicht bekannt sein; ein Computer kann mehrere IP-Adressen besitzen, und Verbindungsanfragen können in der Regel an jede dieser Adressen gerichtet werden). Geht ein Paket mit einer Verbindungsanfrage ein, so werden die fehlenden Einträge ergänzt. Der Server-Prozeß kann vom Betriebssystem dupliziert werden, so daß auch weitere Anfragen auf denselben Port behandelt werden können. Clients nutzen die angebotenen Dienste. Client-Prozessen wird normalerweise eine beliebige freie Portnummer von ihrem lokalen Betriebssystem zugeteilt. Sie können auch spezielle Port-Nummern anfordern. In Abbildung 18 [Cheswick, Bellovin 94] ist eine TCP-Sitzung skizziert. Dabei gibt das einleitende Paket mit gesetztem SYN-Bit (“synchronize” oder “open request”, Verbindungsaufforderung) seiner Seite die erste Sequenznummer bekannt. Diese wird zufällig bestimmt, damit TCP Pakete einer vorhergehenden Verbindung (d.h. von früheren Verwendungen des selben sockets). Bei allen nachfolgenden Paketen ist das ACK-Bit (“acknowledge” oder positive Quittung) gesetzt. Alle Pakete außer dem ersten TCP-Paket einer Verbindung enthalten eine Quittierungsnummer. Diese ist die Sequenznummer des letzten erfolgreich empfangenen Pakets. In der ersten Zeile ist die Initial Sequence Number 1000. Der Server bestätigt den Empfang mit dem ACK und der Quittierungsnummer 1001 und sendet gleichzeitig SYN mit der neuen Initial Sequence Number 2000. Der Client bestätigt den Empfang mit ACK und der Quittierungsnummer 2001. Erst nach diesem „three-way-handshake“ können Daten gesendet werden. Beachtenswert ist das Quittieren des FIN-Bits (“final”) und der unabhängige Verbindungsaufbau.
11.09.97
Firewall-Studie
Seite 35
SIEMENS
Bedrohungsanalyse der Protokolle
Abbildung 18: Ablauf einer TCP-Sitzung 3.4.3 Steuerkommandos TCP arbeitet wie IP mit dem Konzept der Dienste-Primitive, um mit den oberen Schichten zu kommunizieren. Die Kommunikation mit der darunterliegenden Schicht ist im TCP-Standard nicht spezifiziert. Es wird angenommen, daß TCP und die unteren Schichten Informationen asynchron austauschen können. TCP erwartet, daß die untere Schicht dieses Interface spezifziert. Das Interface zu den oberen Schichten wird durch die Befehle und Nachrichten in Tabelle 3 [Black 95] spezifiziert.
Seite 36
Firewall-Studie
11.09.97
SIEMENS
Transmission Control Protocol (TCP)
Service Request Primitive (ULP zu TCP) Befehl UNSPECIFIED-PASSIVE-OPEN FULL-PASSIVE-OPEN ACTIVE-OPEN ACTIVE-OPEN-WITH-DATA
SEND RECEIVE ALLOCATE CLOSE ABORT STATUS Service Response Primitive (TCP zu ULP) Primitive OPEN-ID OPEN-FAILURE OPEN-SUCCESS DELIVER CLOSING TERMINATE STATUS RESPONSE
ERROR
Parameter Lokaler Port, ULP time-out (*), time-out Aktion (*), precedence, security (*), Optionen (*) Lokaler Port, Zielsocket, ULP time-out (*) time-out Aktion (*), precedence (*), security (*), Optionen (*) Lokaler Port, fremder Host, ULP-time-out (*) time-out Aktion (*), precedence (*), security (*), Optionen (*) Quellport, Zieladresse, ULP-time-out (*) time-out Aktion (*), precedence (*), security (*), Daten, Datenlänge, Push-Flag, Urgent-Flag (*) Lokaler Verbindungsname, Pufferadresse, Byteanzahl, PushFlag, Urgent-Flag, ULP time-out (*), ULP time-out Aktion (*) Lokaler Verbindungsname, Pufferadresse, Byteanzahl, UrgentFlag, Push-Flag Lokaler Verbindungsname, Datenlänge Lokaler Verbindungsname Lokaler Verbindungsname Lokaler Verbindungsname Parameter Lokaler Verbindungsname, fremder Socket, Zieladresse Lokaler Verbindungsname Lokaler Verbindungsname Lokaler Verbindungsname, Pufferadresse, Byteanzahl, Urgentflag Lokaler Verbindungsname Lokaler Verbindungsname, Beschreibung Lokaler Verbindungsname, Quellport und -adresse, fremder Port, Verbindungszustand, Sende- und Empfangsfenster, Urgent-Modus, time-out, time-out Aktion Lokaler Verbindungsname, Fehlerbeschreibung
Tabelle 3: TCP-Steuerkommandos12 3.4.4 Dienste von TCP TCP bietet den oberen Schichten folgende Dienste an: Connection-oriented data management. TCP speichert Status und Zustandsinformationen eines jeden Datenstroms, der durch das TCP Modul fließt. Ferner ist TCP für den Ende-zu-Ende Transfer von Daten zu einer empfangenden Anwendung durch ein oder mehrere Netze verantwortlich. Reliable data transfer. TCP garantiert einen verläßlichen Datentransfer. Dazu benutzt es Sequenznummern und positive oder negative Bestätigungsflags. TCP setzt dabei Timer und sendet die Daten erneut, wenn bei Ablauf des Timers noch keine Empfangsbestätigung in Form des gesetzten ACK-Bits angekommen ist. Stream-oriented data transfer. TCP erhält die Daten eines Upper Layer Protocols (ULP) stromorientiert. Das heißt, es werden einzelne Oktets und keine Blöcke oder Datagramme entgegengenommen. Kommen diese Oktets in der Transportschicht an, so werden sie zu TCP-Segmenten zusammengefaßt. Diese werden dann an IP oder ein anderes darunterliegendes Protokoll weitergeleitet. Die Länge der Segmente wird dabei von TCP bestimmt. Push function. Diese Operation wird benutzt, wenn eine Applikation sicher gehen möchte, daß alle Daten, die sie an TCP weitergeleitet hat, auch sofort übertragen werden. Dabei wird TCP durch einen Sendebefehl aufgefordert, den gesamten gepufferten Datenbestand in Form von Segmenten zur Zieladresse zu senden. Flow control. Das Empfänger-TCP-Modul ist in der Lage, den Datenfluß des Senders zu steuern. Dadurch wird ein Pufferüberlauf und eine mögliche Überlastung der Empfängermaschine vermieden. Dem Übertragenden wird ein Fensterwert mitgeteilt. Er kann dann eine bestimmte Anzahl von Bytes innerhalb dieses Fensters versenden. Danach wird das Fenster geschlossen und der Sender muß die Übertragung beenden. Resequencing. TCP verwendet Sequenznummern nicht nur zur Bestätigung, sondern auch zum sogenannten resequencing. Dabei werden diejenigen Segmente zurückgeschickt, die am Zielort zerstört ankommen. Da TCP auf einem verbindungslosen Dienst aufbaut, ist es möglich, daß im Internet Duplikate der Datagramme erstellt und weggeschickt werden (der sogenannte Replay-Attack). Solche Datagramme werden von TCP erkannt und verworfen.
12
Das Zeichen (*) bedeutet, daß dieser Parameter optional ist
11.09.97
Firewall-Studie
Seite 37
SIEMENS
Bedrohungsanalyse der Protokolle
Multiplexing. TCP kann mehrere Benutzersitzungen innerhalb eines einzelnen Hostrechners zu den einzelnen ULPs schalten. Full-duplex transmission. TCP bietet volle Duplex-Übertragung zwischen zwei TCP-Instanzen an. Dies erlaubt eine gleichzeitige Zweiweg-Übertragung, ohne daß man auf ein Turnaround-Signal warten muß. Dieses Signal wäre in einer Halb-Duplex Situation notwendig. Graceful close. TCP schließt eine logische Verbindung zwischen zwei Diensten erst, wenn der gesamte Datenverkehr quittiert wurde. Passive und active open. TCP bietet zwei Formen des Verbindungsaufbaus an. Der passiv open-Modus ermöglicht den ULPs, TCP mitzuteilen, daß es auf einen Connection Request des fremden Systems warten soll. Empfängt TCP ein solches Connection Request, so wählt das Betriebssystem des Hosts eine Portnummer aus. Die zweite Form des Verbindungsaufbaus ist die des active open-Modus. Dabei bestimmt das ULP ein socket, durch das die Verbindung aufgebaut werden soll. TCP muß wie erwähnt einige Informationen der Verbindung speichern. Dies geschieht in den sogenannten Transmission Control Blocks (TCBs). Unter anderem sind dort die local und die remote socket number, Pointer zu den Sende- und Empfängerpuffern, Pointer zur Warteschlange der erneut zu übertragenden Daten, die Sicherheits- und Prioritätspuffer und das derzeitige Segment gespeichert. 3.4.5 Protokolldatenstruktur PDUs, die zwischen zwei TCP-Modulen ausgetauscht werden, nennt man Segmente. Abbildung 19 [Black 95] zeigt das Format eines solchen Segments. Es besteht aus den beiden Teilen Header und Daten. Die ersten beiden Felder des Segments beschreiben den Quell- und den Zielport. An Hand dieser 16-Bit-Felder werden die Anwendungsprogramme identifiziert, die die TCP-Verbindung belegen. Das nächste Feld beinhaltet die Sequenznummer des ersten Oktets des Datenfelds. Die Bestätigungsnummer beinhaltet die Sequenznummer des als nächstes erwarteten Oktets. Dies bestätigt, daß vorherige Daten angekommen sind. An Hand des Feldes Daten-Offset kann man bestimmen, wo das Datenfeld beginnt. Das Reserve-Feld ist für spätere Verwendung reserviert. Die nächsten sechs Felder werden Flags genannt. Sie spezifizieren Dienste und Operationen, die während einer Sitzung angewendet werden: • • • • • •
URG zeigt an, ob das “urgent pointer” Feld von Bedeutung ist. ACK zeigt an, ob das Bestätigungsfeld von Bedeutung ist. PSH gibt an, daß das Modul die Pushfunktion ausführen soll. RST zeigt an, daß die Verbindung zurückgesetzt werden soll. SYN gibt vor, daß die Sequenznummern synchronisiert werden sollen (zum Beispiel im Fall von Verbindungsaufbausegmenten, um anzuzeigen, daß eine handshake-Operation stattfindet). FIN. Dies ist vergleichbar mit dem end-of-transmission (EOT) Signal in anderen Protokollen. Es sagt, daß der Sender keine Daten mehr zu senden hat.
Das Window-Feld teilt mit, wieviele Oktets der Empfänger zu empfangen bereit ist. Das Feld Prüfsumme beinhaltet einen vom Inhalt des Segments abhängigen Wert, mit dem der Empfänger überprüfen kann, ob das Segment fehlerfrei angekommen ist. Dieser Wert ist das 16-Bit-Einserkomplement der Einserkomplementsumme aller 16-Bit-Worte in dem Segment inklusive Header und Text. Das Feld urgent pointer wird nur verwendet, wenn das URG-Flag gesetzt ist. Es gibt an, in welchem Oktet sich wichtige Daten befinden. Was mit diesen Daten passiert, hängt von der Implementierung des TCP ab. Das Option-Feld ist für zukünftige Weiterentwicklungen des TCP gedacht. Das Padding-Feld stellt sicher, daß der TCP-Header bis zu einem geradzahligen Vielfachen von 32 Bits aufgefüllt wird. Nach dem Paddingfeld folgen die Nutzerdaten. Quellport (16)
Datenoffset (4)
Reserviert (6)
U A R C G K Prüfsumme (16) Optionen (variabel)
Zielport (16) Sequenznummer (32) Bestätigungsnummer (32) P R S F S S Y I H T N N
Window (16)
Urgent Pointer (16) Padding Nutzerdaten (variabel)
Abbildung 19: Das TCP-Segment (PDU)
Seite 38
Firewall-Studie
11.09.97
SIEMENS
Transmission Control Protocol (TCP)
3.4.6 Sicherheitsbedrohungen Angriff: Spoofing Bedrohung: Maskerade Die meisten TCP- und UDP-Versionen für UNIX stellen sicher, daß nur der Systemverwalter Port-Nummern unterhalb 1024 (privilegierte Ports) benutzen kann. Fremde Systeme sollen der Authentizität von Informationen, die sie von diesen Ports erhalten, vertrauen können. Diese Einschränkung ist allerdings nur eine Konvention, deren Einhaltung von der Protokollspezifikation nicht verlangt wird. Spezifikationskonforme Implementierungen müssen sich also nicht an diese Konvention halten. Auf Einbenutzermaschinen wie PCs ist eine solche Regelung bedeutungslos. Auf Mehrbenutzermaschinen kann man jedoch privilegierten Port-Nummern aufgrund von IP-Spoofing nur dann trauen, wenn zusätzliche Maßnahmen wie Authentisierung oder Verschlüsselung der Adressen und Vertrauen in die Maschine und den Adminstrator insgesamt vorhanden sind. Angriff: Sequence Number Guessing Bedrohung: Einfügen gefälschter Nachrichten TCP erkennt anhand der für jedes gesendete Paket neuen zufällig bestimmten Initial Sequence Number alte Pakete aus vorangegangenen Verbindungen (identifizierbar durch Quellsocket und Zielsocket). Somit ist ein Man-in-the-Middle-Angriff nicht möglich. Da eine Verbindung erst dann zustande kommt, wenn beide Seiten jeweils den Empfang der Initial Sequence Number der Gegenseite quittiert haben, ist somit ein Sicherheitsmechanismus gegen replay attacks vorhanden. Kann allerdings ein Angreifer die Auswahl der Initial Sequence Number seines Opfers vorhersagen, was nach [Morris, 85; Bellovin, 89] möglich ist, so kann der Angreifer seinem Opfer eine Verbindung mit einer vertrauenswürdigen Maschine vortäuschen. Über Protokolle, die zur Authentisierung lediglich IP-Quelladressen verwenden (z.B. die “r”-Dienste), gelangt der Angreifer somit in das Zielsystem. Dieses Eindringen nach dem Vorherbestimmen der Initial Sequence Number kann durch eine Firewall verhindert werden. Um das Vorhersagen der Initial Sequence Number zu verhindern, empfiehlt [Bellovin 89], den Zeitpunkt der Sequenznummernerhöhung zufällig zu bestimmen, wobei in kleinen Zeitabständen real zu wechseln ist. Angriff: TCP-SYN-Flooding Bedrohung: Denial-of-Service TCP-SYN-Flooding [CERT-Advisory CA-96:21] kann auf zwei Arten für denial-of-service-Angriffe auf Server verwendet werden. Zum einen kann ein Angreifer auf Basis von IP-Spoofing halboffene Verbindungen etablieren. Der Angreifer-Client sendet SYN, der Opfer-Server antwortet mit SYN-ACK, aber der Client bestätigt nicht mit ACK. Solange diese Bestätigung fehlt, ist die Verbindung also halboffen. Bei einer gewissen Anzahl von halboffenen Verbindungen ist der Server nicht mehr in der Lage, neue Verbindungen anzunehmen. Dieser Angriff kann verhindert werden, indem z.B. eine Firewall IP-Spoofing nicht zuläßt (siehe Abschnitt 3.1). Zum anderen ist TCP-SYN-Flooding auch ohne IP-Spoofing möglich, indem der Angreifer als Quelle eine Adresse angibt, zu der das SYN-ACK nicht geroutet werden kann, weil sie nicht existiert, oder für den Server nicht erreichbar ist. Um dies abzuwenden, können zustandsabhängige Filter nur eine begrenzte Anzahl von SYN-Paketen zulassen. Angriff: Hijacking Bedrohung: Eindringen, Denial-of-Service, Maskerade Wenn es einem Angreifer gelungen ist, privilegierte Rechte auf einem System zu erlangen, so kann er anschließend z.B. mit Hilfe eines Tools den Kernel modifizieren. Dies ist auch von fremden Rechner aus möglich. Diese Modifikation erlaubt es ihm, bestehende Verbindungen eines beliebigen Benutzers des Systems zu übernehmen. Indem Angreifer eine bestehende Verbindung auf dem Verbindungsweg übernimmt, können Systeme übernommen werden, ohne daß ein Endknoten der Verbindung dabei direkt angegriffen wird. Man spricht in den beschriebenen Fällen von sogenanntem Hijacking [CERT-Advisory CA-95:01]. Somit umgehen Angreifer die Hürde Einmalpaßwort oder andere starke Authentisierungsmechanismen, denn sie übernehmen die Verbindung nachdem die Authentisierung erfolgt ist. Dieser Angriff läßt sich abwehren, wenn man verhindert, daß privilegierte Rechte erlangt werden können. Angriff: Asynchrone State Bedrohung: Maskerade Dieser Angriff [Joncheray 95] basiert auf dem Versuch, einen asynchronen Zustand auf beiden Seiten der TCP-Verbindung zu erzwingen, durch den der Angreifer Pakete erstellen kann, die auf beiden Seiten als echte Pakete akzeptiert werden. Dieser Angriff ist durch Verkehrsüberwachung zu erkennen. Die einzige Möglichkeit, sich vor diesem Angriff zu schützen, ist, die Daten zu verschlüsseln und zu signieren.
11.09.97
Firewall-Studie
Seite 39
SIEMENS
Bedrohungsanalyse der Protokolle
3.4.7 Filterungsmöglichkeiten Die Filterungsmöglichkeiten gegen TCP-SYN-Flooding entsprechen denen des IP-Spoofings mit zusätzlichem Einsatz von zustandsabhängiger Filterung. Weitere Filterungsmöglichkeiten sind nicht bekannt. 3.4.8 Zusammenfassung Protokoll TCP
Angriff Spoofing
Bedrohung Maskerade
TCP
Sequence Number Guessing
Einfügen von gefälschten Nachrichten
TCP TCP
TCP-SYN-Flooding Hijacking
TCP
Asynchrone State
Denial-of-Service Eindringen, Denial of Service Maskerade, Hijacking
Gegenmaßnahme Authentisierung, Verschlüsselung von Adressen Zeitpunkt der Sequenznummernerhöhung zufällig bestimmen, wobei in kleinen Zeitabständen zu wechseln ist Verhindern von IP-Spoofing Verhindern der Übernahme von privilegierten Rechten Verkehrsüberwachung, Daten verschlüsseln und signieren
3.5 User Datagram Protocol (UDP) 3.5.1 Einsatzumgebung Das User Datagram Protocol [RFC 782] ist ein verbindungsloses Protokoll der Transportschicht. Es sieht keine Transportquittungen oder andere Sicherheitsmaßnahmen für die Korrektheit der Übertragung vor. Der Header enthält u.a. zwei 16-Bit-Portnummern (siehe Abschnitt 3.4), die unabhängig von den beim TCP benutzten Portnummern sind. UDP nutzt IP über ein einfaches Anwendungsinterface und arbeitet im Prinzip als ein Multiplexer bzw. Demultiplexer für den empfangenen und gesendeten IP-Datenverkehr. UDP wird dann als Protokoll der Transportschicht verwendet, wenn nicht alle Dienste von TCP benötigt werden. Für die Nachteile von UDP wird man durch einen wesentlich geringeren Aufwand entschädigt. Insbesondere gibt es keinen Verbindungsaufbau. Das macht UDP besonders geeignet für Datenabfragen, bei denen die Menge der ausgetauschten Nachrichten klein ist, verglichen mit dem Aufwand des Verbindungsaufbaus und -abbaus bei TCP. Zum Beispiel verwenden RPC, SNMP und TFTP das Protokoll UDP. 3.5.2 Schematischer Ablauf Abbildung 20 [Black 95] zeigt, wie UDP Datagramme von IP empfängt und weiterleitet. UDP bedient sich dabei dem Portkonzept und der Zieladresse in der UDP-Nachricht, um die Datagramme zu den richtigen Anwendungen in den oberen Schichten weiterzuleiten.
Seite 40
Firewall-Studie
11.09.97
SIEMENS
User Datagram Protocol (UDP)
Port 1
Port 2
UDP Layer
IP Layer Abbildung 20: UDP-Multiplexing 3.5.3 Steuerkommandos Eine Anwendung kann folgende Funktionen von UDP nutzen: Kommando GET_SRCADDR(remote, ToS) GET_MAXSIZES(local, remote, ToS) ADVISE_DELIVPROB(sense, local, remote, ToS) REC_ICMP()
Erläuterung Wählt eine Quelladresse aus liefert die maximale Größe eines Datagramms Quittung mit Angabe bzgl. Erfolg der Lieferung Befehl zum Empfang einer ICMP-Nachricht
Tabelle 4: Steuerkommandos von UDP Dabei bedeuten • • • •
remote = remote IP address ToS = Type of Service local = local IP address sense = positive oder negative Aussage
3.5.4 Protokolldatenstruktur UDP-Nachrichten haben das in Abbildung 21 [Black 95] gezeigte Format. • Quellport identifiziert den Port des sendenden Applikationsprozesses. Dieses Feld ist optional. Wird es nicht verwendet, so steht eine 0 in diesem Feld • Zielport identifiziert den Empfängerprozeß am Zielhost. • Länge gibt die Länge des Nutzer-Datagramms inklusive Header und Nutzerdaten an. Die Mindestlänge beträgt 8 Oktets. • Prüfsumme ist ein vom IP-Header, dem UDP-Header, den Daten und dem Padding (falls vorhanden werden die Daten bis zu einem Vielfachen von 8 Oktets durch Nullen ergänzt) abhängiger Wert.
11.09.97
Firewall-Studie
Seite 41
SIEMENS
Bedrohungsanalyse der Protokolle Quellport (16) Länge (16)
Zielport (16) Prüfsumme (16) Daten
Abbildung 21: Format einer UDP-Nachricht 3.5.5 Sicherheitsbedrohungen Angriff: Flooding, UDP Packet Storm Bedrohung: Denial-of-Service Da UDP eine Flußkontrolle fehlt, kann es das Datennetz lahmlegen, indem es Router und Hosts mit Paketen überflutet. UDP hält sich an dieselben Konventionen für Port-Nummern und Server wie TCP, jedoch in einem eigenen Adreßraum. Meist verwenden die Server niedrige Port-Nummern. Da es keine virtuellen Verbindungen gibt, werden alle Pakete, die für einen bestimmten Zielport bestimmt sind, unabhängig von Quelladresse oder Quellport an denselben Prozeß weitergereicht. Ein Denial-of-Service Angriff kann auch durch sogenannten UDP packet storm auf einem System oder zwischen zwei Systemen gefahren werden. Auf einem System bewirkt er eine Leistungsminderung. Zwischen zwei Systemen kann er zum Netzzusammenbruch führen. Daher sollten unnötige UDP-Dienste auf jedem Host abgeschaltet werden, insbesondere die Dienste chargen (erzeugt eine lange Folge von Zeichen) und echo (siehe Abschnitt 3.2.5). Ferner sollten diese Dienste von einer Firewall abgewiesen werden. Der Angriff erfolgt nach folgendem Muster: Sobald eine Bezeihung zwischen zwei UDP-Diensten besteht, die jeweils Output produzieren, können diese Dienste eine hohe Anzahl an Paketen produzieren, die zu einem Denial-of-Service bei den Maschinen führen, auf denen die Dienste ablaufen. Für die Durchführung dieses Angriffs ist lediglich eine Netzverbindung notwendig. Wird zum Beispiel der chargen-Service eines Hosts mit dem echo-Service der gleichen oder einer anderen Maschine verknüpft, so werden eine sehr große Zahl an UDP-Paketen produziert. Die involvierten Maschinen werden überlastet. Sind mehrere solcher Verknüpfungen auf verschiedenen Rechnern etabliert, so kann die Überlastung das gesamte Netz betreffen. (CERT-Advisory CA:96.01) Angriff: UDP-Spoofing Bedrohung: Maskerade, Eindringen UDP-Pakete sind leichter zu fälschen als TCP-Pakete, weil es weder Quittungs- noch Laufnummern gibt. Es ist daher äußerste Vorsicht geboten, wenn man die Quelladressen solcher Pakete zur Authentisierung verwendet. Die Applikationen selbst müssen geeignete Sicherheitsvorkehrungen treffen. Angriff: Portscan Bedrohung: Denial-of-Service, Sniffing Durch systematisches Scannen aller Ports kann ein Angreifer feststellen, welche Dienste und Prozesse auf der Zielmaschine derzeit ablaufen. Das Scannen kann bei einigen Betriebssystemen auf Grund von Implementierungsschwächen zu einem Denial-of-Service oder sogar zu Systemabstürzen führen. Die erhaltenen Informationen können für weitere Angriffe verwendet werden (z.B. Sniffing). 3.5.6 Filterungsmöglichkeiten UDP-Pakete ohne Funktionalitätsverlust zu filtern, ist schwieriger als bei TCP-Paketen. Dies liegt an einem grundsätzlichen Unterschied zwischen TCP und UDP: TCP ist verbindungsorientiert und merkt sich daher Kontext, während UDP paketorientiert ist und somit die Datagramme unabhängig voneinander betrachtet. Bei TCP erlaubt das ACK-Bit die Unterscheidung zwischen eingehenden Verbindungsabfragen und Rückantworten auf ausgehende Verbindungen. Doch bei UDP fehlt ein solches Selektionskriterium. Hier kann man sich lediglich auf Quellport- oder IP-Nummern stützen, die jedoch fälschbar sind. Ein konservatives Sicherheitskonzept fordert, aus dem zu schützenden Bereich herausgehenden UDP-Verkehr praktisch vollständig zu verbieten. Nicht etwa, weil dieser eine Gefahr darstellt, sondern weil man den Antworten darauf nicht trauen kann. Die einfachere Möglichkeit ist, eingehende UDP-Pakete abzuweisen. Die einzigen Ausnahmen sind Protokolle auf Basis UDP, die über feste Port-Nummern kommunizieren. Zum Beispiel werden bei NTP (Network Time Protocol) Nachrichten jeweils zwischen den Ports 123 ausgetauscht. Da die Antworten an eine bekannte Port-Nummer statt an irgendeine zufällige im unprivilegierten Bereich gerichtet ist, können diese von der Firewall durchgelassen werden. Allerdings sollte ein Betriebsmodus von NTP - Initialisierung der Systemuhr beim Systemstart - durch eine Firewall abgewiesen werden, weil der Client dabei nicht den Port 123 verwendet.
Seite 42
Firewall-Studie
11.09.97
SIEMENS
Domain Name System (DNS)
Da in der Protokolldefinition keine Unterscheidung zwischen einer Dienstanfrage und einer Antwort vorgesehen ist, muß diese Unterscheidung von der Firewall übernommen werden. Es muß eine Kontrolle über den Zustand der Abfrage möglich sein, und es muß möglich sein, die Zugehörigkeit eines Paketes zu einer Abfrage eindeutig festzustellen. Dies kann z.B. erreicht werden, indem bei einer UDP-Abfrage der Zielport gespeichert und temporär freigegeben wird, Antwortpakete nur zu diesem Port durchgelassen werden und nach Beantwortung der Abfrage der Port wieder gesperrt wird. Um sich gegen oben beschriebene Angriffe schützen zu können, sollten unnötige UDP-Dienste gesperrt und gefiltert werden. Hierzu sollten alle UDP-Ports mit Portnummern kleiner als 1024 abgewiesen werden (mit Ausnahme der Dienste, die unbedingt benötigt werden, wie zum Beispiel DNS auf Port 53). Sollte ein externer Zugang zu UDP-Diensten notwendig sein, so sollte ein Proxymechanismus verwendet werden, um den jeweiligen Dienst vor Mißbrauch zu schützen. Ferner sollte in diesem Fall mit Tools wie Argus, tcpdump und netlog das Netz auf Mißbrauch beobachtet werden. 3.5.7 Zusammenfassung Protokoll UDP
Angriff UDP-Spoofing
Bedrohung Maskerade, Eindringen
UDP UDP
Flooding echo
Denial-of-Service Maskerade
UDP
Ausnutzen Ports
privilegierter
Maskerade, Eindringen
Gegenmaßnahme Applikationen müssen sich schützen. Quelladressen in UDP sind nicht vertrauenswürdig chargen und echo filtern Filtern von Antworten auf echo Filtern von UDPPortnummern < 1024 außer 53, bei notwendigem externen Zugang Einsatz eines Proxies
3.6 Domain Name System (DNS) 3.6.1 Einsatzumgebung Meist verwenden Benutzer alphanumerische Namen, um ihre Netzkomponenten zu identifizieren. Dies liegt daran, daß alphanumerische Namen einfacher zu behalten und einzugeben sind. Allerdings verlangt IP Adressen in numerischer Form. Das Domain Name System (DNS) ist eine spezielle verteilte Datenbank und bildet Adreßnamen auf numerische IP-Adressen ab (einige Anbieter nennen es bind, nach einer verbreiteten Implementierung). Hierzu werden Prozeduren etabliert, die die Verwendung benutzerfreundlicher Namen ermöglichen und Konventionen für die Abbildung von Namen auf IP-Adressen definieren. DNS benutzt dazu ein hierarchisches Schema. Dadurch lassen sich Administratoren benennen, die ihre eigenen Namen in der unter ihnen liegenden Hierarchiestufe verwalten können. Im Normalbetrieb senden Hosts UDP-Anfragen an DNSServer. Diese antworten entweder mit der richtigen Antwort oder verweisen auf besser informierte Server. 3.6.2 Schematischer Ablauf Das Konzept von DNS ist in Abbildung 22 [Black 95] dargestellt. Der Namensraum bei DNS ist baumförmig strukturiert. Jeder Name an einem Knoten im Baum muß in dieser Ebene eindeutig sein. Die hierarchische Namensvergebung funktioniert, indem man am Baum nach unten entlang geht und die Namen der Knoten durch einen Punkt getrennt konkateniert. Dabei wird der Name so bestimmt, daß man das letzte Blatt zuerst und anschließend die nächsthöheren Ebenen nennt (Beispiel: RD.ACME.COM.). Jeder Bereich ist durch einen eindeutigen domain name identifiziert. Dieser kann wegen der hierarchischen Struktur selbst Subdomäne einer anderen Domäne sein. So ist im Beispiel von oben die Domäne RD.ACME eine Subdomäne von RD.ACME.COM..
11.09.97
Firewall-Studie
Seite 43
SIEMENS
Bedrohungsanalyse der Protokolle
.(ROOT)
GOV
EDU
ARPA
WIDGETCO
RD
ACME
COM
MIL
SMALLFRY
ORG
BIGFRY
CON
... etc.
MKT Abbildung 22: Konzept von DNS
DNS verwendet zwei logische Bäume. Der eine setzt Systemnamen in IP-Adressen um. Dabei kann noch Information über den Host in der Antwort mitgesendet werden. Der andere setzt IP-Adressen in Systemnamen um (letzterer wird oft inverser Baum genannt). Allerdings wird zwischen beiden Bäumen keine Konsistenz garantiert (s.u.). Derzeit beinhaltet das DNS neben verschiedenen Länderdomänen (z.B. .de, .uk, .fr) sieben Domänen-Namen: • • • • • • •
GOV EDU ARPA COM MIL ORG CON
eine Regierungseinrichtung ein Bildungsinstitut ARPANET-Internet Host-Identifikation kommerzielle Unternehmen militärische Organisationen andere oben noch nicht genannte Organisationen Länder, die den ISO Standard für Namen (ISO 3166) benutzen
Die eigentliche Abbildung von Namen auf IP-Adressen wird vom name server und name resolver erledigt. Der Benutzer richtet seine Anfrage an einen lokalen Agenten (der sogenannte name resolver). Dieser überprüft seinen Cache auf Informationen aus dem Domänen-Namen. Enthält der Cache keine ausreichenden Informationen, so leitet der name resolver die Anfrage weiter an den name server. Der name server kann anhand seiner Datenbank und seines Caches den Namen in die IP-Adresse übersetzen oder die Anfrage an einen name server weiterleiten, der die Anfrage beantworten kann. Abbildung 23 [Black 95] zeigt die Struktur der Domänen-Namen-Auflösung. Dabei sendet der name resolver eine Anfrage an den name server. Der name resolver agiert wie ein Dienstleister zum Benutzerprogramm. Umgekehrt agiert er wie ein Benutzer zum name server.
Seite 44
Firewall-Studie
11.09.97
SIEMENS
Domain Name System (DNS)
Cache
References
Additions
Foreign Name Server
Response
Query
Database Query
Query
User Response
Name Resolver
Response
Name Server Database
Additions
References
References
Additions
Cache
Cache
Abbildung 23: Struktur der Namensauflösung 3.6.3 Protokolldatenstruktur Jeder Knoten im Baum beinhaltet Informationen über seine Ressourcen. Diese Information zusammen mit dem Knoten und einem Namen nennt man resource record (RR). Dieser RR ist in einer Datenbank gespeichert und definiert eine Zone einer Domäne. Das Format der RRs ist in Abbildung 24 [Black 95] dargestellt. Dabei bedeutet • •
name: TTL:
•
class:
• • •
type: RD length: RDTA:
11.09.97
Domänen-Name des Knotens für dieses RR. Time to live Parameter. Spezifiziert die Gültigkeitsdauer dieses RRs in Sekunden. Beinhaltet den Wert des RR Klassencodes: IN = Internet, CH = Chaos System. Beschreibt den RR-Typcode. Spezifiziert die Länge des Datenfeldes RDATA in Oktets. Beschreibt die Ressource in Abhängigkeit von Typ und Klasse des RR.
Firewall-Studie
Seite 45
SIEMENS
Bedrohungsanalyse der Protokolle
NAME (Variable) TYPE (16) CLASS (16) TTL (32) RDLENGTH (16) RDATA (Variable)
Abbildung 24: Format der Resource Records Abbildung 25 [Black 95] zeigt das Format der DNS Nachrichten. Diese werden zwischen name servern ausgetauscht, um die RR zu aktualisieren. Die Nachricht besteht aus 5 Teilen. • • • • •
Header Question Answer Authority Additional Record
beinhaltet Informationen über die Art der Frage oder Antwort. formuliert eine Frage an den name server. beinhaltet RRs, die zum autorisierten name server verweisen. beinhaltet den autorisierten name server. enthält bei der Frage unterstützende RRs.
Header Question Answer Authority Additional
Abbildung 25: Format der DNS-Nachrichten 3.6.4 Sicherheitsbedrohungen Angriff: DNS-Spoofing Bedrohung: Maskerade, Eindringen Gelingt es dem Angreifer, den DNS-Baum, der Systemnamen in IP-Adressen umsetzt, derart zu manipulieren, daß dieser auf eine Anfrage gefälschte IP-Adressen zurückliefert, so kann der Angreifer den Namen eines vertrauenswürdigen Systems in seine IP-Adresse übersetzen. Umgekehrt kann der Angreifer den inversen DNS-Baum zu seinen Gunsten manipulieren, indem er dem inversen Eintrag mit der Adresse des Angreifersystems den Namen eines vertrauten Systems zuordnet. Beide Manipulationen ermöglichen dem Angreifer den Mißbrauch eines Dienstes, der nur anhand von IP-Adressen authentifiziert (z.B. rlogin). Aktuelle Implementierungen sind gegen den zweitgenannten Angriff immun, da sie, nachdem sie von DNS den mutmaßlichen Seite 46
Firewall-Studie
11.09.97
SIEMENS
Domain Name System (DNS)
Host-Namen erhalten haben, im Gegenzug die diesem Namen zugeordnete IP-Adresse prüfen. Ist es nicht die Quelladresse, so wird der Verbindungsaufbau abgebrochen und als sicherheitsrelevant protokolliert. Angriff: Penetration des DNS-Caches Bedrohung: Denial-of-Service Ein Angreifer kann vor dem eigentlichen Eindringversuch den DNS-Cache seines Ziels mit Fehlinformationen infiltrieren oder durch Überfluten das DNS verwirren. Dann versagt die Konsistenzprüfung. Daher sollten gefährdete Systeme nicht namensbasiert, sondern adreßbasiert authentifizieren, obwohl Authentisierung durch IP-Adressen selbst einige Schwächen hat. Angriff: Sniffing Bedrohung: Maskerade DNS ist eine reiche Informationsquelle für Systemnamen und -adressen, Organisationsstrukturen u.ä. Zusätzlich kann ein Angreifer mittels inverser DNS-Anfragen den gesamten Adreßraum des Datennetzes durchsuchen. Er erhält eine Liste von Host-Namen, über die er durch DNS-Anfragen weitere Informationen erhalten kann. Angriff: IP-Spoofing Bedrohung: Abhören, Maskerade Ein kombinierter Angriff auf DNS und die Routingmechanismen beruht darauf, daß ein Angreifer alle Requests an den DNS, Namen in IP-Adressen zu übersetzen, mithört und stattdessen die IP-Adresse eines zuvor bereits gekaperten Hosts liefert. Dadurch kann der Angreifer die gesamte Kommunikation ausspähen und Paßworte sammeln. Somit sind DNS-Server ein sehr attraktives Angriffsziel. Dies impliziert, daß DNS-Server nur auf gesicherten Rechnern installiert sein sollten. Angriff: Recursive Zone Transfer Request Bedrohung: Maskerade DNS besitzt einen Zonen-Transfer Request. Dieser kann dazu benutzt werden, einen Teil der DNS Datenbank zu kopieren [Bellovin 89]. Wendet ein Angreifer diesen Request rekursiv an, so kann er eine komplette Aufzeichnung des Namenraums produzieren. Um dies abzuwehren, besitzt DNS den Fehlercode refused. Jeder Zonen-Transfer Request von einem unbekannten Host sollte mit refused beantwortet werden. Allerdings kann die Authentisierung hier nur mittels IP-Source-Adresse erfolgen. Jüngste Entwicklungen versuchen, DNS mit Authentisierungsmechanismen auszurüsten. Diese authentifizieren die DNS-Informationen, die ein Knoten als Antwort auf einen DNS-Request erhält. Sie erlauben ferner, unterschriebene öffentliche Schlüssel im DNS und im nachfragenden System zu speichern, um diese zu authentifizieren. Diese Erweiterungen werden derzeit im IETF standardisiert. Die öffentlichen Schlüssel können auch bei der Implementierung eines dynamischen Key-Managements verwendet werden [Atkinson 97]. 3.6.5 Filterungsmöglichkeiten Ein DNS-Server verwendet standardmäßig Port 53 für alle UDP-Übertragungen und als Server-Port für TCP. TCP-Anfragen erfolgen auf einer beliebigen Portnummer oberhalb von 1023. Ein DNS-Client benutzt sowohl für UDP als auch für TCP eine beliebige Portnummer oberhalb von 1023. Somit lassen sich folgende Vorgänge unterscheiden: • • •
Anfrage eines Clients an den Server: Quellportnummer über 1023, Zielport 53. Antwort des Servers an den Client: Quellport 53, Zielportnummer über 1023. Anfragen und Antworten zwischen Servern: bei UDP werden Quell- und Zielport 53 benutzt, bei TCP verwendet der anfragende Server eine Portnummer über 1023.
Eine Filterregelmenge könnte wie folgt aussehen [Chapman, Zwicky 96]13. Dabei beschreibt jede Zeile eine "Erlaubt"-Regel. Alles, was nicht erlaubt ist, ist verboten.
13
Die Tabelle zeigt alle möglichen filterbaren Regeln. Ein Administrator kann je nach Sicherheitspolitik anhand der Spalte „Bemerkungen“ diejenige Regel aussuchen, deren zugehörige Kommunikation zugelassen werden, und als Filterregel in der vom Hersteller des Paketfilters vorgeschriebenen Syntax implementieren. 11.09.97
Firewall-Studie
Seite 47
SIEMENS Richtung
Bedrohungsanalyse der Protokolle
ein
QuellAdresse extern
Zieladresse intern
Protokoll UDP
Quellport > 1023
Zielport 53
ACK gesetzt nicht möglich
aus
intern
extern
UDP
53
> 1023
nicht möglich
ein
extern
intern
TCP
>1023
53
ja, außer im ersten
aus
intern
extern
TCP
53
> 1023
ja
aus
intern
extern
UDP
> 1023
53
nicht möglich
ein
extern
intern
UDP
53
> 1023
nicht möglich
aus
intern
extern
TCP
> 1023
53
ja, außer im ersten
ein
extern
intern
TCP
53
> 1023
ja
ein
extern
intern
UPD
53
53
nicht möglich
aus
intern
extern
UDP
53
53
nicht möglich
ein
extern
intern
TCP
> 1023
53
ja, außer im ersten
aus
intern
extern
TCP
53
> 1023
ja
aus
intern
extern
TCP
> 1023
53
ja, außer im ersten
ein
extern
Intern
TCP
53
> 1023
ja
Bemerkungen Eingehende Anfrage über UDP; Client an Server Antwort auf eingehende UDPAnfrage, Server an Client Eingehende Anfrage über TCP, Client an Server Antwort auf eingehende TCPAnfrage; Server an Client Ausgehende Anfrage über UDP; Client an Server Antwort auf ausgehende UDPAnfrage; Server an Client Ausgehende Anfrage über TCP; Client an Server Antwort auf ausgehende TCPAnfrage, Server an Client Anfrage oder Antwort zwischen zwei Servern über UDP Anfrage oder Antwort zwischen zwei Servern über UDP Anfrage externer Server an internen Server über TCP, Anfrage ZonenTransfer Antwort interner Server an externen Server über TCP; Antwort auf ZonenTransfer Anfrage des internen Servers an den externen Server über TCP Antwort des externen Server an internen Server über TCP
Tabelle 5: DNS-Filterungsmöglichkeiten
Seite 48
Firewall-Studie
11.09.97
SIEMENS
Address Resolution Protocol (ARP)
3.6.6 Zusammenfassung Protokoll DNS
Angriff DNS-Spoofing
DNS DNS
Penetration Caches Sniffing
DNS
IP-Spoofing
DNS
Recursive Request
Bedrohung Maskerade, Eindringen des
DNS
Denial-of-Service Maskerade Maskerade
Zone
Transfer
Maskerade
Gegenmaßnahme neue DNS Implementierungen verwenden kryptographische Authentisierung von IP-Adressen inverse DNS-Anfragen filtern Splitten der DNS-Server in intern und extern Beantworten eines ZonenTransfer Request von einem unbekannten Host mit refused. Zusätzlich kryptographische Authentisierung von IP-Adressen.
3.7 Address Resolution Protocol (ARP) 3.7.1 Einsatzumgebung IP-Pakete werden im allgemeinen über Ethernet verschickt, dessen Endgeräte die 32 Bit breiten IP-Adressen nicht verstehen, da diese Pakete der Breite 48 Bit verarbeiten. Daher müssen die IP-Treiber die IPZieladressen in Ethernet-Zieladressen umsetzen. Diese Umsetzung erfolgt im wesentlichen über Tabellen an Hand des Address Resolution Protocols (ARP). Dazu sendet ARP einen Ethernet-Broadcast, der die gewünschte IP-Adresse enthält. Der Host mit dieser Adresse oder ein stellvertretendes System antworten mit einem Paket, welches das IP-Ethernet-Adreßpaar enthält. Das fragende System speichert das Adreßpaar kurzzeitig in einem Cache, um diese nicht erneut erfragen zu müssen. 3.7.2 Sicherheitsbedrohungen Angriff: Fälschen von ARP-Antworten Bedrohung: Umleiten Es ist möglich, daß eine Maschine ARP-Antworten fälscht, um so den Datenverkehr auf sich selbst umzulenken. Dadurch kann diese Maschine sich für einen anderen Host ausgeben oder Datenströme selbst modifizieren. Insofern ist ARP nur sicher, solange ausschließlich vertrauenswürdige Maschinen auf dem lokalen Datennetz senden können. Um solche Attacken zu vereiteln, können zum Beispiel ARP-Tabellen fixiert und das automatische Ablaufen von ARP unterbunden werden. Aufgrund der Tatsache, daß ARP nicht das InternetProtokoll benutzt, kann IPv6 mit seinen Sicherheitsmechanismen dieses bezüglich Authentizität nicht schützen. Daher soll ARP durch Neighbor Discovery - ein neues Protokoll basierend auf ICMP - ersetzt werden [Atkinson 97]. 3.7.3 Filterungsmöglichkeiten ARP arbeitet zwischen der physikalischen Schicht und der Vermittlungsschicht und verwendet somit keine Ports. Somit können die auf der Vermittlungsschicht arbeitenden Paketfilter einer Firewall ARP nicht sinnvoll filtern. Die einzige Möglichkeit ARP zu sichern, besteht im Schutz der ARP-Tabellen (d.h. Abblocken von ARP sowie Deaktivierung des ARP Dienstes auf der Firewall) und dem Fixieren von Einträgen (statische Tabellen). 3.7.4 Zusammenfassung Protokoll ARP
11.09.97
Angriff Fälschen von ARPAntworten
Bedrohung Umleiten
Firewall-Studie
Gegenmaßnahme ARP Tabellen fixieren, automatisches Ablaufen von ARP unterbinden, Abblokken auf der Firewall
Seite 49
SIEMENS
Bedrohungsanalyse der Protokolle
3.8 Einführung Routing Router sorgen dafür, daß Datenpakete auf dem Weg durch das Internet bestimmte Wege wählen. Sie verbinden verschiedene Netze und arbeiten auf der Netzschicht mittels Netzschicht-Adressen. Router bieten Vermittlungsfunktionen und Flußkontrolle. Die Vermittlungsfunktion erfolgt nach den Methoden source routing oder nonsource routing. Beim source routing bestimmt das Ursprungsgerät (die Quelle) die Route des Datenpaketes durch das Internet. Es gibt dabei die Adressen der Zwischenknoten, die durchlaufen werden sollen, explizit an. Der Router muß in diesem Fall keine Adressen pflegen, sondern leitet das Datenpaket lediglich an die im Routerfeld des Datenpaketes nächststehende Adresse weiter. Beim nonsource routing entscheidet der Router über die Route des Datenpaketes. Diese Entscheidungen trifft der Router über Routing-Tabellen. Sofern sich der Zielhost in einem anderen Netz befindet, muß der IP-Router entscheiden, wie er ein Datenpaket zu dem anderen Netz routen kann. Sind mehrere Zwischensprünge am Kommunikationsprozeß beteiligt, so muß jeder Router überquert werden und Routingentscheidungen treffen. Dazu pflegt jeder Router eine Routing-Tabelle (s.u.), die den nächsten Router auf dem Weg zum Zielrouter beinhaltet. Diese Tabelle enthält die IP-Adresse für jedes erreichbare Netz und die IP-Adresse, zu der Datenpakete für dieses Netz weitergeleitet werden sollen. Diese Adresse ist so zu wählen, daß eine gewissen „Abstandsmetrik“ minimiert wird. IP-Routing basiert also auf dem Konzept der Abstandsmetrik. Dies ist zum Beispiel die Anzahl an Hops zwischen dem Router und dem Zielort. IP bietet zwei Source-Routing-Optionen an. Die erste (loose source routing genannt) ermöglicht dem IPModul, Zwischensprünge auszuführen, sofern die auf der Sourceliste stehenden Knoten auf jeden Fall überquert werden. Dieser Vorgang ist aus Sicherheitssicht sehr bedenklich, da der Angreifer Pakete umleiten könnte. Im Gegensatz dazu werden bei strict source routing nur diejenigen Router passiert, deren Adressen in der Sourceliste aufgeführt sind. Kann dabei dieser Route nicht gefolgt werden, so wird der Sender mit einer Fehlermeldung benachrichtigt. Routing-Tabellen. Jede Zeile der IP-Routing-Tabelle (siehe Tabelle 6 [Black 95]) beinhaltet einen Eintrag für jede Route, die demjenigen IP-Modul bekannt ist, das die Tabelle speichert. Die Spalten beschreiben die Information, die auf jeder Route verfügbar ist. Hier eine Beschreibung der Spalten: • Ziel beinhaltet die IP-Adresse des Ziels. • IfIndex steht für den Interface-Index. Er identifiziert das lokale Interface (auch unter physikalischem Port bekannt), durch das der nächste Hop in der Route erreicht werden kann. • Die nächsten fünf Spalten enthalten Metriken. Die Metrik-Einträge beinhalten Informationen über die Kostenmetrik für die Bestimmung der Route. In den meisten Systemen ist die Kostenmetrik die Anzahl der Hops, die benötigt werden, um das Ziel zu erreichen. Mit der Entwicklung komfortablerer Route-Entdeckungsprotokollen (wie z.B. OSPF) kann man mehr als eine Kostenmetrik benutzen. Daher können bis zu fünf Metriken gespeichert werden. • Next Hop bestimmt die IP-Adresse des nächsten Hops dieser Route. • Route Type bestimmt zusätzliche Informationen für die Route, wie z.B. "keine der folgenden", "eine ungültige Route", "direkt" oder "indirekt". • Routing Protokoll identifiziert das Route-Entdeckungsprotokoll, mit der diese Route entdeckt wurde (z.B. RIP oder OSPF). • Route Age besagt in Sekunden, wieviel Zeit seit dem letzten Update oder der letzten Verifikation vergangen ist. • Das nächste Feld in der Tabelle beinhaltet die Route Mask für diese Route. Diese Maske wird logisch UND-verknüpft mit der Zieladresse im IP-Datagramm und dann mit der ersten Spalte der Routing-Tabelle verglichen. • Die letzte Spalte Route Information erlaubt einen Verweis zu einer Management Information Database (MIB)-Definition, die zu einem besonderen Routing-Protokoll gehört. Dessen Wert hängt vom Typ des in dieser Zeile verwendeten Routing-Protokolls ab.
Seite 50
Firewall-Studie
11.09.97
SIEMENS
Einführung Routing Ziel
If Index
Metrik 1
Metrik 5
Next Hop
Route Typ
Routing Protokoll
Route Age
Routing Maske
Route 1 Route 2 Route 3 Route n
Tabelle 6: IP-Routing-Tabelle Im folgenden werden verschiedene Routing-Protokolle untersucht. 3.8.1 Routing Information Protocol (RIP) 3.8.1.1 Einsatzumgebung Routing Protokolle wie RIP [RFC 1058] oder OSPF (Open Shortest Path First) dienen der dynamischen Suche nach geeigneten Wegen im Internet. Sie sind grundlegend für den Betrieb von TCP/IP. Dabei werden zwei Routen festgelegt: von der Quell- zur Zielmaschine und zurück. Der Rückweg ist gewöhnlich die Umkehrung des Hinwegs (andernfalls spricht man von asymmetrischen Routing). Somit können Veränderungen der Routen zwischen zwei vernetzten Systemen an die beteiligten Systeme weitergeleitet werden, was eine dynamische Änderung der Routing-Tabellen ermöglicht. 3.8.1.2 Schematischer Ablauf RIP wurde ursprünglich für LANs entwickelt, daher basiert es auf einer Broadcast-Technologie: ein Router sendet periodisch seine Routing-Tabellen zu seinen Nachbarn. Maschinen, die an RIP-Operationen beteiligt sind, werden in aktiv oder passiv eingeteilt. Aktive Maschinen (gewöhnlich Gateways) machen Routen zu anderen Maschinen publik. Passive Maschinen (gewöhnlich Hosts) erhalten diese Routeninformation und aktualisieren damit ihre Routing-Tabellen. Als Kostenmetrik sind Anzahl der Hops, Verspätung, Sicherheit oder Bandbreite möglich. Die meisten Implementierungen nutzen jedoch die Anzahl der Hops zur Zieladresse als Entscheidungskriterium. Dabei ist 16 die Anzahl der Hops, ab der ein Netz als unerreichbar gilt. RIP benutzt zur Informationsübertragung das User Data Protocol (UDP). Dabei wird der Port 520 benutzt, um RIPNachrichten zu senden und zu empfangen. Jeder Knoten, der mittels RIP geroutetet wird, besitzt eine Routing-Tabelle. Mit jeder Route werden zwei Timer verbunden: ein time-out timer und ein garbage-collection timer. Der time-out timer wird dann gesetzt, wenn eine Route initialisiert oder aktualisiert wird. Wenn 180 Sekunden ablaufen, bevor eine Aktualisierung erhalten wird, oder wenn die Abstandsmetrik einen Eintrag von 16 enthält, wird die Route nicht beachtet. Dann wird der garbage-collection timer gesetzt, der nach weiteren 120 Sekunden diese Route aus der Tabelle entfernt. Ein weiterer Timer wird verwendet, um sogenannte responses an Nachbarmaschinen zu senden. Alle 30 Sekunden werden diese Nachrichten durch aktive Maschinen gesendet. Diese beinhalten Wertepaare. Einer dieser Werte ist die IP-Adresse, der andere ist die Anzahl der notwendigen Hops, von der Ursprungsadresse beginnend gezählt. 3.8.1.3 Protokolldatenstruktur Das Nachrichtenformat ist in Abbildung 26 [Black 95] dargestellt. Dabei besteht ein Header aus drei Feldern: • Command: • Version: • Reserved:
dieser Wert ist 1, wenn ein Request vorliegt und 2, wenn es sich um eine Antwort handelt, spezifiziert die Versionsnummer des Protokolls, wird nicht benutzt.
Es folgt eine Menge von Feldern, deren Werte eine bestimmte Protokollfamilie identifizieren. Da RIP auch in anderen Netzwerkprotokollen außer dem Internet-Protokoll eingesetzt werden kann, identifiziert das Feld family of net 1 die Protokollfamilie. Internet-Anwendungen bekommen den Wert 2. Die nächsten 12 Oktets enthalten die Netzwerk ID (net 1 address). Allerdings benötigt eine IP-Adresse nur 4 der 12 Oktets. RIP unterscheidet dabei nicht zwischen den Typen von Adressen in der Nachricht. Das Metrik-Feld beinhaltet den Wert der Metrik. 11.09.97
Firewall-Studie
Seite 51
Route Information
SIEMENS
Bedrohungsanalyse der Protokolle
Command Version Reserved Repeat for each set
Family of Net 1 Net 1 Address (32) Net 1 Address (32) Net 1 Address (32) Metric Abbildung 26: Das RIP-Nachrichtenformat 3.8.1.4 Sicherheitsbedrohungen Angriff: Loose-Source-Routing Bedrohung: Maskerade, Umleiten Es gibt eine Reihe von Möglichkeiten, Standardmechanismen des Routing anzugreifen. Am einfachsten ist, die Option zur freien Senderwegwahl von IP - loose source route - zu nutzen. Der Initiator einer TCPVerbindung kann damit eine explizite Route zum Ziel angeben und den üblichen automatischen RoutingVorgang umgehen. Die einfachste Verteidigung gegen einen solchen Angriff ist, Pakete mit Loose-Source-Route-Option abzuweisen. Der Rückweg einer Route ist aus Sicherheitssicht besonders wichtig. Kann nämlich ein Angreifer die Routing-Strategien unterwandern, so kann er sich dem angegriffenen Host gegenüber als ein vertrauenswürdiges System ausgeben. In diesem Fall versagen Authentisierungsmechanismen, die sich allein auf die Verifikation von Quelladressen verlassen. Angriff: RIP-Spoofing Bedrohung: Umleiten Da RIP als Informationsträger UDP verwendet, ist es recht einfach, gefälschte RIP-Nachrichten ins Netz einzuschleusen. Befindet sich der Host des Angreifers näher am Ziel als das Quellsystem, so kann er den Datenverkehr leicht umlenken. Router können und sollten so konfiguriert werden, daß sie wissen, welche Routen auftauchen dürfen (statisches Routen). 3.8.1.5 Filterungsmöglichkeiten RIP ist ein Dienst auf Basis von UDP. RIP-Server überwachen Port 520 auf Broadcasts anderer Server und Anfragen von Clients. RIP-Server senden ihre Broadcasts gewöhnlich auf Port 520. RIP-Clients benutzen gewöhnlich Portnummern über 1023. Folgende Tabelle gibt eine "Erlaubt"-Regelmenge an. Alles, was nicht erlaubt ist, ist verboten [Chapman, Zwicky 96]13.
Seite 52
Firewall-Studie
11.09.97
SIEMENS
Richtung
Einführung Routing
Zieladresse
Protokoll
Quellport
Zielport
Ein
Quell Adresse Extern
ACK gesetzt nicht möglich
intern
UDP
> 1023
520
Aus
Intern
extern
UDP
520
> 1023
nicht möglich
Aus
Intern
extern
UDP
>1023
520
nicht möglich
Ein
Intern
extern
UDP
520
> 1023
nicht möglich
ein
Extern
Broadcast
UDP
520
520
nicht möglich
aus
Intern
Broadcast
UDP
520
520
nicht möglich
Bemerkungen Anfrage des externen Clients an den internen Server Antwort des internen Servers an den externen Client Anfrage des internen Clients an den externen Server Antwort des externen Servers an den internen Client Broadcast des externen Servers an interne Server Broadcast des internen Servers an externe Server
Tabelle 7: RIP-Filterungsmöglichkeiten 3.8.1.6 Zusammenfassung Protokoll RIP
Angriff Loose-Source-Routing
Bedrohung Maskerade, Umleiten
RIP
RIP-Spoofing
Umleiten
Gegenmaßnahme Filtern von Paketen mit loose source routing Option statisches Routen
3.8.2 Border Gateway Protocol (BGP) 3.8.2.1 Einsatzumgebung Border Gateway Protocol [RFC 1267] ist ein Routing-Protokoll zwischen autonomen Systemen14 (AS). Wie innerhalb dieser autonomen Systeme geroutet wird, ist für BGP nicht von Interesse. An Hand der Information, die über BGP ausgetauscht wird, läßt sich ein Graph ableiten, mittels dessen Routing-Schleifen entfernt und Routing-Entscheidungen getroffen werden können. Dabei publiziert BGP alle autonomen Systeme auf dem Weg zur Zieladresse, wodurch sich ein Knoten den besten Pfad auswählen kann. Wesentliches Merkmal von BGP sind die Pfadattribute, die in der sogenannten Network Layer Reachability Information (NLRI) zusammengefaßt sind. Pfadattribute werden in well-known und optional eingeteilt. Durch optionale Attribute kann man Experimente durchführen, die nur eine Gruppe von BGP-Router betreffen, den Rest jedoch nicht beeinflussen. Das wichtigste Pfad-Attribut ist der AS-PATH. Um Bandbreite und Prozessorbelegung zu sparen, benutzt BGP eine inkrementelle Aktualisierung der Route-Information. Dabei werden nur Änderungen übertragen. Ferner kann BGP Informationen über Routes in Gruppen zusammenfassen. 3.8.2.2 Schematischer Ablauf Grundlage von BGP ist TCP. Zwei Maschinen tauschen Nachrichten aus, um die Verbindungsparameter festzulegen und zu bestätigen. Der Datenfluß zu Beginn ist dabei die gesamte BGP-Routing-Tabelle. Aktualisierungen werden gesendet, sobald die Routing-Tabelle sich ändert. Dabei benötigt BGP keine periodischen Auffrischungen der gesamten Routing-Tabelle. Somit muß ein BGP-Sprecher (eine Maschine, die BGPNachrichten aussendet) die gesamte derzeitige Version der BGP-Routing-Tabelle bis zum Ende der Verbindung behalten. Lebenszeichen werden periodisch gesendet, um sicherzustellen, daß die Verbindung noch aufrechterhalten ist. Der Host, der BGP ausführt, muß dabei kein Router sein. Ein nichtroutender Host kann RoutingInformationen mit anderen Routern über ein internes Routing-Protokoll austauschen. Dieser nichtroutende Host könnte dann BGP verwenden, um Routing-Informationen mit dem Grenzrouter eines anderen autonomen Systems auszutauschen. 14
zum Beispiel die Teil-LANs eines VPNs.
11.09.97
Firewall-Studie
Seite 53
SIEMENS
Bedrohungsanalyse der Protokolle
Sofern ein besonderes AS mehrere BGP-Sprecher besitzt und Übertragungsdienste für andere ASs übernimmt, muß auf die Konsistenz des Routing innerhalb des AS geachtet werden. Dies wird durch das interne Routing-Protokoll gewährleistet. Konsistenz außerhalb des AS wird durch die Tatsache gewährleistet, daß alle BGP-Sprecher untereinander durch BGP verbunden sind. 3.8.2.3 Attribute BGP definiert mehrere Attribute, die in den Aktualisierungsnachrichten mitversendet werden. Die wichtigsten sind: ORIGIN AS_PATH NEXT_HOP UNREACHABLE
definiert den Ursprung der Pfadinformation. listet die autonomen Systeme auf, die überquert werden müssen, um das Zielnetz zu erreichen. enthält die IP-Adresse des Grenzrouters, der als nächstes benutzt werden muß. teilt dem Sprecher mit, daß eine zuvor ausgewählte Route unerreichbar geworden ist.
3.8.2.4 Protokolldatenstruktur Die folgenden Tabellen beschreiben die Struktur des Headers, der open message und der update message. In Klammern ist die Länge des Feldes in Bit angegeben. Marker kann der Authentisierung oder zum Erkennen fehlender Synchronisation zwischen Partnerinstanzen von BGP dienen. Length gibt die Länge der gesamten Nachricht inklusive Header in Oktets an. Type gibt an, ob es sich um eine open-, update-, notification- oder keep-alive Nachricht handelt.
Marker (64) Length (16) Type (8)
Header Version gibt die verwendete BGP-Version an. My AS enthält die autonome Nummer des Senders. Hold Time gibt die maximale Zeit an, in der aufeinanderfolgende Nachrichten des im Header angegebenen Typs ankommen sollen. BGP ID ist die IP-Adresse eines Senders, diese bleibt während der Lebensdauer der Nachricht gleich. Auth code identifiziert den Authentisierungsmechanismus. Auth data beinhaltet die zugehörigen Daten Version (8) My AS (16) Hold Time (16) BGP ID (32 Auth code (8) Auth data (Variable)
Open Message Total length gibt die Länge des Feldes Path attributes an. Path attributes enthält Informationen, ob das Attribut optional/required oder partial/full ist. Außerdem enthält es das Attribut (s.o.). Network 1 bis Network n gibt die Netze an, die diese Nachricht durchlaufen soll. Total length (16) Path attributes (Variable) Network 1 (32) Network n (32)
Update Message 3.8.2.5 Sicherheitsbedrohungen/Filterungsmöglichkeiten Angriff: Spoofing Seite 54
Firewall-Studie
11.09.97
SIEMENS
Einführung Routing
Bedrohung: Maskerade, Umleiten BGP bietet schwache Mechanismen zur Authentisierung an. Dabei werden BGP-Sitzungen an Hand des BGPIdentifiers einer Instanz und der Nummer des autonomen Systems, die durch eine Instanz publik gemacht wird, im Marker-Feld authentifiziert. Diese Nummern können vorhergesagt oder ausgetestet werden. In der Open Message sind Felder reserviert für optionale applikationsabhängige Authentisierung. Wird von der Applikation ein starker Authentisierungsmechanismus verwendet, so ist die Gefährdung durch Spoofing abgewendet. Angriff: NOTIFICATION Bedrohung: Denial-of-Service Alle Authentisierungsfehler führen zum Aussenden der Nachricht NOTIFICATION und zum Abbruch der BGP-Verbindung. Da BGP über TCP und IP läuft, ist BGP verwundbar bezüglich der Angriffe auf TCP und IP. Jüngste Entwicklungen haben algorithmenunabhängige kryptographische Authentisierung für RIP und OSPF Nachrichten entwickelt [Atkinson 97]. Diese verwenden den Keyed MD5 Algorithmus, um den Knoten zu authentifizieren, der das Routingpaket sendet. Hierdurch werden alle Angriffe auf Routingprotokolle abgewehrt mit Ausnahme der Replay-Attacke. Das Inter-Domain Routing Protokoll wird BGP in Zukunft ersetzen. Es übernimmt jedoch die Authentisierungsmöglichkeiten von BGP. 3.8.2.6 Zusammenfassung Protokoll BGP BGP
Angriff Spoofing NOTIFICATION
Bedrohung Maskerade, Umleiten Denial-of-Service
Gegenmaßnahme starke Authentisierung Filtern von NOTIFICATION
3.8.3 Open Shortest Path First (OSPF) 3.8.3.1 Einsatzumgebung Das Open Shortest Path First Protokoll [RFC 1247] ist ein für das Internet und Intranets maßgeschneidertes Routing-Protokoll. Grundlage für Entscheidungen sind zwei Felder im IP-Datagramm: Die Zieladresse und der Type of Service (ToS). OSPF ist ein dynamisches Protokoll, das Probleme im Netz behebt und unnötige Schleifen im Datenverkehr auflöst. 3.8.3.2 Schematischer Ablauf Jeder Router enthält ein Routing-Verzeichnis (in OSPF routing database genannt). Diese Datenbank enthält Informationen über die Schnittstellen am Router und Informationen über den jeweiligen Nachbarn. Die Information über den Nachbarn besteht aus der Topologie des Netzes und wird durch einen gerichteten Graphen beschrieben. Dabei bilden Router und Netze die Ecken des Graphen. Wie bei RIP werden diese Informationen periodisch per Broadcast übertragen. Ein OSPF-Router berechnet den kürzesten Weg zu einem anderen Router. Dabei können im Gegensatz zu RIP für jede ToS separate Metriken berechnet werden. Die Graphen beinhalten Werte zwischen zwei Punkten, entweder Netze oder Gateways. Diese Werte stellen den gewichteten kürzesten Pfad aus der Sicht der Wurzel (der im Moment arbeitende Router) dar. Die topologische Datenbank, die in der Berechnung des kürzesten Pfades benutzt wird, wird von den Informationen abgeleitet, die durch die Router an die Maschinen verteilt werden. OSPF arbeitet über dem Internet-Protokoll und verläßt sich für die Fragmentierung von großen Datenpaketen auf IP. Ferner sind einige der OSPF-Pakete multicast. Die OSPF Datenpakete werden stets in IP-Datagrammen gesendet, bei denen der IP-ToS-Wert null ist. Es wird empfohlen, daß OSPF-Pakete als hochpriore Daten eingestuft werden und Vorrang vor regulärem Verkehr bekommen. Dafür eignet sich das IP-Precedence-Feld. 3.8.3.3 Protokolldatenstruktur Abbildung 27 [Black 95] beschreibt den Header der OSPF-Datenpakete. Jedem OSPF-Datenpaket ist dieser 24 Oktets lange Header vorangestellt. Er besteht aus den Feldern • • • • 11.09.97
Version TYPE Packet Length Router ID
Version des verwendeten Protokolls Typ des Pakets Länge des Feldes in Oktets inklusive des Headers identifiziert den Ursprung des Pakets Firewall-Studie
Seite 55
SIEMENS
Bedrohungsanalyse der Protokolle
• •
Area ID Checksum
•
Authentication type
•
Authentication
identifiziert die Area des Paketursprungs enthält eine Prüfsumme über das gesamte Feld inklusive des Authentisierungsfeldes derzeit gibt es die Auswahl zwischen 0 = keine Authentisierung und 1 = einfaches Paßwort der Wert der Authentisierung
Version (8) TYPE (8) Packet Length (16) Router ID (32) Area ID (32) Checksum (16) Authentication (AU) Type (16) Authentication (64) Abbildung 27: Header der OSPF-Datenpakete OSPF arbeitet mit fünf verschiedenen Datenstrukturen. Diese sind •
Protokolldaten-Struktur
•
Bereichsdaten-Struktur
•
Schnittstellendaten-Struktur
• •
Nachbardaten-Struktur Routing-Tabellen-Struktur
besteht aus Datenstrukturen wie RouterID und Routing-Tabellen, enthält Informationen über den Bereich, in dem sich der Router befindet, enthält Informationen über Router-zu-Netzwerk Operationen und Router-zu-Router Operationen, siehe Schnittstellendaten-Struktur, diese enthalten Informationen wie Zieladresse, Zieltyp, ToS, Bereich, Pfad, Kosten, nächster Sprung.
3.8.3.4 Sicherheitsbedrohungen Angriff: Paßworte abhören Bedrohung: Maskerade, Eindringen Im Gegensatz zu RIP besitzt OSPF ein explizites Authentisierungsfeld. Dies ist jedoch nur begrenzt von Wert: als Authentisierungsmechanismen werden lediglich Paßworte benutzt. Jeder, der in der Lage ist, Routing-Protokolle in die Irre zu führen, ist auch in der Lage, Paßworte, die über das lokale Ethernet wandern, auszuspähen. Angriff: Hijacking Bedrohung: Verlust der Systemkontrolle Ein autorisiertes Routing-System könnte von Angreifern gekapert werden, woraufhin seinen Nachrichten korrekt und legitim vom autorisierten System signiert - nicht mehr zu trauen wäre. Angriff: Einfügen von falschen Informationen Bedrohung: Täuschung Bei den meisten Routing-Protokollen reichen die Rechner Information nur an ihre jeweiligen Nachbarn weiter, und diese wiederholen, meist in blindem Vertrauen, was ihnen mitgeteilt wurde. So werden Täuschungen verbreitet. Abhilfe schafft da der Einsatz von Paket-Filtern (siehe Abschnitt 3.8.1).
Seite 56
Firewall-Studie
11.09.97
SIEMENS
Simple Network Management Protocol (SNMP)
3.8.3.5 Zusammenfassung Protokoll OSPF
Angriff Paßworte abhören
Bedrohung Maskerade, Eindringen
OSPF
Hijacking
Verlust der Systemkontrolle
OSPF
Einfügen falscher Informationen
Täuschung
Gegenmaßnahme starke Authentisierungsmechanismen, Paßworte verschlüsseln starke Authentisierungsmechansimen Einsatz von Paket-Filtern
3.9 Simple Network Management Protocol (SNMP) 3.9.1 Einsatzumgebung Das Simple Network Management Protocol (SNMP) dient zur Steuerung von Routern, Bridges und anderen Netzkomponenten. Sogenannte Manager und Agenten tauschen PDUs aus, wobei der Manager Informationen vom Agenten abfragt und dort Parameter setzt. Alle Management Informationen, die von SNMP behandelt werden können, sind in sogenannten managed objects (MO) vorhanden. Diese sind über ASN.1 definiert und hierarchisch im Registrierungsbaum von SNMP gespeichert. Die MO-Sammlung der Agenten wird AgentenMIB genannt. Die MOs in der MIB heißen MIB-Einträge. Die Management Information Database (MIB) ist der logische Speicherort für Netzwerk Management Information und wird lokal von den SNMP-Agenten gepflegt. Neben den gewöhnlichen SNMP Servern (Agenten) gibt es noch sog. SNMP-trap-Server, die von den Agenten (als Clients!) in zeitkritischen Fällen angesprochen werden können, wenn nicht auf die Abfrage des Managers gewartet werden kann. 3.9.2 Sicherheitsbedrohungen Angriff: Abhören des Community Strings Bedrohung: Maskerade, Eindringen Eine Authentisierung in SNMP erfolgt in der Version 1 über das sogenannte Communitiy-Konzept. Eine Community ist eine Menge von Managern, die auf einen gegebenen Agenten in gleicher Weise zugreifen dürfen. Die Community hat einen Namen (community string), der gleichzeitig als Paßwort dient und bei allen Operationen angegeben werden muß. Alle Manager, die zu einer Community gehören, verwenden denselben community string. Dabei läuft dieser ungeschützt übers Netz. Kann also ein Angreifer den community string abhören, so kann er sich als Manager ausgeben und z.B. Router zu seinen Gunsten konfigurieren Bei den Standardisierungen von SNMPv2 waren die Sicherungsdienste Integritätsschutz, Authentisierung, Vertraulichkeit und Zugriffskontrolle vorgesehen. So war z.B. die Implementierung des Keyed MD5 geplant. Wegen Differenzen im Standardisierungsgremium wurden diese Sicherungsdienste jedoch aus SNMPv2 zurückgezogen, so daß SNMPv2 wieder mit dem Community-Konzept arbeitet. Das IETF möchte 1997 einen neuen Anlauf für die Standardisierung von Sicherheitsmechanismen in SNMPv2 unternehmen. Solange gilt für SNMPv2 dasselbe wie für SNMPv1 - es sollte von Firewalls abgewiesen werden. 3.9.3 Filterungsmöglichkeiten SNMP verwendet Port 161 bzw. Port 162 (trap-Server). Somit kann es über einen statischen Paketfilter gefiltert werden, wobei dann das Erlauben beider Richtungen (Manager – Agent) notwendig ist. SNMP-Verkehr sollte jedoch von Firewalls abgewiesen werden, da eine Administration von Netzkomponenten nicht von außen möglich sein sollte (zumindest was die Abfrage interner Server betrifft). Folgende Tabelle gibt eine "Erlaubt"-Regelmenge an. Alles, was nicht erlaubt ist, ist verboten [Chapman, Zwicky 96]13.
11.09.97
Firewall-Studie
Seite 57
SIEMENS
Richtung
Bedrohungsanalyse der Protokolle
Zieladresse
Protokoll
Quellport
Zielport
aus
Quell Adresse intern
ACK gesetzt nicht möglich
extern
UDP
>1023
161
ein
extern
intern
UDP
161
> 1023
nicht möglich
aus
intern
extern
TCP
>1023
161
ja, außer im ersten
ein
extern
intern
TCP
161
> 1023
ja
aus
intern
extern
UDP
>1023
162
nicht möglich
ein
extern
intern
UDP
162
> 1023
nicht möglich
aus
intern
extern
TCP
>1023
162
ja, außer im ersten
ein
extern
intern
TCP
162
> 1023
ja
Bemerkungen Anfrage des internen Clients an den externen Server Antwort des externen Servers an den internen Client Anfrage des internen Clients an den externen Server Antwort des externen Servers an den internen Client Anfrage des internen Clients an den externen trap-Server Antwort des externen trapServers an den internen Client Anfrage des internen Clients an den externen trap-Server Antwort des externen trapServers an den internen Client
Tabelle 8: SNMP-Filterungsmöglichkeiten
3.9.4 Zusammenfassung Protokoll SNMP
Seite 58
Angriff Abhören des Community Strings
Bedrohung Maskerade, Eindringen
Firewall-Studie
Gegenmaßnahme Verschlüsseln des Community Strings oder Filtern mittels Paketfilter
11.09.97
SIEMENS
Network Information System (NIS)
3.10 Network Information System (NIS) 3.10.1 Einsatzumgebung Netzwerk-Informationsdienste wie DNS, NIS und NIS+ speichern Informationen, die Anwender, Workstations und Anwendungen für die Kommunikation über das Netz benötigen. Ohne einen NetzwerkInformationsdienst müßte jede Workstation ihre eigene Kopie dieser Daten verwalten. Dazu gehören: • • • • • •
Adressen, Sicherheitsinformationen Mail-Informationen Informationen über Ethernet-Schnittstellen Informationen über Netzwerk-Dienste Informationen über Zugriffsberechtigung auf das Netzwerk oder über die im Netzwerk zur Verfügung stehenden Dienste
Diese Informationen speichert und pflegt der Netz-Informationsdienst auf einem Server und stellt sie jeder anfragenden Workstation zur Verfügung. Das Network Information System [RFC 1094] gehört zu den Netz-Informationsdiensten und dient der Verteilung wichtiger, zentraler Konfigurationsdateien von einem Server an seine Clients. Darunter fallen Namen, Adressen von Workstations, Informationen über Benutzer, wie die Paßwortdatei, die Tabelle der HostAdressen sowie öffentliche und private Tabellen der Schlüsselverwaltung für Secure-RPC. Der Zugriff kann dabei auf die gesamte Datenbasis erfolgen oder durch Suchschlüssel begrenzt werden. Informationen über das Netz bezeichnet man auch als NIS-Zuordnungsraum. Es existiert jedoch keine hierarchische Struktur eines Zuordnungsraums. NIS basiert auf RPC (siehe Abschnitt 3.29) und verwendet eine Client-Server-Struktur. NIS-Server stellen für NIS-Clients Dienste zur Verfügung. Die Haupt-Server werden Master-Server genannt; wegen der Ausfallsicherheit verfügen sie über Sicherheits- oder Slave-Server. 3.10.2 Schematischer Ablauf NIS speichert Informationen in einer Reihe von „Karten“. Diese NIS-Karten sind Listen zweispaltiger Elemente. Eine Spalte enthält den Schlüsselwert, die andere Informationen über den Schlüsselwert. NIS findet Informationen für einen Client, indem es die Schlüsselwerte durchsucht. Tabelle 9 zeigt einige NIS-Karten. NIS-Karte bootparams ethers.byaddr ethers.byname group.bygid group.byname hosts.byaddr hosts.byname mail.aliases mail.byaddr netgroup netgroup.byhost netgroup.byuser netid.byname netmasks.byaddr networks.byaddr networks.byname passwd.byname passwd.byuid protocols.byname protocols.bynumber publickey.byname rpc.bynumber services.byname ypservers
Beschreibung Enthält die Namen der Clients ohne Laufwerke und die Standorte der Dateien, die sie während des Startvorganges brauchen. Enthält die Ethernet-Adressen der Workstations und die ihnen zugeordneten Namen. Enthält die Namen der Workstations und die ihnen zugeordneten Ethernet-Adressen. Mitglieder-Informationen über Gruppen mit Schlüssel GID (ID der Gruppe). Mitglieder-Informationen über Gruppen mit Schlüssel Gruppenname Enthält Namen und Adressen der Workstations mit Schlüssel Adresse. Enthält Namen und Adressen der Workstations mit Schlüssel Name. Führt die Alias-Namen für die Mail im Zuordnungsraum und die zugehörigen Workstations auf. Führt die Alias-Namen für die Mail im Zuordungsraum auf, benutzt aber die Adresse als Schlüssel Enthält Informationen über Netzgruppen mit Schlüssel Name Enthält Informationen über die Netzgruppen im Zuordnungsraum, benutzt Workstation-Namen als Schlüssel Enthält Informationen über Netzgruppen, benutzt die Anwender als Schlüssel Enthält den RPC-Netznamen der Workstation und Anwender, zusammen mit ihren UIDs und GIDs. Enthält die bei IP-Untervernetzung gebrauchten Netzwerk-Masken mit Schlüssel Adresse. Enthält die Namen und Adressen der Netzwerke im Zuordnungsraum und ihre Internet-Adresse. Enthält die Namen und Adressen der Netzwerke im Zuordnungsraum mit Schlüssel Name. Enthält Passwort-Informationen mit Schlüssel Anwendername. Enthält Passwort-Informationen mit Schlüssel UID (Anwender-ID). Führt die verwendeten Netzwerk-Protokolle auf. Führt die verwendeten Netzwerk-Protokolle anhand ihrer Nummer auf. Enthält Public Keys und Secret Keys (Verschlüsselungen) für RPC. Führt den für RPCs bekannten Programmnamen und die Nummer auf. Führt die verfügbaren Internet-Dienste auf. Enthält die NIS-Server innerhalb des Zuordungsraumes und ihre IP-Adressen
Tabelle 9: NIS-Karten 11.09.97
Firewall-Studie
Seite 59
SIEMENS
Bedrohungsanalyse der Protokolle
3.10.3 Steuerkommandos Die Steuerkommandos entsprechen denen von RPC (siehe Abschnitt 3.29). 3.10.4 Protokolldatenstruktur Die Protokolldatenstruktur entspricht der von RPC (siehe Abschnitt 3.29). 3.10.5 Sicherheitsbedrohungen Angriff: Diebstahl von Dateien, Wörterbuchattacke Bedrohung: Eindringen Kommt ein Angreifer in den Besitz der Datei, in der Paßwörter gespeichert sind, so hat er Zugang zu allen mit diesen Paßwörtern geschützten Diensten und Hosts. Paßwörter wurden in früheren UNIX-Versionen in der Datei /etc/passwd verschlüsselt gespeichert, die für alle zugänglich war. Somit konnte jeder über eine Wörterbuchattacke die dort gespeicherten Paßwörter entschlüsseln. In heutigen UNIX-Versionen sind die Paßwörter verschlüsselt in einer sogenannten Shadow-Datei abgelegt. Diese ist nur mit privilegierten Rechten lesbar. Eine Wörterbuchattacke verschlüsselt gängige Wörter aus einem Wörterbuch und vergleicht das Ergebnis mit dem verschlüsselten Text. Mittels hoher Anfrageraten kann ein Angreifer so Paßwörter entschlüsseln. Daher sollte vermieden werden, daß Unbefugte privilegierte Rechte auf einem System bekommen können. Ferner sollten aktuelle UNIX-Versionen eingesetzt werden. Andernfalls haben sogar Externe Zugriff auf verschlüsselte Paßwörter, sofern sie den Domänennamen erraten. Dann ist eine Abfrage des NIS-Servers möglich. In der NIS-Paßwortdatei stehen wiederum die verschlüsselten Paßwörter, so daß der Schutz durch die Shadow-Datei unterlaufen wird. Angriff: Umleiten Bedrohung: Maskerade Einige NIS-Server besitzen Stellvertreter, die bei Ausfall einspringen sollen. Dabei ist es möglich, die Clienten ferngesteuert auf einen eventuell betrügerischen NIS-Server umzuleiten. Dieser kann dann erschwindelte Einträge für die UNIX-Datei /etc/passwd, Host-Adressen usw. bereitstellen. In Anbetracht der beschriebenen Gefährdungen sollte NIS auf gefährdeten Maschinen, insbesondere Gateways, nicht zugelassen werden. 3.10.6 Filterungsmöglichkeiten Als RPC-Dienst, der normalerweise über UDP abgewickelt wird, ist NIS sehr schwer zu filtern, da die Server meist keine festen Portnummern benutzen. Generische Proxies können die Schwächen von NIS ebenfalls nicht beheben. Zustandsabhängige Filter können RPC-Dienste gezielt filtern. 3.10.7 Zusammenfassung Protokoll NIS
Angriff Diebstahl von Dateien, Wörterbuchattacke
Bedrohung Eindringen
NIS
Umleiten
Maskerade
Gegenmaßnahme Starke Authentisierung für privilegierte Nutzer, Einsatz neuer UNIX-Versionen, Starke Authentisierung, Filtern über Firewalls
3.11 NIS+ 3.11.1 Einsatzumgebung NIS+ wurde als Ersatz für NIS entworfen. Aufgrund der Vergrößerung lokaler Netze und dem Anschluß an das Internet waren Sicherheitsfunktionen notwendig. Dabei ist der NIS+-Zuordnungsraum im Gegensatz zu NIS mit hierarchischen Domains versehen, die denen von DNS vergleichbar sind. Das erlaubt den Einsatz von NIS+ in sowohl kleinen als auch in sehr großen Netzen.
3.11.2 Schematischer Ablauf Die Client-Server-Struktur von NIS+ ähnelt insoweit der von NIS oder DNS, als daß jede Domain von einer Menge von Servern versorgt wird. Der Haupt-Server heißt Master-Server, die Sicherungs-Server heißen Replika. Veränderungen im Zuordnungsraum müssen wie bei NIS auf dem Master-Server vorgenommen wer-
Seite 60
Firewall-Studie
11.09.97
SIEMENS
NIS+
den. Im Gegensatz zu NIS werden nach Abschluß der Änderungen diese automatisch an die Replika-Server weitergereicht. NIS+ speichert seine Informationen nicht in Karten sondern in Listen. Dabei gibt es 16 Arten von vordefinierten Listen bzw. System-Listen (siehe Abbildung 28 [Ramsey 94]). Netgroups Hosts
Mail Aliases
Bootparams Password Cred Group
Services
Timezone Networks Netmasks Ethers
Protocols RPC Auto_Home Auto_Master
Abbildung 28: System-Listen in NIS+ Diese Listen können über jede Spalte (auch als Schlüssel bezeichnet), aber auch auf Listenebene und Eintragebene verändert werden. 3.11.3 Steuerkommandos NIS+ enthält einen kompletten Befehlssatz zur Verwaltung des Zuordnungsraumes. Tabelle 10 listet alle Befehle auf. Befehl nisaddcred nissaddent nis_cachemgr niscat nischgrp nischmod nischown nischttl nisdefaults
nisgrep nisgrpadm
nisinit nisln nisls nismatch nismkdir nispasswd nisrm nisrmdir nissetup nisshowcache nistbladm nisupdkeys
Beschreibung Erzeugt Kennungen für NIS+-Principals und speichert sie in der Cred-Liste. Fügt Informationen aus /etc-Dateien oder NIS-Karten in NIS+-Listen ein. Startet den NIS+ Cache Manager auf einem NIS+-Client Zeigt den Inhalt von NIS+-Listen an. Ändert Gruppen-Eigentümer eines NIS+-Obejekts. Ändert die Zugriffsberechtigungen, die ein NIS+-Obekt den vier Klassen von NIS+-Principals (Eigentümer, Gruppe, Welt und Niemand) zuweist. Ändert den Eigentümer eines NIS+-Objekts. Ändert das Verfalldatum eines NIS+-Objekts. Zeigt die Standard-Werte eines NIS+-Objekts an: Domain-Name, Gruppenname, Workstation-Name, NIS+-Principal-Name, Zugriffsberechtigung Verzeichnis-Suchpfad und Verfalldatum. Sucht in einer NIS+-Liste nach Einträgen. Erzeugt eine NIs+-Gruppe oder löst sie auf, kann eine Liste der Mitglieder anzeigen. Fügt einer Gruppe Mitglieder hinzu, entfernt sie oder überprüft sie auf Mitgliedschaft in der Gruppe. Initialisiert einen NIS+-Client oder -Server Erzeugt symbolische Verbindung (Link) zwischen zwei NIS+-Objekten Zeigt Inhalt eines NIS+-Verzeichnisses an Durchsucht eine NIS+-Liste nach Einträgen. Erzeugt ein NIS-Verzeichnis und legt seine Master- und Replika-Server fest. Ändert NIS+-Passwort-Informationen. Löscht NIS+-Objekte (außer Verzeichnissen) aus dem Zuordungsraum. Löscht NIS+-Verzeichnisse aus dem Zuordnungsraum Erzeugt die Verzeichnisse org_dir und groups_dir und einen vollständigen Satz von (leeren) NIS+-Listen für eine NIS+-Domain Zeigt den Inhalt des gemeinsamen NIS+-Cache, der vom NIS+-Cache Manager verwaltet wird Erzeugt und löscht NIS+-Listen, bzw. verändert oder löscht die Einträge einer NIS+-Liste. Aktualisiert die Public Keys Verschlüsselungen in einem NIS+-Objekt.
Tabelle 10: Befehlssatz in NIS+ 3.11.4 Sicherheitsbedrohungen und Filterungsmöglichkeiten NIS+ bietet eine ausgedehnte Menge von Zugriffsrechten auf die beschriebenen Tabellen. So kann man auch einzelne Spalten und Einträge in der Tabelle verwalten. NIS+ erlaubt zudem alle Übertragungen zwischen
11.09.97
Firewall-Studie
Seite 61
SIEMENS
Bedrohungsanalyse der Protokolle
NIS-Server und NIS-Client zu verschlüsseln. Bei einigen Installationen von NIS+ bleiben jedoch die Zugriffsrechte auf Paßwort-Tabellen in einem unsicheren Zustand. Dadurch können Angreifer leicht privilegierte Rechte erlangen. NIS+ wurde als Weiterentwicklung von NIS entwickelt, fand jedoch keine weite Verbreitung. Es erhöht die Sicherheit nur dann, wenn es so konfiguriert wurde, daß es NIS nicht mehr unterstützt. Da es nur wenige Clients für NIS+ gibt, betreiben aber die meisten Netze NIS+ in diesem Kompatibilitätsmodus. Daher gilt für NIS+ das gleiche wie für NIS. Es sollte von einer Firewall abgewiesen werden [Chapman, Zwicky 96]. 3.11.5 Zusammenfassung Protokoll NIS+
Angriff siehe Abschnitt 3.10
Bedrohung siehe Abschnitt 3.10
Gegenmaßnahme nicht über Firewalls zulassen
3.12 File Transfer Protocol (FTP) 3.12.1 Einsatzumgebung Das File Transfer Protocol [RFC 959] definiert Prozeduren, mit denen man Dateien zwischen zwei Maschinen transferieren kann. Es wird eingesetzt, um • • • •
eine Datei (Programm oder Daten) mehreren Benutzern zur Verfügung zu stellen, indirekten oder impliziten Gebrauch von Remote Computern zu ermöglichen (third party transfer s.u.), einzelne Hosts von der Vielzahl der Speichersysteme abzuschirmen und Daten effektiv zu verteilen.
3.12.2 Schematischer Ablauf FTP benötigt zwei logische Verbindungen zwischen den beiden Maschinen. Eine Verbindung wird für das Login und die Steuerkommandos zwischen den Maschinen genutzt und verwendet dazu das TELNETProtokoll. Die zweite Verbindung wird für den Datentransfer benutzt. Das Konzept ist in Abbildung 29 [Black 95] dargestellt. Der Endbenutzer kommuniziert mit einem protocol interpreter (PI), der die Steuerungsverbindung regelt. Der PI muß Informationen zwischen Benutzer und dem PI-file-System übertragen. Kommandos und Antworten werden zwischen User-PI und Server-PI übertragen. Abbildung 29 stellt die Management- und die Datenverbindungen dar.
CLIENT User
User Interface User PI
File System
DTP User
SERVER Control Data
Server PI DTP Server
File System
Abbildung 29: Das FTP-Modell FTP erlaubt auch die Übertragung von Daten zwischen zwei Servern, angestoßen von einem Client. Diese Operation ist als third party transfer bekannt. Wie in Abbildung 30 [Black 95] beschrieben, öffnet der Client eine Verbindung zu zwei Servern.
Seite 62
Firewall-Studie
11.09.97
SIEMENS
File Transfer Protocol (FTP)
Control
CLIENT
Data SERVER
File System
Data Control
SERVER
Data
File System
Abbildung 30: FTP-Third-Party-Transfer Dann verlangt der Client eine Datenübertragung zwischen den Dateisystemen der beiden Server. Daraufhin baut ein Server eine TCP-Verbindung zu dem anderen Server auf und überträgt Daten über das sendende FTP-Modul, die TCP-Module und das empfangende FTP-Modul. 3.12.3 Steuerkommandos FTP benutzt eine Vielzahl von Kommandos zur Identifikation, Paßwort-Authentisierung und den anschließenden Filetransfer-Operationen. Tabelle 11 [Black 95] listet die Kürzel dieser Befehle auf und beschreibt deren Bedeutung. Kommando USER <username> PASS <password> ACCT CWD <pathname> CDUP SMNT <pathname> QUIT REIN PORT PASV TYPE STRU <structure-code> MODE <mode-code> RETR <pathname> STOR <pathname> STOU APPE <pathname> ALLO <decimal-integer> REST <marker> RNFR <pathname> RNTO <pathname> ABOR DELE <pathname> RMD <pathname> MKD <pathname> PWD LIST [<pathname>] NLST [<pathname>] SITE <string> SYST STAT [<pathname>] HELP [<string>] NOOP
Bedeutung Identifiziert den Benutzer; durch den Server gefordert User Password; USER geht voraus User account id Change working directory Change to parent directory Mount a different file system data structure Verbindung beenden Verbindung beenden, neue Verbindung starten die Port Adresse Request for passive open Spezifiziert den Darstellungstyp (ASCII, EBCDIC, etc.) File structure = file, record, or page Transfer mode = stream, block, or compressed übertrage Kopie des Files zur anderen Instanz Akzeptiere Daten und speichere sie Akzeptiere Daten und speichere sie unter anderem Namen Akzeptiere Daten und hänge sie an andere Datei an Allokiere Platz für Operation Restart marker, an dem die Übertragung wiederbeginnt Alter Pfadname eine Datei soll umbenannt werden Neuer Pfadname einer Datei soll umbenannt werden Unterbreche vorhergehenden FTP-Befehl und die zugehörige Datenübertragung Lösche spezifizierte Datei auf Server-Seite Remove directory make directory zeige aktuelles Verzeichnis an Übertrage Liste von Verzeichnissen, Datei, etc. zu FTP Übertrage ein Verzeichnis-Listing zur User-Seite Biete für den User spezielle Dienste an Abfrage des Typs des Betriebssystems des Servers Gebe den Status der Steuerungsverbindung zurück Erhalte hilfreiche Information vom Server no operation
Tabelle 11: FTP-Kommandos FTP beschreibt auch eine Vielzahl von „Antworten“, die zum korrekten File-Transfer zwischen zwei Prozessen verwendet werden. Wie der Name suggeriert, werden diese „Antworten“ als Ergebnis von FTP-Befehlen
11.09.97
Firewall-Studie
Seite 63
SIEMENS
Bedrohungsanalyse der Protokolle
genutzt. Sie bestehen aus einer Dreiziffern-Zahl xyz gefolgt von beschreibendem Text. Hier sei auf [RFC 959] verwiesen. 3.12.3.1 Datentypen FTP unterstützt nur wenige verschiedene Typen der Datendarstellung. Dem FTP-Benutzer ist es erlaubt, einen Typ zu spezifizieren, der während der Übertragung benutzt wird (zum Beispiel ASCII, EBCDIC, etc.). ASCII ist der voreingestellte Typ. FTP verlangt, daß alle Implementationen ASCII unterstützen. EBCDIC wird ebenfalls meist unterstützt und ist im Datentransfer zwischen Mainframe Host Computern verbreitet. Sowohl ASCII als auch EBCDIC benutzen einen zweiten Parameter, um anzuzeigen, ob die Zeichen zur Formatsteuerung verwendet werden. Zum Beispiel können carriage return (CR), line feed (LF), vertical tab (VT) und form feed (FF) als Steuerungszeichen während der FTP-Session definiert werden. Ein lokaler Typ wird ebenfalls unterstützt. Dieser Typ wird in Bytes übertragen, deren Größe durch einen Parameter byte size bestimmt wird. FTP schreibt vor, daß die Bytegröße als natürliche Zahl angegeben wird. 3.12.3.2 Reihenfolge der Operationen in einer FTP-Session Die für einen Datentransfer zwischen zwei Rechnern nötigen Operationen werden im folgenden in derselben Reihenfolge beschrieben, in der sie typischerweise auftreten. Remote host login. Bevor es zum Datentransfer zwischen zwei Usern kommen kann, muß die LoginOperation ausgeführt werden. Dies ermöglicht Identifikation und Authentisierung, falls erwünscht. Der Benutzer muß für die andere Maschine einen akzeptablen Namen und das zugehörige Paßwort besitzen. Directory definition. Dieses Merkmal muß nicht benutzt werden. Wenn die Steuerungsverbindung verfügbar ist, kann es notwendig werden, ein Verzeichnis zu ändern, um Platz für die Daten zu organisieren. (z.B. durch den Befehl CWD oder CDUP) File transfer definition. Eine Reihe von Kommandos steht für die Definition der zu übertragenden Dateien zur Verfügung. Die geläufigsten sind PUT und GET (kopieren der Datei vom remote host zum lokalen Filesystem oder umgekehrt). Mode transfer definition. Der nächste Schritt im Prozeß des FTP-Filetransfers beinhaltet die Definition des Modustyps, der während der Übertragung verwendet werden soll. Dies ist verbunden mit der Definition der Darstellungsart der Bits während der Übertragung. FTP unterstützt dabei folgende Darstellungsarten: Block: Dieser Modus erhält den logischen Record innerhalb der Datei. FTP überträgt die Datei in dem Format, in dem diese in das Übertragungsmodul gesteckt wurde. Stream: Dieser Modus ist der voreingestellte Modus für den Transfer. Er ist recht effizient, da er keine Blocksteuerungs-Information mitsendet. Der Stream-Modus kümmert sich nicht um die Art der Daten, die übertragen werden. Type: Dieser Modus wird mit den Parametern IMAGE, ASCII oder EBCDIC benutzt. ASCII: Dies ist der voreingestellte Transfermodus für TYPE. EBCDIC: EBCDIC wird oft zwischen Hosts verwendet, die EBCDIC Zeichen benutzen, so zum Beispiel Mainframes vom Typ IBM. IMAGE: Dieser Modus unterstützt den Transfer von kontinuierlichen in 8-Bit Bytes verpackte Binärbits. Es ist die am weitesten verbreitete Methode, um Binärdaten ohne Unterbrechung zu übertragen. Starting the data transfer. Der eigentliche Datentransfer kann z.B. mit den Befehlen RETRIEVE, APPEND beginnen. Stopping the data transfer. Der Befehl QUIT beendet die Verbindung zu dem Host, der die FTP-Operation ausführt. Soll dies vermieden werden, so kann man stattdessen den Befehl CLOSE ausführen, der keine Verbindung abbricht. In diesem Fall bleibt FTP aktiv, so daß ein anderer User eine neue FTP-Session mit dem OPEN-Befehl beginnen kann.
Seite 64
Firewall-Studie
11.09.97
SIEMENS
File Transfer Protocol (FTP)
3.12.4 Sicherheitsbedrohungen Das File Transfer Protocol (FTP) ermöglicht den Austausch von Dateien zwischen zwei entfernten Rechnern. Bei Benutzung von FTP werden zwei Verbindungen aufgebaut, wobei die Kommandos über Port 21 und die Daten über Port 20 übertragen werden. Um den Austausch von Befehlen zwischen Rechnern verschiedener Betriebssysteme zu ermöglichen, definiert FTP eine Reihe von Standardbefehlen. Diese sind nicht identisch mit den Kommandos der Benutzeroberfläche. Der FTP-Client übersetzt die Kommandos der Benutzeroberfläche in die entsprechenden Standardbefehle. Für die Firewall sind die Standardbefehle relevant, da nur diese tatsächlich über TCP/IP übertragen werden. Im folgenden wird davon ausgegangen, daß sich der Client im zu schützenden internen Netz und der Server im externen Netz befindet. Angriff: PORT Bedrohung: Maskerade Während der Client die Kommandoverbindung zum Port 21 des Servers aufbaut, ist der Server für den Aufbau des Datenkanals von seinem Port 20 zu einem Port (> 1023) des Clients verantwortlich. Dies stellt eine Sicherheitslücke dar, da sich Angreifer als Server ausgeben könnten. Daher sollte der Verbindungsaufbau für den Datenkanal umgekehrt stattfinden und seitens des Clients der Standardbefehl PASV statt PORT verwendet werden. Hierdurch wird erreicht, daß der Client eine zufällige Portnummer berechnet und auf diesem Port die Datenübertragung erwartet. Der Client kann dann eine Verbindung von diesem Port aus aufbauen, der TCP-Verbindungsaufbau findet also vom sicheren ins unsichere Netz statt. Angriff: Manipulieren und Lesen Bedrohung: Manipulation Alle Befehle, die Dateien oder Verzeichnisse manipulieren oder lesen (CWD, CDUP, RETR, STOR, DELE, LIST, NLIST), müssen an eine entsprechende Rechteverwaltung gekoppelt sein. Zugriffe nicht vertrauenswürdiger Benutzer werden damit auf bestimmte Dateien eingeschränkt oder ganz unterbunden. Dies setzt einen starken Authentisierungsmechanismus voraus. Insbesondere sollte der Befehl SITE (führt ein Kommando auf dem entfernten FTP-daemon aus, z.B. SITE idle 7200) gesperrt oder sehr restiktiv an eine Rechteverwaltung gekoppelt werden. Sehr gefährlich ist hier der Befehl SITE EXEC, mit dem ein Programm auf dem entfernten Rechner ausgeführt werden kann. Auch der Befehl SYST, mit dem ein Client nach der Betriebssystemversion des Servers fragt, sollte an eine Rechteverwaltung gekoppelt sein bzw. für nicht vertrauenswürdige Benutzer gesperrt werden. Ferner sollte es möglich sein, die Übertragung der Dateien, der Verzeichnisinformation und der Paßworte zu verschlüsseln. Dazu ist die Modifikation des FTP-Client und -Servers notwendig. Angriff: Ausnutzen des anonymous ftp Bedrohung: Eindringen, Maskerade Anonymous ftp - ein oft genutztes Programm zur Datenverteilung - stellt eine weitere Sicherheitslücke dar. Falls erwünscht, kann man den FTP-Server so konfigurieren, daß Externe ohne vorherige Autorisierung aus einem eingeschränkten Bereich des Systems Dateien kopieren können. Die Benutzer loggen sich mit dem Namen anonymous ein, um den Dienst zu nutzen. Einige Stellen verlangen die Mailadresse als Paßwort. Der FTP-Dämon besitzt zumindest zu Beginn privilegierte Rechte, da er normalerweise ein Login zu einem Account inklusive der Passwortbehandlung ausführt. Neuere Implementierungen führen anschließend ein change userid durch. Das Protokoll nutzt Port 20. Port 20 gehört zum privilegierten Bereich. Anonymous ftp ist ein sehr wertvoller Service. Jedoch muß große Vorsicht beim Administrieren ausgeübt werden. So sollte unter anderem keine Datei oder kein Verzeichnis im Bereich des anonymous ftp schreibbar oder im Besitz des FTP-Login sein, da der anonymous ftp mit dieser User-Id läuft. Ferner sollte vermieden werden, eine echte /etc/passwd-Datei im Bereich des anonymous ftp liegen zu lassen. Falls es das System zuläßt, sollten alle Einträge in dieser Datei gelöscht werden. Falls nicht, so sollte eine solche Datei als DummyFile ohne echte Accounts erstellt werden. Falls möglich, sollte ein FTP-Server verwendet werden, der die Begriffe “intern” und “extern” versteht. Dateien, die außerhalb erstellt wurden, können gekennzeichnet werden, damit sie für andere Externe nicht lesbar sind. Angriff: Ausführbarer Code Bedrohung: Manipulation, Eindringen Je nach Konfiguration könnte Software im FTP-Bereich manipuliert sein - besonders, wenn es sich um ausführbaren Code handelt. Ist ein Angreifer in der Lage, ausführbare Programme auf ein fremdes System zu bringen, so kann er dort "Trojanische Pferde" installieren. Dies können Programme sein, die intern Informati-
11.09.97
Firewall-Studie
Seite 65
SIEMENS
Bedrohungsanalyse der Protokolle
on sammeln und diese möglichst unbemerkt nach außen zurück zum Angreifer schmuggeln. Sie verstecken sich in einem scheinbar nützlichen ausführbaren Programm. Dieses kann per FTP angeboten oder per Mail verschickt werden - in jedem Fall muß der Empfänger dazu motiviert werden, das Programm zu starten. Es wird i.d.R. dann irgendeine für den Anwender sichtbare Funktion ausgeführt und im Hintergrund laufen die vom Angreifer eigentlich gewünschten Aktionen. Z.B. kann ein Trojanisches Pferd den internen Netzverkehr beobachten (Sniffing) und nach bestimmten Informationen filtern oder es wird bei einem Login aktiv und schreibt Nutzeridentifikation und Paßwort mit. Die gesammelten Informationen können beispielsweise per EMail wieder nach außen geschickt werden. Angriff: Firewalls tunneln Bedrohung: Maskerade Ein lokaler User verbindet sich über anonymous ftp zu einem remote FTP-Server (Port 21). Um eine Datei zu übertragen, wählt der Client des Users zunächst einen beliebigen TCP-Port, an dem er auf die Datei wartet. Der Client sendet ein PORT-Kommando, um diese Wahl dem Server mitzuteilen. Der Server antwortet, indem er eine aktive TCP-Verbindung zu dem angegebenen Host öffnet und die Datei versendet. Ist das Netz des Clients durch einen Paketfilter geschützt, so wird die Datenübertragung fehlschlagen, da der Server ja einen internen Port öffnen möchte. Ein Applikationsfilter untersucht die Daten nach diesem speziellen PORTBefehl. Hat es diesen entdeckt, so läßt es eine Verbindung zwischen Remote Host und internem Client etablieren, da die Anfrage für eine solche Verbindung ja vom internen Client kam. Ist diese Verbindung erst etabliert, so kann sie beliebig lange bestehen bleiben. Öffnet ein bösartiger interner Nutzer eine FTP-Verbindung nach außen und gibt an, die Datei auf Port 23 (dem Telnet-Port) zu erwarten, so kann der Remote Host eine Telnet Verbindung zum Client erstellen. Dieser Angriff läßt sich mittels Java auch von externen Angreifern ausführen (siehe Abschnitt 3.33). Angriff: FTP Hijacking Bedrohung: Eindringen, Maskerade Mittels des third party transfer ist es möglich, eine bereits bestehende Verbindung zwischen zwei Servern zu übernehmen und für seine Zwecke auszunutzen. 3.12.5 Filterungsmöglichkeiten Wie bereits beschrieben, bestehen bei FTP zwei Verbindungen. Serverseitig geht der Steuerungskanal dabei an Port 21, der Datenkanal an Port 20. Die interessantesten Angriffsziele bieten niedrige Port-Nummern. Clients nutzen meist Port-Nummern höher als 1023. Damit ergibt sich folgende Menge erlaubter Verbindungen [Chapman, Zwicky 96]13. Richtung
Zieladresse
Protokoll
Quellport
Zielport
ein
Quell Adresse extern
intern
TCP
> 1023
21
ACK gesetzt A
aus
intern
extern
TCP
21
> 1023
Ja
aus
intern
extern
TCP
20
> 1023
A
ein
extern
intern
TCP
> 1023
20
Ja
ein
extern
intern
TCP
> 1023
> 1023
A
aus
intern
extern
TCP
> 1023
> 1023
Ja
aus
intern
extern
TCP
> 1023
21
a
Seite 66
Firewall-Studie
Bemerkungen Eingehende FTP-Anfrage Antwort auf eingehende FTPAnfrage Einrichten eines Datenkanals für eingehende FTPAnfrage, normaler Modus Antworten im Datenkanal für eingehende FTPAnfrage, normaler Modus Einrichten des Datenkanals für eingehende FTPAnfrage, passiver Modus Antworten im Datenkanal für eingehende FTPAnfrage, passiver Modus Ausgehende FTP-Anfrage
11.09.97
SIEMENS
Trivial File Transfer Protocol (TFTP)
ein
extern
intern
TCP
21
> 1023
ja
ein
extern
intern
TCP
20
> 1023
a
aus
intern
extern
TCP
> 1023
20
ja
aus
intern
extern
TCP
> 1023
> 1023
a
ein
extern
intern
TCP
> 1023
> 1023
ja
a.
Antwort auf ausgehende Anfrage Einrichten des Datenkanals für ausgehende FTP-Anfrage, normaler Modus Antworten im Datenkanal für ausgehende FTP-Anfrage, normaler Modus Einrichten des Datenkanals für ausgehende FTP-Anfrage, passiver Modus Antworten im Datenkanal für ausgehende FTP-Anfrage, passiver Modus
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 12: FTP-Filterungsmöglichkeiten
3.12.6 Zusammenfassung Protokoll FTP
Angriff PORT
Bedrohung Maskerade
FTP
CWD, CDUP, RETR, STOR, DELE, LIST, NLIST, SITE, SYST
Manipulation
FTP
anonymous ftp
Diebstahl von Informationen
FTP
Ausführbarer Code
Manipulation
FTP
Firewalls tunneln mittels FTP Verbindung nach außen und Angabe von Port 23 FTP Hijacking
Maskerade
FTP
Eindringen, Maskerade
Gegenmaßnahme PORT durch Befehl PASV ersetzen Rechteverwaltung, SITE sperren, Einsatz einer verschlüsselungsfähigen Firewall Nur zur Veröffentlichung vorgesehene Daten zugänglich machen (z.B. keine Paßwortdateien) Java, ActiveX und MIME filtern eingehende Telnet Daten auf Port 23 filtern
FTP filtern
3.13 Trivial File Transfer Protocol (TFTP) 3.13.1 Einsatzumgebung Das Trivial File Transfer Protocol (TFTP) ist ein UDP-basiertes Dateitransferprotokoll ohne Sicherheitskontrollen, Benutzerauthentifikation und Ende-zu-Ende Verläßlichkeit. Es wird häufig bei Diskless Workstations angewendet, um Daten zu laden oder X11-Terminals zu booten. 3.13.2 Sicherheitsbedrohungen Angriff: Diebstahl der Paßwortdatei, Wörterbuchattacke Bedrohung: Eindringen, Maskerade Bei der Konfiguration eines TFTP-Dämons sollte man beachten, daß der Dateitransfer auf ein bis zwei Verzeichnisse und die Zeichensatzbibliothek von X11 beschränkt bleibt. Andernfalls kann ein Angreifer per TFTP die Paßwortdatei stehlen und diese dann mit Hilfe eines Wörterbuchangriffs15 zu knacken. TFTP sollte
15
Bei einer Wörterbuchattacke werden häufige Paßwörter, insbesondere Wörter aus einem Wörterbuch verschüsselt und mit dem verschlüsselten Paßwort verglichen. 11.09.97
Firewall-Studie
Seite 67
SIEMENS
Bedrohungsanalyse der Protokolle
nur auf den Maschinen laufen, die es wirklich benötigen (z.B. interne Server für X-Terminals). Aus diesem Grund sollte TFTP von Firewalls abgewiesen werden. Einige Router nutzen TFTP, um ihre Programme oder Konfigurationsdateien zu laden. Dies ist riskant, da die Konfigurationsdateien meist Paßworte enthalten. Wenn also Konfigurationsdateien verteilt werden, so sollte sichergestellt sein, daß nur der Router Zugriffsrechte auf diese Dateien besitzt. 3.13.3 Filterungsmöglichkeiten TFTP ist ein UDP-basierter Dienst und sollte aufgrund der Sicherheitsbedrohungen von Firewalls geblockt werden. Ist es dennoch notwendig, TFTP über Firewalls hinweg anbieten zu wollen, so sind dynamische Firewalls notwendig, die die sich ändernden Ports verfolgen können. 3.13.4 Zusammenfassung Protokoll TFTP
Angriff Diebstahl der Paßwortdatei
Bedrohung Eindringen, Maskerade
Gegenmaßnahme Filtern von TFTP über Firewall
3.14 File Service Protocol (FSP) 3.14.1 Einsatzumgebung Das File Service Protocol (FSP) ist ein Dateitransferprotokoll und bietet über einen UDP-Port einen FTPähnlichen Dienst an. Es wird kaum benötigt. 3.14.2 Sicherheitsbedrohungen FSP wird gerne durch Hacker genutzt, die es als leicht installierbar und nützlich zum Versenden ihrer Werkzeuge und ausgelesenen Daten schätzen. Angesichts des bisherigen Mißbrauchs sollte FSP von Firewalls abgewiesen werden. 3.14.3 Filterungsmöglichkeiten FSP verwendet UDP als Transportprotokoll. Sofern FSP über Firewalls hinweg betrieben werden soll, sind zur granulierten Filterung von FSP dynamische Paketfilter erforderlich, die die wechselnden Portnummern verfolgen können. 3.14.4 Zusammenfassung Protokoll FSP
Angriff Versenden von Angriffstools
Bedrohung Eindringen
Gegenmaßnahme Abweisen
3.15 GOPHER 3.15.1 Einsatzumgebung Gopher ist ein Informationsprotokoll, mit dem man Dateien und Verzeichnisse im Internet durchsuchen kann. Dabei expandiert Gopher komprimierte Dateien automatisch, für GIF-Bilder startet Gopher beispielsweise einen GIF-Viewer. 3.15.2 Sicherheitsbedrohungen Angriff: IP-Spoofing Bedrohung: Maskerade Die Anfragen bergen mögliche Gefahrenquellen. So verwendet das Gopher-Protokoll ein uuencode-Format, welches Dateinamen und Zugriffsrechte enthält. Bei der Dateiübertragung werden die Zugriffsrechte mit übertragen. Dies sollte man verhindern, indem man nach der Übertragung eigene Zugriffsrechte setzt. Unter bestimmten Voraussetzungen öffnet der Informationsserver gopherd auf eine Benutzeranfrage hin eine FTPVerbindung. Obwohl die Verbindung vom Client initiiert wird, geht sie von der IP-Adresse des Informationsservers aus. Dadurch ist eine Kontrolle der Quelladresse nicht mehr möglich. Gopherd ermöglicht also IPSpoofing und damit eine Verschleierung der Quelle von FTP-Sitzungen.
Seite 68
Firewall-Studie
11.09.97
SIEMENS
Hyper Text Transfer Protocol (HTTP)
Angriff: Ausführbarer Code Bedrohung: Manipulation Gopher kann über WWW-Browser übertragen werden. Es besteht somit die Möglichkeit, Java-Applets über Gopher zu versenden. Die Risiken von Java und zugehörige Gegenmaßnahmen sind in 3.33 ausführlich beschrieben. 3.15.3 Filterungsmöglichkeiten Standardmäßig verwenden Gopher-Clients Portnummern über 1023. Die meisten Gopher-Server verwenden Port 70, jedoch nicht alle. An Hand dieser Standardports können Gopherpakete auf Basis TCP gefiltert werden, indem man nur folgende Verbindungen zuläßt [Chapman, Zwicky 96]13: Richtung
Zieladresse
Protokoll
Quellport
Zielport
ein
Quell Adresse extern
intern
TCP
> 1023
70
ACK gesetzt a
aus
intern
extern
TCP
70
> 1023
ja
aus
intern
extern
TCP
>1023
70
a
ein
extern
intern
TCP
70
> 1023
ja
a.
Bemerkungen Eingehende Sitzung, Client an Server Eingehende Sitzung Server an Client Ausgehende Sitzung, Client an Server Ausgehende Sitzung, Server an Client
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 13: Gopher-Filterungsmöglichkeiten
3.15.4 Zusammenfassung Protokoll Gopher Gopher
Angriff IP-Spoofing ausführbarer Code
Bedrohung Maskerade Manipulation
Gegenmaßnahme siehe Abschnitt 3.1 Java, ActiveX und MIME filtern
3.16 Hyper Text Transfer Protocol (HTTP) 3.16.1 Einsatzumgebung Das Hyper Text Transfer-Protokoll ist ein zustandsloses, objektorientiertes Protokoll auf Anwendungsebene für ein verteiltes Hypermedia-Informationssystem. Es regelt die Übertragung von Dokumenten zwischen WWW-Servern und WWW-Clients. 3.16.2 Steuerkommandos / schematischer Ablauf HTTP unterscheidet vier Operationen: Connection: Der Client initiiert eine Verbindung zum Server, die von diesem bestätigt wird. Über TCP erfolgt der Verbindungsaufbau entweder über den well known16 Port 80 oder über einen anderen Port, der dann aber explizit angegeben werden muß. Request: Der Client stellt über eine sog. request message eine Anfrage. Response: Der Server sendet seine Antwort an den Client (response message). Close: Der Verbindungsabbau erfolgt entweder durch den Server nach Übertragung der Daten oder durch den Client durch Abbruch. 3.16.3 Protokolldatenstruktur Im folgenden werden der Request Block und der Response Block näher erläutert:
16
Alle Ports, die in der UNIX-Datei etc/services stehen, werden als well known Ports bezeichnet.
11.09.97
Firewall-Studie
Seite 69
SIEMENS
Bedrohungsanalyse der Protokolle
Request Block Beim Request, also der Anfrage des Clients beim Server, unterscheidet man zwischen einem SimpleRequest und einem FullRequest. Der SimpleRequest besteht aus der Zeile GET URL wobei URL für eine Server-URL und für steht. Der FullRequest ist wie folgt aufgebaut: Method URL ProtocolVersion [*] [ ] Über ProtocolVersion wird das Aussehen der gesamten Anfrage spezifiziert. Dabei ist eine beliebige Anzahl von -Feldern (Hypertext Transfer Request) erlaubt, was durch * gekennzeichnet ist. Über diese Felder kann der Client dem Server bestimmte Mitteilungen machen. Diese sind beispielsweise ein From: Accept: Authorisation:
Feld, über das die Mailadresse des Anwenders dem Server bekannt gemacht werden kann oder das Feld, über das der Client anzeigt, welche MIME-Typen er akzeptiert. Hier kann der Client ein Paßwort im Klartext angeben, das der Server zuvor verlangt hat.
Als Method können angegeben werden: GET: HEAD: PUT:
POST:
Weist den Server an, das Objekt unabhängig vom Format zu senden. Weist den Server an, nur den HTTP-Header zu senden. Die im Datenteil vorhandenen Daten sollen vom Server unter der angegebenen URL abgespeichert werden. Dies setzt geeignete Berechtigungen voraus. Erzeugt ein neues Objekt, welches über einen Link zum spezifizierten Objekt in Beziehung gesetzt wird und diesem untergeordnet ist. POST wird z.B. verwendet, um die Eingaben eines Formulars einem externen Programm zu übergeben.
Response Block Der Response Block, der vom Server zum Client gesendet wird, hat folgende Syntax: <status line> Die Antwort des Servers beginnt mit der Statuszeile, die das folgende Format hat: <status line> ::= <status code> Die Statuszeile gibt die HTTP-Version des Servers zurück, <status code> gibt einen 3 ziffrigen Zahlencode als Statusmeldung aus, 200 bedeutet z.B. O.K., die Anfrage wurde also korrekt bearbeitet. gibt eine kurze Erläuterung der angegebenen Ziffer (im Falle von <status code> = 200 ist = OK). Anschließend folgen die Header-Informationen. Dies sind im Falle des o.g. Beispiels das Datum, die Serverspezifizierung, die MIME-Version und der Content-Type des Dokuments in Byte. Abschließend erfolgt die Übertragung der Daten. 3.16.4 Sicherheitsbedrohungen Angriff: Spoofing Bedrohung: Maskerade Indem einem HTTP-Browser gefälschte HTTP-Pakete zugespielt werden, kann der Benutzer des Browsers in die Irre geführt werden. Seite 70
Firewall-Studie
11.09.97
SIEMENS
Secure Hyper Text Transfer Protocol (S-HTTP)
Angriff: Ausführbarer Code Bedrohung: Manipulation Über HTTP können Java-Applets und ActiveX Controls übertragen werden. Außerdem dient MIME dazu, den Aufbau einer Seite im HTML-Format zu beschreiben. Somit ist ausführbarer Code eine wesentliche Gefahr, die von HTTP ausgeht. Proxies können HTTP-Nachrichten auf ausführbaren Code untersuchen (siehe Abschnitt 3.33). 3.16.5 Filterungsmöglichkeiten Die Filterungsmöglichkeiten von HTTP werden in der folgenden Tabelle aufgezeigt. Dabei wird davon ausgegangen, daß Clients Ports > 1023 und Server den Standardport 80 benutzen. Alles, was gemäß dieser Tabelle nicht erlaubt ist, sollte verboten sein. Jede Zeile beschreibt also eine zulässige Nachrichtenart [Chapman, Zwicky 96]13. Richtung
Zieladresse
Protokoll
Quellport
Zielport
ein
Quell Adresse extern
intern
TCP
> 1023
80
ACK gesetzt a
aus
intern
extern
TCP
80
> 1023
ja
aus
intern
extern
TCP
>1023
80
a
ein
extern
intern
TCP
80
> 1023
ja
a.
Bemerkungen Eingehende Sitzung, Client an Server Eingehende Sitzung, Server an Client Ausgehende Sitzung, Client an Server Ausgehende Sitzung, Server an Client
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 14: HTTP-Filterungsmöglichkeiten
Eine Firewall sollte in der Lage sein, die Befehle eines HTTP-Paketes zu analysieren und durch Filter einzuschränken. So sollte es z.B. möglich sein, bei der Request-Operation die Ausführung des Befehls POST und die damit verbundene Änderung einer Datei zu verbieten. Die Filter müssen möglichst benutzerabhängig (mit Hilfe einer starken Authentisierung) und rechnerabhängig sein, um den Benutzern bzw. Rechnern individuelle Möglichkeiten bieten zu können. Die übertragenen Daten sollten nach ihrem Inhalt unterschieden werden können. Ferner sollten spezielle Dateitypen auf bestimmte Informationen hin untersucht werden können. Sollten für die Verarbeitung der übertragenen Daten weitere Prozesse nötig sein (z.B. ein externer Viewer oder eine Shell), so sollte es möglich sein, die Ausführung dieser Prozesse vorher vom Benutzer bestätigen zu lassen. Neben den Filterungsmöglichkeiten kann man einen Proxy für HTTP verwenden. Weiter kann man den WebServer zwischen äußerem Filter und Bastion-Host installieren, um den Bastion-Host einfach und übersichtlich zu halten. 3.16.6 Zusammenfassung Protokoll HTTP HTTP
Angriff Spoofing Ausführbarer Code
Bedrohung Maskerade Manipulation
Gegenmaßnahme Einsatz eines Proxies Java, ActiveX und MIME filtern
3.17 Secure Hyper Text Transfer Protocol (S-HTTP) 3.17.1 Einsatzumgebung Secure HTTP (S-HTTP) erlaubt es, Nachrichten, die zwischen einem HTTP-Client-Server Paar versendet werden, zu sichern. S-HTTP stellt als Erweiterung von HTTP einem Client-Server-Paar folgende Mechanismen zur Verfügung:
11.09.97
Firewall-Studie
Seite 71
SIEMENS • • •
Bedrohungsanalyse der Protokolle Authentisierung von Instanzen, Aushandeln von Sicherungsdiensten, Schutz der Vertraulichkeit und Integrität von HTML (Hypertext Markup Language) Dokumenten.
Die Sicherungsdienste basieren auf den Algorithmen RSA, DES, RC2, MD2 und MD5. Durch eine optionale Verhandlungsphase vor jeder Übertragung erlaubt S-HTTP Flexibilität in der Wahl des Key-Management Mechanismus', der Sicherheitspolitik und der zu verwendenden kryptographischen Algorithmen. S-HTTP wurde 1994 von der Firma EIT wegen des zunehmenden Bedarfs nach kommerziellen Anwendungen im Internet entwickelt und besitzt heute den Status eines Internet-Drafts. Mehrere kryptographische Sicherheitsmechanismen können in S-HTTP-Clients und -Server eingebunden werden, so zum Beispiel PKCS-7 (Cryptographic Message Syntax) und PEM. Durch die optionale Verhandlungsphase ist Interoperabilität zwischen S-HTTP-Clients und -Server, die kein S-HTTP verwenden, gewährleistet. Nachrichten werden durch Signaturen, Authentisierung und Verschlüsselung geschützt. Der wesentlichen Unterschiede zu SSL (siehe Abschnitt 3.18) sind: • •
S-HTTP muß in WWW-Clients und -Server auf Applikationsebene integriert werden. S-HTTP bietet die Sicherungsdienste auf Basis des Inhalts der HTML-Dokumente, wohingegen SSL den HTTP-Kommunikationskanal schützt.
3.17.2 Schematischer Ablauf Nach einer optionalen Verhandlungsphase eröffnet ein Client die Kommunikation mit einem Secure HTTPRequest, der eine Reihe von Headern mit Informationen über den Dateninhalt enthält (siehe Abschnitt 3.16.3). Der Server antwortet mit Secure-HTTP /1.1 200 OK unabhängig davon, ob der Request erfolgreich war oder nicht. S-HTTP schützt übergebene HTTP-Daten auf der Seite des Senders durch Verschlüsselung oder Anhängen einer kryptographisch erzeugten Prüfsumme und übergibt die geschützten Daten dem Transportsystem. Die so geschützten Daten werden zum Empfänger übertragen. Auf der Seite des Empfängers werden die gekapselten Daten vom Transportsystem dem lokalen S-HTTP übergeben. Dieses entschlüsselt die geschützten HTTPDaten und übergibt sie der HTTP-Anwendung. Die optionale Verhandlungsphase vor der eigentlichen Datenübertragung erfolgt über sogenannte Verhandlungsblocks. Diese bestehen jeweils aus vier Teilen: • • • •
Property gibt die Option an, die ausgehandelt werden soll (z.B. den kryptographischen Algorithmus) Value ist der vorgeschlagene Wert der Option (z.B. DES-CBC) Direction gibt aus Sicht des Verhandelnden an, ob die Option beim Versenden oder beim Empfang von Daten angewendet werden soll. Strength hat die Werte required, optional oder refused.
Die Verhandlung findet vor der eigentlichen Datenübertragung statt. Dazu sind zusätzliche Header-Formate definiert, die in HTTP-Headern und nicht in S-HTTP-Headern verwendet werden. Findet keine Verhandlungsphase statt, so verwendet S-HTTP folgende Default-Werte: SHTTP-Privacy-Domains: SHTTP-Certificate-Types: SHTTP-Key-Exchange-Algorithms: SHTTP-Signature-Algorithms: SHTTP-Message-Digest-Algorithms: SHTTP-Symmetric-Content-Algorithms: SHTTP-Symmetric-Header-Algorithms: Seite 72
orig-optional=PKCS-7, PEM recv-optional=PKCS-7, PEM orig-optional=X.509 recv-optional=X.509 orig-optional=RSA,Inband recv-optional=RSA,Inband orig-optional=RSA recv-optional=RSA orig-optional=RSA-MD5 recv-optional=RSA-MD5 orig-optional=DES-CBC recv-optional=DES-CBC orig-optional=DES-ECB Firewall-Studie
11.09.97
SIEMENS
Secure Hyper Text Transfer Protocol (S-HTTP) recv-optional=DES-ECB orig-optional=sign,encrypt, auth recv-required=encrypt recv-optional=sign, auth
SHTTP-Privacy-Enhancements:
3.17.3 Steuerkommandos Eine S-HTTP-Nachricht besteht aus einer Request-Zeile oder einer Status-Zeile, gefolgt von einer Reihe von Headern und geschütztem Inhalt. Dekodiert man diesen Inhalt, so erhält man eine weitere S-HTTP-Nachricht oder eine HTTP-Nachricht. Secure-HTTP-Kopfzeilen beinhalten auf jeden Fall 'Content-Type' und 'Content-Privacy-Domain'. Die Nachricht selbst ist vom Headerblock durch zwei aufeinanderfolgende CRLF getrennt. Die verschiedenen Headerzeilen sind: Headerzeile Content-Privacy-Domain Content-Transfer-Encoding Content-Type Prearranged-Key-Info
MAC-Info Content
Bedeutung Gibt die Sicherheitsumgebung an. Werte sind PKCS-7, PEM (früher auch PGP) Gibt die Art der Kodierung an. Werte sind BASE64, 8BIT, BINARY für PKCS-7 und 7BIT für PEM Der Inhalt der Daten ist vom Typ HTTP/1.0, Werte sind application/http, application/shttp Enthält Informationen über das zu verwendende Schlüsselmaterial. Dabei gibt es die Möglichkeiten Inband und Kerberos für zuvor vereinbarte Schlüssel, Outband für externes Schlüsselmaterial enthält einen MAC mit Angabe des Hash-Algorithmus, der Zeit- und Schlüsselinformation Je nach Werten der vorangehenden Headerzeilen enthält es die Daten pur oder die Daten eingekapselt durch -----BEGIN PRIVACY-ENHANCED MESSAGE---------END PRIVACY-ENHANCED MESSAGE-----
3.17.4 Protokolldatenstruktur Da S-HTTP-Daten in HTTP-Formate gekapselt werden, entspricht das Datenformat von S-HTTP dem von HTTP. 3.17.5 Sicherheitsbedrohungen Angriff: Tunneling Bedrohung: Eindringen, Maskerade Wenn eine Firewall einen Proxy als HTTP-Server einsetzt, ist auf folgendes zu achten: Da die Authentisierung nicht mit einem Proxy, sondern mit dem eigentlichen Benutzer jenseits des Proxies erfolgen soll, werden sogenannte Tunneling-Protokolle eingesetzt. Der Benutzer unternimmt einen zusätzlichen Handshake mit dem Proxy-Mechanismus. Dieser Handshake teilt dem Proxy die Zieladresse und den Port mit des Ziels mit. Ist die Firewall nicht Teil der Security-Session, so kann der HTTP-Proxy die verschlüsselten Daten nicht entschlüsseln. Der Proxy kann lediglich eine Transportverbindung zum externen Server aufbauen und diesem die kryptographisch behandelten Daten des internen Clients weiterreichen. Dieses Tunneln der Firewall kann von bösartigen Insidern ausgenutzt werden. Abhilfe schafft hier die Einbeziehung der Firewall in die Security Association zwischen Client und Server oder das Abweisen aller S-HTTP-Daten.. Angriff: Ausführbarer Code Bedrohung: Manipulation Die Sicherheitsbedrohungen bezüglich ActiveX, Java und MIME sind in den entsprechenden Kapiteln beschrieben. S-HTTP hat sich als Industriestandard nicht durchgesetzt, da Netscape seine Webbrowser mit SSL ausrüstete.
3.17.6 Interaktion mit Firewalls Die Problematik der Interaktion bei einer doppelten Verschlüsselung (S-HTTP und Firewall) birgt keine Sicherheitsrisiken, solange eine Firewall auf den Schichten 3 oder 4 verschlüsselt. Da S-HTTP auf Anwenderebene verschlüsselt, ist die Verschlüsselung der Firewall für den Anwender transparent, solange Symme11.09.97
Firewall-Studie
Seite 73
SIEMENS
Bedrohungsanalyse der Protokolle
trie bei der Aufstellung gewährleistet ist. Dies ist zum Beispiel der Fall, wenn sich der Web-Server sowohl senderseitig als auch empfängerseitig innerhalb der Firewall befindet. 3.17.7 Filterungsmöglichkeiten S-HTTP dient zur Sicherung von Web-Anwendungen. Dennoch können bösartige Applets bzw. MIMEcodierte ausführbare Programme trotz der Sicherung oder gerade deswegen auf interne Systeme gespielt werden. Aus diesem Grund sollten HTTP-Daten und S-HTTP-Daten über einen Proxy oder eine isolierte Opfermaschine betrieben werden. 3.17.8 Zusammenfassung Protokoll S-HTTP
Angriff Tunneling
Bedrohung Mißbrauch
S-HTTP
Ausführbarer Code
Manipulation
Gegenmaßnahme Abweisen von S-HTTPDaten über Firewalls oder Einsatz eines Proxies Filtern von ActiveX, Java und MIME
3.18 Secure Socket Layer (SSL) 3.18.1 Einsatzumgebung Netscape entwickelte SSL (Secure Socket Layer), um Sicherheitsanforderungen für HTTP-Anwendungen abdecken zu können. Durch eine Integration von SSL in den 'Navigator' und den 'Commerce Server' wurden neben den bekannten Sicherheitsmechanismen auf Anwendungsebene (z.B. PGP) kryptographische ITSicherungsdienste einer breiten Öffentlichkeit zugänglich. SSL wurde von Netscape als Internet-Draft [SSL_Web] in die Internet-Standardisierung eingebracht. Mittlerweile hat dieses Dokument die Version 3 erreicht. Der Source-Code der Referenzimplementierung SSLRef V.2 ist in Nordamerika frei zugänglich. Aufgrund des durch SSL erreichbaren Sicherheitsniveaus haben amerikanische Banken begonnen, elektronische Filialen im Internet zu eröffnen. Die Nutzung von SSL ist nicht auf HTTP-Clients und -Server beschränkt. Weitere Anwendungen wie Telnet, FTP oder NNTP, denen Client/Server-Architekturen zugrunde liegen, können SSL zur sicheren Kommunikation nutzen. Allerdings setzt dies voraus, daß die betreffenden Clients und Server jeweils dafür angepaßt werden. 3.18.2 Schematischer Ablauf SSL steht auf UNIX und PC-Systemen zur Verfügung. In seiner Grundfunktionalität ist SSL als Schicht zwischen Clients bzw. Servern und dem Transportsystem TCP/IP angesiedelt. Im wesentlichen versorgt SSL die Transportsystemschnittstellen Berkeley Sockets bei UNIX-Systemen bzw. Windows Socket API bei PCs. Dadurch ist es der Anwendung möglich, eine Transportverbindung ähnlich wie eine lokale Datei zu handhaben und durch read/write Befehle von ihr zu lesen bzw. auf sie zu schreiben. Durch einen Connect-Befehl wird die Eröffnung einer Transportverbindung auf Client-Seite angestoßen. Durch einen Accept-Befehl auf Server-Seite wird eine Transportverbindung etabliert. SSL stellt Clients und Servern spezielle Funktionen für die Eröffnung und Nutzung einer Transportverbindung zur Verfügung. Anstelle der eigentlichen Socket Funktionen (z.B. accept, connect, write und read) rufen Client und Server die von SSL bereitgestellten Funktionen auf. Diese SSL-Funktionen werden durch SSL auf das Socket API der jeweiligen Plattform abgebildet. Dadurch werden die Daten nicht direkt dem Betriebssystem zur Übertragung übergeben, sondern stehen zunächst SSL zur Bearbeitung zur Verfügung. SSL schützt übergebene Daten auf der Seite des Senders mittels kryptographischer Sicherungsdienste und übergibt die geschützten Daten dem Transportsystem. Die so geschützten Daten werden zum Empfänger übertragen. Auf der Seite des Empfängers werden die gekapselten Daten vom Transportsystem dem lokalen SSL übergeben. Dieses packt die eingekapselten HTTP-Daten aus und übergibt sie der Anwendung. Abbildung 31 zeigt die Integration des SSL in den Protokollstack am Beispiel HTTP.
Seite 74
Firewall-Studie
11.09.97
SIEMENS
Secure Socket Layer (SSL)
HTTP Client
HTTP Protokoll SSL
HTTP Server SSL
SSL Protokoll TCP/IP
TCP/IP Transport Protokoll Abbildung 31: Integration von SSL im Protokollstack am Beispiel HTTP
SSL stellt die Dienste Authentizität, Vertraulichkeit und Integrität zur Verfügung. Diese Sicherungsdienste erfordern eine vorherige Verständigung auf einen Sicherheitsmechanismus und den Austausch von kryptographischen Schlüsseln. Diese beiden Aufgaben werden beim Verbindungsaufbau erledigt. Die Authentisierung des Clients ist optional. SSL nutzt Public-Key-Verfahren. Auf der Seite des Clients wird ein Masterkey für die betreffende SSL-Verbindung erzeugt. Dieser wird, geschützt durch den öffentlichen Schlüssel des Servers, zum Server transportiert. Dann errechnen beide Seiten jeweils auf deterministische Weise (d.h., ohne ein weiteres Geheimnis) aus diesem Masterkey einen Client-Sessionkey und einen Server-Sessionkey. Der Server-Sessionkey wird für den Weg von Server zu Client verwendet. Der Client-Sessionkey wird für die Gegenrichtung verwendet. Die kryptographischen Parameter einer Sitzung werden durch das SSL-Handshake-Protokoll produziert. Wenn ein SSL-Client und -Server eine neue Verbindung etablieren, einigen sie sich auf die Protokollversion, wählen einen kryptographischen Algorithmus und legen den Authentisierungsmodus fest. Die Authentisierung ist optional. SSL bietet drei Authentisierungsmodi an: keine Authentisierung, Client- und Serverauthentisierung mittels Diffie-Hellmann und Serverauthentisierung. Um ein gemeinsames Geheimnis zu erzeugen, benutzen Client und Server Public-Key-Verfahren. In Abbildung 32 ist der SSL-Protokollverlauf skizziert. Dabei ist der Authentisierungsmodus Serverauthentisierung dargestellt. Der Client sendet eine Nachricht ClientHello, die eine Zufallszahl, die Protokollversion und einen Vorschlag für einen Verschlüsselungsalgorithmus enthält. Der Server antwortet mit einer Nachricht ServerHello, die ebenfalls eine Zufallszahl, die Protokollversion und einen Vorschlag für einen Verschlüsselungsalgorithmus enthält. Der Server sendet sein Zertifikat nach, sofern eine Authentisierung gewünscht ist (z.B. ein X.509-Zertifikat). Der Client sendet dann die Nachricht ClientKeyExchange, die eine weitere Zufallszahl enthält (das sog. PreMasterSecret). Diese ist mit dem Public Key des Servers verschlüsselt. Client und Server berechnen daraus und aus den Zufallszahlen Client_Random und Server_Random mittels des ausgehandelten kryptographischen Algorithmus das MasterSecret. Mittels einer Berechnungsvorschrift wird ein Session_Secret ermittelt, das als Schlüssel zur symmetrischen Verschlüsselung der Daten verwendet wird. Der Client sendet die Nachricht ChangeCipherSpec. Client und Server speichern Informationen wie Zufallszahlen, Initialvektor, Protokollversion, Schlüssel und Cipher Suite in den Strukturen pending state und current state. Dadurch ist es möglich, Parameteränderungen während einer Sitzung basierend auf aktuellen Parametern durchzuführen. Durch das Signal ChangeCipherSpec wird der current state mit dem pending state überschrieben. Somit wird eine Synchronisation bei der Verwendung der Parameter erreicht. Auf das Signal ChangeCipherSpec sendet der Server die Nachricht Finished. Hier werden alle bisher ausgetauschten und verwendeten kryptographisch relevanten Parameter konkateniert, darüber wird ein Hashwert gebildet und dieser wird verschlüsselt. Der Server antwortet nach dem gleichen Verfahren. Server und Client vergleichen den Wert der Finished-Nachricht. Dadurch wird einerseits der Server authentifiziert und andererseits können bei Werteübereinstimmung Client und Server sicher sein, daß beide das gleiche Schlüsselmaterial verwenden. Anschließend kann der Datenaustausch erfolgen.
11.09.97
Firewall-Studie
Seite 75
SIEMENS
Bedrohungsanalyse der Protokolle
Client
Server
)
Client_Random CipherSuite_Proposal Protocol_Version
ClientHello ServerHello Certificate
Encrypted_PreMasterSecret
ClientKeyExchange
( (
Server_Random CipherSuite Protocol_Version X.509_Certificate
MasterSecret = f(PreMasterSecret, Client_Random, Server_Random)
MasterSecret = f(PreMasterSecret, Client_Random, Server_Random)
Session_Secrets = g(MasterSecret, Client_Random, Server_Random)
Session_Secrets = g(MasterSecret, Client_Random, Server_Random)
) Encapsulated_Handshake_Messages ) ChangeCipherSpec_Message
ChangeCipherSpec Finished ChangeCipherSpec Finished
( ChangeCipherSpec_Message ( Encapsulated_Handshake_Messages Encapsulated_Application_Data
Encapsulated_Application_Data
Abbildung 32: Protokollübersicht SSLv3 mit Serverauthentisierung 3.18.3 Steuerkommandos SSL schreibt keine Steuerkommandos vor, sondern kapselt Daten in das IP-Format. Lediglich die Darstellung der Bytes, die über das Netz gehen, sind vorgeschrieben. Steuerkommandos und Datenstruktur sind bei SSL implementierungsabhängig. 3.18.4 Protokolldatenstruktur Abbildung 33 beschreibt die Datagramm-Struktur von SSL.
SSLv3.0 record header
SSLv3.0 record body
Encryption under Write_Secret and IV_Secret HTTP datagram or SSLv3.0 Handshake, ChangeCipherSpec or Alert Data
SSLv3.0 Keyed Hash
Padding Padding length (if required) (if block cipher)
Payload content (MD5, SHA)(Payload content, MAC_Secret, Sequence_Number, Padding_Values, Length_Value, Type_Value)
Abbildung 33: SSL-Datagramm-Struktur
Seite 76
Firewall-Studie
11.09.97
SIEMENS
Secure Socket Layer (SSL)
3.18.5 Sicherheitsbedrohungen Angriff: Schlüsselrekonstruktion Bedrohung: Maskerade, Abhören Einige SSL-Implementierungen verwenden schwache Pseudozufallszahlengeneratoren, die für die Schlüsselgenerierung verwendet werden. Durch ein Schätzen der relevanten Parameter (diese betreffen Systemzeit und Prozess-ID des Clients) ist es möglich, den ursprünglichen Suchraum einer Brute-Force-Attacke entscheidend zu reduzieren. Dieses Problem betrifft die Export-Version und die nordamerikanische Version des 'Navigator' auf UNIX sowie PC-Plattformen sowie des 'Commerce Server'. Im Gegensatz zu der oben beschriebenen Berechnung eines Sessionkeys durch vollständiges Durchsuchen des Schlüsselraumes mit einigen hundert Stunden Rechenzeit, ermöglicht der zweite Angriff die Berechnung eines Masterkeys einer Verbindung in kürzester Zeit. Eine ausführliche Beschreibung dieses Angriffs findet sich in [Dr. Dobb's 96]. Angriff: Man-in-the-Middle Bedrohung: Maskerade Ein beim SSLv2 noch möglicher Man-in-the-Middle-Angriff ist bei SSLv3 nicht mehr von Erfolg gekrönt, sofern zumindestens eine Server-Authentifikation stattfindet. Eine weitere Verbesserung zu SSLv2 ist, daß SSLv3 weniger Handshake-Nachrichten während der Authentisierungsphase benötigt. 3.18.6 Interaktion mit Firewalls Die Problematik beim Einsatz eines Proxies z. B. als HTTP-Server auf einer Firewall und dem dadurch notwendigen Tunneling-Protokoll entspricht den Ausführungen zu S-HTTP (siehe Abschnitt 3.17). Die doppelte Verschlüsselung impliziert eine symmetrische Aufstellung von Web-Servern und Firewalls. Eine Beschreibung des Tunnelings von SSL ist in [Lu 95] beschrieben. 3.18.7 Filterungsmöglichkeiten SSL alleinstehend kann über Paketfilter nicht sinnvoll gefiltert werden, da weder feste Portnummern noch Spezifika des Anwendungsprotokolls bekannt sind. Erst im Zusammenhang mit einem bestimmten Anwendungsprotokoll (etwa HTTP) lassen sich Filterregeln aufstellen. Hier sind dann auch Portnummern bekannt (Port 443 bei HTTP/SSL), so daß Verbindungen von außen nach innen gezielt gesperrt werden können. Im Zusammenhang mit HTTP/SSL gelten dann die gleichen Ausführungen wie bei S-HTTP (siehe Abschnitt 3.17). Für Verbindungen von innen nach außen gelten analog zu den Forderungen bei IPv6 (siehe Abschnitte 3.2.2.1.3 und 3.2.2.2.1), daß eine durch SSL abgesicherte Verbindung zum Applikationsfilter und von dort eine zweite, unabhängige Verbindung zum Empfänger aufgebaut wird. Die auf dem Applikationsfilter installierten Applikationen bzw. Proxies führen Authentisierung, Zugriffskontrolle und Audit durch. 3.18.8 Zusammenfassung Protokoll SSL
Angriff Schlüssel-Rekonstruktion
Bedrohung Maskerade, Abhören
SSL
Man-in-the-Middle
Maskerade
11.09.97
Firewall-Studie
Gegenmaßnahme Vermeiden des Einsatzes von Export-Versionen und nordamerikanischen Versionen des Navigator und des Commerce Servers Einsatz von SSLv3 mit Authentisierung des Servers
Seite 77
SIEMENS
Bedrohungsanalyse der Protokolle
3.19 Internet Relay Chat (IRC) 3.19.1 Einsatzumgebung Das Internet Relay Chat (IRC)- Protokoll ermöglicht eine textbasierte Echtzeitkonferenz mit mehreren Teilnehmern basierend auf dem Client-Server Modell. Dabei greifen Benutzer auf IRC über dedizierte IRCClients zu oder verwenden Telnet zum Zugang zu einem Standort, der einen öffentlichen IRC-Dienst anbietet. IRC-Server stellen zahlreiche Kanäle bereit, bei denen sich Benutzer einklinken können. Jeder kann neue Kanäle einrichten, die dann bestehen bleiben, solange jemand Anschluß dazu hat. An einem IRC-Kanal können gleichzeitig unbegrenzt viele Teilnehmer angeschlossen sein. Der Server bildet eine zentrale Anlaufstelle, an den sich Clients anhängen können. Der Server führt dann das Verteilen und Multiplexen der Nachrichten durch. 3.19.2 Schematischer Ablauf IRC-Clients unterstützen sogenannte Direct Client Connections (DCCs). Mit DCC können zwei IRC-Clients eine direkte TCP-Verbindung untereinander aushandeln, wobei sie mit Ausnahme der Verhandlungsphase alle Server umgehen. Um mittels DCC mit anderen Servern zu kommunizieren, verwenden Clients Portnummern über 1023. Am Anfang sendet der anrufende Client eine Einladung an den angerufenen Client, wofür er die normalen Kanäle der IRC-Server verwendet. Die Einladung enthält eine TCP-Portnummer, auf der der anrufende Client auf die eingehende Verbindung wartet. Der angerufene Client öffnet eine TCP-Verbindung, wenn er die Einladung annehmen möchte. 3.19.3 Steuerkommandos PASS <password>
Vergibt ein Verbindungspaßwort
NICK []
Gibt den Namen an, mit dem der Benutzer angesprochen werden möchte
USER <username> <servername>
Zeigt an, daß ein neuer User hinzugekommen ist
SERVER <servername> OPER <user> <password>
Zeigt an, daß die neue Verbindung ein Server anstatt ein User ist Ermöglicht einem User, Operator-Rechte zu erlangen
QUIT []
Zeigt an, daß ein Client aussteigt
SQUIT <server>
Zeigt an, daß ein Server aussteigt
JOIN {,}[{,}] PART {,}
Zeigt an, daß ein Client dem angegebenen Kanal zuhören möchte Der Client möchte aus dem angegebenen Kanal aussteigen
MODE
Ändert den Kanalmodus
MODE
Ändert den Benutzermodus
TOPIC []
Ändert das Thema des Kanals
NAMES [{,}]
Listet die Namen der Benutzer im angegebenen Kanal auf
LIST [{,}[<server>]]
Listet die Kanäle mit ihren Themen auf
INVITE
Lädt einen Benutzer zu einem Kanal ein
KICK <user> []
Setzt einen Benutzer aus dem Kanal
VERSION [<server>]
Gibt die Versionsnummer von IRC aus
STATS [ [<server>]]
Erfragt Statistiken vom Server
LINKS [[] <server mask>]
Erfragt eine Liste der dem Server bekannten Server
TIME [<server>]
Erfragt die Zeit auf dem angegebenen Server
Seite 78
Firewall-Studie
11.09.97
SIEMENS
Internet Relay Chat (IRC)
CONNECT [<port> [[]] TRACE [<server>] ADMIN [<server>] INFO [<server>] PRIVMSG {,} WHO [[]] WHOIS [<server>][,[, ...]] WHOWAS [[<server>]] KILL PING <server1>[<server2>] PONG [] ERROR <error message>
Operator-Befehl. Zwingt einen Server eine Verbindung zu einem anderen Server aufzunehmen Erfragt eine Liste der Server, die eine Route zum angegebenen Server bilden Erfragt den Namen des Administrators des angegebenen Servers Erfragt verschiedene Informationen vom angegebenen Server Sendet eine private Nachricht an eine Liste von Empfängern Erfragt eine Liste von Benutzern, die zu dem angegebenen Namen passen Erfragt Informationen über eine Liste von Benutzern Wie WHOIS, jedoch für Benutzer, die nicht mehr existieren Unterbricht die Verbindung des Benutzers zu seinem lokalen Server Testet die Existenz einer Verbindung zum Client Antwort auf eine PING-Nachricht Sendet eine wichtige Nachricht an den Operator
Tabelle 15: IRC – Steuerkommandos
3.19.4 Sicherheitsbedrohungen Angriff: Mißbrauch von Operatoren Bedrohung: Denial-of-Service Zur Wartung des Netzes wird eine besondere Klasse von Clients ausgezeichnet (sogenannte Operatoren). Operatoren können die Verbindung zwischen jedem Client und Server kappen. Das ermöglicht einen Denialof-Service-Angriff. Angriff: USER, ping, whois, whowas Bedrohung: Sniffing IRC eignet sich aufgrund der Auskunftsfreudigkeit sehr gut für Sniffing-Angriffe. So kann man IRC durch Befehle wie USER, ping, whois, whowas ähnlich wie finger zum Sniffing ausnutzen. Angriff: IP-Spoofing Bedrohung: Maskerade Client und Server Authentisierung wird auf Basis von IP-Adressen durchgeführt. Anschließend findet optional ein Paßwortcheck statt. Als zusätzliche Hürde soll die Angabe des Benutzernamens desjenigen erfolgen, der die Verbindung aufgebaut hat. Es werden lediglich schwache Authentisierungsmechanismen eingesetzt, die leicht durch IP-Spoofing o.ä. umgangen werden können. Benutzer ohne entsprechendes Mißtrauen können durch sogenanntes social engineering dazu aufgefordert, Kommandos auszuführen, die dann das System zerstören. IRC verursacht weitere zahlreiche Sicherheitsprobleme, die aber weniger das Protokoll selbst betreffen, sondern die Konfiguration der Clients. Viele Clients gestatten den Servern unvernünftig breiten Zugang zu lokalen Ressourcen wie Dateien, Prozessen oder Programmen. Auf einem solchen schwachen Client kann ein böswilliger Server immensen Schaden anrichten. 3.19.5 Filterungsmöglichkeiten IRC basiert als Dienst auf TCP. Dabei überwachen Server den Port 6667 auf eingehende Verbindungen (sowohl von Clients als auch von anderen Servern), manche Server benutzen jedoch auch andere Portnummern. Clients und Server, die mit anderen Servern kommunizieren, verwenden Portnummern über 1023. Folgende Tabelle gibt eine "Erlaubt"-Regelmenge an. Alles, was nicht erlaubt ist, ist verboten [Chapman, Zwicky 96]13.
11.09.97
Firewall-Studie
Seite 79
SIEMENS
Bedrohungsanalyse der Protokolle
Richtung
QuellAdresse
ZielAdresse
Protokoll
QuellPort
ZielPort
ACK gesetzt
Bemerkungen
ein
extern
intern
TCP
>1023
6667
a
Externer Client oder Server nimmt Kontakt zum internen Server auf
aus
intern
extern
TCP
6667
>1023
ja
Interner Server antwortet externem Client oder Server
aus
intern
extern
TCP
>1023
6667
a
Interner Client oder Server nimmt Kontakt zum externen Server auf
ein
extern
intern
TCP
6667
>1023
ja
externer Server antwortet internem Client oder Server
ein
extern
intern
TCP
>1023
>1023
a
Interner Client fordert eine IRCVerbindung an; externer Client beantwortet die Einladung des internen Clients
aus
intern
extern
TCP
>1023
>1023
ja
Interner Client fordert eine IRCVerbindung an
aus
intern
extern
TCP
>1023
>1023
a
Externer Client fordert eine IRC-Verbindung an; interner Client beantwortet die Einladung des externen Clients
ein
extern
intern
TCP
>1023
>1023
ja
Externer Client fordert eine IRC-Verbindung an
a.
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 16: IRC-Filterungsmöglichkeiten
Wegen der verbreiteten Schwächen der Clients ist der Einsatz von IRC über Filter, obwohl möglich, nicht empfehlenswert [Chapman, Zwicky 96]. Die beste Möglichkeit zum Einsatz von IRC ist eine Opfermaschine ohne vertrauliche Daten in einem Screened Subnet. Die Benutzer müssen sich auf dieser Maschine einloggen und IRC starten. IRC-Server sind baumartig angeordnet und kommunizieren untereinander, um Nachrichten an alle Clients weiterzuleiten. Wegen dieser baumartigen Architektur dient jeder IRC-Server als Proxy-Server. Um einen Proxy für IRC einzurichten, startet man einfach einen IRC-Server auf dem Proxy-Rechner und richtet die internen Clients auf diesen Server. Zusätzlich kann man einen Server innerhalb der Firewall für private (interne) IRC-Konferenzen zu betreiben. Dabei muß sichergestellt werden, daß der interne IRC-Server nicht mit externen IRC-Servern kommuniziert. Andernfalls dient er als Proxy für die internen IRC-Clients und für Attacken, die von außen ausgehen. Wird IRC über eine Firewall hinweg erlaubt, so muß man zumindest unterbinden, daß interne Clients DCCVerbindungen anfordern. Andernfalls müßten eingehende TCP-Verbindungen von externen Clients zu allen Portnummern > 1023 auf den internen Rechnern erlaubt werden. 3.19.6 Zusammenfassung Protokoll IRC
Angriff Mißbrauch von Operatoren
Bedrohung Denial-of-Service
IRC
USER, ping, whois, whowas
Sniffing
IRC
IP-Spoofing
siehe Abschnitt 3.1
Seite 80
Firewall-Studie
Gegenmaßnahme Zusätzliche Verwendung starker Authentisierungsmechan-ismen Filtern von IRCNachrichten siehe Abschnitt 3.1
11.09.97
SIEMENS
Line Printer Spooler (lpr)
3.20 Line Printer Spooler (lpr) 3.20.1 Einsatzumgebung Line Printer Spooler (lpr) ermöglicht es, eine Datei im Hintergrund zu drucken. Die Datei wird in eine Warteschlange geleitet und gedruckt, sobald der Drucker verfügbar ist. Lpr basiert als Dienst auf TCP. Server benutzen Port 515. Clients benutzen wie die r-Kommandos beliebige Portnummern unter 1023. 3.20.2 Filterungsmöglichkeiten Damit Benutzer von außen die Drucker im internen Netz nicht blockieren können, sollte lpr durch eine Firewall abgewiesen werden. Durch einen statischen Paketfilter kann lpr als Dienst abhängig von Benutzer und Zeit gefiltert werden, da lpr den Port 515 verwendet.
3.21 Network File System (NFS) 3.21.1 Einsatzumgebung Das Network File System ermöglicht mehreren Benutzern, auf Dateien zuzugreifen, die im Netz verteilt gespeichert sind. Es ist unabhängig von Rechnern und unteren Schichten, wie zum Beispiel der Transportschicht, denn es befindet sich oberhalb des RPC (siehe Abschnitt 3.29). NFS besteht aus zwei Protokollen: mount protocol und NFS protocol. Das mount protocol identifiziert das Filesystem und den Remote Host, auf den zugegriffen werden soll. Das NFS protocol führt die eigentlichen Operationen zur Datenübertragung aus. Ein NFS-Server führt seine Operationen durch mehrere Prozeduren aus. Diese Prozeduren sind zustandslos, d.h. es werden keine Zustandstabellen gepflegt, die z.B. den Fortschritt der Prozeduroperation verfolgen. Der Benutzer von NFS kann u.a. folgende Dienste in Anspruch nehmen: • •
Erzeugen, Umbenennen, Kopieren, Lesen von Dateien und Verzeichnissen, Attribute von Dateien lesen und setzen.
3.21.2 Sicherheitsbedrohungen Angriff:
Ausnützen von Sicherheitslücken, falsche Systemkonfiguration Bedrohung: Maskerade In zunehmendem Umfang werden Sicherheitslücken in der Implementation oder Konfiguration des NFS von Angreifern ausgenutzt. Die entsprechenden Programme zum Ausnutzen dieser Lücken sind weit verbreitet. In der Regel kann ein erfolgreicher Angreifer jede beliebige Identität außer root annehmen. Es ist normalerweise nicht notwendig, daß Rechner außerhalb des eigenen Subnetzes auf exportierte Platten zugreifen. Darum sollte der Zugang zu dem NFS-Protokoll auf lokale Maschinen eingeschränkt werden. Der NFS-Dämon läuft üblicherweise auf dem UDP-Port 2049. Ein direkter Zugriff auf den NFS-Dämon kann also unterbunden werden, wenn Pakete zu diesem UDP-Port nicht durch einen Router bzw. eine Firewall gelassen werden. Um das Restrisiko eines NFS-Dämons auf einem anderen Port auszuschalten, müßten alle UDPPakete gefiltert werden. Da dies aber entscheidende Auswirkungen auf den Betrieb des gesamten Rechnernetzes hat (alle UDP-Dienste würden abgewiesen), ist dies nur im Rahmen eines umfassenden FirewallKonzeptes realisierbar (siehe Abschnitt 4.6). Um den Zugang zum portmapper einzuschränken, sollten alle Verbindungen von Rechnern außerhalb des eigenen Netzes zu dem Port 111 für beide Transportprotokolle TCP und UDP abgewiesen werden (siehe Abschnitt 3.29) [CA-94:15]. Neben den Sicherheitslücken in den o.g. Programmen kann auch die System-Konfiguration zu Problemen führen. Daher sollte der Zugriff auf Rechner, die den Zugriff zu NFS benötigen, beschränkt werden. Ferner sollten keine Dateisysteme an den eigenen Rechner oder an localhost exportiert werden, damit kein indirekter Zugriff über ein anderes Programm möglich wird. Wenn möglich, sollten die NFS-Zugriffe auf read-only (ro) beschränkt sein. Diese Option ro sollte bei dem Export auf dem Server benutzt werden. Zugriffe für den Benutzer root sollten ebenfalls nur dort erlaubt sein, wo sie unbedingt notwendig sind. Eine Authentisierung des Zugriffes über NFS findet nur statt, wenn man ein entsprechendes Verfahren aktiviert. Unterstützt werden z.B. DES (Option secure) oder Kerberos (Option kerberos). Ein DES-Verfahren wird in der Regel von dem 11.09.97
Firewall-Studie
Seite 81
SIEMENS
Bedrohungsanalyse der Protokolle
Betriebssystem mitgeliefert. Sollte keine der o.g. Authentisierungsmethoden genutzt werden, so findet keine Überprüfung der zugreifenden Benutzerkennung statt. Somit kann jeder Benutzer (unter Verwendung eines entsprechenden Programms) auf die Daten der anderen Benutzer zugreifen. Besonders gravierend wirkt sich dieses Problem aus, falls der NFS-Server keine Kontrolle der Portnummern durchführt und so auch einen Zugang von nicht-privilegierten Ports (größer 1023) - also von jedem Benutzer - zuläßt. Bei der Aufteilung in privilegierte und nichtprivilegierte Ports ist zu beachten, daß dem Rechner aber auch dem Administrator selbst Vertrauen entgegengebracht werden muß, damit Rechner oder Administrator diese Vereinbarung nicht unterlaufen. Vielfach ist ein solches Vertrauen nicht gerechtfertigt, so daß diese Einteilung obsolet geworden ist. Gleiches gilt analog, falls einem System NFS-Zugang gewährt wird, welches keine Unterscheidung zwischen "privilegierten" und "nicht-privilegierten" Ports kennt (z.B. DOS). 3.21.3 Filterungsmöglichkeiten NFS basiert als Dienst auf RPC, das mit einem Paketfilter nur schwer zu sichern ist, da die meisten RPCServer keine festen Portnummern verwenden. NFS verwendet zwar standardmäßig Port 2049, es gibt aber Ausnahmen. Auch ist ein geeigneter Proxy für NFS nicht vorhanden, da bei NFS große Datenmengen ausgetauscht werden müssen. Somit ist empfehlenswert, NFS nicht über eine Firewall hinweglaufen zu lassen. 3.21.4 Zusammenfassung Protokoll NFS
Angriff Ausnutzen falscher Systemkonfiguration
Bedrohung Diebstahl von Daten
Gegenmaßnahme von Firewalls abweisen
3.22 Network Time Protocol (NTP) 3.22.1 Einsatzumgebung Das Network Time Protocol [RFC 1305] synchronisiert die Systemuhren einzelner Netzkomponenten. Die Systeme organisieren sich selbst entsprechend einem gerichteten Graphen, in Abhängigkeit von ihrem Abstand zu einem zuverlässigen Zeitgeber. Genaugehende Systemuhren erlauben den Vergleich von Protokolldaten verschiedener Maschinen. Die Präzision von NTP liegt bei einer Abweichung von 10ms und weniger. Somit bleibt die Reihenfolge von automatisierten Angriffen auf mehrere Systeme selbst dann rekonstruierbar, wenn sie fast gleichzeitig ablaufen. 3.22.2 Sicherheitsbedrohungen Angriff: Replay-Attack Bedrohung: Maskerade Indem dem Zielsystem eine falsche Uhrzeit vorgetäuscht wird, können bei Authentisierungsverfahren, die Zeitstempel benutzen, alte Authentisierungsnachweise wiederverwendet werden. NTP sollte über ein Proxy geschaltet werden, damit einerseits eine Synchronisation möglich ist, andererseits eine Manipulation ausgeschlossen werden kann (z.B. durch Einsatz von Kryptographie). Sofern eine genaue Zeitquelle im internen Netz vorhanden ist oder der Abgleich der Zeit mit der externen Welt nicht notwendig ist, ist NTP über eine Firewall obsolet. Es reicht aus, NTP intern zu betreiben. Sollte NTP jedoch zum Internet betrieben werden, so ist ein NTP-Server auf einem Bastion-Host als Proxy für einen internen Server empfehlenswert. 3.22.3 Filterungsmöglichkeiten NTP-Server verwenden Port 123, um untereinander und mit NTP-Clients zu kommunizieren. NTP-Clients benutzen beliebige Portnummern über 1023. Die folgende Tabelle gibt "Erlaubt"-Regeln an. Dabei ist alles, was nicht erlaubt ist, verboten [Chapman, Zwicky 96]13.
Seite 82
Firewall-Studie
11.09.97
SIEMENS
Richtung
Network News Transfer Protocol (NNTP)
Zieladresse
ein
Quell Adresse extern
intern
Protokoll UDP
Quellport > 1023
Zielport 123
ACK gesetzt nicht möglich
aus
intern
extern
UDP
123
> 1023
nicht möglich
aus
intern
extern
UDP
>1023
123
nicht möglich
ein
extern
intern
UDP
123
> 1023
nicht möglich
ein
extern
intern
UDP
123
123
nicht möglich
aus
intern
extern
UDP
123
123
nicht möglich
Bemerkungen Eingehende Anfrage, Client an Server Antwort auf eingehende UDPAnfrage Server an Client Ausgehende Anfrage, Client an Server, Client an Server Antwort auf ausgehende UDPAnfrage, Server an Client Anfrage oder Antwort zwischen zwei Servern Anfrage oder Antwort zwischen zwei Servern
Tabelle 17: NTP-Filterungsmöglichkeiten 3.22.4 Zusammenfassung Protokoll NTP
Angriff Replay
Bedrohung Maskerade
NTP
Sniffing
Spoofing
Gegenmaßnahme NTP filtern bis auf eventuell vorhandene vertrauenswürdige externe Zeitquelle TRACE sperren
3.23 Network News Transfer Protocol (NNTP) 3.23.1 Einsatzumgebung Das Network News Transfer Protocol [RFC 977] wird für die Übertragung von Newsartikeln benutzt. Es ähnelt der des SMTP, nur werden keine interpersonellen Nachrichten zwischen Benutzern, sondern Artikel zwischen NNTP-Servern bzw. NNTP-Servern und NNTP-Clients ausgetauscht. NNTP benötigt als darunterliegendes Protokoll TCP. 3.23.2 Schematischer Ablauf Auf den über NNTP kommunizierenden Rechnern läuft je ein NNTP-Dämon. Der NNTP-Dämon (in UNIX nntpd) verwaltet die Verbindungen mit Benutzern und anderen NNTP-Servern und regelt den Zugriff auf die Newsdateien. Zwei weitere Programme (in UNIX nntpsend und nntpxmit) übernehmen das regelmäßige Aufbereiten und Senden von News zum Nachbar-NNTP-Server (siehe Abbildung 34 [Schel 94]). Das Zusammenspiel dieser beiden Programme nennt man Push-Methode.
11.09.97
Firewall-Studie
Seite 83
SIEMENS
Bedrohungsanalyse der Protokolle
NNTP-Server B
NNTP-Server A Artikel
directory
nntpsend
rnews
nntpxmit
nntpd
Internet
Abbildung 34: Die Push-Methode Ein letztes Programm (in UNIX nntpxfer) übernimmt die Anfrage nach News beim Nachbar-NNTP-Server. Das Zusammenspiel zwischen nntpd und nntpxfer wird Pull-Methode genannt (siehe Abbildung 35 [Schel 94]).
NNTP-Server A
NNTP-Server B
nntpd
nntpxfer
ô í ÷ û ø
Connect Greeting New News Response Article (ID) Send Article (wiederhole 5&6...)
ù î
QUIT Disconnect
Abbildung 35: Die Pull-Methode 3.23.3 Steuerkommandos Tabelle 18 zeigt eine Auswahl interaktiver Kommandos, die zwischen News-Clients und News-Servern ausgetauscht werden [Schel 94].
Seite 84
Firewall-Studie
11.09.97
SIEMENS
Network News Transfer Protocol (NNTP)
Kommando
Beschreibung
NEWNEWS
Sende eine Liste neuer Newsartikel!
HEAD
Sende den Header eines Artikels!
ARTICLE
Sende den angeforderten Artikel!
NEXT
Sende den nächsten Artikel in der aktuellen Newsgruppe!
LIST
Sende eine Liste gültiger Newsgruppen!
POST
Versende den folgenden Artikel!
IHAVE
Habe einen bestimmten Artikel, möchtest Du ihn?
Tabelle 18: NNTP-Kommandos 3.23.4 Protokolldatenstruktur Eine Usenet-News-Nachricht besteht aus einem Header und dem Body, der den eigentlichen Artikel enthält. Die Felder des Headers sind im einzelnen: • • •
From: Path: Newsgroups:
• • •
Subject: Message-ID: Date:
beschreibt die E-Mail Adresse des Senders, beschreibt den Pfad, den die Nachricht bisher durch das Netz ging, enthält diejenige(n) Newsgruppe(n), an die die Nachricht geschickt wurde, enthält den Gegenstand der Nachricht, ordnet einer Nachricht eine eindeutige Kennung zu, Absendedatum bezogen auf den Verfasser der Nachricht.
3.23.5 Sicherheitsbedrohungen Angriff: Ausführbarer Code Bedrohung: Manipulation Eine Gefahrenquelle liegt darin, daß NNTP über WWW-Browser übertragen werden kann. Somit besteht die Möglichkeit, Java-Applets oder ActiveX-Controls über NNTP zu versenden. Die Risiken von Java und zugehörige Gegenmaßnahmen sind in 3.33 beschrieben. 3.23.6 Filterungsmöglichkeiten Sollen externe News-Gruppen intern zur Verfügung stehen, so können diese nicht abgewiesen werden. Allerdings kann man eine Auswahl derjenigen News-Gruppen treffen, die nicht durch ein Gateway durchgelassen werden sollen. NNTP ist ein Dienst auf Basis von TCP. NNTP-Server verwenden Port 119. NNTP-Clients (sowie Server, die News zu anderen Servern übertragen), benutzen Portnummern über 1023. Jede Zeile der folgenden Tabelle enthält eine "Erlaubt"-Regel. Alles, was nicht erlaubt ist, ist verboten [Chapman, Zwicky 96]13.
11.09.97
Firewall-Studie
Seite 85
SIEMENS
Richtung
Bedrohungsanalyse der Protokolle
Zieladresse
Protokoll
Quellport
Zielport
ein aus
QuellAdresse extern intern
Intern Extern
TCP TCP
> 1023 119
119 > 1023
ACK gesetzt a ja
aus ein
intern Extern
Extern Intern
TCP TCP
>1023 119
119 > 1023
a ja
meist intern
intern
News-Server
TCP
> 1023
119
a
meist intern
NewsServer
Intern
TCP
119
>1023
ja
a.
Bemerkungen Eingehende News Eingehende News-Antworten Ausgehende News Ausgehende News-Antworten Client zum Lesen von News / (Newsreader) Server sendet Artikel zu einem Newsreader
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 19: NNTP-Filterungsmöglichkeiten
Es gibt verschiedene Wege, wie NNTP durch einen Firewall-Server geschleust werden kann. Die naheliegendste Lösung ist, es wie Mail zu behandeln, da der Ablauf von NNTP dem von SMTP ähnelt. Eingehende und ausgehende News-Artikel werden auf dem Gateway verarbeitet und bereitgehalten. Da allerdings NNTP viele Ressourcen beansprucht, sollte der reguläre Gateway nicht damit belastet werden. Es sollten keine vertraulichen, internen News-Gruppen im Gateway lagern. Folglich sollte das Gateway kein interner NewsServer sein. Somit bietet sich eine Tunnelstrategie an: man läßt NNTP intern auf einem News-Server laufen, der Gateway reicht die News-Artikel von außen mit einem Relaisdienst an den News-Server durch. Wegen der Zugriffsvielfalt auf einen News-Server sollte als News-Server kein Bastion-Host verwendet werden. Außerdem sollten externe NNTP-Verbindungen nur mit Standorten erlaubt werden, mit denen News ausgetauscht werden sollen. Soll eine Verbindung zu einem ausgesuchten externen NNTP-Server aufgebaut werden, so sollte ein Proxy eingesetzt werden, um mittels Authentisierungsmechanismen die Identität und Authentizität der externen Newsserver überprüfen zu können. 3.23.7 Zusammenfassung Protokoll NNTP
Angriff ausführbarer Code
Bedrohung Manipulation
Gegenmaßnahme JAVA, ActiveX, MIME filtern. Einsatz eines Gateways für externe Newsgruppen. Kein Bastion-Host als News-Server
3.24 Post Office Protocol (POP) 3.24.1 Einsatzumgebung Das Post Office Protocol (POP) ermöglicht einem Rechner, der nicht genügend Ressourcen für einen Mailserver oder keinen Mail-Dämon laufen hat, Mails von einem Server zu holen, der diese dort speichert. Dabei ist die Funktionalität auf “Mail herunterladen und optional auf dem Server löschen” beschränkt. 3.24.2 Filterungsmöglichkeiten Authentisierung bei POP erfolgt lediglich aufgrund des Usernames und eines Paßwortes in einem Befehl. Diese Paßwörter laufen ungeschützt übers Netz und sind somit für Angreifer lesbar. Empfehlenswert sind hier Einmalpaßworte oder Challenge & Response Mechanismen und somit eine Modifikation von Client und Server. Sofern dies nicht möglich ist und eine Firewall eine entsprechende Verschlüsselung nicht anbietet, sollte dieser Dienst nicht nach außen angeboten werden. In diesem Fall sind also POP-Nachrichten von Firewalls abzuweisen.
Seite 86
Firewall-Studie
11.09.97
SIEMENS
Simple Mail Transfer Protocol (SMTP)
3.25 Simple Mail Transfer Protocol (SMTP) 3.25.1 Einsatzumgebung Der Simple Mail Transfer Protocol [RFC 821, 822] Standard ist eines der meist genutzten Protokolle in den oberen Ebenen des Internet-Protokollstacks. Wie der Name sagt, definiert SMTP, wie Nachrichten (Mails) zwischen zwei Usern zu übertragen sind. SMTP benutzt dabei das Spooling-Konzept. Die Idee des Spoolings ist, Mail von einer lokalen Anwendung zur SMTP-Anwendung zu senden, die dann die Mail speichert. Üblicherweise wird die bei der SMTP-Anwendung ankommende Nachricht in eine Warteschlange geleitet. Ein Server überprüft, ob Nachrichten verfügbar sind, und versucht dann diese zu senden. Ist der User nicht erreichbar, so versucht es der Server zu einem späteren Zeitpunkt erneut. Können die Nachrichten schließlich nicht geliefert werden, so werden sie entweder vernichtet oder zum Sender zurückgeschickt. Dies ist unter dem Namen “Ende-zu-Ende-Liefersystem” bekannt. 3.25.2 Schematischer Ablauf Abbildung 36 [Black 95] zeigt das allgemeine SMTP-Modell. Zuerst etabliert das Sender-SMTP eine Kommunikation mit dem Empfänger-SMTP. Bevor die Mails übertragen werden, besteht die Gelegenheit, Paßwörter oder Authentisierungssignale auszutauschen. Danach überträgt der Sender den Befehl “MAIL”, der die Identifizierung des Senders und einige zusätzliche Informationen zum Mailaustausch liefert. Der Empfänger muß daraufhin eine Bestätigung senden. In SMTP ist diese Bestätigung “250” oder “250 OK”. Dann wird mit dem Befehl RCPT der Bestimmungsort der Nachrichten übertragen. Hierauf ist wieder eine Bestätigung von dem Empfänger notwendig. Anschließend wird der Befehl DATA gegeben, um den (die) Empfänger auf eine nachkommende Nachricht vorzubereiten. Dann werden die Daten zeilenweise übertragen, bis der Sender eine spezielle Folge von Steuerungszeichen sendet, die das Ende der Nachricht signalisieren. Um anzuzeigen, daß der Sendeprozeß abgeschlossen ist, sendet der Sender den Befehl QUIT. Die SMTP-Verbindung wird dann abgebaut. Andernfalls kann er weitere Nachrichten senden.
User
SenderSMTP
SMTP-Befehle, Antworten und Mails
EmpfängerSMTP
File System
File System Abbildung 36: Das SMTP-Modell
3.25.2.1 Nachrichtenformat Das Sender-SMTP benutzt für seine Sender- und Empfänger-Adreßfelder ein Standardformat. Sie sind von der Form local-part@domain-name17 Daher entspricht der SMTP-Name dem Konzept des Domain Name Systems (DNS). Einige Server benutzen denselben Server, um eine IP-Adresse von diesem Namen abzuleiten. In der Praxis könnte dieses Format wie folgt aussehen:
17
Statt einem Domänen-Namen kann dort auch ein bestimmter Rechnername stehen.
11.09.97
Firewall-Studie
Seite 87
SIEMENS
Bedrohungsanalyse der Protokolle
[email protected] dabei
ist
der lokale Sender
Name
Andreas.Bonnard, und Empfänger
der
Domain-Identifikator
mchp.siemens.de.
Establish Connection 220 OK HELO .mchp.siemens.de 250 mchp.siemens.de MAIL FROM [email protected] 250 OK RCPT TO [email protected] 250 OK DATA 354 Lines Lines CRLF CRLF 250 OK QUIT 221
Abbildung 37 [Black 95] zeigt einen einfachen Mail-Austausch zwischen zwei SMTP-Usern.
Seite 88
Firewall-Studie
11.09.97
SIEMENS
Simple Mail Transfer Protocol (SMTP) Sender
Empfänger
Establish Connection 220 OK HELO .mchp.siemens.de 250 mchp.siemens.de MAIL FROM [email protected] 250 OK RCPT TO [email protected] 250 OK DATA 354 Lines Lines CRLF CRLF 250 OK QUIT 221
Abbildung 37: Eine SMTP-Mail-Transaktion Der Sender etabliert eine Verbindung. Der Empfänger antwortet mit 220 OK. Das Kommando HELO dient zur Identifizierung der beiden beteiligten Maschinen. Der Befehl MAIL FROM zeigt dem Empfänger an, daß eine neue Mail-Transaktion beginnt. Der Empfänger leert auf dieses Kommando hin seine Puffer, setzt Zustandstabellen zurück und bereitet sich für die Nachricht vor. Als nächstes gibt das RCPT-Kommando den Forward-Pfad des End-Adressaten an. In diesem Beispiel ist [email protected] der Adressat, was mit 250 OK beantwortet wird. Der Befehl DATA informiert den Empfänger, daß die Nachricht folgt. Er antwortet 354, das “starte Mail-Input und ende mit CRLF CRLF” bedeutet. Die Daten werden übertragen und das Ende der Nachricht wird mit CRLF CRLF angezeigt. Der Empfänger antwortet mit 250 OK. Zum Abschluß wird die Verbindung durch den Befehl QUIT aufgehoben. Der Empfänger bestätigt mit 221. 3.25.3 Steuerkommandos Syntax HELO <domain> MAIL FROM: RCPT TO: DATA RSET SEND FROM: SOML <SP> FROM: SAML <SP> FROM: VRFY <SP> <string> EXPN <SP> <string> HELP [<SP> <string>] NOOP QUIT TURN
11.09.97
Semantik identifiziert das Sender-SMTP initiiert eine Mail-Transaktion identifiziert den jeweiligen Empfänger kündigt das Nachfolgende als Mail an Mailübertragung wird abgebrochen initiiert eine Mail-Transaktion Send or Mail From Send and Mail identifiziert den Benutzer zum Expandieren einer mailing-list sendet Hilfe-Informationen zum Sender Empfänger antwortet mit OK Empfänger sendet OK und schließt die Verbindung vertauscht die Rollen Sender - Empfänger
Firewall-Studie
Seite 89
SIEMENS
Bedrohungsanalyse der Protokolle
3.25.4 Sicherheitsbedrohungen Angriff: Flooding Bedrohung: Denial-of-Service SMTP kann als Basis für einen Denial-of-Service Angriff dienen. Dieser Angriff zielt darauf ab, die legitime Benutzung einer Maschine zu verhindern. Angenommen, ein Angreifer sendet von 50 Maschinen aus jeweils 1000 1-MB Mails an sein Opfer. Dann ist es wahrscheinlich, daß das System des Opfers dies nicht verarbeiten kann. Es ist empfehlenswert, daß eine Organisation eine zentrale Einrichtung benennt, die für Mail zuständig ist. Dieser zentrale Mailserver sollte sich in einem Screened Subnet hinter dem äußeren Paketfilter befinden. Ein zusätzlicher innerer Mailserver hinter der Bastion-Host sollte über die Bastion-Host mit dem äußeren Mailserver Mails austauschen (siehe Abschnitt 4.3). Angriff: MAIL FROM Bedrohung: Maskerade, Umleiten Eine Gefahr stellt der Befehl MAIL FROM dar. Bei der Ausführung eines Mail-Austauschs nach SMTP spezifiziert der Sender eine Absenderadresse im Befehl MAIL FROM. Für die lokale Maschine gibt es hier jedoch keine verläßliche Möglichkeit, die Absenderadresse zu verifizieren. Basierend auf SMTP kann man nicht sicher sein, von wem die Nachricht stammt. Um Vertraulichkeits- oder Integritätsschutz zu ermöglichen, sind zusätzliche (z.B. kryptographische) Schutzmaßnahmen nötig. Angriff: VRFY, EXPN Bedrohung: Sniffing Der Mail-Alias gibt dem Angreifer einige nützliche Informationen. Befehle wie VRFY <postmaster> VRFY übersetzen den Mail-Alias in den eigentlichen Login-Namen. Dies gibt dem Angreifer Hinweise, wer der Administrator des Systems ist und welche Accounts die Interessantesten im Falle eines erfolgreichen Angriffs sind. Für nicht vertrauenswürdige User sollte der Befehl VRFY gesperrt werden. Allerdings kann z.B. der finger Service viel mehr Informationen bieten. Ebenfalls gesperrt werden sollte EXPN. EXPN expandiert einen Alias einer Mailingliste. Dies kann zum Vertraulichkeitsverlust führen. Hierbei ist es nützlich, einen Alias auf einer wohlbekannten Maschine zu einer inneren Maschine zu haben, die von außen nicht erreichbar ist, so daß die Expansion dort ohne Risiko vonstatten gehen kann. sendmail In UNIX ist die häufigste Implementierung von SMTP sendmail. Dieses Programm ist in den meisten UNIXSoftware-Paketen enthalten. Das Programm sendmail ist aus Sicherheitssicht sehr bedenklich. Es besteht aus zehntausenden Zeilen C-Code und besitzt häufig privilegierte Rechte. Die Größe des Programms widerspricht dem Prinzip, daß privilegierte Programme so klein und modular wie möglich sein sollen. Sendmail benötigt Schreibrechte auf seinem Spool-Verzeichnis (in UNIX-Systemen üblicherweise /var/spool/mqueue) und Leserechte auf /dev/kmem, so daß es die aktuelle Auslastung ermitteln kann. Außerdem benötigt es eine Möglichkeit, um sich an Port 25 anzubinden. Dies kann vermieden werden, indem man es über inetd18 laufen läßt, so daß sendmail selbst den Befehl bind nicht aufrufen muß. Der Nachteil dabei ist, daß die Verbindung nach Beendigung abbricht und sendmail immer wieder gestartet werden muß. In sendmail ist es standardmäßig möglich, ein beliebiges Kommando unter der sendmail-userid (uid) auszuführen. Falls also postprocessing nicht vorgesehen bzw. notwendig ist, sollte die Möglichkeit, an Programme (z.B. Filter) zu mailen, untersagt werden. Der Debug-Modus erlaubt einem Angreifer, über den sendmail-Port Zugang zu einer Maschine zu erlangen. Dies ist lediglich in alten sendmail-Versionen möglich. Diese sollten durch neuere ersetzt werden. Mittels des Steuerbefehls Wizard erhält ein Angreifer Zugang zu einer Maschine über einen sendmail-Port. Der SMTP-Befehl Wizard sollte gesperrt sein oder neuere Versionen von sendmail verwendet werden. Angriff: Ausführbarer Code Bedrohung: Manipulation Der Inhalt einer Mail kann eine Gefahr darstellen. Abgesehen von möglichen Fehlern im Mailer der Empfängermaschine ist die automatische Ausführung von “Multipurpose Internet Mail Extensions (MIME)”-
18
Internetdämon in UNIX
Seite 90
Firewall-Studie
11.09.97
SIEMENS
Telnet
codierten Nachrichten sehr gefährlich. Dadurch können beispielsweise beliebige Dateien des Benutzers überschrieben werden. Genaueres über Gefahrenquellen von MIME ist in 3.31.11 ausgeführt. Eine weitere Gefahrenquelle liegt darin, daß Mail über Mailtools übertragen werden kann (z.B. auch WWWBrowser), wobei Dateien als Anhang mitversendet werden. Somit besteht die Möglichkeit, Java-Applets über Mail zu versenden. Die Risiken von Java und zugehörige Gegenmaßnahmen sind in 3.33 ausführlich beschrieben. 3.25.5 Filterungsmöglichkeiten SMTP basiert als Dienst auf TCP. SMTP-Empfänger benutzen Port 25, SMTP-Sender beliebige Portnummern über 1023. Folgende Tabelle enthält "Erlaubt"-Regeln. Dabei wird davon ausgegangen, daß alles, was nicht erlaubt ist, verboten ist [Chapman, Zwicky 96]13. Richtung
Zieladresse
Protokoll
Quellport
Zielport
ein
Quell Adresse extern
intern
TCP
> 1023
25
ACK gesetzt a
aus
intern
extern
TCP
25
> 1023
ja
aus
intern
extern
TCP
>1023
25
a
ein
extern
intern
TCP
25
> 1023
ja
a.
Bemerkungen Eingehende Mail, Absender an Empfänger Eingehende Mail, Empfänger an Sender Ausgehende Mail, Absender an Empfänger Ausgehende Mail, Empfänger an Absender
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 20: SMTP-Filterungsmöglichkeiten
Ein Mailserver wie sendmail sollte nicht auf einem Bastion-Host installiert sein. Vielmehr sollte sich ein Mailserver für externe Mails innerhalb des Screened Subnet befinden. Sofern der Mailserver dennoch auf dem Bastion-Host installiert wird, sollte er nur mit der notwendigsten Funktionalität als Relay dienen. Eine Firewall sollte dazu in der Lage sein, SMTP-Verbindungen zwischen vertrauenswürdigen Usern zu verschlüsseln. Dazu ist jedoch ein starker Authentisierungsmechanismus notwendig. Eine Möglichkeit, SMTP-Verbindungen zu schützen ist, den Nachrichten-Header zu verschlüsseln [Bellovin 89]. [RFC 822] unterstützt dies. Diese Option wird allerdings kaum verwendet. Indem der NachrichtenHeader verschlüsselt wird, kann ein Angreifer zum einen Mail-Header nicht sinnvoll fälschen und zum anderen die Informationen im Header nicht interpretieren. 3.25.6 Zusammenfassung Protokoll SMTP SMTP
Angriff Flooding MAIL FROM
Bedrohung Denial-of-Service Maskerade, Umleiten
SMTP SMTP
sendmail Ausführbarer Code
Manipulation
Gegenmaßnahme zentraler Mailserver starke Authentisierungsmechanismen Alternative upas einsetzen JAVA, ActiveX, MIME filtern
3.26 Telnet 3.26.1 Einsatzumgebung Das Telnet-Protokoll [RFC 1416] ermöglicht einem Benutzer, eine Terminal-Sitzung auf einem entfernten Rechner durchzuführen und definiert hierzu virtuelle Ein- und Ausgabe-Einheiten (sog. Network Virtual Terminals), für die Verbindungsparameter ausgehandelt werden müssen. Telnet trifft Vereinbarungen zur Aushandlung einer Anzahl von Funktionen und Diensten für eine Terminal-basierte Sitzung zwischen zwei Maschinen. Damit ermöglicht das Telnet-Protokoll einem Programm auf einer Host-Maschine den Zugriff auf die Ressourcen einer anderen Maschine (Telnet-Server genannt), so als ob der Client lokal an den Server angeschlossen wäre.
11.09.97
Firewall-Studie
Seite 91
SIEMENS
Bedrohungsanalyse der Protokolle
Um mit dem Kommando telnet auf einen anderen Rechner zugreifen zu können, muß auf diesem der Telnet-Dämon laufen. Standard-Port für eine Telnet-Sitzung ist der Port 23. Andere Portnummern lassen sich als Parameter angeben, wodurch auch eine Verbindung zu anderen Server-Prozessen hergestellt werden kann. 3.26.2 Schematischer Ablauf Abbildung 38 [Black 95] zeigt, wie die einzelnen Optionen zwischen zwei Parteien ausgehandelt werden können. Der Client beginnt mit der Aushandlung, indem es der anderen Partei eine Option vorschlägt. Die zweite Partei antwortet, ob sie diese Option unterstützen kann. Falls ja, fragt die initiierende Partei nach den Charakteristika dieser Option. Die antwortende Partei sendet Informationen über die Option, die z.B. Charakteristika des Terminals der antwortenden Partei beinhalten.
A
B
unterstützt Du Funktion x? Ja, ich werde Funktion x unterstützen. Sende mir die Charakteristika der Funktion x. Hier sind meine Charakteristika von Funktion x. Unterstützt Du Funktion y? Nein, ich unterstütze Funktion y nicht.
Abbildung 38: Aushandlung von Optionen in Telnet 3.26.3 Steuerkommandos Die Nachrichten, die zwischen Client und Server hin- und herfließen, müssen dem Telnet-Nachrichtenformat entsprechen. Die wichtigsten Telnet-Funktionen sind in Tabelle 21 [Black 95] mit einer kurzen Erläuterung aufgeführt. Diese Funktionen sind in fast allen Terminal-basierten Anwendungen vorhanden. Funktion Interrupt process (IP) Abort output (AO) are you there (AYT) erase character (EC)
erase line (EL) go ahead (GA)
Beschreibung erlaubt dem System, einen Benutzerprozeß zu unterbrechen oder zu beenden. Dadurch kann der Benutzer beispielsweise aus einer Endlosschleife herauskommen. ermöglicht einer Anwendung, zu Ende zu laufen, jedoch den Output nicht zur Workstation des Benutzers zu senden. Sie löscht auch gespeicherten, noch nicht angezeigten Output. wird benutzt, wenn der Benutzer feststellen möchte, ob eine Anwendung ausgeführt wird. ermöglicht dem Benutzer, ein Zeichen in einem Datenstrom zu löschen. In seiner einfachsten Form wird es verwendet, um Daten auf dem Bildschirm zu editieren, wenn Input-Fehler gemacht wurden. der Benutzer kann eine ganze Zeile löschen. ermöglicht einer Sitzung, einer Folge von Halbduplex-Übertragungen zu folgen.
Tabelle 21: Telnet-Funktionen 3.26.4 Protokolldatenstruktur Das Format der Telnet-Befehle ist in Abbildung 39 [Black 95] zu sehen. Die Länge der Daten beträgt zwei oder drei Bytes. Das erste Byte ist das Interpret as Command (IAC) Byte. Dieses Byte ist in Telnet reserviert. Ist dies ein Escape-Zeichen, so handelt es sich nicht um Daten, sondern um einen Telnet-Befehl. Das
Seite 92
Firewall-Studie
11.09.97
SIEMENS
Telnet
nächste Byte heißt Command Code. Es beschreibt zusammen mit dem IAC den Typ des Befehls. Das dritte Byte heißt Option Negotiation Code. Damit können eine Anzahl von Optionen festgelegt werden, die während der Sitzung benutzt werden sollen.
Byte 1
Byte 3 (Optional)
Byte 2
Interpret as Command (IAC)
Command Code
Option Negotiation
Abbildung 39: Format der Telnet-Befehle 3.26.5 Sicherheitsbedrohungen Angriff: IP-Spoofing Bedrohung: Maskerade, Abhören In der Regel rufen Telnet-Dämonen zum Authentisieren und Initialisieren einer Sitzung login auf, welches dann Benutzernamen und meist auch ein Paßwort abfragt. Oft werden Telnet-Sitzungen auf Maschinen gestartet, zu denen kein Vertrauensverhältnis besteht. Dabei kann der Nutzer weder dem sendenden Programm oder Betriebssystem noch den dazwischenliegenden Datennetzen trauen. Paßwort und Inhalt der Sitzung sind dabei für alle preisgegeben. Da Telnet vollständigen Zugang zu einem Remote-Host für einen Benutzer ermöglicht, sollte dieser Zugang durch eine starke Authentisierung geschützt werden. Bei Telnet besteht weiter die Gefahr, daß sich ein Angreifer auf dem Übertragungsweg in eine autorisierte Telnet-Verbindung eingeschaltet hat, z.B. um sicherheitsrelevante Informationen abzuhören oder um eigene Befehle in die Telnet-Verbindung einzugeben. So kann zum Beispiel das Sitzungsende nur vorgetäuscht und die Verbindung aufrechterhalten werden. Dagegen hilft eine verschlüsselte Übertragung. Dies ist in UNIX zum Beispiel mit der Implementierung secure telnet möglich. Falls Telnet über eine Firewall hinweg überhaupt zugelassen werden soll, ist ein Applikationsfilter sinnvoll, wobei ein Proxy den Telnet-Dienst vermittelt und eine starke Authentisierung verlangt. Unverschlüsselte Telnet-Daten sollten abgewiesen werden. 3.26.6 Filterungsmöglichkeiten Telnet basiert auf TCP. Telnet-Server arbeiten normalerweise auf Port 23 (Ausnahmen sind sehr selten). Telnet-Clients arbeiten mit Portnummern über 1023. Eine Regelmenge könnte wie folgt aussehen [Chapman, Zwicky 96]13. Dabei beschreibt jede Zeile eine "Erlaubt"-Regel. Alles, was nicht erlaubt ist, ist verboten: Richtung
Zieladresse
Protokoll
Quellport
Zielport
ein
Quell Adresse extern
intern
TCP
> 1023
23
ACK gesetzt a
aus
intern
extern
TCP
23
> 1023
ja
aus
intern
extern
TCP
>1023
23
a
ein
extern
intern
TCP
23
> 1023
ja
a.
Bemerkungen Eingehende Verbindung, Client an Server Eingehende Verbindung, Server an Client Ausgehende Verbindung, Client an Server Ausgehende Verbindung, Server an Client
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 22: Telnet-Filterungsmöglichkeiten
3.26.7 Zusammenfassung Protokoll Telnet
11.09.97
Angriff IP-Spoofing
Bedrohung Maskerade, Abhören, Hijacking
Firewall-Studie
Gegenmaßnahme Einsatz eines Proxies mit starker Authentisierung. Unverschlüsselte Telnet Daten abweisen
Seite 93
SIEMENS
Bedrohungsanalyse der Protokolle
3.27 Wide Area Information Server (WAIS) 3.27.1 Einsatzumgebung Der Wide Area Information Server ist ein System, das eine Volltextsuche in weltweit verteilten Datenbeständen ermöglicht. Über WAIS werden sowohl reine Texdokumente in unterschiedlichsten Formaten als auch multimediale Dokumente zugänglich gemacht. WAIS hat seine Bedeutung durch die heutigen WWW-SearchEngines verloren. 3.27.2 Schematischer Ablauf WAIS arbeitet nach dem Client/Server-Konzept. Ein WAIS-Server besteht aus zwei Hauptkomponenten: Dem eigentlichen Server, der für die Bearbeitung der Anfragen und die Durchführung der Suche zuständig ist und der Datenbank, die aus dem WAIS-Index und den Originaldaten besteht (siehe Abbildung 40 [Schel 94]). Das Protokoll ist ein standardisiertes Protokoll aus der Bibliothekswelt (Z39.50). Alles was ein Client von einem Server wissen muß, ist die Datenbankbeschreibung (sog. source description). Typische Einträge in dieser Beschreibung sind: • • • • • •
Rechnername IP-Adresse Serverport Name der Datenbank Adresse des Systemverwalters kurze Beschreibung des Datenbankinhalts
Die Datenbankbeschreibungen aller Datenbanken werden zentral in der sogenannten Directory-of-ServersDatenbank zur Verfügung gestellt. WAIS unterstützt eine informelle Anfragesprache. Dokumente werden im Hinblick auf ihre Relevanz bewertet und entsprechend geordnet.
Server Datenbank
Client Bearbeiten Anzeige
Z39.50
INDEX Suchen
Anfrage Ausgeben
Originaldaten
Abbildung 40: WAIS-Komponenten 3.27.3 Steuerkommandos Es gibt drei unterschiedliche Typen von WAIS-Clients: • zeilenorientierte Clients, wie z.B. waissearch und ws, • bildschirmorientierte Clients, wie z.B. swais und • Clients für Windows-Systeme, z.B. xwais, os2wais oder waisman. Wegen der Implementierungsabhängigkeit wird hier nicht näher auf die Steuerkommandos eingegangen. 3.27.4 Sicherheitsbedrohungen Da WAIS eine Telnet-Verbindung zur Informationsübertragung aufbaut, gelten die Sicherheitsbedrohungen von Telnet (Maskerade, Sniffing). Seite 94
Firewall-Studie
11.09.97
SIEMENS
r-Dienste
Angriff: Ausführbarer Code Bedrohung: Manipulation Auch bei WAIS ist darauf zu achten, daß Dokumente im MIME-Format oder einem anderen ausführbaren Code versendet werden. Wie bei allen Informationsprotokollen (Gopher, HTTP, WAIS) sollte ein ProxyServer zwischengeschaltet werden, so daß die Auswirkungen einer Kompromittierung nicht in das zu schützende Netz durchschlagen. Somit sollte ein WAIS-Server auf einem speziellen Rechner (Opfermaschine) im Screened Subnet laufen. Soll internen Rechnern Zugang zu allen WAIS-Servern gewährt werden, so muß man ihnen Zugang zu allen TCP-Ports gewähren, da manche WAIS-Server nicht auf den Standard-Ports laufen. Andernfalls muß man die Benutzer auf Server mit der Standard-Portnummer 210 beschränken oder einen Proxy einsetzen. Soll ein WAIS-Server eingerichtet werden, so muß man sicherstellen, daß der Server außerhalb des zu schützenden Netzes liegt. 3.27.5 Filterungsmöglichkeiten WAIS basiert auf TCP. WAIS-Clients benutzen beliebige Portnummern über 1023. WAIS-Server verwenden meist Port 210, doch nicht immer. Folgende Tabelle gibt "Erlaubt"-Regeln an. Alles, was nicht erlaubt ist, ist verboten [Chapman, Zwicky 96]13. Richtung
Zieladresse
Protokoll
Quellport
Zielport
Ein
Quell Adresse extern
intern
TCP
> 1023
210
ACK gesetzt a
Aus
intern
extern
TCP
210
> 1023
ja
Aus
intern
extern
TCP
>1023
210
a
Ein
extern
intern
TCP
210
> 1023
ja
a.
Bemerkungen Eingehende Sitzung, Client an Server Eingehende Sitzung, Server an Client Ausgehende Sitzung, Client an Server Ausgehende Sitzung, Server an Client
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 23: WAIS-Filterungsmöglichkeiten
3.27.6 Zusammenfassung Protokoll WAIS WAIS
Angriff siehe Abschnitt 3.26 ausführbarer Code
Bedrohung siehe Abschnitt 3.26 Manipulation
Gegenmaßnahme siehe Abschnitt 3.26 JAVA, ActiveX, MIME filtern
3.28 r-Dienste 3.28.1 Einsatzumgebung Die sogenannten r-Dienste sind die Befehle rlogin, rcp und rsh/rcmd. Sie unterstützen das "Trusted Host"Konzept. Dabei kann ohne Angabe eines Paßwortes auf einen anderen Rechner zugegriffen werden, wenn der Server dem Client bzw. der betreffenden Kennung auf dem Server vertraut. • • •
rlogin oder remote login verbindet lokale Sitzungen mit einer Fernsitzung auf einem anderen Host. rcp oder remote copy ermöglicht dem Benutzer, Dateien von einem Host zum anderen zu kopieren. Es basiert auf dem Programm rsh. rsh (remote shell), remsh und rcmd führen einen Befehl auf dem Remote-System ohne vorheriges Einloggen aus.
3.28.2 Schematischer Ablauf Durch Eingabe des Befehls rlogin wird eine Verbindung zum rlogind-Server auf dem RemoteHost aufgebaut. Der Terminal-Typ ist dabei der gleiche wie auf dem eigenen Host. Die gesamte Zeichenwie-
11.09.97
Firewall-Studie
Seite 95
SIEMENS
Bedrohungsanalyse der Protokolle
dergabe wird auf dem Remote-Host ausgeführt, so daß außer bei Verspätungen die Benutzung von rlogin für den Benutzer transparent ist. Die Verbindung wird durch ein logout abgebrochen. Beim Befehl rcp ist jede Datei- oder jedes Verzeichnisargument entweder ein Remote File der Form rhost:path oder ein lokaler Dateiname. Die genannte Datei wird zum oder vom Fernsystem kopiert. 3.28.3 Sicherheitsbedrohungen Angriff: rlogin Bedrohung: Maskerade Die r-Befehle verlassen sich auf die BSD-Authentisierung. Dabei kann man z.B. ein rlogin auf eine fremde Maschine ohne Paßwortabfrage durchführen, wenn folgende Authentisierungskriterien erfüllt sind:
•
• •
Die Anfrage muß von einem privilegierten TCP-Port ausgehen. Auf manchen Systemen (wie PCs) gibt es solche Beschränkungen nicht. Daraus folgt, daß Anfragen per rlogin und rsh nur Maschinen gestattet werden sollten, die die Vergabe privilegierter Ports wirksam kontrollieren. Dies erfordert die Verläßlichkeit des Administrators. Die Kombination von Benutzer und System, von der die Anfrage ausgeht, muß dem Zielsystem als vertrauenswürdig erklärt worden sein, entweder systemweit, meist in der Datei /etc/hosts.equiv19, oder auf Benutzerebene in $HOME/.rhosts. Name und IP-Adresse des Quellsystems müssen übereinstimmen.
Angriff: rlogin, rsh Bedrohung: Island Hopping Angreifer, die in einen Host eingedrungen sind, haben Zugang zu weiteren Hosts, die dem ersten vertrauen. Ein Hauptziel von Angreifern ist daher, geeignete Einträge in /etc/hosts.equiv oder der .rhosts-Datei eines Benutzers zu deponieren. Dazu setzen sie FTP, UUCP, TFTP oder andere Mittel ein. Häufig ist das Ziel solcher Angriffe das home directory einer Systemkennung, wie root, bin, ftp oder uucp. Diese Verzeichnisse sollten nur von Administratoren les- bzw. schreibbar sein. Angriff: Manipulation der rhosts-Datei Bedrohung: Eindringen Ein Angreifer versucht typischerweise zuerst, Zugang zu einem System zu bekommen. Anschließend versucht er seine Spuren zu verwischen, indem er Protokolldaten löscht. Weiter versucht er sich Hintereingänge anzulegen, für den Fall, daß der ursprüngliche Zugangsweg später nicht mehr offensteht. Dafür eignen sich die Dateien /etc/hosts.equiv und $HOME/.rhosts. Angriff: third party copy Bedrohung: Diebstahl von Dateien Wie bei FTP ist auch hier ein third party copy möglich. Dabei kann ein Angreifer einer Maschine im internen Netz, zu der er per rcp Zugang hat, Dateien zu einer anderen Maschine kopieren. So kann ein Angreifer über einen Drittrechner Dateien stehlen, ohne, daß sein Rechner dabei in Erscheinung tritt. Zusammenfassend treten bei r-Diensten folgende Sicherheitsmängel auf: • • • •
19
Unvorsichtige Einträge in ~/.rhosts-Dateien. Dadurch werden Accounts für mehr Benutzer geöffnet, als vorgesehen. Veränderungen in ~/.rhosts-Dateien. Mittels Trojaner- oder NFS-Angriff können Angreifer den Inhalt der ~/.rhosts-Datei zu ihren Gunsten verändern. DNS-Angriff. Um ermitteln zu können, ob der anrufende Rechner als Trusted Host gilt, ermittelt das System mittels DNS-Auflösung aus der IP-Adresse den Rechnernamen. Somit kann sich ein Angreifer durch DNS-Manipulation als Trusted Host ausgeben. Durch Island-Hopping mittels rlogin und rsh kann ein Angreifer, der bereits in einen Account eingebrochen ist, von einem Rechner zum nächsten gelangen.
allerdings nicht für root
Seite 96
Firewall-Studie
11.09.97
SIEMENS
r-Dienste
3.28.4 Filterungsmöglichkeiten Angesichts der vielen Schwächen bei der Authentisierung sollten die r-Dienste nicht auf Systemen angeboten werden, die direkt an das Internet angeschlossen sind. Paketfilter sollten diese Dienste abweisen. rKommandos sollten über eine Firewall nicht erlaubt werden, es sei denn mit Hilfe eines Proxies auf einem Applikationsfilter mit Verschlüsselung (z.B. durch ein VPN). Sind dennoch r-Dienste über eine Firewall notwendig (z.B. in VPNs oder kaskadierten Intranets), so sollten Paketfilter die unten aufgeführten Regeln implementieren. Server verwenden die Portnummer 513 (rlogin) oder 514 (rsh, rcp, rdump, rrestore und rdist). Ungewöhnlicherweise verwenden Clients beliebige Portnummern unter 1023. Dadurch wird ein Sicherheitsschema implementiert, das den Zugang zu diesen Diensten ohne Paßwort erlaubt, wenn die Anfrage von einem vertrauenswürdigen Rechner stammt. Einige Clients benutzen eine zweite TCP-Verbindung für Fehlermeldungen von Verbindungen zu Port 514 des Servers. Diese zweite TCP-Verbindung wird von einem beliebigen Port unter 1023 auf dem Server zu einem beliebigen Port unter 1023 auf dem Client hergestellt. Das bedeutet, daß zu einem ausgehenden rsh-Kommando eine eingehende TCP-Verbindung für den Fehlerkanal gehört. Folgende "Erlaubt"-Regeln sind sinnvoll. Dabei ist alles, was nicht erlaubt ist, verboten [Chapman, Zwicky 96]13. Richtung
Zieladresse
Protokoll
Quellport
Zielport
ein
Quell Adresse extern
intern
TCP
< 1023
513
ACK gesetzt a
aus
intern
extern
TCP
513
< 1023
ja
aus
intern
extern
TCP
< 1023
513
a
ein
extern
intern
TCP
513
< 1023
ja
ein
extern
intern
TCP
< 1023
514
a
aus
intern
extern
TCP
514
< 1023
ja
ein
extern
intern
TCP
< 1023
< 1023
ja
aus
intern
extern
TCP
< 1023
< 1023
a
aus
intern
extern
TCP
< 1023
514
a
ein
extern
intern
TCP
514
< 1023
ja
aus
intern
extern
TCP
< 1023
< 1023
ja
ein
extern
intern
TCP
< 1023
< 1023
a
a.
Bemerkungen Eingehendes rlogin, Client an Server Eingehendes rlogin, Server an Client Ausgehendes rlogin, Client an Server Ausgehendes rlogin, Server an Client Eingehendes rsh/rcp/rdump/rres tore/rdist, Client an Server Eingehendes rsh/rcp/rdump/rres tore/rdist, Server an Client Eingehendes rsh, Fehlerkanal vom Client zum Server Eingehendes rsh, Fehlerkanal vom Server zum Client Ausgehendes rsh/rcp/rdump/rres tore/rdist, Client an Server Ausgehendes rsh/rcp/rdump/rres tore/rdist, Server an Client Ausgehendes rsh, Fehlerkanal vom Client zum Server Ausgehendes rsh, Fehlerkanal vom Server zum Client
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 24: r-Dienste-Filterungsmöglichkeiten
11.09.97
Firewall-Studie
Seite 97
SIEMENS
Bedrohungsanalyse der Protokolle
3.28.5 Zusammenfassung Protokoll r-Dienste r-Dienste r-Dienste r-Dienste
Angriff rlogin-Mißbrauch rlogin-, rsh-Mißbrauch Manipulation der rhostsDatei third party copy
Bedrohung Maskerade Island-Hopping Eindringen Diebstahl von Dateien
Gegenmaßnahme r-Dienste abweisen Rechteverwaltung Schutz der rhosts-Datei durch Verschlüsselung rcp verbieten
3.29 Remote Procedure Call (RPC) 3.29.1 Einsatzumgebung RPC ermöglicht, Anwendungen auf mehrere Rechner zu verteilen. Es ist eine Programmsammlung, mit der man Prozeduren auf anderen Rechnern aufrufen kann. Es erlaubt einem Client, eine Nachricht an einen Server zu senden. Der Client wartet dann auf eine Antwort. Die Nachricht des Clients enthält Parameter, die beschreiben, was auf dem Server auszuführen ist. Die Antwort des Servers enthält das Ergebnis des Prozeduraufrufs. Remote Procedure Call (RPC) ist steng genommen oberhalb von der Transportschicht anzusiedeln, jedoch wird RPC von vielen Anwendungsprogrammen (wie NFS und NIS) als Transportprotokoll eingesetzt. Die Begrenzung auf zwei Byte lange Portnummern in TCP und UDP wird durch RPC aufgehoben. Hier ist die eindeutige RPC-Service-Nummer vier Byte lang. Um auf UDP und TCP aufbauen zu können, müssen die RPC-Service-Nummern der auf RPC basierenden Server eines Rechners auf die jeweils verwendeten TCPoder UDP-Ports abgebildet werden. Diese Aufgabe übernimmt der Server portmapper, der als einziger RPCServer die feste TCP- und UDP-Portnummer 111 besitzt. Startet ein RPC-basierter Server wie z.B. NFS oder NIS, so beauftragt der Server den portmapper des Rechners, auf dem der Server sich befindet, sich dessen eindeutige RPC-Service-Nummer und den oder die momentan zugehörigen Ports zu merken, um einem Client darüber Auskunft geben zu können. Bevor ein RPC-basierter Client mit einem bestimmten RPC-basierten Server Kontakt aufnimmt, wendet er sich an den portmapper dieses Servers. Der Client teilt dem portmapper die eindeutige RPC-Service-Nummer des gewünschten Servers mit, worauf der portmapper mit der Portnummer antwortet, sofern der Dienst im Moment zur Verfügung steht. 3.29.2 Protokolldatenstruktur Eine RPC-Call-Nachricht eines Clients an einen Server besteht aus drei Feldern: •
remote program number
•
remote procedure number
•
remote program version number
Identifiziert eine Gruppe von Prozeduren (z.B. ein Datenbanksystem oder ein Filesystem). Diese Nummern werden von SUN Microsystems zentral verwaltet. Sie sollen für jede Installation eindeutig sein. Die einzelnen Prozeduren in einer Gruppe sind Macros oder katalogisierte Prozeduren (wie z.B. read oder write) und werden durch die remote procedure number identifiziert. Innerhalb der Prozeduren kann es notwendig sein, das System zu wechseln. Da die Implementierungen verschiedene Versionen besitzen, muß für diesen Fall die remote program version number angehängt werden.
3.29.3 Steuerkommandos Im folgenden werden mögliche Antworten von RPC auf eine Anfrage aufgeführt: MSG_ACCEPTED Success (RPC-Ausführung war erfolgreich) PROG_UNAVAIL (Programm ist nicht verfügbar) PROG_MISMATCH (Version wird nicht unterstützt) PROC_UNAVAIL (Prozedur wird nicht unterstützt) GARBAGE_ARGS (Parameter können nicht dekodiert werden) MSG-DENIED
Seite 98
Firewall-Studie
11.09.97
SIEMENS
Unix to Unix Copy Protocol (UUCP)
RPC_MISMATCH (RPC Versionsproblem) AUTH_ERROR (Authentisierungsproblem) AUT_BADCRED (Bad Credentials) AUTH_REJECTEDCRED (Client muß erneut beginnen) AUTH_BADVERF (Bad Verifier) AUTH_REJECTEDVERF (Verifier ist abgelaufen) AUTH_TOOWEAK (Sicherheitsproblem) 3.29.4 Filterungsmöglichkeiten Aufgrund der Tatsache, daß RPC-basierte Dienste beliebige Ports an verschiedenen Rechnern benutzen, sind sie durch Paketfilterung nicht zu kontrollieren. Dabei genügt es nicht, den Zugriff auf portmapper zu verhindern, denn ein Angreifer könnte alle TCP- und / oder UDP-Ports durchprobieren. Hier können bestenfalls zustandsabhängige Filter (siehe Abschnitt 4.1.2) Abhilfe schaffen. 3.29.5 Sicherheitsbedrohungen Sicherheitsbedrohungen von RPC hängen stark mit den Anwendungen zusammen, die auf RPC basieren. Protokolle wie NIS oder NFS können dazu mißbraucht werden, Informationen auszugeben oder Paßwortdateien zu überspielen. RPC unterstützt zwar kryptographische Authentisierung mittels DES (dies wird dann als Secure RPC bezeichnet), wobei sich alle Aufrufer durch einen gemeinsamen Sitzungsschlüssel authentifizieren, der nach dem Diffie-Hellmann-Verfahren verteilt wird. Allerdings ist wegen der Schlüssellänge (40 Bit langer Schlüssel bei Implementationen aus den USA) der DES nicht stark genug, um einem massiven Angriff standzuhalten. Ferner ist Secure RPC nicht weit verbreitet. Angriff: Mißbrauch des portmappers Bedrohung: Denial-of-Service, Sniffing Der Zugriff auf den portmapper sollte verhindert werden, da er mittels eines Aufrufs einen Dienst abmelden kann. Ferner teilt der portmapper jedem im Datennetz mit, welche Dienste angeboten werden. 3.29.6 Zusammenfassung Protokoll RPC
Angriff Mißbrauch des portmappers
Bedrohung Denial-of-Service, Sniffing
Gegenmaßnahme Zugriff verhindern, portmapper Anfragen filtern
3.30 Unix to Unix Copy Protocol (UUCP) 3.30.1 Einsatzumgebung Das Unix to Unix Copy Protokoll ermöglicht Unix-Systemen, gegenseitig über ein Netz Kontakt aufzunehmen. (Die Infrastruktur ist dabei gleichermaßen nutzbar für den Aufbau lose gekoppelter LANs wie auch für den Aufbau von WANs). UUCP ist eine Kommandosammlung für die Durchführung verschiedener Kommunikationsdienste, z.B. Electronic Mailing und Electronic Conferencing, aber auch Kommandoausführung auf einem Remote Computer sowie interaktive Nutzung von Remote-Computern. Die Nachrichten werden nach dem "store and forward"-Prinzip (Weiterreichen zum nächsten Nachbarn) verteilt. 3.30.2 Sicherheitsbedrohungen Firewalls sollten vor allem wegen des Remote Login und der interaktiven Nutzung von Remote-Computern UUCP-Dienste vollständig abweisen. Die Funktionalität Electronic Mailing wird heutzutage durch SMTP abgedeckt.
11.09.97
Firewall-Studie
Seite 99
SIEMENS
Bedrohungsanalyse der Protokolle
3.30.3 Filterungsmöglichkeiten Sofern UUCP verwendet werden soll, gibt es folgende Filterungsmöglichkeiten, die den Zugang auf einen Bastion-Host beschränken. Richtung
Zieladresse
Protokoll
Quellport
Zielport
ein
Quell Adresse extern
intern
TCP
> 1023
540
ACK gesetzt a
aus
intern
extern
TCP
540
> 1023
ja
aus
intern
extern
TCP
>1023
540
a
ein
extern
intern
TCP
540
> 1023
ja
Bemerkungen Eingehende UUCPVerbindung, Client an Server Eingehende UUCPVerbindung, Server an Client Ausgehende UUCPVerbindung, Client an Server Ausgehende UUCPVerbindung, Server an Client
a. Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. 3.30.4 Zusammenfassung Protokoll UUCP
Angriff Remote Login
Bedrohung Mißbrauch
Gegenmaßnahme UUCP an Firewalls abweisen
3.31 X11 3.31.1 Einsatzumgebung Viele Anwendungen im Internet verwenden X11 als graphische Oberfläche. Es nutzt TCP/IP zur Kommunikation zwischen Applikationen und I/O-Geräten (Bildschirm, Maus, etc.) und erlaubt damit eine Trennung von Geräten und Applikationen auf verschiedene Hosts. Das Grundkonzept liegt in der ungewohnten Vorstellung, das Terminal des Benutzers sei ein Server. Der X11-Server kontrolliert die I/O-Geräte. Wenn Applikationen Kontakt mit dem Benutzer aufnehmen wollen, müssen sie sich an den Server wenden. Applikationen, die mit einem X11-Server verbunden sind, haben die Möglichkeit, die Tastatur abzufragen, Bildschirminhalte auszulesen, für andere Applikationen Tastatureingaben auszuführen, künstlich Tastatureingaben zu erzeugen und vieles mehr. 3.31.2 Schematischer Ablauf X11 besteht aus zwei Hauptmodulen: xlib und X-Server. Wie in Abbildung 41 [Black 95] gezeigt, wird xlib vor dem Programm des Clients ausgeführt. Das Modul xlib ist dafür verantwortlich, Daten zum Benutzerterminal hin- und zurückzuschicken. Die Applikation wird X-Client genannt. Der X-Server befindet sich im Benutzerterminal. Dieser stellt nur die Anzeigesoftware dar, die Daten zur Clientanwendung sendet und von dort empfängt. Die grundlegenden Regeln von X11 sind: • • • •
Seite 100
Pro Terminal ist ein X-Server installiert, mit diesem können mehrere X-Clients kommunizieren. Der X-Server verändert das Window nicht. Das liegt in der Verantwortung des X-Clients. Der XClient wird vom X-Server über sogenannte events informiert, daß sich etwas an der Anzeige geändert hat. Die Sichtbarkeit des Windows liegt in der Verantwortung des X-Servers. Windows werden durch ein sogenanntes Stapel-Konzept verwaltet. Ferner werden neu geöffnete Windows mit einem Attribut versehen, das beschreibt, von welchem Window aus es erzeugt wurde. Dadurch kann ein neu geöffnetes Window sichtbar bleiben, auch wenn das Ursprungswindow ganz oben auf dem Stapel liegt.
Firewall-Studie
11.09.97
SIEMENS
X11
Appl (e.g.,xterm)
Appl (e.g., uwm)
xlib
Appl (xeyes)
xlib
xlib
X-Server Keyboard Bit-mapped display Mouse
Abbildung 41: Konzept von X11 X11-Anwendungen müssen zunächst eine Displayverbindung aufbauen, bevor sie miteinander kommunizieren können. Die Anwendung benutzt dazu den Befehl XRequest XOpenDisplay aus der xlib Bibliothek. Der Server und xlib tauschen während des Verbindungsaufbaus Informationen aus. Anschließend erzeugt xlib eine Display-Struktur, die die notwendigen Konfigurationsdaten für die eigentliche Kommunikation zwischen der Anwendung und dem Server beinhaltet. Nachdem eine Display-Verbindung erstellt worden ist, sind die Anwendung und der Server bereit, miteinander zu arbeiten. 3.31.3 Steuerkommandos Client-Anwendungen und der Server kommunizieren miteinander über das X-Window-System-Protokoll. Dabei werden vier Typen von Nachrichten verwendet: •
Request:
• •
Reply: Event:
•
Error:
Eine Instruktion an den X-Server, eine Aktion auszuführen (z.B. eine Gerade zeichnen). Die Antwort des X-Servers auf ein Request. Der X-Server informiert damit die Anwendung über Veränderungen am Display (z.B. Mausbewegungen, Eingaben). Mit dieser Nachricht informiert der X-Server den X-Client über aufgetretene Fehler (z.B. mangelnder Speicher).
3.31.4 Protokolldatenstruktur Das Format der Nachrichten ist in Abbildung 42 [Black 95] dargestellt. Das Request-Format beinhaltet einen major operation code und einen minor operation code, jeweils ein Oktet lang. Das Feld length besteht aus zwei Oktets, die Länge des Datenfelds ist variabel. Die Reply-, Error- und Eventformate beinhalten ein Oktet für das Feld type und ein 31-Oktet langes Datenfeld. 1
2
1
Varies
Major Op code
Length
Minor Op code
Data
1
31
Type
Data
Request Format
Reply, Error, Event Formats
Abbildung 42: Nachrichtenformat von X11
11.09.97
Firewall-Studie
Seite 101
SIEMENS
Bedrohungsanalyse der Protokolle
3.31.5 Sicherheitsbedrohungen Angriff: Hijacking Bedrohung: Maskerade, Verlust der Vertraulichkeit Aufgrund der standardmäßig nicht vorhandenen Authentisierungsmöglichkeit kann ein Angreifer im Internet nach X11-Servern suchen und eine Verbindung erstellen, ohne den Benutzer des X11-Terminals zu benachrichtigen. Dadurch verliert der Benutzer die Kontrolle über sein System. Die Portnummer für X11 liegt immer bei Port 6000 plus eine kleine Zahl (meist Null). Dadurch kann der Angreifer Paßworteingaben mitlesen oder dem Nutzer von X11 Kommandos unterschieben, indem er die Tastaturbelegung ändert und somit z.B. das Kopieren der Paßwortdatei veranlaßt. Angriff: Erzwingen eines Paßwortwechsel Bedrohung: Eindringen Sicherheitsmechanismen, wie quelladressenbasierte Authentisierung oder Magic Cookie sind nicht ausreichend sicher. Somit kann zum Beispiel der Benutzer zu einem Paßwortwechsel aufgefordert werden. 3.31.6 Filterungsmöglichkeiten Wie FTP benötigt auch X11 eingehende Verbindungen. Das Endgerät des Benutzers fungiert als Server, den die X11-Applikationen via TCP kontaktieren. Laufen die Applikationen auf externen Hosts, so wird eine eingehende Verbindungsanfrage benötigt, die von typischen Regelsätzen abgewiesen würde, hier aber erwünscht ist. Jedoch ist die Art der Anwendung - interne Benutzer greifen auf externe Dienste zu - im allgemeinen erlaubt und sogar erwünscht. Dennoch sollten zumindest auswärtige Verbindungsanfragen an die PortNummern 6000+20 abgewiesen werden, denn wenn statt auswärtiger Verbindungsanfragen jeder Kontakt mit diesen Ports abgewiesen werden würde, könnten Clients, die zufällige Port-Nummern in diesem Bereich verwenden, gestört werden. Folgende Tabelle gibt eine "Erlaubt"-Regelmenge an. Alles, was nicht erlaubt ist, ist verboten [Chapman, Zwicky 96]13. Richtung
Zieladresse
Protokoll
Quellport
Zielport
ein
Quell Adresse extern
intern
TCP
> 1023
6000+n
ACK gesetzt a
aus
intern
extern
TCP
6000+n
> 1023
ja
aus
intern
Extern
TCP
>1023
6000+n
a
ein
extern
Intern
TCP
6000+n
> 1023
ja
a.
Bemerkungen Eingehende X11Verbindung zum (n+1)-ten Server, Client an Server Eingehende X11Verbindung zum n-ten Server; Server an Client Ausgehende X11-Verbindung zum (n+1)-ten Server, Client an Server Ausgehende X11-Verbindung zum n-ten Server, Server an Client
Außer im ersten Paket dieses Typs (Aufbau der Verbindung) ist ACK bei allen Paketen gesetzt. Tabelle 25: X11-Filterungsmöglichkeiten
Ein X11-Filter auf einem Gateway, der die X11-Primitive kennt und nur sichere und erlaubte durchläßt wäre zu komplex und somit nicht mehr vertrauenswürdig. Clients aus dem Internet sollten keine Verbindungen zu X11-Servern ermöglicht werden. Ist dies dennoch notwendig, so sollte ein X11-Proxy-Server benutzt werden, der auf einem Bastion-Host läuft. Allerdings ist bei X11 die Verwendung von Video-Applikationen über einen X11-Proxy wegen der Synchronisation mit Audio-Daten problematisch. Eine weitere Möglichkeit, X11-Verbindungen zu schützen, ist, die Verbindung kryptographisch zu verschlüsseln.
20
Die virtuellen Bildschirme des X-Servers werden über die Portnummern 6000 + n angesprochen, wobei n eine kleine ganze Zahl ist (Beispiel: Bildschirm 0 liegt auf Port 6000, Bildschirm 4 liegt auf Port 6004). Seite 102
Firewall-Studie
11.09.97
SIEMENS
X11
3.31.7 Zusammenfassung Protokoll X11
Angriff Hijacking
Bedrohung Verlust der Kontrolle über System
X11
Paßwortwechsel erzwingen
Eindringen
Gegenmaßnahme Filtern, Einsatz eines Proxies (Problem: Audio/Video), starke Authentisierung, Verschlüsselung Filtern, Einsatz eines Proxies (Problem Audio/Video), starke Authentisierung, Verschlüsselung
3.31.8 Schutzmechanismen für X-Verbindungen über eine Firewall Das X-Protokoll basiert auf TCP und kann somit durch einen Paketfilter verboten werden, sofern sich interne X-Clients an externe X-Server anbinden wollen. Befindet sich jedoch der X-Server innerhalb des zu schützenden Bereiches, so sind Firewalls mit Paketfilter ohne Applikationsfilter nicht ausreichend, um diese zu sichern. Der Paketfilter-Ansatz kann zwar externe X-Verbindungsanfragen an X-Server einschränken, jedoch kann er einzelne X-Clients nicht unterscheiden. Ebenso kann dieser Ansatz nicht sicherstellen, daß eingehende Verbindungen zu X-Servern erkannt werden. Dies ist wichtig für X-Server, die nicht die Ressourcen für verbundene Clients trennen. Bekannte X-Protokoll-Relays bieten nicht die Möglichkeit einer X-ClientAuthentisierung an. Es bietet sich der Ansatz des Tunnelns der Firewall an. Durch das Etablieren eines sicheren Kanals auf Anwendungsebene kann Ende-zu-Ende-Sicherheit geboten werden. Dadurch gehen die Vorteile der Firewall (z.B. zentrale Überwachungsmöglichkeit und Umsetzung einer einheitlichen Sicherheitspolitik) verloren. Man kann auch den externen X-Client durch eine Sicherungsschicht erweitern und einen kryptographische Authentisierung bietenden Proxy für X-Dienste auf einer Firewall einsetzen. Dies ermöglicht die X-ClientAuthentisierung und das Erkennen eingehender Verbindungen zwecks Überwachung der Sicherheitspolitik. Dabei unterhält ein Proxy-Sicherheitsserver eine ungeschützte X-Verbindung mit dem X-Server, der sich in der gleichen Sicherheitsdomäne wie der Proxy-Sicherheitsserver befindet. Dieser Proxy-Sicherheitsserver unterhält eine geschützte X-Verbindung mit einem X-Client, der durch eine Sicherheitsschicht erweitert wurde und sich in einer anderen Sicherheitsdomäne befindet (siehe Abbildung 43 [Pfaff 96]). External network
Internal network Proxy security server
X client
X forwarding module
TCP/IP
Security Layer TCP/IP
accept*
read*
write*
Security Layer
X server
Access control Authentication
accept
read
TCP/IP write
read write connect
X client TCP/IP
X server
X server
TCP/IP
TCP/IP
Abbildung 43: X-Application-Level-Proxy Dieser Proxy-Sicherheitsserver wird als Teil einer Firewall zu einem X-Protokoll-Relay. X-Clients von externen Netzen, die sich zu einem X-Server im inneren Netz verbinden möchten, können aufgefordert werden, sich zu authentifizieren, und die durch die Sicherheitspolitik festgelegte Zugangskontrolle des Firewall-
11.09.97
Firewall-Studie
Seite 103
SIEMENS
Bedrohungsanalyse der Protokolle
Proxy-Sicherheitsservers zu passieren, bevor sie zum internen X-forwarding-Modul weitergeleitet werden. Da Authentisierung und Zugangskontrolle Aufgabe der Sicherheitsschicht innerhalb des Proxy-Servers ist, werden diese Dienste nicht auf Host-Adressen beschränkt. Daher können mehrere Clients desselben Hosts in autorisierte und unautorisierte Clients unterschieden werden. Falls der Server nicht Ressourcen trennt, muß dies das X-forwarding-Modul der Serverseite vor dem Weiterleiten der externen X-Verbindung mitteilen. Weiterhin kann das X-forwarding-Modul gewisse X-Requests an etablierte Verbindungen filtern. Der X-Client muß um eine Sicherungsschicht erweitert werden und eine Verbindung zu einem ProxySicherheitsclient haben. Abbildung 43 zeigt den Proxy-Sicherheitsserver im beschriebenen Szenario. Dabei sind die mit * gekennzeichneten Prozeduren modifizierte X-Prozeduren. 3.31.9 Verteilte Anwendungen unter X11 [Pfaff 96] IT-Systeme, die synchrone Zusammenarbeit ermöglichen, basieren auf der Fähigkeit, Anwendungen zwischen Konferenzteilnehmern an verschiedenen Orten zu teilen. Viele Systeme, die verteilte Anwendungen ermöglichen, basieren auf dem X Window System, und machen sich dessen Netzeigenschaften und HardwareUnabhängigkeit zu nutze. So können Standard X-Anwendungen für Single User, die mit einem Single XServer interagieren, von heterogenen Plattformen und Konferenzteilnehmern an verschiedenen Orten durch eine spezifische Komponente, die X Protokoll Multiplexing ausführt, geteilt werden. Damit derartige CSCWSysteme (Computer Supported Coorperative Work) ihre Fähigkeiten voll nutzen können, müssen diese Systeme Informationen über Grenzen von z.B. firmeninternen LANs hinweg anbieten, um dadurch Kooperationen mit z.B. anderen Firmen zu ermöglichen. Dies erfordert die Gewährleistung von Informationssicherheit. 3.31.9.1 Verteilte Anwendungen Single User X-Anwendungen können verteilt werden, indem man X-Requests zu einer gewünschten Anzahl von X-Requests (diese Anzahl sei n) für involvierte X-Server multiplexed und deren X-Replies, X-Events und X-Errors demultiplexed. Alle Teilnehmer von Sitzungen verteilter X-Anwendungen erhalten gleichzeitig den Output der Anwendung und genau ein Teilnehmer kann Input für diese Anwendung erstellen. Dieses Privileg heißt Token Possession. Es kann während einer Sitzung zu anderen Teilnehmern transferriert werden. Der Teilnehmer, der das Verteilen der Anwendung initiiert hat, heißt Application Owner. X-Verbindung und XServer des Application Owners heißen primär, wohingegen X-Verbindung und X-Server der übrigen Teilnehmer sekundär genannt werden. Die ASC (Application Sharing Component) hat die Aufgabe X-Requests zu multiplexen und X-Replies, X-Events und X-Errors zu demultiplexen. Das bedeutet, daß die ASC selbst X-Pakete bezüglich der Anforderungen jeder einzelnen Verbindung erstellen und verarbeiten können muß. Die ASC könnte wie in Abbildung 44 realisiert werden. Abbildung 44 zeigt ein allgemeines Szenario verteilter Anwendungen. Zu beachten ist, daß die Gruppe verteilte Anwendung (bestehend aus deren Instanzen XClient, ASC und n aktuelle X-Server (wovon einer den Application Owner darstellt)) dynamisch in Bezug auf die derzeit teilnehmenden sekundären X-Server und auch bezüglich des derzeitigen Token Possession sind. Application Sharing Component Primary
Server 1 (primary)
connection X requests X server X client
X replies,events and errors
X requests Application
X replies, events and errors System calls
Display Keyboard Mouse
ASC
Xlib
Device drivers
... Secondary connection X requests
Server n (secondary) Display X server
X replies,events and errors
Device drivers
Keyboard Mouse
Application resources
Abbildung 44: Application Sharing Szenario
Seite 104
Firewall-Studie
11.09.97
SIEMENS
X11
3.31.9.2 Sicherheitserfordernisse Das beschriebene Szenario wird unter dem Aspekt betrachtet, daß sich die Instanzen der Gruppe der verteilten Anwendung nicht vollständig in einem Trusted Network befinden. Das bedeutet, daß einige Instanzen (z.B. X-Client, ASC und primärer X-Server) über einen vertrauenswürdigen Netzpfad erreicht werden können und andere nicht. Typischerweise sind die n involvierten X-Server in verschiedenen Sicherheitsbereichen21 plaziert, so daß einige von ihnen mit dem ASC nur über einen nicht vertrauenswürdigen Pfad verbunden werden können. Ein Beispiel für einen Sicherheitsbereich ist das durch eine Firewall separiertes Intranet. Hier kann die ASC bzw. ein X-Server außerhalb des zu schützenden Bereiches liegen. Folgende Sicherheitserfordernisse können identifiziert werden. •
•
•
Schutz des X-Protokolls. Das X-Protokoll muß bezüglich Vertraulichkeit, Integrität und Datenursprungsauthentizität gesichert werden. Unautorisierte Instanzen dürfen Daten nicht mitschneiden oder manipulieren können. Auch muß verhindert werden, daß unautorisierte Instanzen X-Protokoll-Daten einfügen können. Diese Forderung ist nicht spezifisch für verteilte Anwendungen sondern tritt auch bei Single User X-Anwendungen auf. Schutz des X-Servers. Hierzu muß sich der X-Client am X-Server authentifizieren. Der Zugang zum XServer muß kontrollierbar sein und X-Server-Ressourcen müssen sicher getrennt werden können. Das bedeutet, daß sensitive X-Server-Ressourcen, wie z.B. key events in gewissen Fenstern, nur von privilegierten X-Clients zugreifbar sind. Auch diese Forderung ist nicht spezifisch für verteilte Anwendungen. Schutz des X-Clients. X-Server müssen sich an X-Clients authentifizieren. X-Clients-Ressourcen müssen sicher getrennt werden können. Durch das Verteilen von Anwendungen werden die X-ClientRessourcen (wie z.B. Dateien, Datenbanken und weitere Anwendungen) der verteilten Anwendung für die Konferenzteilnehmer zugänglich. Single-User-Anwendungen werden unter den Privilegien des Application Owners verteilt. Die Single-User-Anwendung erkennt nicht, daß sie verteilt ist. Somit können Token Holder über sekundäre Verbindungen wie Impersonisationen des Application Owners handeln und zeitweise auf Applikationsressourcen ohne Zugriffsrechte zugreifen. Deshalb kann auf Client-Ressourcen unautorisiert durch sekundäre Teilnehmer (z.B. durch Lesen, Modifizieren, Löschen oder Kopieren) zugegriffen werden. Die Trennung von X-Client-Ressourcen bedeutet also, daß auf sensitive Ressourcen von verteilten X-Clients nur autorisierte Nutzer zugreifen können. Diese Dienste erfordern eine Authentifizierung von X-Servern, die auf Ressourcen von verteilten Anwendungen zugreifen wollen. Diese Forderung ist spezifisch für verteilte Anwendungen und tritt nicht bei Single User X-Anwendungen auf.
3.31.9.3 Sicherheitsdienste Die in Abschnitt 3.31.9.2 beschriebenen Sicherheitserfordernisse können durch die folgenden Sicherheitsdienste gewährt werden: •
•
Gegenseitige Authentifizierung und Schutz des X-Protokolls. Der Schutz des X-Protokolls bezüglich Vertraulichkeit, Integrität und Datenursprungsauthentizität erfolgt durch kryptographische Methoden. Dabei werden X-Protokoll-Daten verschlüsselt. Integrität und Datenursprungsauthentizität können z.B. durch Anhängen eines MACs gewährleistet werden. Bei der Verschlüsselung der Daten des X-Protokolls ist zu beachten, daß beim Übergang über eine Firewall diese getunnelt wird. Je nach Sicherheitspolitik muß man entscheiden, ob Ende-zu-Ende-Sicherheit zu bevorzugen ist (dann besteht die Gefahr, daß nicht vertrauenswürdige Teilnehmer einer Konferenz diesen Tunnel benutzen, um über das X-Protokoll Zugang zu Rechnern hinter der Firewall zu erlangen), oder ob die Firewall in die Security Association miteinbezogen wird (dann muß die Firewall vertrauenswürdig sein). Die Verschlüsselung von X-ProtokollDaten muß auf einer gegenseitigen Authentifizierung basieren, damit die Identität der Teilnehmer überprüft werden kann. Hier ist es ratsam, von den Teilnehmern einer verteilten X-Anwendung zu verlangen, daß sie sich an einer Firewall authentisieren. Zugriffskontrolle für X-Server. Firewalls erlauben üblicherweise keine Verbindungen von X-Clients von außen zu internen X-Servern ohne zusätzlichen Schutz (s.o.). Ohne diesen Zugang können jedoch CSCW-Systeme, die auf verteilten X-Anwendungen basieren, nicht arbeiten. Daher muß die Zugangskontrolle zu X-Servern derartig verbessert werden, daß solche Verbindungen nicht mit der Sicherheitspolitik kollidieren. Dazu wird eine Client-Authentifizierung anhand einer Sicherungsschicht während der Ausführung der Funktionen zur Initialisierung einer sicheren Verbindung durchgeführt. Die geschützte X-Verbindung wird erst nach erfolgreicher gegenseitiger Authentifizierung etabliert.
21
Ein Sicherheitsbereich ist eine Menge von Hosts mit einer gemeinsamen Sicherheitspolitik und einem gemeinsamen Sicherheitslevel. 11.09.97
Firewall-Studie
Seite 105
SIEMENS •
Bedrohungsanalyse der Protokolle
Zugriffskontrolle für X-Client-Ressourcen. Systeme verteilter Anwendungen leiten ein X-Event eines X-Servers in die Gruppe der verteilten Anwendung nur dann weiter, wenn der X-Server den Token besitzt. Somit agieren die involvierten Teilnehmer wie Einzelpersonen. Jeder Token Holder agiert als eine Impersonisation des Application Owners. Dadurch können Token Holder auf X-Client-Ressourcen mit den Privilegien des Application Owners zugreifen. Dies kann bestehende Regeln der Zugriffskontrolle umgehen bzw. eine lokale Sicherheitspolitik verletzen. Daher dürfen verteilte Anwendungen nicht unter den Privilegien des Application Owners, sondern unter gesonderten „verteilten Privilegien“ laufen. Dazu ist es notwendig, daß der Mechanismus der Zugriffskontrolle verschiedene Nutzer erkennt. Dies bedeutet, daß je nach Privilegien einzelner Teilnehmer Zugriffsrechte erteilt oder verwehrt werden. Zumindest sollte erkannt werden, ob eine Instanz ein primärer oder sekundärer Nutzer oder ein Token Holder ist. Somit kann Zugriff auf X-Client-Ressourcen in Abhängigkeit der Rollen Application Owner, Token Holder oder Beobachter gewährt werden. Diese Zugriffskontrolle kann von einer (erweiterten) ASC durchgeführt werden. Um diese Aufgabe basierend auf einer Nutzer / Ressource Zugriffskontroll-Relation erfüllen zu können, muß die (erweiterte) ASC Anfragen auf Ressourcen des Clients empfangen und verarbeiten können. Ferner muß die (erweiterte) ASC Anfragen auf Ressourcen mit den zugehörigen X-Events verbinden können, da z.B. der Token Holder in der Zwischenzeit gewechselt haben kann, so daß nicht der aktuelle Token Holder die Anfrage an Ressourcen gestellt hat. Somit muß der X-Client Informationen liefern, die eine erweiterte ASC befähigt, die Ressource-Anfrage mit dem zugehörigen X-Event zu verbinden. Dies erfordert spezifische oder besonders modifizierte Clients. Eine Möglichkeit, Zugriffskontrolle in Abhängigkeit von Nutzern für Clients transparent zu gewährleisten wird in [Pfaff 96] beschrieben.
3.31.9.4 Empfehlungen für verteilte X-Anwendungen in Bezug auf Firewalls Aufgrund der bei allen verschlüsselten Kanälen bestehenden Bedrohungen durch Tunnelung der Firewall und der mit X11 im speziellen verbundenen Bedrohung durch Hijacking (siehe Abschnitt 3.31.5) sollten verteilte X-Anwendungen nur dann über eine Firewall betrieben werden, wenn alle der drei folgenden Bedingungen verwirklicht sind. • • •
Vertrauenswürdiger X11-Proxy auf der Firewall. Einbinden des X11-Proxies in die Security Association. Authentisierung von X-Client und X-Server an der Firewall.
Ist eine dieser Bedingungen nicht erfüllbar (z.B. durch eine Kollision mit der Sicherheitspolitik), so sollten X11-Daten von verteilten Anwendungen von der Firewall abgewiesen werden. 3.31.10 Videoübertragung Im Rahmen des BERKOM Projektes wurde bei Siemens der Sicherheitsaspekt von MMC (Multi Media Conference) behandelt. Es wurde hierbei ein Gruppenkonzept für die Teilnehmer einer Videokonferenz verwendet, d.h. für alle Videodatenübertragungen innerhalb einer Sitzung bei unverändertem Teilnehmerkreis wird derselbe Schlüssel zur Verschlüsselung mit symmetrischen Verfahren verwendet. Verläßt ein Teilnehmer die Sitzung oder kommt ein neuer Teilnehmer hinzu, so wird der Schlüssel gewechselt, um das Entschlüsseln nachfolgender bzw. vorhergehender Daten zu verhindern. Aus Performanzgründen wurde der Datenkanal von dem Managementteil getrennt, um die Geschwindigkeitsvorteile von ATM ausnutzen zu können. 3.31.10.1 Schematischer Aufbau Zur Realisierung der Videokonferenz wurde ein hybrides Schema gewählt. Der Managementteil basiert auf herkömmlichen IP-Verbindungen, der Video- und Audiodatenkanal dagegen basiert auf ATM. Wie in Abbildung 45 dargestellt gibt es einen Backbone, der die Koordinierung des Verbindungsaufbaus bei Einberufung einer Videokonferenz übernimmt. Dieser handelt die Sitzungsschlüssel sowie sonstige Sitzungsparameter mit den Clients aus. Zur Authentifizierung der Clients werden dabei X.509-Zertifikate verwendet, deren Vorhandensein vorausgesetzt wird. Der Conference Manager (CM) lädt die gewünschten Teilnehmer zur Konferenz ein, authentifiziert sie und vereinbart den Gruppenschlüssel. Der Audio Video Manager (AVM) sorgt anschließend für den Aufbau der ATM-Verbindungen. Der eigentliche Datentransfer findet direkt zwischen den Clients statt, wobei für die Ende-zu-Ende Verschlüsselung der vorher ausgehandelte Gruppenschlüssel verwendet wird.
Seite 106
Firewall-Studie
11.09.97
SIEMENS
X11
Firewall Client
Backbone
Client
CIA
CD (Conference Directory)
CIA (Conference Interface Agent)
ASC
CM (Conference Manager)
ASC (Application Sharing Component)
AVC
AVM (Audio Video Manager)
AVC (Audio Video Component)
ATM Datenkanal
Abbildung 45 : Schema für Videokonferenzen 3.31.10.2 Sicherheitsbedrohungen Das Management für die Videokonferenz läuft über gewöhnliche TCP/IP-Verbindungen ab, daher ist eine entsprechende Absicherung dieser Verbindung nötig. Insbesondere Gefährdungen wie Spoofing, ReplayAttacken sowie Sniffing sind in Betracht zu ziehen. Desweiteren können interne Attacken auf den Backbone erfolgen, um Konferenzen zu kompromittieren. Der Backbone sollte daher speziell geschützt sein, sofern externe Teilnehmer von Videokonferenzen zugelassen sind. Da die eigentliche Nutzdatenübertragung nicht über die Firewall sondern direkt über eine ATM-Verbindung zwischen den einzelnen Clients abläuft, kann dieser Datenkanal unter Umgehung der Firewall zum Eindringen in das interne Netz benutzt werden. 3.31.10.3 Filterungsmöglichkeiten Da die Kommunikation zwischen dem Backbone und den Clients verschlüsselt abläuft (auf Ende-zu-Ende Basis), hat die Firewall außer den Portnummern sowie den IP-Adressen keine weiteren Informationen über die ausgetauschten Daten. Filterung ist daher nur sehr eingeschränkt möglich (entweder durchlassen oder abblocken). Sofern ein Client von extern an der Videokonferenz teilnimmt, sollte zusätzlich zu den applikationsspezifischen Authentisierungsmaßnahmen eine starke Authentisierung des Clients mittels eines (generischen) Proxies durch die Firewall erfolgen. Im wesentlichen ergibt sich also eine vergleichbare Situation wie bei IPv6 Ende-zu-Ende Verschlüsselung bei gleichzeitigem Einsatz von Firewalls (mit Ausnahme des zusätzlichen ATM-Kanals). 3.31.10.4 Schutzmechanismen Da die Filterungsmöglichkeiten sehr beschränkt sind, ist strikt darauf zu achten, daß der (interne) Backbone ausnahmslos starke Authentifizierungsmechanismen sowie „sichere“ Verschlüsselungsverfahren verwendet. Desgleichen sind für die ATM-Verbindungen ebenfalls entsprechend starke Verschlüsselungsverfahren zu verwenden, da hierbei keinerlei Schutz durch die Firewall gewährleistet werden kann. Zudem dürfen die ATM-Schnittstellen nur über die AVC (oder vergleichbare Applikationen) zugänglich sein, d.h., es darf keine allgemein zugängliche Schnittstelle (mit entsprechenden Serverprogrammen) wie bei IP vorhanden sein. Die AVC muß gewährleisten, daß auf der ATM-Verbindung keine Daten akzeptiert werden, die nicht gemäß obigem Konzept verschlüsselt sind. 11.09.97
Firewall-Studie
Seite 107
SIEMENS
Bedrohungsanalyse der Protokolle
3.31.11 Sicherer Dokumentenserver Im Zuge des IVBB (Informationsverbund Berlin Bonn) kam es im Projekt POLIVEST zur Anforderung eines sicheren Dokumentenservers. Das Anforderungsszenario ging hierbei von verstreuten Clients aus, die auf einen Dokumentenserver zugreifen sollen. Der Server ist hierbei durch eine Firewall vom Internet getrennt. Es muß zum einen der Zugriff auf den Server gewährleistet werden, zum anderen müssen die Daten vor unbefugtem Zugriff (lesen und/oder schreiben) geschützt werden. Der Zugriff erfolgt hierbei seitens des Clients über ISDN. Die Sicherheitsinfrastruktur ist zur Zeit im Aufbau und wird laufend an neue Erkenntnisse angepaßt. 3.31.11.1 Schematischer Aufbau Als Lösung wurde ein Web-Server auf HTTP-Basis gewählt, ergänzt durch eine Sicherheitsschicht. Die Sicherheitsschicht realisiert das SSL-Protokoll sowie eine Zugriffskontrolle auf den Dokumentenserver. Durch das SSL-Protokoll wird die Verbindungssicherheit (Integrität, Vertraulichkeit) und die Authentifizierung der Kommunikationspartner (Dokumentenserver und Client) auf Basis von X.509 Zertifikaten durchgeführt. Zusätzlich wird auch Schutz vor Replay-Attacken gewährleistet. Die Zugriffskontrolle auf den Dokumentenserver basiert auf den durch das SSL-Protokoll authentisch übermittelten „Distuinguished Names“22 und einer ACL. Hiermit ist die Zugriffskontrolle auf den Dokumentenserver und zukünftig auch auf einzelne Dokumente möglich. Der Verbindungsaufbau erfolgt vom Client aus via SSL zum Server, wobei die dazwischenliegende Firewall einen entsprechenden Proxy zur Verfügung stellen muß, um die Tunnelung via SSL zu ermöglichen.
Client
Firewall
Web-Server
HTTP SecurityLayer TCP/IP
SSLProxy
HTTP SecurityLayer TCP/IP
Abbildung 46: Sicherer Dokumentenserver 3.31.11.2 Sicherheitsbedrohungen Die Sicherheitsschicht bietet Authentizität, Integrität, Vertraulichkeit sowie Schutz vor Replay-Attacken. Somit verbleiben als Hauptangriffspunkte die ISDN-Netzanschlüsse. Bei ISDN waren bzw. sind diverse Attacken auf Schicht 2 des Transportprotokolls möglich, womit sowohl der Client als auch die Firewall durch solche Attacken potentiell gefährdet sind (Kontrolle des jeweiligen Rechners). Eine Kompromittierung des Clients würde trotz Schutzmechanismen wie Chipkarten und Verschlüsselung dazu führen, daß Informationen oberhalb der Sicherheitsschicht mitgelesen bzw. verändert werden können. Ansonsten gelten die bei SSL-Tunnelung allgemein aufgeführten Bedrohungen. 3.31.11.3 Filterungsmöglichkeiten Eine Filterung ist nur insoweit möglich, als eine zusätzliche Kontrolle von Quell- und Zieladressen durchgeführt werden kann. Weitergehende Filterungsmöglichkeiten sind auf Grund der Tunnelung nicht möglich. 3.31.11.4 Schutzmechanismen Um das interne Netz vor beliebigem SSL Zugriff zu schützen, werden Proxies oder Paketfilter verwendet, die Informationen über zulässige Quell- und Zieladressen haben, so daß nur bestimmte interne Server überhaupt angesprochen werden können. Da bei ISDN-Verbindungen diverse Attacken auf Schicht 2 des Transportprotokolls möglich waren oder sind, sollte der ISDN-Pool kein direkter Bestandteil des Firewall-Hosts sein, sondern sich in der DMZ befinden. Dadurch wird verhindert, daß sich solche Attacken direkt auf den Bastion-Host auswirken. Des weiteren
22
Ein Distuinguished Name ist der Identifikator bei X.509 Zertifikaten.
Seite 108
Firewall-Studie
11.09.97
SIEMENS
Mutipurpose Internet Mail Extensions (MIME)
sollte zum Schutz sowohl der Firewall als auch der Clients nur ISDN-Karten mit aktuellen Treibern verwendet werden, die solche Attacken nicht mehr zulassen.
3.32 Mutipurpose Internet Mail Extensions (MIME) 3.32.1 Einsatzumgebung Das Multipurpose Internet Mail Extensions (MIME)-Protokoll bietet neben der E-Mail weitere Möglichkeiten auf, Dokumente jedweder Art wie Grafiken, Audio, Videosequenzen über Mail zu versenden. Die wesentliche Beschränkung von SMTP besteht darin, nur den US-ASCII-Zeichensatz zu unterstützen. Außerdem wird nicht spezifiziert, wie Audio-Mail, Videos oder Grafiken übertragen werden können. Daher ist für diese Fälle immer eine Kodierung durch den Anwender notwendig. Eine Lösung, kompatibel zu bleiben und doch auch andere als US-ASCII-Texte zu versenden, liefert MIME. Es beruht auf der Erweiterung der Header-Funktionalität und auf der Möglichkeit sog. multipart messages zu versenden. Der Body einer Mail wird in mehrere Teile untergliedert, die ihrerseits wieder als eigenständige BodyParts angesehen werden. 3.32.2 Protokolldatenstruktur MIME definiert im [RFC 822] neue Headerfelder, die den Inhalt einer Mime-Nachricht beschreiben. Indem ein solches Headerfeld in die IP-Nachricht eingefügt wird, erkennt MIME, daß es sich um eine MIMENachricht handelt. Es sind 5 zusätzliche Headerfelder möglich. Diese sind: • • • •
MIME-Version zur Angabe einer Mime-Version Content-Type zur Angabe eines Attributs und eines Wertes des BodyParts der Mail, Content-Transfer-Encoding zur Spezifizierung weiterer Kodierungsmaßnahmen bzgl. Angaben zum Mail-Transportsystem, Content-ID und Content-Description zur Beschreibung der Daten im Nachrichtenbody.
Das Mime-Version-Headerfeld ist ein Textfeld. Es tritt nur einmal zu Beginn einer Mail auf. Das Content-Type-Headerfeld bestimmt den Typ und den Subtyp des folgenden Bodies und enthält, wenn notwendig, weitere Parameter an. Die Schreibweise lautet: Attribut/Wert;Parameter, wobei sieben Attribute offiziell anerkannt sind: • • • • • • •
Application kennzeichnet im Body Anwendungsdaten, z.B. application/postscript. Audio wird zum Senden von Audio Daten bzw. von Sprache verwendet, z.B. audio/basic. Image wird zum Senden von Grafiken verwendet, z.B. image/gif oder image/jpeg. Ein Body vom Typ Message enthält seinerseits wieder eine komplette RFC822-Nachricht mit Header und Body. Multipart kennzeichnet voneinander unabhängige Datentypen innerhalb eines Bodyparts, z.B. multipart/mixed. Text kennzeichnet unterschiedliche Darstellungen von Texten, z.B. text/plain. Video wird zum Senden von Videosequenzen verwendet, z.B. video/mpeg X steht zur freien Erweiterbarkeit zur Verfügung und wird auch als "privates" Attribut bezeichnet.
Das Feld Content-Transfer-Encoding beschreibt, welche Kodierung nach ASCII verwendet werden soll. Werte sind beispielsweise BASE64, quoted printable oder binary. Bei binary findet keine Kodierung statt. Dies führt an herkömmlichen Internet Gateways zu Problemen. Bilder und sonstige binäre Dateien müssen daher durch die Angabe von Content-Transfer-Encoding: base64 nach ASCII transformiert werden.
11.09.97
Firewall-Studie
Seite 109
SIEMENS
Bedrohungsanalyse der Protokolle
3.32.3 Sicherheitsbedrohungen Angriff: Ausführbarer Code Bedrohung: Manipulation MIME-codierte Nachrichten können beim Benutzer Anwendungen aufrufen oder Befehle ausführen lassen. Die Auswirkungen seien an einem Beispiel erläutert: Content-Type: Message/External-body; name=“rfc1480.txt”; site=“ds.internic.net”; access-type=“anon-ftp”; directory=“rfc” Content-Type:
text/plain
Ein MIME-fähiger Mailer würde einen anonymous-ftp auf die Maschine mit der Adresse ds.internic.net ausführen und die Datei rfc1480.txt in sein Verzeichnis rfc kopieren - ein harmloser Fall. Angenommen, ein Angreifer würde eine Nachricht senden, die folgendes enthält:
Content-Type: Message/External-body; name=“.rhosts”; site=“ftp.visigoth.org”; access-type=“anon-ftp”; directory=“.” Content-Type:
text/plain
Hier würde der MIME-Agent einen anonymous-ftp auf die Maschine mit der Adresse ftp.visigoth.org ausführen und die dortige Datei .rhosts in sein aktuelles Verzeichnis kopieren. Die „fremde“ .rhosts-Datei könnte Plus-Einträge enthalten, so daß Zugänge von jedem Host mit jeder Kennung möglich sind. Dieser Fall ist keineswegs harmlos. Man könnte auch ausführbare Programme versenden, die selbst bedenkliche Aktivitäten entfalten können. Ein Lösungsvorschlag ist, von außen kommende MIME-codierte Nachrichten nicht automatisch auszuführen, sondern den Benutzer um Zustimmung zu bitten. MIME kommt sehr oft im WWW vor. Ein WWW-Server beschreibt mit MIME das Format jeder Web-Seite, die er an einen Client sendet. Die WWW-Clients ermitteln mit MIME, wie die empfangenen Daten darzustellen oder anderweitig zu verarbeiten sind. Ein wesentlicher Unterschied liegt darin, wie E-Mail-Clients bzw. WWW-Clients die Daten erhalten. Bei einem WWW-Client entscheidet der Benutzer, auf welche Daten zugegriffen wird. Bei E-Mail greift der Benutzer auf alles zu, was ihm gesendet wurde. In UNIX-Systemen sind in der Datei .mailcap die Programme aufgelistet, die aufgerufen werden, wenn der entsprechende Identifikator einer MIME-Nachricht auftaucht. Gelingt es dem Angreifer, diese Datei zu manipulieren, so kann er die Ausführung von ihm gewollter Programme initiieren. 3.32.4 Filterungsmöglichkeiten Zustandsabhängige Filter können MIME-Formate auf gefährliche Inhalte hin untersuchen. 3.32.5 Zusammenfassung Protokoll MIME
Angriff ausführbarer Code
Bedrohung Manipulation
Gegenmaßnahme Zustandsabhängiges Filtern von MIME
3.33 Java Java stellt neben ActiveX eine wesentliche Technologie zur Entwicklung von Programmen für heterogene Netzumgebungen dar. Es wurde von Sun Microsystems entwickelt und besteht im wesentlichen aus drei Komponenten:
Seite 110
Firewall-Studie
11.09.97
SIEMENS
Java
•
einer Programmiersprache Java, die von dem Compiler in ein architektonisch neutrales, binäres Format (Byte Code genannt) übersetzt wird, der Java Virtual Machine - ein Interpreter, der gemäß der Java VM Spec implementiert ist einer Ausführungsumgebung, die auf dem Interpreter läuft und die Grundlage für vollständige GUI-Anwendungen bildet.
• •
Ist der Interpreter auf einer beliebigen Maschine vorhanden, so kann der Byte Code auch auf dieser Maschine ausgeführt werden. Somit besitzt Java ein hohes Maß an Portabilität. Sofern ein Web Browser einen Java Interpreter und die Ausführungsumgebung (Java ist enabled) enthält, kann ein Benutzer, während er im Netz surft, ein Java Programm durch Anklicken einer URL ausführen. Ein so erhaltenes Java Programm nennt man ein Applet. 3.33.1 Java Programmiersprache Wesentliche Merkmale sind: • • • • •
Jedes Programm stellt eine Sammlung von Klassen dar, wobei eine Klasse die Implementierung eines abstrakten Datentyps ist. Die objektorientierten Merkmale von Java sind denen von C++ ähnlich. Java erlaubt Applikationen, mehr als eine Aufgabe gleichzeitig auszuführen. Java beinhaltet eine automatische Garbage Collection. Dies beseitigt eine wesentliche Fehlerquelle bei der Programmierung. Java Softwaremodule werden erst während der Laufzeit gelinkt. Java Programme benötigen kein Preprocessing und besitzen keine #include-Anweisungen wie C. Stattdessen finden Java Programme ihre Funktionen über einen Pfadnamen, der das benötigte Modul lokalisiert.
3.33.2 Java Virtual Machine Diese zweite Komponente interpretiert die Byte Codes und hat folgende Merkmale: Feste Größen und feste Formatvariablen. Alle primitiven Typen in Java haben feste Größen und Formate. Dadurch sind sie maschinen- und compilerunabhängig. Symbolische Datenspeicherung in Objectfiles. Merkmale der Java Sprache wie "Typsicherheit" und "keine Pointerarithmetik" sind entscheidend für das sichere Ablaufen von Java Programmen. Java Byte Codes enthalten ausreichend symbolische Informationen, die einer Java-fähigen Applikation vor der Ausführung die automatische Analyse von Programmen bezüglich der Konformität mit den Java Sprachregeln ermöglicht. 3.33.3 Ausführungsumgebung Java bietet eine vollständige graphische Benutzerschnittstelle inklusive Fenster, Dialogboxen, scrollbars, buttons, etc. an. Für die Netzfähigkeit bietet Java socket, stream, datagram, serversocket und URLs an. Das I/O-System bietet Schnittstellen zu file/directory-, streams- und pipe-Operationen. Die Ausführungsumgebung ist in Java implementiert und bietet all das, was zum Schreiben einer vollständigen Applikation notwendig ist. 3.33.4 Sicherheitsbedrohungen Ein Java-fähiger Browser befähigt den Benutzer, Java-Applets vom Netz runterzuladen und auszuführen, ohne daß der Benutzer das Applet erkannt hat. Dies stellt Java-Benutzer vor bedeutende Sicherheitsrisiken: • • •
Enthüllungsangriff: Ein Java Applet kann Standardnetzprotokolle (wie zum Beispiel SMTP) benutzen, um sensitive Daten vom Rechner des Benutzers zu exportieren. Integritätsangriff: Ein Java-Applet kann das Java-System angreifen, indem es dessen Speicher korrumpiert, oder es kann das darunterliegende Betriebssystem angreifen, indem es Dateien fälscht oder wichtige Prozesse beendet. Verfügbarkeitsangriff: Ein Java Applet kann den gesamten Speicher des Systems belegen oder hochpriore Nachrichten erzeugen. Der Verfügbarkeitsangriff ist auch bei der richtigen Interpretation des JavaSicherheitsmodells möglich.
11.09.97
Firewall-Studie
Seite 111
SIEMENS
Bedrohungsanalyse der Protokolle
3.33.5 Das Java Sicherheitsmodell Java besitzt ein Sicherheitsmodell, das theoretisch die ersten beiden Angriffsarten unmöglich macht. Sie gelingen nur aufgrund einer fehlerhaften Implementierung des Sicherheitsmodells. Java-Sicherheit beruht auf einer dreischichtigen Verteidigung [Bad, Kohli 96]: Byte-Code Verifier. Die erste Schicht überprüft, ob Java Programme, die vom Netz gezogen wurden, den Einschränkungen der Java-Sprache entsprechen. Diese Überprüfung wird unternommen, bevor ein Programm ausgeführt wird. Class Loader. Die zweite Schicht schränkt die APIs ein, die für Applets sichtbar sind. Applets können nur auf das zugreifen, was für sie sichtbar ist. Ferner beschränkt diese Schicht, inwiefern Applets in laufende Javasysteme Klassen hinzufügen oder Klassen entfernen können, und bewahrt daher ein Applet davor, ein entscheidendes Teil der Laufzeitumgebung zu ersetzen. Diese Schicht ist durch den Class Loader implementiert, ein Modul, das als Template von Sun angeboten wird. Der Class Loader arbeitet wie ein Gateway für Java Applets zu Benutzersystemen. Sofort wenn ein Applet vom Netz geladen wird, erhält der Class Loader die Binärdaten und definiert diese Daten als neue Klasse. Der Class Loader teilt die Applets basierend auf deren Ursprung (z.B. Internetadressen) auf und speichert diese vom Netz erhaltenen Applets in getrennten Namensräumen, um lokale vertrauenswürdige Klassen vor Korruption zu schützen. Ein Class Loader ist eine geeignete Stelle, um Applet-Zertifizierung als Gatekeeper zu implementieren, indem der Ursprung und die Integrität von empfangenen Applets durch kryptographische Prüfsummen oder digitale Signaturen verifiziert wird. Dies ist derzeit aber noch nicht üblich. Java Security Manager. In der dritten Schicht schränkt der Java Security Manager das Benutzen sichtbarer Interfaces für Applets ein. Wie der Class Loader wird der Java Security Manager von Sun als Template angeboten. Der Programmierer einer "Java-enabled"-Applikation füllt die Schablone aus, um die Sicherheitserfordernisse für diese Applikation zu spezifizieren. Alle Zugangsforderungen müssen den Security Manager passieren. Der Security Manager • • • • • •
verhindert die Installation eines neuen Class Loaders, steuert die Ausführung von OS Programmen, steuert den Zugriff auf OS Prozesse, steuert Filesystem-Operationen, steuert Socket-Operationen, steuert Zugriff auf Java-Pakete23.
Derzeit ruht die Sicherheit von Java auf einer Liste von low-level Details. Hinzu kommt, daß das JavaRuntime-System sehr groß ist und dadurch Fehlerfreiheit kaum zu erreichen ist. Folgende Möglichkeiten bieten sich an, den Gefahren von Java zu begegnen: • • •
• •
23
Grundsätzlich kann Java im Browser ausgeschaltet werden. Dadurch gehen jedoch alle Vorteile von Java verloren. Wer stets die neuesten Webbrowser verwendet, ist wenigstens gegen alte bekannte Javaspezifischen Lücken geschützt. Die dritte Möglichkeit ist, nur signierten Applets zu trauen. Dies bedingt allerdings, daß demjenigen, der das Applet signiert hat, vertraut werden muß. Bei ausschließlicher Verwendung von Applets aus dem internen Netz ist dies ein möglicher Weg, da eine entsprechende Zertifizierungsumgebung realisierbar ist. Java Applets können durch eine Firewall gefiltert werden. Dies wird im folgenden Abschnitt ausführlich beschrieben. Der Java Interpreter kann auf einem Mehrbenutzersystem unter der Kennung eines Benutzers ohne Rechte laufen. Dadurch können bösartige Java-Applets keinen Schaden anrichten, falls die Rechteprüfung korrekt funktioniert.
Java-Pakete sind Gruppen von Klassen
Seite 112
Firewall-Studie
11.09.97
SIEMENS
Java
3.33.6 Java und Firewalls Um dem Nutzer die Vorzüge von Java zu gestatten und gleichzeitig den Nutzer vor bösartigen externen Applets zu schützen, bietet sich der Einsatz einer Firewall an. Es existieren Implementierungen von Firewalls, die Java abweisen (siehe Abschnitt 6). [Martin, Rajagopalan, Rubin 97] beschreiben in ihrem Artikel folgende Filterungsmöglichkeiten: Überschreiben des Schildes 
