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 Jedes Java-Applet enthält als Kennzeichen das Schild . Ein Proxy kann in Dokumenten nach dem Schild suchen und dieses durch etwas überschreiben, das den empfangenden Web-Browser nicht erkennen läßt, daß es sich um ein Applet handelt. Der Web-Browser wird dann dieses Applet niemals ausführen. Der Proxy kann den Benutzer durch ein harmloses Applet informieren, daß ein unzulässiges Applet gefunden wurde. Damit nicht Dokumente gefiltert werden, die die Zeichenfolge lediglich als Text enthalten, muß dieses Proxy zum einen in HTML-Dokumenten nachschauen und zum anderen bestimmen können, ob der Datenstrom überhaupt ein HTML-Dokument enthält. Dazu muß der Proxy die HTML-Datei genauso untersuchen, wie es der Browser tut. Bei älteren HTTP-Versionen, FTP und gopher ist es einem Angreifer möglich, einen Browser dazu zu bringen, eine Datei als HTTP-Datei zu interpretieren, obwohl es kein Schild besitzt, da HTTP 0.9, FTP und gopher dem Browser überlassen, wie dieser eine übertragene Datei interpretiert. Schutz vor ungewollten Lieferungen Ein Angreifer kann Applets in Mails oder News verpacken und diese an das Opfer senden. Sofern eine Firewall Mails oder News nicht als potentielle HTML-Dateien auffaßt und nach dem Schild untersucht, kann es dem Angreifer gelingen, ein Applet zu plazieren, das ausgeführt wird, sobald der Benutzer die Mail oder die News liest. Daher ist es notwendig, daß ein Proxy neben HTTP, FTP und gopher auch Mails und News auf das Schild untersucht und gegebenenfalls filtert. Abweisen von CAFEBABE Die Java Virtual Machine verlangt, daß alle Java Class Files mit dem 4-Byte Hexadezimalcode CA, FE, BA, BE beginnen. Indem ein Proxy HTTP, FTP und gopher diesbezüglich untersucht, können derartige Transfers erkannt und abgewiesen werden. Das Untersuchen von Mail und News ist hier nicht notwendig, sofern der User nur lokale und vertrauenswürdige Mail- und Newsserver anspricht, da Mail- und Newsserver wegen des Voranstellens von ASCII Headern Class Files nicht unverändert übertragen können. In Verbindung mit dem Filtern nach stellt dies einen guten Schutz vor externen Java-Applets dar. Wird die -Hürde von einem Angreifer genommen, so bietet das Schlüsselwort CAFEBABE eine zweite wirksame Hürde, die der Angreifer nur schwer überwinden kann. Abweisen durch Dateinamen In früheren Netscape-Versionen (bis Netscape 3.0 beta 7 ausschließlich) war es möglich, HTTP, FTP und gopher nach Dateien mit der Endung .class zu filtern. Mittlerweile ist es üblich, Java Class Files in Archive zu kapseln (z.B. Zip), um multi-class Applets in einem Schritt übertragen zu können. Bemerkung Die beschriebenen Filterungsmöglichkeiten auf Anwenderebene sind nutzlos, wenn sich bereits ein bösartiges Applet auf dem internen System befindet. Weiterhin wird es für einen Proxy problematisch, wenn Ende-zuEnde-Verschlüsselung (wie z.B. durch IPv6 möglich) eingesetzt wird. Der Proxy ist dann nicht in der Lage, die Dateien auf Schlüsselworte wie CAFEBABE oder zu untersuchen, es sei denn, er besitzt den privaten Schlüssel des internen Empfängers. Um das Ausmaß des Schadens, den ein bösartiges Applet anrichten kann, zu begrenzen, bietet sich bei JAVA das Sandkastenprinzip an (siehe Abschnitt 3.34). Das Sandkastenprinzip wird von JAVA unterstützt und basiert auf voneinander abgeschotteten Adreßräumen. 3.33.7 Ein Angriff auf Firewalls mittels Java In 3.12 wird ein Angriff beschrieben, der es einem Insider ermöglicht, durch den FTP-Befehl Port eine Telnet-Verbindung zu einem externen Host aufzubauen, ohne daß dies eine Firewall verhindern kann. [Martin, Rajagopalan, Rubin 97] beschreiben diesen Angriff auf Firewalls mittels Java. Dieser Angriff ermöglicht es auch einem externen Angreifer, eine solche Verbindung aufzubauen. Erstellt ein Angreifer ein Applet, das, sobald es ausgeführt wird, einen anonymous-FTP zu des Angreifers Host ausführt und im PORT-Befehl den Port 23 angibt, so bekommt der Angreifer die Möglichkeit, eine Telnet-Verbindung durch eine Firewall aufzubauen. Dabei ist Voraussetzung, daß dieses Applet schon vorher auf das System des Opfers gelangt ist. Das Opfer muß nicht einmal erkennen, daß ein solches Applet ausgeführt 11.09.97
Firewall-Studie
Seite 113
SIEMENS
Bedrohungsanalyse der Protokolle
wurde. Wie in 3.12 beschrieben, geben starke Authentisierungsmechanismen und der Einsatz des Passiv Open-Befehls Schutz vor einem derartigen Angriff.
3.34 ActiveX ActiveX ist ein verteilter object-basierter Middleware Dienst. Er besteht aus einer Sammlung von Klassen von Component Object Model (COM) und Distributed COM-Objekten (DCOM). Es erlaubt über den WWWBrowser die Online-Installation eigenständiger Programme auf dem Computer des Internet-Nutzers. Durch ActiveX können alle Microsoft Produkte miteinander interoperieren und Dienste des anderen ausnutzen. ActiveX kann man als Windowsprogramm auffassen, das über das Web verteilt werden kann. 3.34.1 Sicherheitsbedrohungen Durch ActiveX ist es möglich, ausführbaren Code dynamisch vom Netz zu laden. Anders als beim verwandten System Java ist die Funktionsvielfalt von Active-X-Programmen kaum eingeschränkt: Bis hin zur Formatierung der Festplatte kann ein Active-X-Programm alle Befehle enthalten. Diese kleinen ausführbaren Codes nennt man Controls. Die meist zur Illustration oder Unterhaltung verteilten Controls können auch böswillige Elemente besitzen, die dann Zugriff auf Datenspeicher des Computers haben oder andere Programme für den Benutzer unbemerkt fernsteuern. ActiveX-Controls können die Festplatte löschen, einen Virus oder ein Trojanisches Pferd enthalten, oder die Festplatte nach bestimmten Informationen durchsuchen. All dies kann passieren, ohne daß der Nutzer bzw. Betrachter des Controls dies bemerkt. Während der Betrachter ein durch Controls übertragenes Videospiel ausführt, kann im Hintergrund dieses Control die e-mail nach bestimmten Informationen durchsuchen. Sobald ein Control den PC erreicht hat, kann es die Datei ändern, in der die entsprechenden Sicherheitseinstellungen gespeichert sind. Die Controls haben dabei die gleichen Zugriffsrechte, die auch der legitime Benutzer innehat. Somit sind auch Administratoren gefährdet. 3.34.2 Sicherheitsmerkmale Die Bedrohungen durch ActiveX unterscheiden sich durch die Umgebung Internet oder Intranet, in der es eingesetzt wird: 3.34.2.1 ActiveX im Internet Um Sicherheitsprobleme beim Einsatz von ActiveX im Internet zu bekämpfen, hat Microsoft ein Zertifizierungssystem eingeführt: Die Autoren von Programmen werden von sogenannten vertrauenswürdigen, zentralen Stellen geprüft und zertifiziert. Der Nutzer kann auf seinem PC festlegen, daß nur Programme aus dem Internet geladen werden, die über ein Sicherheitszertifikat einer bestimmten Organisation oder Firma verfügen. Durch digitale Signaturen können Controls auf Authentizität und Integrität überprüft werden. ActiveX kennt drei Schutzgrade, die der Benutzer auswählen kann: niedrig, mittel und hoch. In der höchsten Stufe sind nur Controls zugelassen, die sich mit einem Authentisierungscode identifizieren. Dennoch muß der Nutzer dem Inhalt eines Controls trauen. Microsoft empfiehlt, nur dann Programme vom Netz zu laden, wenn (i) der Nutzer sicher ist, daß er dem Autor des Programms trauen kann, und (ii) der Nutzer sicher ist, daß das Programm nicht durch einen Dritten modifiziert wurde. Beides kann durch die digitale Signaturumgebung von Microsoft gewährleistet werden. Der Nutzer erhält digitale Zertifikate von vertrauenswürdigen Organisationen und lädt Programme nur vom Netz, wenn er den Authentisierungscode verifizieren kann und ein Zertifikat des Autors besitzt. Damit der Zugriff auf einen Rechner durch Controls eingeschränkt werden kann, bietet sich wie bei JAVA auch bei ActiveX das Sandkastenprinzip an. Ein Sandkasten ist dabei ein abgegrenzter Adreßraum. Indem man verschiedene voneinander getrennte Adreßräume auf einer Maschine einrichtet, kann der Schaden, den ein bösartiges Control eines Angreifers anrichten kann, begrenzt werden. Die Adreßräume sind durch sogenannte Sicherheitsmauern getrennt. Diese Sandkästen können z.B. durch den Windows NT User Manager eingerichtet werden, indem man verschiedene Accounts mit wenigen Zugriffsrechten und Privilegien einrichtet. Im Unterschied zu JAVA ist das Sandkastenprinzip bei ActiveX nicht inhärent. Es muß nachträglich implementiert werden. 3.34.2.2 ActiveX im Intranet Das Intranetmodell geht von gegenseitigem Vertrauen und einer nicht vertrauenswürdigen darunterliegenden Kommunikationsinfrastruktur aus. Da jeder der Integrität aller Intranetnutzer traut, bleiben Bedrohungen durch Viren oder Trojanische Pferde ohne Gegenmaßnahmen. Die wesentlichen Bedrohungen im Intranet be-
Seite 114
Firewall-Studie
11.09.97
SIEMENS
ActiveX
züglich ActiveX liegen bei den Servern. Die Sicherheitsmechanismen von DCOM bewirken, daß der Account eines Clients in ein Sicherheitstoken übersetzt und an den Server gesendet wird. Auf Serverseite interpretiert DCOM den Sicherheitstoken und führt den Auftrag des Clients aus, indem er ein Programm ausführt, das die gleichen Rechte besitzt, wie der Client (der Server impersoniert den Client). Die Clients und deren Rechte auf dem Server sind in Tabellen im Server gespeichert. Gelingt es einem Angreifer, diese Tabelle zu modifizieren, so kann er sich weitreichende Rechte auf dem Server ergattern. 3.34.3 Filterungsmöglichkeiten Eine Firewall untersagt Internet-Clients den Zugang zu Ressourcen innerhalb des Schutzraums. Sofern eine Firewall ActiveX-Daten erkennen und einige Zertifikate authentifizieren kann, kann es dem Besitzer des Zertifikats Zugang durch die Firewall ermöglichen. Dies ist insofern bedenklich, als die Firewall dem Ersteller des Zertifkats trauen muß. Durch digitale Signaturen bzw. Authentisierungscodes kann man jedoch nicht erkennen, ob der Inhalt des Controls bösartig ist. Daher sollte ein Proxy eingesetzt werden, das die von einem Control angerichteten potentiellen Schäden nicht auf interne Systeme durchschlagen läßt. Im Zusammenspiel mit Java, das auf verschiedenen Plattformen existiert, wird Java beim Übergang in eine ActiveX-Umgebung auf ActiveX abgebildet, wodurch die Sicherheitsmechanismen von Java obsolet werden. Aufgrund des erhöhten Aufwands für eine Implementierung des Sandkastenprinzips, der unzureichenden Sicherheitsmechanismen und des möglichen Schadens, den Controls anrichten können, ist es empfehlenswert, AcitveX über Firewalls nicht zu zulassen.
11.09.97
Firewall-Studie
Seite 115
SIEMENS
Bedrohungsanalyse der Protokolle
3.35 Übersichtsmatrix24 - Bedrohungen / Gegenmaßnahmen 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
IPv6
IP-Spoofing
Maskerade, Eindringen
IPv6
IP-Source Routing
Maskerade
IPv6
IP-Tiny Fragment
Eindringen
IPv6
IP-Overlapping Fragment
Eindringen
IPv6
Tunneln der Firewall
Informationsverlust
ICMP ICMP
Time-to-Live Exceeded Destination Unreachable
Denial-of-Service Denial-of-Service
ICMP
Redirect
Eindringen
ICMP
Ping-to-death
Denial-of-Service
TCP
Spoofing
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 Abweisen von externen Datagrammen mit internen IP-Adressen. Abweisen von ausgehenden Paketen, die als Quelladresse keine interne Adresse besitzen. Abweisen 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 dynamsichen Filtern Abweisen von externen Datagrammen mit internen IP-Adressen, Verschlüsselung mit ESP Abweisen 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 dynamsichen Filtern 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 abfedern. 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
24
Diese Matrix stellt eine Zusammenfassung aller identifizierten Bedrohungen der untersuchten Protokolle und zugehörige Gegenmaßnahmen dar. Seite 116
Firewall-Studie
11.09.97
SIEMENS
Übersichtsmatrix - Bedrohungen / Gegenmaßnahmen
Protokoll UDP
Angriff UDP-Spoofing
Bedrohung Maskerade, Eindringen
UDP UDP
Flooding echo
Denial-of-Service Maskerade
UDP
Ausnutzen Ports
DNS
DNS-Spoofing
DNS DNS
Penetration Caches Sniffing
DNS
IP-Spoofing
DNS
Recursive Request
ARP
Fälschen von ARPAntworten
Umleiten
ARP Tabellen fixieren, automatisches Ablaufen von ARP unterbinden, Filtern über Firewalls
RIP
Loose-Source-Routing
Maskerade, Umleiten
RIP
RIP-Spoofing
Umleiten
Filtern von Paketen mit loose source routing Option statisches Routen
BGP BGP
Spoofing NOTIFICATION
Maskerade, Umleiten Denial-of-Service
starke Authentisierung Filtern von NOTIFICATION
OSPF
Paßworte abhören
Maskerade, Eindringen
OSPF
Hijacking
Verlust der Systemkontrolle
OSPF
Einfügen falscher Informationen
Täuschung
starke Authentisierungsmechanismen, Paßworte verschlüsseln starke Authentisierungsmechansimen Einsatz von Paket-Filtern
SNMP
Abhören des Community Strings
Maskerade, Eindringen
Verschlüsseln des Community Strings oder Filtern mittels Paketfilter
NIS
Diebstahl von Dateien, Wörterbuchattacke
Eindringen
NIS
Umleiten
Maskerade
Starke Authentisierung für privilegierte Nutzer, Einsatz neuer UNIX-Versionen, Starke Authentisierung, Filtern über Firewalls
NIS+
siehe NIS
siehe NIS
11.09.97
privilegierter
Maskerade, Eindringen
Maskerade, Eindringen des
DNS
Denial-of-Service Maskerade Maskerade
Zone
Transfer
Maskerade
Firewall-Studie
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 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.
nicht über Firewalls zulassen
Seite 117
SIEMENS
Bedrohungsanalyse der Protokolle
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
Maskerade
FTP
Firewalls tunneln mittels FTP Verbindung nach außen und Angabe von Port 23 FTP Hijacking
Eindringen, Maskerade
FTP filtern
TFTP
Diebstahl der Paßwortdatei
Eindringen, Maskerade
Filtern von TFTP über Firewall
FSP
Versenden von Angriffstools
Eindringen
Abweisen
Gopher Gopher
IP-Spoofing ausführbarer Code
Maskerade Manipulation
Protokoll HTTP HTTP
Angriff Spoofing Ausführbarer Code
Bedrohung Maskerade Manipulation
siehe IP Java, ActiveX und MIME filtern Gegenmaßnahme Einsatz eines Proxies Java, ActiveX und MIME filtern
S-HTTP
Tunneling
Mißbrauch
S-HTTP
Ausführbarer Code
Manipulation
SSL
Schlüssel-Rekonstruktion
Maskerade, Abhören
SSL
Man-in-the-Middle
Maskerade
IRC
Mißbrauch von Operatoren
Denial-of-Service
IRC
USER, ping, whois, whowas
Sniffing
IRC
IP-Spoofing
siehe IP
Zusätzliche Verwendung starker Authentisierungsmechan-ismen Filtern von IRCNachrichten siehe IP
NFS
Ausnutzen falscher Systemkonfiguration
Diebstahl von Daten
von Firewalls abweisen
NTP
Replay
Maskerade
NTP filtern bis auf eventuell vorhandene vertrauenswürdige externe Zeitquelle
Seite 118
Firewall-Studie
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
Abweisen von S-HTTPDaten über Firewalls oder Einsatz eines Proxies filtern von ActiveX, Java und MIME Vermeiden des Einsatzes von Export-Versionen und nordamerikanischen Versionen des Navigator und des Commerce Servers Einsatz von SSLv3
11.09.97
SIEMENS
Übersichtsmatrix - Bedrohungen / Gegenmaßnahmen
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
SMTP SMTP
Flooding MAIL FROM
Denial-of-Service Maskerade, Umleiten
SMTP SMTP
sendmail Ausführbarer Code
Manipulation
zentraler Mailserver starke Authentisierungsmechanismen Alternative upas einsetzen JAVA, ActiveX, MIME filtern
Telnet
IP-Spoofing
Maskerade, Abhören, Hijacking
Einsatz eines Proxies mit starker Authentisierung. Unverschlüsselte Telnet Daten abweisen
WAIS WAIS
siehe Telnet ausführbarer Code
siehe Telnet Manipulation
siehe Telnet JAVA, ActiveX, MIME filtern
r-Dienste r-Dienste r-Dienste
Maskerade Island-Hopping Eindringen
r-Dienste
rlogin-Mißbrauch rlogin-, rsh-Mißbrauch Manipulation der rhostsDatei third party copy
r-Dienste abweisen Rechteverwaltung Schutz der rhosts-Datei durch Verschlüsselung rcp verbieten
RPC
Mißbrauch des portmappers
Denial-of-Service, Sniffing
Protokoll UUCP
Angriff Remote Login
Bedrohung Mißbrauch
X11
Hijacking
Verlust der Kontrolle über System
X11
Paßwortwechsel erzwingen
Eindringen
MIME
ausführbarer Code
Manipulation
11.09.97
Diebstahl von Dateien
Firewall-Studie
Zugriff verhindern, portmapper Anfragen filtern Gegenmaßnahme UUCP an Firewalls abweisen Filtern, Einsatz eines Proxies (Problem: Audio/Video), starke Authentisierung, Verschlüsselung Filtern, Einsatz eines Proxies (Problem Audio/Video), starke Authentisierung, Verschlüsselung Zustandsabhänigiges Filtern von MIME
Seite 119
SIEMENS
Firewall - Architekturen
4 Firewall - Architekturen Bei den heutigen Firewalls unterscheidet man im wesentlichen vier Konzepttypen: • • • •
statischer Paketfilter, dynamischer Paketfilter (Paketfilter, die Kontext speichern können), Applikationsfilter (Application-Gateway) überwachter Applikationsfilter.
Die Typen können technisch wie folgt realisiert werden: • statische oder dynamische Paketfilter auf einem Router, • Applikationsfilter auf einer Workstation (Bastion-Host), • überwachte Applikationsfilter, durch einen Bastion-Host mit einer durch Paketfilter geschützten demilitarisierten Zone (DMZ) (d.h. dem Applikationsfilter sind Paketfilter vor- und nachgeschaltet). Die vier Firewall-Typen werden nachfolgend mit ihren Vor- und Nachteilen beschrieben und bewertet.
4.1 Paketfilter Aufgabe des Paketfilters ist es, sockets anhand der IP-Adressen und Portnummern zu sperren oder zu erlauben. In den hierzu notwendigen Filterregeln, die aus einer zu definierenden Sicherheitspolitik abgeleitet werden, werden obige Daten verwendet, um z. B. UDP-Dienste generell zu sperren oder gewisse TCP-Dienste (via der Portnummer) zu erlauben. Der Paketfilter schützt das innere Netz sowohl vor unerwünschten Verbindungen (meist von außen nach innen) als auch vor IP-Spoofing (Fälschen der Quelladresse). Zu letzterem ist es wichtig, daß der Paketfilter in seinen Regeln den physikalischen I/O-Port referenzieren kann, um gefälschte Quelladressen (des zu schützenden Netzes) auf dem äußeren I/O-Port erkennen und abweisen zu können. Die Konfiguration von Paketfiltern erfolgt in drei Schritten: 1.
2. 3.
Festlegen einer Sicherheitspolitik (was ist erlaubt, was ist verboten). Die Sicherheitspolitik sollte bereits explizite Aussagen enthalten, welche Dienste in welche Initiierungsrichtung zugelassen werden. Mittels obiger Aussagen werden die zugelassenen Pakettypen formal spezifiziert. Abschließend werden diese formalen Spezifikationen in die Syntax des Paketfilters übersetzt.
Die dabei entstehenden formalen Regeln wendet der Paketfilter üblicherweise streng sequentiell an. Sobald eine Regel auf ein Paket zutrifft, bricht die Regelprüfung ab und die betreffende Regel wird auf dieses Paket angewendet. Danach wird die Regelprüfung für das nächste Paket ausgeführt. Pakete, die nicht explizit durch eine Filterregel zugelassen sind, müssen somit durch eine abschließende generelle Sperr-Regel abgewiesen werden (Realisierung des allgemeinen Sicherheitsprinzips: alles, was nicht ausdrücklich erlaubt ist, ist verboten). Durch die sequentielle Abarbeiten kann es unter Umständen zu unbeabsichtigten Effekten, insbesondere zu Sicherheitslücken kommen, wenn die Reihenfolge der Filterregeln falsch gewählt wurde. 4.1.1 Statische Paketfilter Die einfachste, gleichzeitig aber begrenzteste Lösung ist der statische Paketfilter. Dieser prüft IP-Pakete an Hand • • • •
Seite 120
der IP-Quelladresse, der IP-Zieladresse, der TCP- oder UDP-Portnummer bzw. des Funktionstyps (ICMP), und des ACK-Bits (neuer Verbindungsaufbau oder Antwortpakete).
Firewall-Studie
11.09.97
SIEMENS
Paketfilter
Da nur jeweils das einzelne IP-Paket betrachtet wird, sind die Einsatzmöglichkeiten begrenzt. Es besteht keine Möglichkeit, über Kontextinformationen selektive Entscheidungen durchzuführen. Ein socket kann daher nur entweder komplett zugelassen oder komplett abgewiesen werden. Bei TCP/IP-Paketen geschieht dies, in dem das erste Paket eines Verbindungsaufbaus betrachtet wird (das einzige, in dem das ACK-Bit nicht gesetzt ist). An Hand dieses Paketes wird erkannt, ob die Anforderung des sockets aus dem zu schützenden Bereich kam (Quelladresse, die evtl. gefälscht sein kann) oder von außerhalb dieses Bereichs (dann wird es meist abgewiesen). Da Pakete mit ACK-Bit von den empfangenden Rechnern verworfen werden, wenn kein vorhergehender Verbindungsaufbau erfolgte, können solche Pakete von außen generell durchgelassen werden. Bei UDP/IP-Paketen findet keine verbindungsorientierte Kommunikation statt. Jedes Paket ist logisch als Verbindungsaufbau zu sehen. Da UDP-Dienste oft nicht an feste Portnummern gebunden sind, kann Datentransfer, der auf UDP/IP-Paketen beruht, von statischen Paketfiltern nicht durchgelassen werden, da ansonsten das innere Netz komplett ungeschützt gegenüber UDP-Diensten wäre. ICMP-Funktionen (wie z.B. REDIRECT) können von statischen Paketfiltern nur komplett zugelassen oder abgewiesen werden.
WAN Paketfilter: •geeignet für paketorientierte Dienste (ftp, login, ...)
ROUTER
•NICHT geeignet für kontextabhängige Dienste (X11, http, mail, ...)
Internes LAN
Abbildung 47: Paketfilter Vorteile des statischen Paketfilters sind die relativ einfache Handhabung sowie der geringe finanzielle und zeitliche Aufwand bei der Installation. Statische Paketfilter schützen vor IP-Spoofing, einer der Hauptangriffsmethoden zur Umgehung von Abweisungsregeln für gesperrte Dienste. Hinzu kommt der Vorteil, daß in der Regel für die Anbindung an das externe Netz ohnehin ein Router benötigt wird, der heute zumeist die Funktionalität eines statischen Paketfilters bereits integriert hat. Nachteile des statischen Paketfilters sind hauptsächlich die Einschränkungen bei den Filterregeln: es können nur die Dienste ohne Sicherheitsrisiko durchgelassen werden, die feste Portnummern verwenden und verbindungsorientiert arbeiten (dann läßt sich der Initiator der Verbindung ermitteln), also TCP-Pakete. Bei UDPPaketen ist es auf UDP-Ebene nicht möglich, festzustellen, ob es sich um eine Anfrage oder eine Antwort handelt. Daher sind UDP-Pakete durch statische Paketfilter nur sicher handhabbar, wenn es sich um Dienste handelt, bei denen sichergestellt ist, daß sie keinen Schaden anrichten (etwa DNS bei entsprechender Konfiguration des internen DNS-Servers sowie der internen DNS-Clients (siehe Abschnitt 4.3)). Daher ist aus Sicherheitssicht ein statischer Paketfilter allein in der Regel nur dann tragbar, wenn man sich auf die Nutzung weniger Dienste wie z.B. FTP, TELNET, SMTP und DNS beschränkt. Auch ist es nicht möglich, Dienste nur für bestimmte Benutzer zuzulassen. Ein weiterer entscheidender Nachteil von (statischen und dynamischen) Paketfiltern ist schließlich, daß Angriffe nicht oder erst zu spät erkannt werden können, da die Protokollierung auf den Inhalt der sockets beschränkt ist.
11.09.97
Firewall-Studie
Seite 121
SIEMENS
Firewall - Architekturen
4.1.2 Dynamische oder kontextabhängige Paketfilter Dynamische Paketfilter können zusätzlich zur Filterungsfähigkeit auf IP- und TCP-Ebene Kontext speichern. Diese Fähigkeit wird auch als stateful packetfiltering bezeichnet. Da UDP kein ACK-Bit besitzt, kann ein statischer Paketfilter nicht anhand des Headers des UDP-Paketes erkennen, ob es sich um das erste von einem externen Client an einen internen Server handelt oder um die Antworten von einem externen Server an einen internen Client. Dynamische Paketfilter speichern nach außen gesendete UDP-Pakete. Dadurch besteht für sie die Möglichkeit, nur erwartete Antworten durch den Filtermechanismus passieren zu lassen. Für sie gelten nur diejenigen Pakete als Antwort, die vom selben Rechner und vom selben Port kommen, an den die Anfrage ursprünglich gerichtet wurde und deren Ziel derselbe Rechner und derselbe Port ist, von dem die Anfrage ausging. Der dynamische Paketfilter speichert also den socket eines gesendeten Paketes und überprüft ein ankommendes Paket, ob Zieladresse und Zielport dieses sockets mit der Quelladresse und Quellport eines sokkets übereinstimmen, das er zuvor gespeichert hat. Ebenso müssen Quelladresse und Quellport des ankommenden Paketes mit der Zieladresse und Zielport eines zuvor gesendeten Paketes übereinstimmen. Da sich dadurch die Paketfilterregeln dynamisch ändern, wird diese Art von Paketfilter als dynamisch bezeichnet. Mittels dieser intelligenten Paketfilter können UDP-Dienste wie NFS, NIS, RPC granuliert z.B. nach Benutzer und Zeit gefiltert werden, wohingegen Paketfilter ohne Kontextabhängigkeit diese Dienste lediglich generell sperren oder erlauben können. Es können somit auch Dienste erlaubt werden, die nicht auf festen Ports ablaufen oder die nicht verbindungsorientiert sind (UDP), wobei dann die zugehörigen Antwortpakete erkannt und durchgelassen werden können. Dynamische Paketfilter sollten eine Möglichkeit zur zeitlichen Begrenzung der Kontextspeicherung haben (Verfallsdatum). Ansonsten werden die Dienste, die nur temporär erlaubt sein sollen, doch wieder generell oder zumindest für einen unerwünscht langen Zeitraum zugänglich gemacht. Ist nach Ende der Zeitbegrenzung der Dienst noch nicht regulär beendet, so wird eine bestehende Verbindung beendet bzw. evtl. nacher eintreffende Antworten (UDP, ICMP) gefiltert.
4.2 Applikationsfilter oder Bastion-Host25 Applikationsfilter laufen üblicherweise auf sog. „multi-homed Hosts“, d. h. Rechnern mit 2 oder mehr Netzkarten. Der Vorteil hierbei ist die Möglichkeit, zusätzlich zur Paketfilterung protokollabhängige Informationen auf Anwendungsebene26 zu speichern. Dies geschieht durch Proxy-Dienste27 auf dem Applikationsfilter. Da der Applikationsfilter Angriffen direkt ausgesetzt ist, sollten unbedingt die bereits in der Einleitung angesprochenen Prinzipien gelten: • •
•
Nach Möglichkeit nur fehlerfreie Software einsetzen! Nur die notwendigste Software installieren und aktivieren! Dies bedeutet insbesondere keine graphische Oberfläche (auf dem Applikationsfilter, der Konfigurationsrechner sollte über ein GUI verfügen, die Verbindung muß allerdings über eine gesicherte Leitung erfolgen)28. Keine Benutzer auf dem Applikationsfilter!
Technisch gesehen verbindet sich bei dieser Lösung der Client nicht direkt mit dem Server sondern mit dem Proxy auf dem Bastion-Host. Dieser wiederum kontaktiert den eigentlichen Server. Weil der Proxy protokollspezifisch ist und sich inmitten der Verbindung befindet, können die benötigten Kontextdaten gespeichert werden. Ein Vorteil ist die protokollspezifische Filterung auf Applikationsebene. Dabei untersucht der Proxy die Nutzdaten und entscheidet, ob Befehle (FTP-SITE), Dateiangaben (wie z.B. HTTP-URLs) oder Programme (wie z.B. ausführbarer Code) der Sicherheitspolitik entsprechen. Ein weiterer Vorteil ist die Möglichkeit, zusätzliche Funktionalität einfügen zu können, wie erweiterte Protokollierung oder Sicherheitsmaßnahmen wie starke Authentisierung sowie Verschlüsselung bei Kommunikation mit Rechnern außerhalb der Firewall. Diese Sicherheitsmaßnahmen erlauben es überhaupt erst, TELNET-
25
Bastion-Host: Der Rechner heißt deshalb so, da über ihn alle Verbindungen in das externe Netz laufen. Nur dieser Rechner hat dazu die Erlaubnis (Paketfilter!), er ist also an vorderster Front und ist dazu gedacht, alle Angriffe abzuwehren, eine Bastion eben. 26 Im TCP/IP-Protokollstack 27 proxy: „Stellvertreter“ 28 Im wesentlichen betrifft dies X11 mit seiner Client/Server Architektur. Das Prinzip, nur die unbedingt nötige Software zu installieren, gilt natürlich aber auch für andere Betriebssyteme und deren graphischen Oberflächen. Seite 122
Firewall-Studie
11.09.97
SIEMENS
Applikationsfilter oder Bastion-Host
oder FTP-Verbindungen von außen zuzulassen, ohne dabei gravierende Sicherheitseinbußen hinnehmen zu müssen.
BASTION-HOST: WAN
•Einsatz von Proxies möglich •Kontextspeicherung möglich •Zusätzliche Sicherheitsmaßnahmen
BASTIONHOST
– Authentifizierung – Interaktive Benutzernachfrage (X11) – Verschlüsselung
Internes LAN
ABER: Bastion-Host ist direkt angreifbar Abbildung 48: Bastion-Host Die Anbindung an den Proxy kann auf 3 Weisen erfolgen: 1. Die Client-Programme werden modifiziert (z. B. ftp). Dies bedeutet für den Administrator erhöhten Aufwand, da alle Client-Programme ausgetauscht werden müssen. Für den Benutzer ergibt sich aber der Vorteil, daß die Verbindung ins äußere Netz für ihn transparent durchgeführt wird. 2. FTP-User müssen sich am Proxy authentisieren. 3. Die Authentisierung erfolgt transparent durch Routing und Absorption. Oftmals stehen auf dem Applikationsfilter gleichzeitig auch Paketfilter zur Verfügung, so daß beide Funktionalitäten abgedeckt werden. Wird für den Applikationsfilter ein multi-homed Host verwendet, so ist darauf zu achten, daß das oftmals voreingestellte IP-Forwarding unterbunden wird, da sonst die Filterung unterwandert werden kann. Die Pakete würden direkt (innerhalb des Betriebssystemkerns) weitergeleitet. Vorteile des Applikationsfilters sind die (weitgehende) Abkoppelung der internen Rechner vom äußeren Netz sowie umfassendere Protokollierungsmöglichkeiten, die Möglichkeit, die Schnittstelle zu weiteren und verstärkte Sicherheitsmaßnahmen (starke Authentisierung, Verschlüsselung). Ein weiterer Vorteil ist die Konzentrierung sicherheitstechnisch relevanter Programme auf einem Rechner, d. h. neue Software, Patches o. ä. müssen primär nur an einer Stelle installiert werden, um die Bedrohung von außen (oder nach außen) abzuwehren (dies entbindet den Administrator nicht davon, etwa Patches auch intern einzuspielen, um lokale Benutzer gegeneinander abzusichern). Als Nachteil verbleiben im wesentlichen vier Punkte: • Der Applikationsfilter ist sowohl von außen als auch von innen direkt angreifbar. Sollte also ein Dienst irgendeine ausnutzbare Schwäche haben29, so ist die Gefahr für den Applikationsfilter sehr groß. • Die Struktur des inneren Netzes läßt sich nicht vor dem äußeren Netz verbergen, ohne daß obiges Grundprinzip verletzt wird, daß auf dem Applikationsfilter nur die unbedingt notwendige Software abläuft (siehe Abschnitt 4.3). • Für jeden Dienst muß ein dedizierter Proxy zur Verfügung gestellt werden. Dies kann daher in der Praxis dazu führen, daß einige Dienste dem internen Benutzer nicht zur Verfügung stehen, sofern kein generischer Proxy vorhanden ist. • Der Datendurchsatz ist bei gleicher Rechenleistung gegenüber Paketfiltern geringer, da jedes Paket bis zur Applikationsebene hochgereicht wird. 29
Dies ist durchaus nicht unüblich. Es können sowohl Konfigurationsfehler als auch Implementierungsfehler oder aber auch konzeptionelle Schwächen vorliegen. 11.09.97
Firewall-Studie
Seite 123
SIEMENS
Firewall - Architekturen
4.2.1 Dedizierte Application-Proxies Während Paketfilter für alle Anwendungen und Dienste allgemeingültige Regeln verwenden, bilden Applikationsfilter das andere Extrem. Hier wird für jeden Dienst ein dedizierter Application-Proxy, der zunächst die Verbindungen vermittelt und an Hand der Semantik entscheiden kann, ob die Anwendung erwünscht ist, oder nicht. Der Nachteil dabei ist, daß in der Praxis nur die wichtigsten Dienste durch dedizierte Proxies unterstützt werden. Das macht es schwerer, neue Technologien einzuführen. Dedizierte Proxies sind jeweils für ein bestimmtes Protokoll ausgelegt und können nur bezüglich dieses einen Protokolls semantische Kontrollen vornehmen. Bietet der Applikationsfilter für ein bestimmtes Protokoll keinen dedizierten Proxy an, so können die hinter dem Applikationsfilter liegenden Rechnersysteme dieses Protokoll auch nicht nutzen. 4.2.2 Circuit-Level-Gateways Wird für einen Dienst kein dedizierter Proxy angeboten, so können generische Proxy-Programme, die beliebige Protokolle unterstützen, Abhilfe schaffen. Somit sind Firewall-Systeme wünschenswert, die standardmäßig mit flexibel konfigurierbaren und generischen Proxies ausgerüstet sind. Mindestanforderung ist hier ein Satz von Softwarewerkzeugen, der den Eigenbau von anwendungsspezifischen Proxies erlaubt [Schlüter, Übelacker, 96]. Generische Proxies haben allerdings den Nachteil, daß sie nur eine Weiterleitung ermöglichen. Dienstspezifische Filterungs- und Protokollmöglichkeiten werden durch den generischen Ansatz nicht zur Verfügung gestellt. Ein Application-Level-Proxy kennt die Anwendung, für die er Proxy-Dienste leistet. Er versteht und interpretiert die Kommandos im Anwendungsprotokoll. Ein Circuit-Level-Gateway vermittelt zwischen Client und Server, ohne das Anwendungsprotokoll zu interpretieren. Application-Level-Proxies arbeiten im allgemeinen mit modifizierten Verfahren, während Circuit-Level-Proxies modifizierte Clients verwenden. Der Vorteil eines Circuit-Level-Gateways liegt darin, daß er die Dienste für eine Vielzahl verschiedener Protokolle bietet. Er kann jedoch nicht problemlos alle Protokolle behandeln. Bei Protokollen wie FTP, die Portinformationen vom Client an den Server übermitteln, muß auf Protokollebene eingegriffen werden, was Kenntnisse auf Anwendungsebene voraussetzt. Ein dedizierter Proxy-Server bedient ein einziges Protokoll, während ein generischer Proxy-Server mehrere Protokolle unterstützt. Vorteil der dedizierten Proxy-Server ist, daß diese die Nutzdaten beispielsweise auf ausführbaren Code untersuchen können.
4.3 Überwachter Applikationsfilter (Screened Subnet) Überwachte Applikationsfilter sind Applikationsfilter, die ihrerseits durch Paketfilter sowohl gegenüber dem externen als auch dem internen Netz abgeschirmt sind. Durch das Vor- und Nachschalten von Paketfiltern wird gewährleistet, daß jeglicher Datenverkehr über den Applikationsfilter geleitet wird. Außerdem schützen die Paketfilter den Applikationsfilter vor Angriffen aus dem Internet (und von innen) und verhindern, daß die Folgen einer Kompromittierung des Applikationsfilters (in vollem Umfange) bis in das zu schützende Netz vordringen. Ferner können durch vor- und nachgeschaltete Paketfilter bereits viele Pakete abgewiesen werden, so daß die Performanz des Applikationsfilters nicht zu sehr beansprucht wird. Außerdem können Dienste wie DNS und SMTP getrennt nach internem und externem Netz implementiert werden, wodurch die Struktur des internen Netzes verborgen werden kann und zudem Angriffsmöglichkeiten (wie z.B. mit Hilfe von sendmail) verringern.
Seite 124
Firewall-Studie
11.09.97
SIEMENS
Überwachter Applikationsfilter (Screened Subnet)
WAN ROUTER
Überwachter Bastion-Host: • Bastion-Host mit Paketfiltern MAIL
WWW FTP
DNS
%$67,21 BASTION+267 HOST
• Vorteil: mehr Hindernisse zu überwinden • Vorteil: Schutz vor Angriffen nach innen
ROUTER (static routing)
DNS (intern)
Internes LAN
MAIL (intern)
Abbildung 49: Überwachter Bastion-Host Das Verbergen der inneren Struktur kann (und sollte) dadurch realisiert werden, daß bei sämtlichen Protokollen, in denen interne Rechnernamen vorkommen, in den Proxies diese durch Standard-Namen ersetzt werden. Dies betrifft insbesondere Protokolle wie FTP, TELNET, HTTP sowie SMTP. Der externe MAIL-Server weiß (fast) nichts über das innere Netz. Er kennt nur den internen MAIL-Server, an den er alle E-Mails weiterreicht (siehe gestrichelte Linie in Abbildung 49), die an die entsprechende außen bekannte Domäne gerichtet waren. Insbesondere weiß er nichts über eventuelle Aliase, die erst intern aufgelöst werden. Der externe DNS-Server weiß ebenfalls nichts über das innere Netz und kann dieses auch nicht (aktiv) kontaktieren. Die einzige Verbindung besteht darin, daß er Anfragen des internen DNS-Servers beantworten kann (siehe gestrichelte Linie in Abbildung 49). Dies ist gleichzeitig auch der einzige interne Rechner, mit dem er überhaupt kommunizieren darf. Die DNS-Abfragen des Applikationsfilters, die dieser zur Weiterleitung von Paketen benötigt, erfolgen dabei immer über den internen DNS-Server. Handelt es sich um eine externe Adresse, so fragt dieser wiederum den externen DNS-Server und reicht dann die Antwort weiter an den Applikationsfilter. Die Vorteile dieser Konfiguration sind: 1. Der Applikationsfilter ist nicht mehr direkt angreifbar (zumindestens nicht über alle verfügbaren Dienste). 2. Ein kompromittierter Applikationsfilter kann das interne Netz nicht direkt gefährden. 3. Die Struktur des internen Netzes kann komplett vor dem äußeren Netz verborgen werden. Hinzu kommt, daß bei Verwendung verschiedener Hersteller und Betriebssysteme für die Paketfilter und den Applikationsfilter ein erhöhter Schutz dadurch besteht, daß ein Fehler bei einer Instanz bei der anderen Instanz nicht vorhanden ist oder zumindestens nicht in identischer Weise ausgenutzt werden kann. Die Nachteile dieser Konfiguration sind der erhöhte Aufwand sowohl finanzieller Art als auch an Zeit für Installation, Konfiguration und Wartung. 11.09.97
Firewall-Studie
Seite 125
SIEMENS
Firewall - Architekturen
Trotz dieses Aufwandes ist für eine (zum aktuellen Zeitpunkt) als sicher geltende Abschottung gegenüber dem externen Netz diese Konfiguration unbedingt zu empfehlen. Die Nachteile bei den einfacheren Lösungen sind zu gravierend, um tatsächlich Sicherheit in vollem Umfange gewährleisten zu können. Applikationsfilter, die von dynamischen Paketfiltern überwacht werden, sind das derzeit sicherste Schutzkonzept für Netze auf Basis von Firewalls.
4.4 Schutzkonzept für behördliche Netze Behördliche Netze verlangen wegen der zum Teil hochsensitiven und schützenswerten Daten ein hohes Maß an Informationssicherheit. Gleichzeitig ist der Zugang zum Intranet z.B. durch öffentliche WWW-Server erwünscht. Daher ist das Konzept Screened Subnet insbesondere für behördliche Netze zu empfehlen. Es sollte möglich sein, mit Partnerbehörden im In- und Ausland VPNs zu knüpfen. Um die z.B. bei Kooperationen mit Behörden oder Firmen auftretende Existenz von fremden Nutzern im Netz absichern zu können, ist es unbedingt zu empfehlen, kaskadierte Intranets (siehe Abschnitt 3.2.3.2) zu verwenden. Das bedeutet, nicht nur der Zugang zum Intranet einer Behörde, sondern auch dortige sensitive Bereiche sollten durch Screened Subnets geschützt werden. Ferner sollte die Sicherheit von behördlichen Netzen eine höhere Priorität besitzen als die der Performanz.
4.5 Übersicht Vor- und Nachteile der einzelnen Konzepte Konzept Paketfilter
Vorteil Einfache Handhabung. Schutz vor IP-Spoofing. Keine zusätzlichen Anschaffungskosten, da Router paketfilterfähig sind.
Nachteil Einschränkungen bei Filterregeln auf verbindungsorientierte Verbindungen von innen nach außen mit festen Portnummern. Keine Einschränkung auf einzelne Benutzer. Keine Protokollierungsfunktionalität auf Anwendungsebene. Erhöhter finanzieller Aufwand sowie zeitlicher Aufwand bei der Administration. Keine Protokollierungsfunktionalität auf Anwendungsebene Direkt angreifbar von außen und von innen. Verbergen des inneren Netzes ohne Aufwand nicht möglich. Pro Dienst eigener Proxy notwendig. Geringer Datendurchsatz. Längere Antwortzeiten. Extra Hardware notwendig (Workstation).
Dynamische Paketfilter
Granulierte Filterung für verbindungslose Protokolle und Dienste in Abhängigkeit von z.B. Zeit und Benutzer
Bastion Host
Einsatz von Proxies möglich. Kontextspeicherung möglich. Benutzerselektion möglich. Zusätzliche Sicherheitsmaßnahmen wie Authentisierung, interaktive Benutzernachfrage und Verschlüsselung realisierbar. Protokollierung und Netzüberwachung möglich.
Durch statische Paketfilter überwachter Bastion Host
Sehr sicher. Verbergen des internen Netzes möglich. Bastion Host nicht direkt angreifbar. Internes Netz vor kompromittiertem Bastion Host geschützt.
Erhöhter Ressourcen-Aufwand für Anschaffung, Installation und Wartung. Geringer Datendurchsatz.
Durch dynamische Paketfilter überwachter Bastion Host
Sehr sicher Granuliertes Filtern für verbindungslose Protokolle und Dienste in Abhängigkeit von z.B. Zeit und Benutzer schon auf Vermittlungsschicht Nützlich für kaskadierte Intranets und VPNs mit IPSec
Erhöhter Ressourcen-Aufwand für Anschaffung, Installation und Wartung. Geringer Datendurchsatz.
4.6 Zusammenfassende Empfehlung für ein Konzept Das sicherste und zugleich flexibelste Konzept ist derzeit ein Screened Subnet bestehend aus einem Applikationsfilter und je einem vor- und nachgeschalteten dynamischen Paketfilter, wobei die einzelnen Komponenten auf unabhängiger Hardware installiert und nach Möglichkeit von verschiedenen Herstellern sein sollten. Als ebenso sicher, jedoch mit Einbußen in der Flexibilität30 ist das Konzept Screened Subnet bestehend aus einem Applikationsfilter und je einem vor- und nachgeschalteten statischen Paketfilter, wobei die einzelnen Komponenten auf unabhängiger Hardware installiert und nach Möglichkeit von verschiedenen Herstellern sein sollten.
30
Flexibilität bezieht sich auf die Anzahl der Dienste, die sicher angeboten werden können.
Seite 126
Firewall-Studie
11.09.97
SIEMENS
Zusammenfassende Empfehlung für ein Konzept
Etwas weniger Sicherheit bietet ein Applikationsfilter mit integriertem dynamischen Paketfilter auf einem Bastion Host. Die Anzahl der Dienste, die angeboten werden kann, ist die gleiche wie bei einem dynamischen Paketfilter. Die gleiche Sicherheit, jedoch weniger Flexibilität bietet das Konzept Applikationsfilter mit integriertem statischen Paketfilter auf einem Bastion Host. Weniger Sicherheit bietet ein ungeschützter Applikationsfilter. Die Anzahl der Dienste hängt von der Anzahl der Proxies ab. Noch weniger Sicherheit wird durch einen dynamischen Paketfilter gewährleistet. Dieser kann jedoch die meisten Dienste anbieten. Genausowenig Sicherheit und wie der dynamische Paketfilter bietet ein statischer Paketfilter. Dieser kann keine UDP-Dienste filtern. Eine Firewall, die nach derzeitigem Kenntnisstand am sichersten, flexibelsten und für zukünftige Anwendungsszenarien am besten gerüstet ist, weist folgende Merkmale auf: • • • • • • • • • •
Screened Subnet, Applikationsfilter, zwei dynamische Paketfilter, Proxies für die wichtigsten Dienste, generischer Proxy für zukünftige Dienste, IPSec für VPNs mit anderen Herstellern, TLS/SSL für kaskadierte Intranets, Unterstützung des ISAKMP/Oakley, Unterstützung einer Zertifizierungsstelle, Verschlüsselung und Authentisierung mit ausreichender Schlüssellänge ohne Key-Recovery.
Die folgende Tabelle zeigt eine Einstufung31 der Konzepte bezüglich Sicherheitslevel und Flexibilitätsstufe. Konzept Screened Subnet mit dynamischen Paketfilter Screened Subnet mit statischen Paketfilter Applikationsfilter mit integriertem dynamischen Paketfilter Applikationsfilter mit integriertem statischen Paketfilter Applikationsfilter Dynamischer Paketfilter Statischer Paketfilter
Sicherheitslevel 1 1 2
Flexibilitätsstufe 1 2 1
2
2
3 4 4
3 1 2
Tabelle: 26 Konzept-Ranking
31
1 = sehr hoch, ..., 6 = sehr niedrig
11.09.97
Firewall-Studie
Seite 127
SIEMENS
Sicherheitsanforderungen an Internet-Firewalls
5 Sicherheitsanforderungen an Internet-Firewalls Die Testkriterien bestehen aus den Sicherheitsanforderungen an Internet-Firewalls des BSI (dokumentiert in [BSI 96] und den Sicherheitsanforderungen, die sich aus der Bedrohungsanalyse der Protokolle der vorliegenden Studie ergeben, sowie den zukünftigen Anforderungen an Internet-Firewalls, die aus dem Einsatz in VPNs mit IPSec und kaskadierten Intranets resultieren. Ferner werden noch nicht genannte Funktionen der Produkte aufgeführt.
5.1 Bisherige Sicherheitsanforderungen an Internet-Firewalls des BSI 5.1.1 Forderungen zur Abwehr von Angriffen auf die Firewall-Anordnung (In Klammern beigefügte Erläuterungen dienen der Verständlichkeit und sind nicht Bestandteil der Forderungen. Insbesondere werden die durch diese Maßnahme abgewehrten Bedrohungen (B) dargestellt.) 1.
Identifikation und Authentisierung für Administrator und Revisor nur über einen vertrauenswürdigen Pfad. (Dies könnte z.B. die Konsole, eine verschlüsselte Verbindung oder ein separates Netz sein. B.: Mitlesen oder Verändern der Authentisierungsinformation. Auch bei einer Evaluierung mit der angestrebten Mechanismenstärke „Mittel“ ist eine starke Authentisierung erforderlich.)
2.
Die Defaulteinstellung der Rechte muß sicherstellen, daß die Rollen Administrator und Revisor realisiert sind. (B: Falsch gesetzte Rechte ermöglichen es auch nicht autorisierten Benutzern, die Access-Dateien zu verändern oder die Protokolle zu lesen32.)
3.
Bei einem Ausfall der Protokollierungskomponente muß eine Warnung ausgegeben werden, die ein unverzügliches Eingreifen des Administrators ermöglicht. Es muß möglich sein, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Nutzung (im Sinne von 1) der Firewall unterbunden wird. (Wenn eine ordnungsgemäße Protokollierung nicht mehr möglich ist (z.B. weil auf dem zugehörigen Datenträger kein Platz mehr ist), muß die Firewall jeglichen Verkehr abweisen. Protokollierungskomponenten sind u.a. Prozesse in den Paket-Filtern oder im Applikationsfilter, die Protokollinformationen über Veränderungen an Konfigurationsdateien oder über abgewiesene oder durchgelassene Pakete erzeugen oder die Datenträger, auf denen die Protokollinformationen gespeichert werden. B.: Keine Protokollierung von Angriffsversuchen.)
4.
Integritätstests der eingesetzten Programme und Dateien mindestens einmal täglich. Es muß möglich sein, die Firewall so zu konfigurieren, daß bei einer Integritätsverletzung jegliche nicht administrative Nutzung der Firewall (im Sinne von 1) unterbunden wird. Die für den Integritätstest notwendigen Programme und Dateien müssen auf einem Medium speicherbar sein, welches hardwaremäßig gegen Schreibzugriffe gesichert werden kann. Es muß protokolliert werden, welche Änderungen (mit Datum und Uhrzeit) an der Konfiguration der Firewall vorgenommen wurden. (Die Tests sollten regelmäßig, aber nicht immer zur gleichen Zeit durchgeführt werden können. Es sollten Verfahren eingesetzt werden, die eine Änderung der Daten und Programme, die auf einer der Komponenten der Firewall vorliegen, rechtzeitig erkennen lassen. B: Durch Ausnutzung verschiedener Gefährdungen ist es oftmals möglich, die Benutzerrechte für einige oder alle Dateien auf dem angegriffenen Rechner zu erlangen und diese - insbesondere auch Programme wie z.B. login - zu verändern, so daß ein erneuter Angriff auf diesem Rechner sehr vereinfacht wird. Die Access-Listen sind die wesentlichen Daten für den Betrieb der Firewall und müssen besonders gesichert werden.)
5.
Es muß möglich sein, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall (im Sinne von 1) unterbunden wird. (Dies läßt sich z.B. durch ein Booten in den Single-User-Mode erreichen. B: Erzeugung eines neuen weniger geschützten Betriebssystem-Kerns oder Benutzung alter oder fehlerhafter Access-Listen bei einem Neustart, der durch den Angreifer erfolgt.)
32
Dies kann von einem Revisor überprüft werden.
Seite 128
Firewall-Studie
11.09.97
SIEMENS 6.
Bisherige Sicherheitsanforderungen an Internet-Firewalls des BSI
Auf den eingesetzten Komponenten darf nur Software vorhanden sein, die für die Funktionsfähigkeit der Firewall nötig ist. Die benutzte Software (inkl. aller Konfigurationsdateien) muß ausführlich dokumentiert und begründet werden. (Dies sind z.B. Treiber, die aus dem Betriebssystem-Kern entfernt werden müssen, oder Software für die grafische Benutzeroberfläche. Das Verbleiben von Software muß dokumentiert und begründet werden. B: Ausnutzung von Sicherheitslücken in Programmen, die für den Betrieb der Firewall nicht nötig sind und u.U. nicht richtig konfiguriert oder fehleranfällig sind.)
5.1.2 Forderungen zur Abwehr von Angriffen aus dem Internet auf das zu sichernde Netz 5.1.2.1 Obligatorische Forderungen 7. Die Firewall-Anordnung muß für den Fall des hohen und sehr hohen Schutzbedarfs aus mindestens zwei getrennten Filtern bestehen. Die Filter müssen hintereinander angeordnet sein, so daß für eine Verbindung zwischen den beiden beteiligten Netzen beide Filter passiert werden müssen. Die Filter müssen mit unterschiedlicher Hard- und Software (Betriebssystem) arbeiten und unterschiedliche Formate für die Beschreibung der Filterregeln benutzen. (Die beiden Filter können z.B. ein Paket-Filter und ein Dual-homed Applikationsfilter sein. Durch die unterschiedlichen Betriebssysteme (d.h. unterschiedliche Quellen, Autoren usw.) wird erreicht, daß mögliche Softwarefehler in einer Komponente nicht sofort zum Überwinden der Firewall benutzt werden können. Durch die unterschiedliche Beschreibung der Filterregeln wird die Wahrscheinlichkeit erhöht, daß Fehler, die bei der Verwaltung einer Komponente gemacht werden, von der richtig konfigurierten anderen Komponente abgefangen werden. B: Ein Fehler in einer Komponente erleichert einen erfolgreichen Angriff.) 8.
Die Einstellung der Filterregeln bei einer Erstinstallation und die Anordnung der Komponenten muß sicherstellen, daß alle Verbindungen, die nicht explizit erlaubt sind, abgewiesen werden. Auch bei einem völligen Ausfall der Firewall-Komponenten dürfen nur Verbindungen durchgelassen werden, die explizit erlaubt worden sind. (Es muß die Regel „Alles, was nicht ausdrücklich erlaubt ist, ist verboten“ realisiert sein. Z.B. darf ein Benutzer, der keinen Eintrag in einer Access-Liste hat, keine Möglichkeit haben, Dienste des Internet zu benutzen. B: Ausnutzung eines nicht als sicherheitsgefährdend angesehenen und deshalb nicht verbotenen Dienstes durch den Angreifer. Automatisches Umleiten der Pakete, um ein defektes Gateway zu umgehen.)
9.
Die Struktur des zu schützenden Netzes muß verdeckt werden können, d.h. daß keine internen Informationen wie Benutzernamen, Rechnernummern, -namen und Mailadressen nach außen gelangen können. (Dies läßt sich z.B. durch den Einsatz eines Applikationsfilters und zweier DNS-Server erreichen. B: MailAdressen, IP-Nummern, Rechnernamen können bei einem nicht durch eine Firewall geschützten Netz von jedem Benutzer im Internet abgerufen werden, wodurch sich Rückschlüsse auf die interne Netzstruktur und die internen Anwender ziehen lassen.)
10. Die Verwaltung der Komponenten muß übersichtlich sein (graphisches Interface). 11. Die Verwaltung der Komponenten muß zentral über einen vertrauenswürdigen Pfad (z.B. ein separates Netz oder über eine verschlüsselte Verbindung) erfolgen. (B: Mitlesen oder Verfälschung der Access- oder Protokoll-Daten.) 12. Der Aufbau von Verbindungen auf der Anwendungsschicht durch die Firewall muß benutzerabhängig und zeitabhängig erlaubt oder verboten werden können. (Dies läßt sich z.B. durch den Einsatz von Proxy-Prozessen für jeden der in 9 aufgeführten Dienste erreichen. B: Unbefugte Benutzung.) 13. Zur Benutzer-Identifikation müssen starke Authentisierungsmethoden benutzt werden. (B: Mitlesen von Paßwörtern.) 14. Es muß möglich sein, mehrere Benutzer zu einer Gruppe zusammenzufassen. (B: Fehler bei der Einstellung der Access-Listen durch eine unübersichtliche Anzahl von Benutzern.) 15. Die Filterregeln müssen auf ihre Widerspruchsfreiheit überprüft werden. (B: Ein nicht unmittelbar erkennbarer Fehler in den Filterregeln.)
11.09.97
Firewall-Studie
Seite 129
SIEMENS
Sicherheitsanforderungen an Internet-Firewalls
16. Es müssen die Protokolle Telnet, FTP, SMTP, DNS, NNTP und HTTP unterstützt werden. (B: Werden diese grundlegenden Dienste nicht zur Verfügung gestellt, werden u.U. andere, unsichere Wege ins Internet genutzt.) 17. Für Telnet-Verbindungen vom Internet zur Firewall (kommende Verbindungen) muß durch zusätzliche Prozesse eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. (Dies kann z.B. durch den Einsatz spezieller Telnet-Server und -Clients geschehen.) 18. Für Verbindungen auf der Anwendungsschicht müssen zusätzlich alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. ein retr bei FTP) oder den Export von lokalen Daten ins Internet (z.B. ein post bei http) bewirken, benutzerabhängig und zeitabhängig erlaubt oder verboten werden können. (B: Unerlaubtes Verschicken von Daten ins Internet.) 19. Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht muß eine Protokollierung von Benutzer-Identifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. führen, wobei auch Einschränkungen auf bestimmte Verbindungen möglich sind. (Die Einschränkungen müssen z.B. ermöglichen, daß nur abgewiesene Verbindungsversuche protokolliert werden. Der vertrauenswürdige Pfad kann z.B. durch eine verschlüsselte Verbindung oder ein separates Netz realisiert werden. B: Erfolgreiche Angriffe können nicht erkannt, entstandene Veränderungen nicht rückgängig gemacht werden.) 20. Spezielle, einstellbare Protokollmeldungen müssen zu einer unverzüglichen Warnung führen. (B: Zu spätes Erkennen eines Angriffs.) 21. Die Protokollinformationen müssen über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden können. (B: Veränderung der Protokollinformation vor ihrer endgültigen Speicherung.) 22. Bei der Benutzung von FTP muß es möglich sein, den Verbindungsaufbau für die Datenverbindung (FTPDATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (B: Verbindungsaufbau vom unsicheren Netz ins zu schützende Netz für die FTP-DATA-Verbindung.) 5.1.2.2 Zusätzliche Forderung bei Verwendung von Filtern auf der Ebene drei (IP) und vier (TCP, UDP) 23. Die Weiterleitung von Paketen muß abhängig von a) IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze und b) Quell- und Zielport für TCP und UDP erlaubt oder verboten werden können. Dies wird in Filterregeln festgelegt. (Der Quell-Port ist z.B. für einen Zone-Transfer zwischen den UDP-Ports 53 zweier DNS-Server wichtig. B: Zugang zum zu schützenden Netz von allen Rechnern im Internet möglich.) 24. Die Filterung gemäß voriger Forderung muß getrennt für jedes Interface möglich sein. (B: Um IP-Spoofing-Angriffe abzuwehren, dürfen Pakete, die den Paket-Filter vom unsicheren Netz aus erreichen, keine IP-Adresse von Rechnern aus dem zu schützenden Netz haben. Dies kann nur an dem mit der unsicheren Seite verbundenen Interface festgestellt werden.) 25. Die Reihenfolge der Filterregeln darf nicht automatisch von der Firewall verändert werden. (B: Unbekannte Ergebnisse der Filterregeln und u.U. eine Aufhebung des Schutzes durch den Paket-Filter.) 26. Wenn mehr als zwei Interfaces vorhanden sind, muß eine Filterung getrennt für kommende und gehende Pakete möglich sein. (Bei Paket-Filtern mit zwei Interfaces sind die eingehenden Pakete des einen Interfaces automatisch die ausgehenden des anderen Interfaces. B: Unübersichtlichkeit der Access-Regeln.) 27. Bei TCP-Paketen muß eine Unterscheidung, ob ein Verbindungsaufbau stattfindet oder eine bestehende Verbindung benutzt wird, d.h. eine Unterscheidung zwischen ACK und ACK-losen Paketen, möglich sein. (Nur so läßt sich sicherstellen, daß ein Verbindungsaufbau nur vom zu schützenden Netz ins unsichere Netz erfolgt. B: Ungesicherter Verbindungsaufbau ins zu schützende Netz.)
Seite 130
Firewall-Studie
11.09.97
SIEMENS
Zusätzliche Sicherheitsanforderungen an Internet-Firewalls
28. Protokollierung von IP-Nummer, Dienst, Zeit und Datum für jedes Paket, wobei auch Einschränkungen auf bestimmte Pakete (z.B. nur Pakete mit einer speziellen Quell-Adresse) möglich sind. (B: Erfolgreiche Angriffe können nicht erkannt, entstandene Veränderungen nicht rückgängig gemacht werden.) 29. Im Falle der Kombination der Firewall mit einem Router darf die Sicherheit der Firewall nicht durch eine Veränderung der Routing-Einträge gefährdet werden. Es muß statisches Routing benutzt werden. (B: Möglichkeit, Routing-Informationen an einen Rechner zu schicken, die dieser in der Regel ungeprüft zum Aufbau seiner Routing-Tabellen benutzt.) 30. Source-Routing Informationen müssen standardmäßig abgewiesen werden. (B: Ausnutzung der Möglichkeit, in einem IP-Paket den Weg, auf dem das Paket sein Ziel erreichen soll oder den die Antwortpakete nehmen sollen, vorzuschreiben, so daß nicht die durch die Routing-Tabellen angegebenen sicheren Wege benutzt werden.)
5.2 Zusätzliche Sicherheitsanforderungen an Internet-Firewalls 5.2.1 Paket-Filterung / Regelimplementierung 31. Firewalls sollten eine Mindestgröße an Fragmentlänge verlangen. (Der Fragmentierungsangriff zielt darauf ab, die Implementierung der IP-Fragmentierung derart auszunutzen, daß Filterregeln von Paketfiltern die fragmentierten IP-Pakete nicht abweisen können und somit diese Fragmente durchgelassen werden. Im [RFC 1858] wird der Tiny Fragment Attack beschrieben. Dabei wird die Mindestgröße des kleinsten Fragments vom Angreifer reduziert, damit einige Felder des Headers eines TCP-Pakets vom ersten in das zweite Fragment verschoben werden. Dadurch kann der Paketfilter das Paket nicht mehr als unerlaubtes Paket erkennen und schleust das Paket durch. Als Gegenmaßnahme sollten Implementierungen von Paketfiltern verwendet werden, bei denen die Länge des Tiny Fragments nicht verändert werden kann.) 32. Firewalls sollten ein Minimum an Fragment-Offset vorschreiben. (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 kann 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). 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.) 33. Firewalls sollten die ICMP-Meldung Destination Unreachable filtern können. (Viele ICMP-Nachrichten, die einen Host erreichen, sind nur für bestimmte Verbindungen relevant oder durch ein bestimmtes Paket ausgelöst. In diesen Fällen finden sich der IP-Header und die ersten 64 Bit des IP-Rumpfes wieder. Dies soll die Auswirkungen der ICMP-Nachricht begrenzen. So sollte sich eine Destination Unreachable-Nachricht lediglich auf eine bestimmte Verbindung beziehen. Jedoch nutzen alte ICMPImplementierungen 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 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.) 34. Firewalls sollten die ICMP-Meldung Redirect filtern können. (s.o.) 35. DNS-Spoofing sollte abgewiesen werden können. (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 Angreifer-
11.09.97
Firewall-Studie
Seite 131
SIEMENS
Sicherheitsanforderungen an Internet-Firewalls
systems 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 letzteren Angriff immun, da sie, nachdem sie von DNS den mutmaßlichen HostNamen 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.) 36. Zonen-Transfer-Requests von einem unbekannten Host sollten mit Refused beantwortet werden können. (DNS besitzt einen Zonen-Transfer Request. Dieser kann dazu benutzt werden, einen Teil der DNS Datenbank runterzuladen [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.) 37. ARP-Tabellen sollten fixiert werden können. (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. Die sicherste Möglichkeit ist, ARP an Firewalls abzuweisen. Aufgrund der Tatsache, daß ARP nicht das Internet-Protokoll 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 ICMPv6 - ersetzt werden [Atkinson 97]. Einträge in den ARPTabellen können in UNIX-Systemen durch den Befehl arp -s fixiert werden.) 38. Das automatische Ablaufen von ARP sollte unterbunden werden können. 39. Die FTP-Befehle CWD, CDUP, RETR, STOR, LIST, NLIST, SYST sollten an eine Rechteverwaltung gekoppelt werden können. Der FTP-Befehl SITE sollte abgewiesen werden können. (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, der Einstellungen auf der Remote-Maschine ändern kann, gesperrt oder sehr restiktiv an eine Rechteverwaltung gekoppelt werden. 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.) 40. Eingehende Telnet-Daten sollten auf Port 23 gefiltert werden können. (Dies ist notwendig, um den im folgenden beschriebenen FTP-Angriff abzuwenden: 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 TCPVerbindung 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 PORT-Befehl. 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 interner Komplize 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)). 41. S-HTTP-Daten sollten vom HTTP-Proxy abgewiesen werden können. (S-HTTP-Pakete werden in HTTP-Pakete gekapselt. Dadurch eignen sie sich sehr gut zum Tunneln einer Firewall. Wenn die Sicherheitspolitik keine Ende-zu-Ende-Sicherheit bieten möchte, kann ein HTTP-Proxy die Pakete auf Anwendungsebene untersuchen und interpretieren, sofern sie nicht verschlüsselt sind, bzw. verschlüsselte Pakete abweisen.)
Seite 132
Firewall-Studie
11.09.97
SIEMENS
Zusätzliche Sicherheitsanforderungen an Internet-Firewalls
42. Paket-Filter sollten Kontext speichern können (Um z.B. dynamisch allokierte Portnummern verfolgen oder Parameter einer Security Association zu können. Somit könnten z.B. RPC-basierte Dienste abgesichert und benutzer- und zeitabhängig gefiltert werden.) 43. Die folgenden Netzobjekte sollten für die Filterung definiert werden können: Host, Domain, Subnet, Group, IP-Range, VPN-Objekte 5.2.2 Abwendung von Standardangriffen 44. Ein Spoof-Checking sollte durchgeführt werden. (Unter IP-Spoofing versteht man das Fälschen der Senderadresse in einem IP-Paket [CERT-Advisory CA95:01]. Dabei werden zunächst mittels Sniffing-Tools die IP-Adressen ermittelt, anhand derer unberechtigt Dienste genutzt werden können, die als einziges Authentisierungsmerkmal IP-Adressen benutzen. IPSpoofing bildet die Grundlage zahlreicher Angriffe. IP-Spoofing kann durch starke Authentisierungsmechanismen oder durch das Verhindern von Sniffing mittels Network Address Translation33 (NAT) abgewendet werden.) 45. Ping-to-Death sollte abgefangen werden. (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 Treiber-Implementierungen, die einen Overflow nicht abfedern, zu einem Systemabsturz. Ping sollte abgewiesen werden.) 46. TCP-SYN-Flooding sollte verhindert werden können. (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. 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, sollen zustandsabhängige Filter nur eine begrenzte Anzahl von SYNPaketen zulassen.) 47. Anti-Virus Checking sollte unterstützt werden können. (Über einen Anti-Virus-Check können Viren z.B. in ausführbarem Code erkannt werden, der in komprimierten Daten versteckt ist oder über Dateitransferprotokolle (wie z.B. FTP) übertragen wurde.) 48. Paket-Reassemblierung sollte durchgeführt werden. (Durch die Fragmentierung von IP-Paketen existiert wenig Information, auf die man eine Filterentscheidung basieren könnte, 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 abgewiesen, so ist das Paket im Inneren unvollständig, und die übrigen Fragmente werden schließlich vom Zielhost verworfen. Ist der Zielhost allerdings ein Komplize 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 verworfen oder dort zusammengesetzt und überprüft werden. Dies ist mit zustandsabhängigen Filtern bzw. Paketfiltern, die Kontext speichern können, realisierbar.)
33
Bei NAT werden IP-Adressen des zu schützenden Bereichs auf andere (z.B. die Adresse des externen Interfaces der Firewall) IP-Adressen abgebildet. Dadurch werden Adressen im zu schützenden Bereichs außerhalb nicht bekannt. 11.09.97
Firewall-Studie
Seite 133
SIEMENS
Sicherheitsanforderungen an Internet-Firewalls
49. Session Hijacking sollte verhindert werden können. (Mittels einer z.B. durch Sniffing bekanntgewordenen IP-Adresse können sich Eindringlinge privilegierte Rechte auf einem System verschaffen, und anschließend mit Hilfe eines Tools den Kernel modifizieren. Diese Modifikation erlaubt es ihnen, bestehende Verbindungen eines beliebigen Benutzers des Systems zu übernehmen. Man spricht 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 durch Verschlüsseln zwischen Firewalls abwehren, sofern nicht ein Endpunkt einer Ende-zu-Ende-Verschlüsselung übernommen wird.) 50. TCP-Sequence-Number-Guessing sollte verhindert werden können. (TCP erkennt anhand der für jedes Paket unterschiedlichen Initial Sequence Number alte Pakete aus vorangegangenen Verbindung (identifizierbar durch Quellsocket und Zielsocket). 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 einen Proxy 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.) 51. Es sollte möglich sein, im internen Netz die gleichen IP-Adressen zu verwenden, wie im externen Netz. (Illegal Address Support ermöglicht, im internen Netz eigene IP-Adressen zu wählen, die sich nicht von externen unterscheiden müssen) 5.2.3 Administration 52. Die Administration der Firewall sollte durch starke Authentisierungsmechanismen geschützt sein. (z.B. durch Chipkarte) (Administrationszugänge sollten nur auf der Konsole der Firewall möglich sein oder der Zugang durch starke Authentisierungsmechanismen geschützt werden können. Insbesondere in dem Szenario VPN mit mehreren Firewalls ist es notwendig, Firewalls remote zu administrieren und zwar synchron, damit gewährleistet werden kann, daß die Sicherheitspolitik auf allen Firewalls des VPN konsistent ist. Hier ist der root-Zugang nur über die Konsole nicht mehr zu realisieren, so daß starke Authentisierungsmechanismen zur Authentisierung des Administrators unerläßlich werden.) 53. IP-Forwarding sollte auch nach einem Neustart noch abgeschaltet sein. 54. Eine Remote-Administration sollte mittels starker Authentisierung und Verschlüsselung geschützt sein. 5.2.4 Verschlüsselung/Authentisierung 55. Die Schlüssellänge bei Verschlüsselungsalgorithmen sollte unbeschränkt sein. (Z.B. durch Exportbeschränkungen.) 56. Das Schlüsselmanagement sollte ausreichend sicher sein. 57. Remote und Mobile Access Control sollten mittels starker Authentisierung und Verschlüsselung geschützt sein. 58. Für Telnet, FTP und HTTP sollte eine erweiterte Login-Prozedur zur Verfügung stehen.
59. Eine Client Authentication zur Authentisierung von Benutzern beliebiger Anwendungen sollte möglich sein. (Sowohl TCP, UDP, als auch RPC-basiert) 60. Die Authentisierung bei kritischen Protokollen sollte transparent sein. 61. Eine Authentisierung sollte pro Sitzung möglich sein. Seite 134
Firewall-Studie
11.09.97
SIEMENS
Zusätzliche Funktionen der Produkte
62. Es sollten die wesentlichen kryptographischen Algorithmen implementiert sein. 63. Sitzungsschlüssel sollten je nach Schlüssellänge mit ausreichender Häufigkeit gewechselt werden können. 5.2.5 Sonstige Anfordungen 64. Folgende Dienste sollten angeboten werden können und nicht schlicht abgewiesen werden: NFS, NIS, RPC, RIP, OSPF, r-Kommandos, DNS, WAIS. (Die Dienste NFS und NIS sind RPC-basiert und können durch einen dynamischen Paketfilter gesichert werden. RIP basiert auf UDP und kann ebenfalls durch einen dynamischen Paketfilter gesichert werden. OSPFPakete werden in IP-Pakete verpackt. Somit könnte OSPF von einem generischen Proxy sicher angeboten werden. WAIS sollte wie alle Informationsprotokolle (Gopher, HTTP) durch einen Proxy gepuffert werden, da auch hier ausführbarer Code übertragen werden kann. R-Kommandos können über einen Proxy abgesichert werden. Auch über NFS kann ausführbaren Code übertragen werden.) 65. Die BGP-Meldung Notification sollte abgewiesen werden können. (Alle Authentisierungsfehler bei BGP führen zum Aussenden der Nachricht Notification und zum Abbruch der BGP-Verbindung. Dies kann für einen Denial-of-Service-Angriff ausgenutzt werden. BGP basiert auf TCP und könnte von einem generischen Proxy gesichert werden.) 66. Die RIP-Meldung Loose-Source-Routing sollte abgewiesen werden. (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 als ein vertrauenswürdiges System ausgeben. In diesem Fall versagen Authentisierungsmechanismen, die sich allein auf die Verifikation von Quelladressen verlassen. 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.) 67. Die Firewall sollte transparent betrieben werden können. (Die Firewall sollte so konfiguriert werden können, daß in den IP Paketen die Zieladresse direkt angegeben werden kann, d. h., nicht die Firewall als mittelbares Ziel angegeben werden muß. Dies bedingt neben entsprechenden Routing-Einträgen auch die Möglichkeit einer Quelladreßumsetzung auf der Firewall.) 68. Eine On-line Hilfe sollte vorhanden sein. 69. Für den Betrieb der Firewall sollte keine proprietäre Hardware notwendig sein. 70. Der Aufwand für die Installation sollte nicht zu hoch sein. 71. Der Aufwand für die Anschaffung sollte nicht übermäßig sein. 72. Der Aufwand für das Betreiben der Firewall sollte angemessen niedrig sein. 73. Support in Installation und Training sollte angeboten werden. 74. Versionspflege sollte angeboten werden
5.3 Zusätzliche Funktionen der Produkte 5.3.1 Filterung und Proxyauswahl 75. Folgende Regelarten sollten angeboten werden: allow, deny, drop.
11.09.97
Firewall-Studie
Seite 135
SIEMENS
Sicherheitsanforderungen an Internet-Firewalls
76. Mindestens eines der folgenden Protokolle sollte durch dedizierte Proxies behandelt werden.34: Oracle SQL*Net, Netscape CoolTalk, Microsoft NetMeeting, Citrix, IntelPhone, RealAudio, X11, Sybase, Finger, whois, syslog, 5.3.2 Protokollierung / Alarmierung 77. Die Alarmierung des Administrators sollte mindestens über e-mail und Audio möglich sein. 78. Protokollinformationen sollten an einen externen Host gesendet werden können. (z.B. automatisch per e-mail) 5.3.3 Plattform 79. Mindestens eine der folgenden Plattformen sollte unterstützt werden: Windows95, Windows NT, SINIX, SunOS und Solaris, HP-UX, BSD, AIX, DEC-UNIX, OSF1, LINUX 80. Router sollten unterstützt werden. (Um mit einem Applikationsfilter ein Screened Subnet aufbauen zu können, sollten zumindest Schnittstellen für Router mit Paketfilterfunktionalität vorhanden sein.) 81. Für folgende Netze sollten Interfaces vorgesehen sein: SLIP, PPP, Ethernet, Fast Ethernet, Token Ring, X.25, FDDI, ATM
5.3.4 Authentisierung 82. Mindestens eines der folgenden Verfahren sollte bei der Authentisierung unterstützt werden: Access Key, APOP, Defender Security System, Digipass, Safeword Authentication Server, SecureNet, SecurID, S/Key, Digital Pathways SNK, Cryptocard, Reusable Passwords, Kerberos, Racal WatchWord Keys, TACACs+, RADIUS 5.3.5 Sonstige Merkmale 83. Modem-Verbindungen sollten gesichert werden können. 84. Andere Protokolle wie IPX oder DECNET sollten unterstützt werden. 85. Network Address Translation (NAT) sollte unterstützt werden. (NAT ermöglicht, private registrierungsfreie IP-Netze zu verwenden. Nach außen werden die IP-Adressen des Netzes auf externe IP-Adressen abgebildet. Durch NAT können auch alle internen IP-Adressen auf eine einzige abgebildet werden. das Netz dann durch NAT auf eine einzige IP-Adresse abgebildet. So kann die Struktur des internen Netzes verborgen werden.)
5.4 Zukünftige Sicherheitsanforderungen an Internet-Firewalls 5.4.1 Ausführbarer Code 86. An ausführbarem Code sollte mindestens JAVA, JAVAScript, MIME und ActiveX gefiltert werden können. (Ausführbarer Code kann über alle Informationsprotokolle (HTTP, Gopher, WAIS) übertragen werden. Diesen ausführbaren Code kann man durch die jeweiligen Proxies erkennen, indem diese die Protokolldaten nach Schlüsselwörtern durchsuchen. MIME selbst kann als Träger für JAVA-Applets oder ActiveX-Controls
34
Diese Anwendungsliste läßt sich beliebig fortsetzen.
Seite 136
Firewall-Studie
11.09.97
SIEMENS
Zukünftige Sicherheitsanforderungen an Internet-Firewalls
dienen. Man kann jedoch MIME-Nachrichten auch derart modifizieren, daß sie, sofern es über Mail versendet wird, Befehle, die im MIME-Header aufgeführt sind, auf dem Zielhost ausführt.) 87. Ausführbarer Code sollte auch in FTP erkannt und gefiltert werden. (Der FTP-Proxy sollte den Inhalt einer Datei, die er über FTP erhalten hat, auf ausführbaren Code untersuchen können. Alle Dateiübertragungsprotokolle eignen sich zum Versenden von ausführbarem Code. Neben einem Proxy könnte ein Anti-Virus-Checker derartig konfiguriert werden.) 88. Es sollte ein Protokoll unterstützt werden, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme (wie z.B. automatische Audit-Tools) zu integrieren. (Für zukünftige Entwicklungen von Firewalls wäre es wünschenswert, den Administrator durch automatische Audit-Tools zu entlasten.) 89. Logfiles sollten automatisch ausgewertet werden können. 5.4.2 VPN / Sicherungsdienste / Key Management 90. VPNs sollten durch IPSec, TLS/SSL oder proprietär geknüpft werden können. 91. Falls eine Firewall eines VPNs ausfällt, sollte deren Aufgabe durch eine andere übernommen werden können. (Dazu ist eine synchronisierte Zustandsübermittlung zwischen mehreren Firewalls notwendig) 92. Mehrere Firewalls sollten von einer zentralen Stelle aus verwaltet werden können. 93. Die Kommunikation mit einer Zertifizierungsstelle sollte unterstützt werden. 94. Mindestens die aktuellen Standards IPSec, ISAKMP/Oakley, TLS/SSL, RADIUS, TACACS+ sollten unterstützt werden. 5.4.3 Sonstige Anforderungen 95. Neue Protokolle sollten hinzugefügt werden können. (z.B. durch generische Proxies) 96. Die eingesetzten Programme sollten gut dokumentiert sein. 97. Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz durch die Installation oder den Betrieb der Firewall sollte nicht notwendig sein. 98. Multicast-Pakete sollten unterstützt werden.
11.09.97
Firewall-Studie
Seite 137
SIEMENS
Test ausgewählter Firewallprodukte
6 Test ausgewählter Firewallprodukte Die folgenden produktspezifischen Angaben beziehen sich stets auf die zum Zeitpunkt der Studienerstellung neueste Version des Produkts. Zum Test der Firewall-Produkte wurden neun Produkte ausgewählt. Die ausgewählten Produkte sind (in alphabetischer Reihenfolge): • • • • • • • • •
AltaVista Firewall 97 der Firma Digital Equipment Corporation Eagle Version 4.0 der Firma Raptor Systems FireWall-1 Version 3.0 der Firma Checkpoint Gauntlet Version 3.2 der Firma Trusted Information Systems KarlBridge Version 2.0 der Firma KarlNet KryptoWall Version 2.0 der Firma KryptoKom Sidewinder Version 3.1 der Firma Secure Computing Corporation PIX Firewall Version Rev 4.0 der Firma Cisco Systems TIS Internet Firewall Toolkit Version 2.0 der Firma Trusted Information Systems
Der Test der Firewallprodukte gliedert sich in drei Teile: • Prüfen aller ausgewählten Firewallprodukte auf Erfüllung der in Abschnitt 0 definierten Sicherheitsanforderungen anhand der Dokumentation bzw. anhand der Angaben des Herstellers (siehe Abschnitt 6.1). • Verifizieren der überprüfbaren Sicherheitsanforderungen auf Erfüllung in der Praxis bei den Produkten Eagle, FireWall-1 und Gauntlet (siehe Abschnitt 6.1) • Penetrationstest bei den Produkten Eagle, FireWall-1 und Gauntlet (siehe Abschnitt 6.2).
6.1 Test auf Erfüllung der Sicherheitsanforderungen Die oben aufgeführten neun Produkte wurden bezüglich der in Abschnitt 0 definierten Sicherheitsanforderungen begutachtet. Das Testvorgehen bei allen Produkten beinhaltete ein Durchsuchen der Dokumentation (technische Handbücher und Produktblätter) sowie das Interviewen der technischen Betreuer der Produkte im direkten Kontakt mit den Herstellerfirmen bzw. ihrer Vertriebspartner. Zusätzlich wurde bei den Produkten Eagle, FireWall-1 und Gauntlet die tatsächliche Erfüllung der Sicherheitsanforderungen in der Praxis überprüft. Im folgenden werden die Ergebnisse des Tests auf Erfüllung der Sicherheitsanforderungen jedes einzelnen Produktes in der Reihenfolge der in Abschnitt 0 aufgestellten Sicherheitsanforderungen aufgeführt35 (siehe Abschnitt 6.1.1-6.1.9). Abschließend werden die Ergebnisse in einer tabellarischen Übersicht dargestellt (siehe Abschnitt 6.1.10).
Legende: (ä) = Anforderung erfüllt, (x) = Anforderung nicht erfüllt, k.a. = keine Angaben, (m) = nicht relevant, (D) = geprüft anhand der Dokumentation bzw. anhand Herstellerangaben, (P) = in der Praxis überprüft.
35
Seite 138
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
6.1.1 AltaVista Firewall 97 der Firma Digital Equipment Corporation (D) AltaVista Firewall 97 ist ein Applikationsfilter mit integriertem statischen Paketfilter. 1. 2. 3.
4. 5.
6. 7. 8. 9.
10. 11. 12. 13. 14. 15. 16.
17. 18.
19.
20. 21. 22.
11.09.97
Die Identifikation und Authentisierung des Administrators ist über einen vertrauenswürdigen Pfad möglich. (ä) Die Rolle des Revisors ist nicht vorgesehen. (x) Bei einem Ausfall einer Protokollierungskomponente wird keine Warnung an den Administrator ausgegeben. Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (x) Integritätstests der eingesetzten Programme werden von der AltaVista nicht angeboten. (x) Es ist möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. Falls Komponenten (z.B. Proxies) abstürzen, wird die Funktion generell verweigert, die von diesen Komponenten bedient wird. Bei der zentralen Komponente der Firewall, die Verbindungsaufbauwünsche erlaubt oder ablehnt, resultiert ein Absturz in ein generelles „DENY“ aller Verbindungsaufbauwünsche. Dann ist die Firewall nur noch zur Administration erreichbar. (ä) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist. Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (x) Die Firewall besteht nicht aus zwei getrennten Filtern, sondern aus einem Applikationsfilter. (x) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) Die Struktur des zu schützenden Netzes kann durch den Einsatz der AltaVista als Applikationsfilter und zweier DNS-Server verdeckt werden, wobei ein DNS-Server extern hinter einem Paketfilter und ein DNS-Server intern hinter dem Applikationsfilter aufgestellt wird, und diese DNS-Server Informationen nur über einen Applikationsfilter austauschen können (sog. splitted DNS-Server). Dadurch können DNS-Requests von einem unbekannten Rechner verhindert oder zu einem bestimmten DNS-Server umgeleitet werden. Außerdem kann die Struktur des internen Netzes durch den Einsatz des split-level DNSDämons verdeckt werden. Dieser gehört zum Lieferumfang des Eagle. Der SMTP-Proxy filtert die internen „Received“-Statements der inneren Rechner nicht. (ä) Für die Verwaltung der Komponenten existiert eine GUI. (ä) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. (ä) Der Aufbau von Verbindungen auf der Anwendungsschicht kann durch die Firewall benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) Zur Benutzeridentifikation werden starke Authentisierungsmethoden angeboten. (ä) Mehrere Benutzer können zu einer Gruppe zusammengefaßt werden. (ä) Die Filterregeln können nicht auf ihre Widerspruchsfreiheit überprüft werden. (x) AltaVista bietet Proxies für MAIL, FTP, Telnet, NNTP, HTTP, finger und RealAudio an. Ferner bietet es UDP, SSL, ICMP, DNS, ActiveX, JAVA, MIME und Gopher an. Ein generischer TCP-Proxy ist ebenfalls vorhanden. (ä) Für Telnet-Verbindungen vom Internet zur Firewall kann durch zusätzliche Prozesse (z.B. Knüpfen eines VPNs) eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. (ä) Für Verbindungen auf der Anwendungsschicht können alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (z.B. post bei HTTP) bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht kann eine Protokollierung von Benutzeridentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. (ä) Die Protokollierung kann auf bestimmte Verbindungen eingeschränkt werden. (ä) Spezielle einstellbare Protokollmeldungen führen zu einer unverzüglichen Warnung. (ä) Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden (nur via syslog). (x) Bei der Benutzung von FTP ist es möglich, den Verbindungsaufbau für die Datenverbindung (FTPDATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (ä)
Firewall-Studie
Seite 139
SIEMENS
Test ausgewählter Firewallprodukte
23. Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze, abhängig von Quell- und Zielport für TCP, jedoch nicht für UDP erlaubt oder verboten werden. (ä/x) 24. Die Filterung ist gemäß voriger Forderung für jedes Interface getrennt möglich. (ä) 25. Die Reihenfolge der Filterregeln wird nicht automatisch von der Firewall verändert. (ä) 26. Eine Filterung ist getrennt für kommende und gehende Pakete möglich, wenn mehr als zwei Interfaces vorhanden sind. (ä) 27. Bei TCP-Paketen ist eine Unterscheidung zwischen ACK und ACK-losen Paketen möglich. (ä) 28. Die Protokollierung von IP-Nummer, Dienst, Zeit und Datum ist für jedes Paket möglich. (ä) 29. Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) 30. Source-Routing Informationen werden standardmäßig abgewiesen. (ä) 31. Die Firewall verlangt keine Mindestgröße an Fragmentlänge. (x) 32. Die Firewall schreibt kein Minimum an Fragment-Offset vor. (x) 33. Die ICMP-Meldung Destination Unreachable wird abgewiesen, da ICMP generell verweigert wird. (ä) 34. Die ICMP-Meldung Redirect wird aus dem gleichen Grund abgewiesen. (ä) 35. Inverse DNS-Anfragen können durch den Ansatz „splitted DNS-Server“ abgewiesen werden. (ä) 36. Zonen-Transfer-Requests von einem unbekannten Host können mit REFUSED beantwortet werden. (ä) 37. ARP-Tabellen können nicht fixiert werden. (x) 38. Das automatische Ablaufen von ARP kann nicht unterbunden werden. (x) 39. AltaVista unterstützt lediglich die FTP-Befehle PUT (STOR) und GET (RETR). Befehle wie CWD, CDUP, SITE und LIST werden nicht abgewiesen. (x) 40. Eingehende Telnet-Daten auf Port 23 können abgewiesen werden. (x) 41. S-HTTP-Daten können vom HTTP-Proxy erkannt und abgewiesen werden. (ä) 42. Die AltaVista bietet keine dynamische Paketfilterfunktionalität. Somit können dynamische Ports nicht verfolgt werden. (x) 43. Es können die Netzobjekte Host, Domain, Group und VPNs definiert werden. (ä) 44. Spoof-Checking wird durchgeführt. (ä) 45. Ping-to-Death kann vom darunterliegenden Betriebssystem abgefangen werden. (ä) 46. TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. (ä) 47. Ein Anti-Virus-Checker ist nicht integriert. (x) 48. Fragmentierte Pakete werden zunächst zusammengesetzt und anschließend untersucht. (ä) 49. Session-Hijacking wird verhindert. (ä) 50. TCP-Sequence-Number-Guessing wird durch Randomisieren der Sequenznummer verhindert. (ä) 51. Illegal Address Support ist möglich. (ä) 52. Die Administration der Firewall ist lediglich durch ein Paßwort geschützt. (x) 53. IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) 54. Die AltaVista kann zentral fernadministriert werden. Die Kommunikation des Administrators mit der Firewall ist durch Verschlüsselung geschützt. (ä) 55. Die verwendeten Verschlüsselungsverfahren unterliegen den US-Exportrestriktionen. (x) 56. Zum Key Management hat der Hersteller keine Angaben gemacht. (k.a.) 57. Die Verbindung zu einem externen Rechner kann von der AltaVista nicht geschützt werden. (x) 58. Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) 59. Für die Authentisierung von Benutzern beliebiger Anwendungen ist eine Client Authentication für TCP, jedoch nicht für UDP und RPC möglich. (x) 60. Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) 61. Eine Authentisierung ist pro Sitzung möglich. (ä) 62. Die kryptographischen Algorithmen DES und Keyed MD5 werden verwendet. (ä) 63. Bezüglich der Möglichkeit, Sitzungsschlüssel zu wechseln hat der Hersteller keine Angaben gemacht. (k.a.) 64. Neben den Standarddiensten werden r-Kommandos angeboten. Die Dienste NFS, NIS, RPC, RIP, DNS, WAIS, SNMP und OSPF werden nicht angeboten. (x) 65. BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. (ä) 66. Die RIP-Meldung Loose-Source-Routing wird abgewiesen, da RIP nicht angeboten wird. (ä) 67. Die Firewall kann nicht transparent betrieben werden. (x) 68. Eine On-line Hilfe ist vorhanden. (ä) Seite 140
Firewall-Studie
11.09.97
SIEMENS 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98.
Test auf Erfüllung der Sicherheitsanforderungen
Für den Betrieb der Firewall ist keine proprietäre Hardware notwendig. (ä) Zum Aufwand für Installation der AltaVista hat der Hersteller keine Angaben gemacht. (k.a.) Der Preis für die AltaVista beträgt je nach User-Anzahl zwischen DM 4.000,- und DM 24.000,Zum Aufwand für den Betrieb der AltaVista hat der Hersteller keine Angaben gemacht. (k.a.) Für Installation und Wartung wird Support angeboten. (ä) Versionspflege wird betrieben. (ä) Zur Filterung werden die Regelarten allow und deny angeboten. (ä) Neben den Standardproxies bietet die AltaVista dedizierte Proxies für den Dienst RealAudio an. (ä) Die Alarmierung des Administrators erfolgt über E-mail. (ä) Protokollinformationen können an einen externen Host gesendet werden (z.B. automatisch per e-mail). (ä) Die AltaVista ist für die Plattformen Solaris, SunOS, BSD und HP-UX verfügbar. (ä) Router werden unterstützt. (ä) Netzkarten sind für die Netze SLIP, PPP, Ethernet, Fast Ethernet und Token Ring erhältlich. (ä) Zur Authentisierung werden die Verfahren SecureNet, S/Key, Digital Pathways SNK und Reusable Passwords angeboten. Modem-Verbindungen können durch das Produkt AltaVista Tunnel gesichert werden. (ä) Andere Protokolle wie IPX oder DECNET können nicht unterstützt werden. (x) Network Address Translation ist möglich. (ä) An ausführbarem Code kann JAVA gefiltert werden. (ä) Ausführbarer Code wird in FTP oder anderen Datenübertragungsprotokollen nicht gefiltert. (x) AltaVista unterstützt kein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integieren. (x) Logfiles können nicht automatisch ausgewertet werden. (x) VPNs können durch das Produkt AltaVista Tunnel proprietär geknüpft werden. (x) Eine synchronisierte Zustandsübermittlung zwischen mehreren Firewalls wird nicht unterstützt. (x) Dadurch ist es nicht möglich, mehrere Firewalls zentral zu administrieren. (x) Die Kommunikation mit einer Zertifizierungsstelle wird nicht unterstützt. (x) Aktuelle Standards wie IPSec, SKIP, RADIUS, ISAKMP/Oakley, TLS/SSL und TACACs werden nicht unterstützt. (x) Ein generischer Proxy ist vorhanden. (ä) Die eingesetzten Programme sind nicht ausreichend dokumentiert. (x) Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation der Firewall nicht notwendig. (ä) Multicast-Pakete werden nicht unterstützt. (x)
Fazit Die AltaVista Firewall unterstützt zwar nicht die Standards IPSec oder TLS/SSL, bietet aber für das Knüpfen von VPNs mit anderen Herstellern das Produkt AltaVista Tunnel an, das die wesentlichen Algorithmen unterstützt. Kaskadierte Intranets werden dadurch ebenfalls realisierbar. Die AltaVista Firewall kostet je nach User-Anzahl zwischen DM 4.000,- und DM 24.000,-. Kontaktadresse:
[email protected].
11.09.97
Firewall-Studie
Seite 141
SIEMENS
Test ausgewählter Firewallprodukte
6.1.2 Eagle Version 4.0 der Firma Raptor (D)+(P) Der Eagle der Firma Raptor ist ein proxy-basierter Filter auf Applikationsebene und bietet keine PaketfilterFunktionalität im eigentlichen Sinne. Paketfilterung ist jedoch in VPN-Tunnels möglich. Innerhalb dieser Tunnels können Pakete bezüglich Typ und Richtung gefiltert werden. 1.
2. 3.
4. 5.
6.
7. 8. 9.
10. 11.
12. 13. 14. 15. 16.
17. 18.
19.
Die Identifikation und Authentisierung des Administrators ist über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole) möglich. Das Protokoll X11 wird geblockt, so daß Zugriffe über X11 nicht möglich sind. Über das Betriebssystem ist konfigurierbar, daß kein remote login möglich ist. (ä) (P) Die Rolle des Revisors ist nicht vorgesehen. (x) (P) Bei einem Ausfall einer Protokollierungskomponente wird keine Warnung an den Administrator ausgegeben. Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (x) (P) Integritätstests der eingesetzten Programme werden vom Eagle durch das Produkt Eagle TripWire angeboten. (ä) (D) Es ist möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. Falls Komponenten (z.B. Proxies) abstürzen, wird die Funktion generell verweigert, die von diesen Komponenten bedient wird. Bei der zentralen Komponente der Firewall, die Verbindungsaufbauwünsche erlaubt oder ablehnt, resultiert ein Absturz in ein generelles „DENY“ aller Verbindungsaufbauwünsche. Dann ist die Firewall nur noch zur Administration erreichbar. (ä) (P) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist (z.B. openwin für die Administrationsoberfläche). Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (x) (P) Die Firewall besteht nicht aus zwei getrennten Filtern, sondern aus einem Applikationsfilter. (x) (P) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) (P) Die Struktur des zu schützenden Netzes kann durch den Einsatz des Eagle als Applikationsfilter und zweier DNS-Server verdeckt werden, wobei ein DNS-Server extern hinter einem Paketfilter und ein DNS-Server intern hinter dem Applikationsfilter aufgestellt wird, und diese DNS-Server Informationen nur über einen Applikationsfilter austauschen können (sog. splitted DNS-Server). Dadurch können DNS-Requests von einem unbekannten Rechner verhindert oder zu einem bestimmten DNS-Server umgeleitet werden. Ferner kann die Struktur des internen Netzes durch Network Address Translation verdeckt werden. (ä) (D) Für die Verwaltung der Komponenten existiert eine GUI. (ä) (P) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. Hier wurde die Existenz eines vertrauenswürdigen Pfades für lokale Komponenten geprüft. (ä) (P) Der Aufbau von Verbindungen auf der Anwendungsschicht kann durch die Firewall benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) (P) Zur Benutzeridentifikation werden starke Authentisierungsmethoden verwendet. (ä) (D) Mehrere Benutzer können zu einer Gruppe zusammengefaßt werden. (ä) (P) Die Filterregeln können nicht auf ihre Widerspruchsfreiheit überprüft werden. (x) (P) Standardprotokolle wie Telnet, FTP, SMTP, DNS, NTP, Gopher und HTTP/S-HTTP werden durch Proxies unterstützt. Zusätzlich existieren Proxies für die Dienste Oracle SQL Net und Real Audio. Hier wurde FTP geprüft, SMTP, DNS und HTTP wurden nicht überprüft, NNTP ist nicht vorhanden (ä) (P) Für Telnet-Verbindungen vom Internet zur Firewall kann durch zusätzliche Prozesse (z.B. Knüpfen eines VPNs) eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. (ä) (D) Für Verbindungen auf der Anwendungsschicht können alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (z.B. post bei HTTP) bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden. Dies wurde bei FTP überprüft. (ä) (P) Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht kann eine Protokollierung von IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. Eine Protokollierung der Benutzeridentifikation ist nicht möglich. (ä) (P)
Seite 142
Firewall-Studie
11.09.97
SIEMENS
20. 21. 22.
23.
24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.
41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 11.09.97
Test auf Erfüllung der Sicherheitsanforderungen
Die Protokollierung kann nicht auf bestimmte Verbindungen eingeschränkt werden. Der Eagle protokolliert alles. (x) (P) Spezielle einstellbare Protokollmeldungen führen zu einer unverzüglichen Warnung. Allerdings kann keine Warnstufe angegeben werden. (ä) (P) Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden (nur via syslog). (x) Bei der Benutzung von FTP ist es möglich, den Verbindungsaufbau für die Datenverbindung (FTPDATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (ä) (D) Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze, wegen der nicht vorhandenen Paketfilterfunktionalität jedoch nicht abhängig von Quell- und Zielport für TCP oder UDP erlaubt oder verboten werden. (ä/x) (P) Die Filterung ist gemäß voriger Forderung für jedes Interface getrennt möglich. (ä) (P) Die Reihenfolge der Filterregeln wird automatisch vom Eagle verändert. Es wurde entdeckt, daß entgegen den Angaben des Herstellers zeitabhängige Regeln vor anderen Regeln abgearbeitet werden. (x) (P) Eine Filterung ist getrennt für kommende und gehende Pakete möglich, wenn mehr als zwei Interfaces vorhanden sind. (ä) (P) Bei TCP-Paketen ist eine Unterscheidung zwischen ACK und ACK-losen Paketen nicht relevant, da der Eagle kein Paketfilter ist. (m) Die Protokollierung von IP-Nummer, Dienst, Zeit und Datum für jedes Paket ist nicht möglich. (x) (P) Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) (D) Source-Routing Informationen werden standardmäßig abgewiesen. Dies wurde mit dem ISS überprüft. (ä) (P) Die Firewall verlangt keine Mindestgröße an Fragmentlänge. (x) (P) Die Firewall schreibt kein Minimum an Fragment-Offset vor. (x) (P) Die ICMP-Meldung Destination Unreachable wird abgewiesen, da ICMP nicht unterstützt wird. (ä) (D) Die ICMP-Meldung Redirect wird aus dem gleichen Grund abgewiesen. Dies wurde mit dem ISS überprüft. (ä) (P) Inverse DNS-Anfragen können durch den Ansatz „splitted DNS-Server“ abgewiesen werden. (ä) (D) Zonen-Transfer-Requests von einem unbekannten Host können mit REFUSED beantwortet werden. (ä) (D) ARP-Tabellen können unter UNIX durch den Befehl arp –s fixiert werden. (ä) (P) Das automatische Ablaufen von ARP kann unter UNIX unterbunden werden. (ä) (P) Der FTP-Proxy kennt lediglich die Befehle PUT (STOR) und GET (RETR). Befehle wie CWD, CDUP und LIST werden nicht abgewiesen. SITE wird abgewiesen. (x) (P) Eingehende Telnet-Daten auf Port 23 können nicht abgewiesen werden. Indem der Telnet-Dienst an eine Authentisierung bzw. Verschlüsselung geknüpft wird (customized telnet), kann dieser Angriff jedoch verhindert werden. (ä) (D) S-HTTP-Daten können vom HTTP-Proxy erkannt und abgewiesen werden. (ä) (D) Der Eagle bietet keine dynamische Paketfilterfunktionalität. Somit können dynamische Ports nicht verfolgt werden. (x) (D) Es können die Netzobjekte Host, Domain, Subnet, Group, IP-Range und VPN-Objekte definiert werden. (ä) (P) Spoof-Checking wird durchgeführt. (ä) (P) Ping-to-Death kann vom darunterliegenden Betriebssystem abgefangen werden. (ä) (P) TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. Dies wurde mit dem ISS geprüft. (ä) (P) Ein Anti-Virus-Checker ist nicht integriert. (x) (D) Fragmentierte Pakete werden zunächst zusammengesetzt und anschließend untersucht. (ä) (D) Session-Hijacking wird verhindert. (ä) (D) TCP-Sequence-Number-Guessing wird durch Randomisieren der Sequenznummer verhindert. Dies wurde mit dem ISS geprüft. Laut Hersteller ist dies auf SINIX nicht möglich. (ä) (P) Illegal Address Support ist möglich. (ä) (D) Die Administration der Firewall ist lediglich durch ein Paßwort geschützt. (x) (P) IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) (P) Firewall-Studie
Seite 143
SIEMENS
Test ausgewählter Firewallprodukte
54. Der Eagle kann fernadministriert werden. Die Kommunikation des Administrators mit der Firewall ist durch Verschlüsselung geschützt. (ä) (D) 55. Die verwendeten Verschlüsselungsverfahren unterliegen den US-Exportrestriktionen. (x) (D) 56. Das Key Management erfolgt durch den off-line Austausch eines Setup-Schlüssels, aus dem pro Session ein Session-Key berechnet wird. (ä) (D) 57. Die Verbindung zu einem externen Rechner kann vom Eagle durch das Produkt Eagle Mobile/-Desk Computing per Verschlüsselung und Authentisierung geschützt werden. (ä) (D) 58. Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) (P) 59. Für die Authentisierung von Benutzern beliebiger Anwendungen ist eine Client Authentication für TCP, jedoch nicht für UDP und RPC möglich. (x) (P) 60. Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) (P) 61. Eine Authentisierung ist pro Sitzung möglich. (ä) (P) 62. Die Verschlüsselung erfolgt mit exportbeschränktem RC2 oder 56-Bit DES-Algorithmus im CBCModus oder DES-3 mit Key Recovery. Zur Authentisierung und Überprüfung der Integrität wird der Algorithmus Keyed MD5 verwendet. (ä) (D) 63. Sitzungsschlüssel werden pro Sitzung neu berechnet. (ä) (D) 64. Neben den Standarddiensten können der Dienst DNS angeboten werden. Die Dienste NFS, NIS, RPC, RIP, WAIS, r-Kommandos, OSPF und SNMP können nicht sicher angeboten werden. Bei SNMP sind nur public MIBs möglich. (ä) (D) 65. BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. (ä) (D) 66. Die RIP-Meldung Loose-Source-Routing wird wie gesamt RIP abgewiesen. (ä) (D) 67. Die Firewall kann nur für Nutzer im zu schützenden Bereich transparent betrieben werden. (x) (P) 68. Eine On-line Hilfe ist im Gegensatz zu den Angaben des Herstellers nicht vorhanden. (x) (P) 69. Für den Betrieb der Firewall ist keine proprietäre Hardware notwendig. (ä) (P) 70. Der Aufwand für die Installation liegt bei ca. einer Stunde ohne die Implementierung der Filterregeln. (ä) (P) 71. Der Preis für den Eagle beträgt abhängig von der Anzahl der Hosts im zu schützenden Bereich zwischen DM 12.000,- und DM 50.000,-. (ä) (D) 72. Der Aufwand für ein sinnvolles Betreiben der Firewall liegt bei ca. einer Stunde pro Tag. (ä) (D) 73. Für Installation und Wartung wird Support angeboten. (ä) (D) 74. Versionspflege wird betrieben. (ä) (D) 75. Zur Filterung werden die Regelarten allow und deny angeboten. (ä) (P) 76. Zusätzlich zu den Standarddiensten bietet der Eagle dedizierte Proxies für die Dienste Oracle SQL und RealAudio an. (ä) (D) 77. Die Alarmierung des Administrators erfolgt über E-mail oder Audio. (ä) (P) 78. Protokollinformationen können an einen externen Host gesendet werden (z.B. automatisch per e-mail). (ä) (P) 79. Der Eagle ist für die Plattformen WindowsNT, SINIX, Solaris, SunOS und HP-UX verfügbar. Der Eagle wurde auf der Plattform Solaris 2.5.1 getestet. (ä) (D) 80. Router werden unterstützt. (ä) (D) 81. Netzkarten sind für die Netze Ethernet, Fast Ethernet, Token Ring, ATM, ISDN und FDDI erhältlich. Der Eagle wurde auf Ethernet getestet. (ä) (D) 82. Zur Benutzerauthentisierung werden die Verfahren SecureID, S/Key, Digital Pathways SNK, CryptoCard, Reusable Passwords, Radius und TACACs angeboten. (ä) (D) 83. Modem-Verbindungen können durch das Eagle Mobile/-Desk Computing gesichert werden. (ä) (D) 84. Andere Protokolle wie IPX oder DECNET werden nicht unterstützt. (x) (D) 85. Network Address Translation ist möglich. (ä) (D) 86. An ausführbarem Code kann JAVA, MIME und ActiveX in HTTP gefiltert werden. (ä) (D) 87. Ausführbarer Code wird in FTP oder anderen Datenübertragungsprotokollen nicht gefiltert. Dies wurde für FTP getestet. (x) (P) 88. Der Eagle unterstützt kein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integieren. (x) (D) 89. Logfiles können automatisch ausgewertet werden. (ä) (D) 90. VPNs können durch IPSec geknüpft werden. (ä) (D) Seite 144
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
91. Eine synchronisierte Zustandsübermittlung zwischen mehreren Eagles ist nicht möglich. (x) (D) 92. Mehrere Firewalls können zentral administriert werden, jedoch ist die Kommunikation lediglich durch ein Paßwort geschützt. (x) (P) 93. Die Kommunikation mit einer Zertifizierungsstelle wird nicht unterstützt. (x) (D) 94. An aktuellen Standards werden IPSec, RADIUS und TACACs unterstützt. ISAKMP/Oakley und TLS/SSL werden nicht unterstützt. (ä) (D) 95. Ein generischer Proxy ist vorhanden, dieser kann jedoch nicht mit Authentisierungsmethoden verknüpft werden. (ä) (P) 96. Die eingesetzten Programme sind nicht ausreichend dokumentiert. (x) (P) 97. Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation der Firewall nicht notwendig. (ä) (P) 98. Multicast-Pakete werden unterstützt. (ä) (D) Fazit Der Eagle ist eine Firewall, die als Applikationsfilter eines Screened Subnet ausreichend Möglichkeiten bietet, derzeitige und zukünftige Anforderungen zu erfüllen. Durch die Unterstützung von IPSec eignet sich die Firewall für VPNs mit anderen Herstellern. Um diesen Aspekt zu komplettieren, sollte das Key-ManagementProtokoll ISAKMP/Oakley und die Kommunikation mit einer Zertifizierungsstelle sowie TLS/SSL für das Szenario kaskadiertes Intranet von Folgeversionen unterstützt werden. Die Unterstützung von MulticastPaketen zeichnet den Eagle unter den getesteten Produkten aus. TCP-Sequence-Number-Guessing sollte auch auf SINIX abgewendet werden können. Ferner sollte ein X11-Proxy angeboten werden. Die Reihenfolge der Filterregeln sollte nicht automatisch vom Eagle verändert, oder der Benutzer darauf aufmerksam gemacht werden. Der Preis für diese Firewall ist von der Anzahl der User abhängig: 100 User DM 12.000,-, 200 User DM 24.000,-, unlimited DM 50.000,-. Diese Preisangaben enthalten ein Inbetriebnahmepaket, das aus der Definition der Sicherheitspolitik (1 Tag), Konfiguration (1 Tag) und Schulung (2-3 Tage) besteht. Der Aufwand für den Administrator im Betrieb bei ca. 1h pro Tag. Kontaktadresse:
[email protected].
11.09.97
Firewall-Studie
Seite 145
SIEMENS
Test ausgewählter Firewallprodukte
6.1.3 FireWall-1 Version 3.0 der Firma Checkpoint (D)+(P) Die FireWall-1 bietet die Funktionalitäten dynamischer Paketfilter und Applikationsfilter an. 1. 2. 3.
4. 5. 6. 7. 8. 9.
10. 11.
12.
13. 14. 15. 16.
17. 18.
19.
20. 21.
Die Identifikation und Authentisierung des Administrators ist über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole) möglich. (ä) (P) Die Rolle des Revisors ist nicht vorgesehen. (x) (P) Bei einem Ausfall einer Protokollierungskomponente wird keine Warnung an den Administrator ausgegeben. Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (x) (P) Integritätstests der eingesetzten Programme werden von der Firewall-1 nicht angeboten, können jedoch zum Beispiel mit TRIPWIRE durchgeführt werden. (ä) (D) Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. (x) (P) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist. Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (x) (P) Die Firewall besteht nicht aus zwei getrennten Filtern, sondern aus einem Applikationsfilter mit integriertem Paketfilter. (x) (P) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) (P) Die Struktur des zu schützenden Netzes kann durch den Einsatz der Firewall-1 als Applikationsfilter und zweier DNS-Server verdeckt werden, wobei ein DNS-Server extern hinter einem Paketfilter und ein DNS-Server intern hinter dem Applikationsfilter aufgestellt wird, und diese DNS-Server Informationen nur über einen Applikationsfilter austauschen können (sog. splitted DNS-Server). Dadurch können DNS-Requests von einem unbekannten Rechner verhindert oder zu einem bestimmten DNS-Server umgeleitet werden. Ferner kann die Struktur des internen Netzes durch Network Address Translation verdeckt werden. (ä) (D) Für die Verwaltung der Komponenten existiert eine GUI. (ä) (P) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch die Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. (ä) (P) Der Aufbau von Verbindungen auf der Anwendungsschicht kann durch die Firewall benutzer- und zeitabhängig erlaubt oder verboten werden. Bei den Zeitangaben war die lokale Zeit abzüglich einer Stunde anzugeben. (ä) (P) Zur Benutzeridentifikation werden starke Authentisierungsmethoden angeboten. (ä) (D) Mehrere Benutzer können zu einer Gruppe zusammengefaßt werden. Es können die Netzobjekte Host, Domain, Subnet, Group, IP-Range und VPN-Objekte definiert werden. (ä) (P) Die Filterregeln können auf ihre Widerspruchsfreiheit überprüft werden. (ä) (P) Die Protokolle Telnet, FTP, SMTP, HTTP und RLOGIN werden von einem sogenannten Security Server geschützt, der keine eigene Verbindung zum internen Client aufbaut und in dem Sinne kein Proxy ist. NNTP kann durch den generischen Proxy, DNS kann durch die dynamische Paketfilterfunktionalität angeboten werden. (ä) (P) Für Telnet-Verbindungen vom Internet zur Firewall kann durch zusätzliche Prozesse (z.B. Knüpfen eines VPNs) eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. (ä) (D) Für Verbindungen auf der Anwendungsschicht können nicht alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (post bei HTTP) bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden. (x) (D) Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht kann eine Protokollierung von Benutzeridentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. (ä) (P) Die Protokollierung kann nicht auf bestimmte Verbindungen eingeschränkt werden. (x) (P) Spezielle einstellbare Protokollmeldungen führen zu einer unverzüglichen Warnung. (ä) (P) Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden (nur via syslog). (x)
Seite 146
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
22. Bei der Benutzung von FTP ist es möglich, den Verbindungsaufbau für die Datenverbindung (FTPDATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (ä) (D) 23. Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze und wegen der dynamischen Paketfilterfunktionalität abhängig von Quell- und Zielport für TCP und UDP erlaubt oder verboten werden. (ä/ä) (P) 24. Die Filterung ist gemäß voriger Forderung für jedes Interface getrennt möglich. (ä) (P) 25. Die Reihenfolge der Paketfilterregeln wird nicht automatisch vom Paketfilter verändert. (ä) (P) 26. Eine Filterung ist getrennt für kommende und gehende Pakete möglich, wenn mehr als zwei Interfaces vorhanden sind. (ä) (D) 27. Bei TCP-Paketen ist eine Unterscheidung zwischen ACK und ACK-losen Paketen möglich. (ä) (D) 28. Die Protokollierung von Dienst, Zeit und Datum ist für jedes Paket möglich. Die IP-Nummer wird nicht protokolliert. (x) (P) 29. Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) (D) 30. Source-Routing Informationen werden standardmäßig abgewiesen. Dies wurde mit dem ISS getestet. (ä) (P) 31. Die Paketfilterkomponente verlangt keine Mindestgröße an Fragmentlänge, wendet aber den IP-TinyFragment-Angriff durch virtuelles Reassemblieren ab. (x) (D) 32. Die Paketfilterkomponente schreibt kein Minimum an Fragment-Offset vor. (x) (D) 33. Die ICMP-Meldung Destination Unreachable wird wie ICMP insgesamt abgewiesen. (ä) (P) 34. Die ICMP-Meldung Redirect wird aus dem gleichen Grund abgewiesen. (ä) (P) 35. Inverse DNS-Anfragen können durch den Ansatz „splitted DNS-Server“ abgewiesen werden. (ä) (D) 36. Zonen-Transfer-Requests von einem unbekannten Host können mit REFUSED beantwortet werden. (ä) (D) 37. ARP-Tabellen können unter UNIX mit dem Befehl arp –s fixiert werden. (ä) (P) 38. Das automatische Ablaufen von ARP kann unterbunden werden. (ä) (P) 39. Der Firewall-1 FTP-Dämon unterstützt lediglich die Befehle PUT (STOR) und GET (RETR). Befehle wie CWD, CDUP, LIST und SITE werden nicht abgewiesen. (x) (P) 40. Eingehende Telnet-Daten können auf Port 23 abgewiesen werden. (ä) (P) 41. S-HTTP-Daten können vom HTTP-Proxy erkannt und abgewiesen werden. (ä) (D) 42. Die Firewall-1 bietet dynamische Paketfilterfunktionalität. Somit können dynamische Ports verfolgt werden. (ä) (D) 43. Es können die Netzobjekte Host, Domain, Subnet, Group, IP-Range definiert werden. VPN-Objekte können als Netzobjekte nicht definiert werden. (ä) (P) 44. Spoof-Checking wird durchgeführt. (ä) (P) 45. Ping-to-Death kann vom darunterliegenden Betriebssystem abgefangen werden. (ä) (P) 46. TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. Dies wurde mit dem ISS überprüft. (ä) (P) 47. Ein Anti-Virus-Checker ist nicht integriert. Fremdprodukte können jedoch unterstützt werden. (ä) (P) 48. Fragmentierte Pakete werden zunächst zusammengesetzt und anschließend untersucht. (ä) (D) 49. Session-Hijacking wird verhindert. (ä) (D) 50. TCP-Sequence-Number-Guessing wird durch Randomisieren der Sequenznummer verhindert. Dies wurde mit dem ISS überprüft. (ä) (P) 51. Illegal Address Support ist möglich. (x) (D) 52. Die Administration der Firewall ist lediglich durch ein Paßwort geschützt. (x) (D) 53. IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) (P) 54. Die Firewall-1 kann zentral fernadministriert werden. Die Kommunikation des Administrators mit der Firewall ist durch Verschlüsselung geschützt. (ä) (D) 55. Die verwendeten Verschlüsselungsverfahren unterliegen den US-Exportrestriktionen. (x) (D) 56. Das Key Management sieht vor, daß Firewall-1-Module und Management je einen privaten RSASchlüssel besitzen. Der öffentliche RSA-Schlüssel wird ausgetauscht. Aus beiden Teilschlüsseln wird ein Sessionkey erzeugt. Dieser dient zur Verschlüsselung in einem VPN. Der Sessionkey kann auf Anforderung des Administrators jederzeit geändert werden. (x) (D) 57. Ein externer Rechner kann von der Firewall-1 durch das Programmpaket SecuRemote mittels Authentisierung und Verschlüsselung geschützt werden. (ä) (D) 11.09.97
Firewall-Studie
Seite 147
SIEMENS
Test ausgewählter Firewallprodukte
58. Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) (P) 59. Für die Authentisierung von Benutzern beliebiger Anwendungen ist eine Client Authentication sowohl für TCP, UDP als auch RPC möglich. (ä) (P) 60. Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) (P) 61. Eine Authentisierung ist pro Sitzung möglich. (ä) (P) 62. Die kryptographischen Algorithmen DES, RSA und Keyed MD5 werden verwendet. (ä) (D) 63. Sitzungsschlüssel können vom Administrator jederzeit manuell geändert werden. (ä) (D) 64. Folgende Dienste können angeboten werden: NFS, NIS, RPC, RIP, DNS, WAIS, r-Kommanods und SNMP. OSPF kann nicht sicher angeboten werden. (ä) (D) 65. BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. (ä) (D) 66. Die RIP-Meldung Loose-Source-Routing kann abgewiesen werden. (ä) (D) 67. Die Firewall kann nicht transparent betrieben werden. (x) (P) 68. Eine On-line Hilfe ist vorhanden. . (ä) (P) 69. Für den Betrieb der Firewall ist keine proprietäre Hardware notwendig. (ä) (P) 70. Der Aufwand für die Installation liegt bei ca. einer Stunde. (ä) (P) 71. Der Preis für die Firewall-1 beträgt abhängig von der Anzahl der Hosts im zu schützenden Bereich mindestens DM 6.690,-. (ä) (D) 72. Der Aufwand für ein sinnvolles Betreiben der Firewall liegt bei ca. einer Stunde pro Tag. (ä) (D) 73. Für Installation und Wartung wird Support angeboten. (ä) (D) 74. Versionspflege wird betrieben. (ä) (D) 75. Zur Filterung werden die Regelarten accept, reject und drop angeboten. (ä) (P) 76. Firewall-1 verwendet keine dedizierten Proxies. (x) (D) 77. Die Alarmierung des Administrators erfolgt über E-mail oder Audio. (ä) (P) 78. Protokollinformationen können nicht per e-mail an einen externen Host gesendet werden. (x) (P) 79. Die Firewall-1 ist für die Plattformen WindowsNT, Solaris, SunOS, HP-UX und AIX verfügbar. (ä) (D) 80. Router werden unterstützt. (ä) (D) 81. Die Firewall-1 ist für die Netze SLIP, PPP, Ethernet, Fast Ethernet, Token Ring und X.25 vorgesehen. (ä) (D) 82. Zur Benutzeridentifikation werden die Authentisierungsmethoden Einmalpaßwort S/Key, SecureNet, SecureID, Digital Pathways, Reusable Passwords und Radius angeboten. Paßwort wurde überprüft. (ä) (D) 83. Modem-Verbindungen können durch das Produkt SecuRemote gesichert werden. (ä) (D) 84. Andere Protokolle wie IPX oder DECNET werden nicht unterstützt. (x) (D) 85. Network Address Translation ist möglich. (ä) (D) 86. An ausführbarem Code kann JAVA, MIME und ActiveX gefiltert werden. (ä) (D) 87. Ausführbarer Code wird in FTP oder anderen Datenübertragungsprotokollen nicht gefiltert. (x) (D) 88. Firewall-1 unterstützt ein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integieren. (ä) (D) 89. Logfiles können über ein Fremdprodukt automatisch ausgewertet werden. (ä) (D) 90. VPNs können durch IPSec oder proprietär geknüpft werden. (ä) (D) 91. Zwischen mehreren Firewalls ist eine synchronisierte Zustandsübermittlung möglich. (ä) (D) 92. Dadurch können mehrere Firewalls zentral administriert werden. (ä) (D) 93. Die Kommunikation mit einer Zertifizierungsstelle wird unterstützt. (ä) (D) 94. An aktuellen Standards werden IPSec, SKIP und RADIUS unterstützt. ISAKMP/Oakley, TLS/SSL und TACACs werden nicht unterstützt. (ä) (D) 95. Ein generischer Proxy ist vorhanden. Hierbei ist jedoch keine User Authentication oder Verschlüsselung über die GUI möglich. (ä) (P) 96. Die eingesetzten Programme sind ausreichend dokumentiert. (ä) (P) 97. Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation der Firewall nicht notwendig. (ä) (P) 98. Multicast-Pakete werden nicht unterstützt. (x) (D)
Seite 148
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
Fazit Das Produkt FireWall-1 besitzt einen dynamischen Paketfilter und bietet damit die Möglichkeit, eine große Anzahl an Diensten anbieten zu können. Außerdem ist die breite Einsatzmöglichkeit in verschiedenen Netzen erwähnenswert. Insgesamt ist FireWall-1 das wohl flexibelste der hier getesteten Produkte und eignet sich sowohl für große Intranets als auch für zukünftige Anwendungen hinsichtlich IPv6. Für den Einsatz in kaskadierten Intranets und VPNs sollte TLS/SSL und die Unterstützung von ISAKMP/Oakley implementiert werden. Die Verwirklichung der Rolle des Revisors, sowie Integritätstests der eingesetzten Programme und der sichere Pfad zwischen Administration und Komponenten würden die FireWall-1 weiter verbessern. Dies ist in Version 3.x vorgesehen. Entgegen den Angaben des Herstellers war es nicht möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. Außerdem ist keine Einschränkung der Protokollierung möglich und IP-Nummern werden nicht protokolliert. Hervorzuheben ist die ausführliche Dokumentation und die Existenz von Manual-Pages. Der Preis der Firewall-1 liegt bei DM 6.690,- (< 25 User), DM 11.900 (< 50 User), DM 15.990,- (< 100 User), DM 19.990,(unlimited). Hinzu kommen Wartung, Installation und Schulung. Der Aufwand für die Administration pro Tag liegt bei ca. 1h, für die Inbetriebnahme bei einem Tag. Kontaktadresse: http://www.bristol.de.
11.09.97
Firewall-Studie
Seite 149
SIEMENS
Test ausgewählter Firewallprodukte
6.1.4 Gauntlet Version 3.2 der Firma TIS (D)+(P) Gauntlet basiert auf dem TIS Firewall Toolkit und wählt den Ansatz Applikationsfilter mit integriertem Paketfilter, wobei jedoch der Einsatz des Paketfilters in der Dokumentation nicht empfohlen wird. TIS empfiehlt stattdessen, einen Paketfilter eines anderen Herstellers vor den Applikationsfilter zu installieren. 1. 2. 3.
4. 5.
6. 7. 8. 9.
10. 11. 12. 13. 14. 15. 16.
17. 18.
19.
20. 21. 22.
Die Identifikation und Authentisierung ist über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole) möglich. (ä) (P) Die Rolle des Revisors ist nicht vorgesehen. (x) (P) Bei einem Ausfall einer Protokollierungskomponente wird keine Warnung an den Administrator ausgegeben. Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (x) (D) Integritätstests der eingesetzten Programme werden von der Gauntlet angeboten. (ä) (D) Es ist möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. Falls Komponenten (z.B. Proxies) abstürzen, wird die Funktion generell verweigert, die von diesen Komponenten bedient wird. Bei der zentralen Komponente der Firewall, die Verbindungsaufbauwünsche erlaubt oder ablehnt, resultiert ein Absturz in ein generelles „DENY“ aller Verbindungsaufbauwünsche. Dann ist die Firewall nur noch zur Administration erreichbar. (ä) (P) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist. Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (x) (P) Die Firewall besteht nicht aus zwei getrennten Filtern, sondern aus einem Applikationsfilter. (x) (P) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) (P) Die Struktur des zu schützenden Netzes kann durch den Einsatz der Gauntlet als Applikationsfilter und zweier DNS-Server verdeckt werden, wobei ein DNS-Server extern hinter einem Paketfilter und ein DNSServer intern hinter dem Applikationsfilter aufgestellt wird, und diese Informationen nur über einen Applikationsfilter austauschen können (sog. splitted DNS-Server). Dadurch können DNS-Requests von einem unbekannten Rechner verhindert oder zu einem bestimmten DNS-Server umgeleitet werden. Ferner kann die Struktur des internen Netzes durch Network Address Translation verdeckt werden. (ä) (D) Für die Verwaltung der Komponenten existiert eine GUI. (ä) (P) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. (ä) (P) Der Aufbau von Verbindungen auf der Anwendungsschicht kann durch die Firewall benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) (D) Zur Benutzeridentifikation werden starke Authentisierungsmethoden angeboten. (ä) (D) Mehrere Benutzer können zu einer Gruppe zusammengefaßt werden. (ä) (D) Die Filterregeln können nicht auf ihre Widerspruchsfreiheit überprüft werden. (x) (P) Standardprotokolle wie Telnet, FTP, SMTP, DNS, NNTP und HTTP werden durch Proxies unterstützt. Zusätzlich existieren Proxies für RealAudio, X11 und syslog. Ein generischer Proxy ist ebenfalls vorhanden. Telnet und FTP wurden überprüft. (ä) (P) Für Telnet-Verbindungen vom Internet zur Firewall kann durch zusätzliche Prozesse (z.B. Knüpfen eines VPNs) eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. (ä) (D) Für Verbindungen auf der Anwendungsschicht können alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (post bei HTTP) bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) (D) Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht kann eine Protokollierung von Benutzeridentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. (ä) (D) Die Protokollierung kann auf bestimmte Verbindungen eingeschränkt werden. (ä) (D) Spezielle einstellbare Protokollmeldungen führen zu einer unverzüglichen Warnung. (ä) (D) Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden (nur via syslog). (x) Bei der Benutzung von FTP ist es möglich, den Verbindungsaufbau für die Datenverbindung (FTP-DATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (ä) (D)
Seite 150
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
23. Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze, wegen der fehlenden Paketfilterfunktionalität jedoch nicht abhängig von Quell- und Zielport für TCP oder UDP erlaubt oder verboten werden. (ä/x) (P) 24. Die Filterung gemäß voriger Forderung getrennt für jedes Interface ist nicht relevant, da Gauntlet kein Paketfilter ist. (ä) (P) 25. Die Reihenfolge der Filterregeln wird nicht verändert (ä) (D) 26. Eine Filterung getrennt für kommende und gehende Pakete, wenn mehr als zwei Interfaces vorhanden sind, ist möglich. (ä) (P) 27. Eine Unterscheidung zwischen ACK und ACK-losen Paketen bei TCP-Paketen ist nicht relevant. (m) 28. Die Protokollierung von IP-Nummer, Dienst, Zeit und Datum ist nicht für jedes Paket möglich. (x) (P) 29. Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) (D) 30. Source-Routing Informationen werden standardmäßig abgewiesen. (ä) (D) 31. Die Firewall verlangt keine Mindestgröße an Fragmentlänge. Fragmentierungsangriffe werden jedoch durch Reassemblieren vor der Untersuchung abgewendet. (x) (D) 32. Die Firewall schreibt kein Minimum an Fragment-Offset vor (s.o.). (x) (D) 33. Die ICMP-Meldung Destination Unreachable wird abgewiesen, da ICMP nicht unterstützt wird. (ä) (P) 34. Die ICMP-Meldung Redirect wird aus dem gleichen Grund abgewiesen. (ä) (D) 35. Inverse DNS-Anfragen können durch den Ansatz „splitted DNS-Server“ abgewiesen werden. (ä) (D) 36. Zonen-Transfer-Requests von einem unbekannten Host können mit REFUSED beantwortet werden. (ä) (D) 37. ARP-Tabellen können unter UNIX durch den Befehl arp – s fixiert werden. (ä) (P) 38. Das automatische Ablaufen von ARP kann unterbunden werden. (ä) (P) 39. Die Gauntlet FTP-Proxy schützt die Befehle STOR, GET, CWD, CDUP, LIST und SITE, indem er per deny oder allow authentifizierten Benutzern Rechte erteilt. (ä) (D) 40. Eingehende Telnet-Daten können auf Port 23 nicht abgewiesen werden. (x) (D) 41. S-HTTP-Daten können vom HTTP-Proxy erkannt und abgewiesen werden. (ä) (D) 42. Die Gauntlet bietet keine dynamische Paketfilterfunktionalität. Somit können dynamische Ports nicht verfolgt werden. (x) (P) 43. Es können die Netzobjekte Host und Subnet definiert werden. VPN-Objekte, Domain, Group und IPRange können als Netzobjekte nicht definiert werden. (ä) (D) 44. Spoof-Checking wird durchgeführt. (ä) (P) 45. Ping-to-Death kann vom darunterliegenden Betriebssystem abgefangen werden. (ä) (P) 46. TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. Dies wurde mit dem ISS überprüft. (ä) (P) 47. Ein Anti-Virus-Checker ist nicht integriert. (x) (D) 48. Fragmentierte Pakete werden zunächst zusammengesetzt und anschließend untersucht. (ä) (D) 49. Session-Hijacking wird verhindert, indem ein Proxy die Verbindung zum internen Zielhost aufbaut. (ä) (D) 50. TCP-Sequence-Number-Guessing wird durch den Proxy-Ansatz verhindert. (ä) (D) 51. Illegal Address Support ist möglich. (ä) (D) 52. Die Administration der Firewall kann durch die in 82 aufgeführten Authentisierungsmechanismen geschützt werden. (ä) (D) 53. IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) (P) 54. Die Gauntlet kann zentral fernadministriert werden. Die Kommunikation des Administrators mit der Firewall ist durch Verschlüsselung geschützt. (ä) (D) 55. Die verwendeten Verschlüsselungsverfahren unterliegen den US-Exportrestriktionen. (ä) (D) 56. Das Key Management erfolgt durch manuelle Schlüsselverteilung. Der Hersteller machte keine genaueren Angaben. (k.a.) 57. Die Verbindung zu einem externen Rechner kann von der Gauntlet durch Knüpfen eines VPNs geschützt werden. (ä) (D) 58. Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) (D) 59. Für die Authentisierung von Benutzern beliebiger Anwendungen ist eine Client Authentication für TCP, jedoch nicht für UDP und RPC möglich. (x) (D) 60. Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) (P) 61. Eine Authentisierung ist pro Sitzung möglich. (ä) (D) 11.09.97
Firewall-Studie
Seite 151
SIEMENS
Test ausgewählter Firewallprodukte
62. Die Verschlüsselung erfolgt mit dem 56 Bit DES-Algorithmus im CBC-Modus oder DES-3 mit Key Recovery. Zur Authentisierung und Überprüfung der Integrität wird der Keyed MD5 verwendet. (ä) (D) 63. Sitzungsschlüssel können vom Administrator jederzeit manuell geändert werden. (ä) (D) 64. Zusätzlich zu den Standarddiensten werden die Dienste OSPF, r-Kommandos, DNS und WAIS angeboten. Nicht angeboten werden die Dienste NFS, NIS, RPC, RIP und SNMP. (ä) (D) 65. BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. (ä) (D) 66. Die RIP-Meldung Loose-Source-Routing wird abgewiesen, da RIP nicht unterstützt wird. Dies wurde mit dem ISS überprüft (ä) (P) 67. Die Firewall kann transparent betrieben werden. (ä) (D) 68. Eine On-line Hilfe ist vorhanden. (ä) (P) 69. Für den Betrieb der Firewall ist keine proprietäre Hardware notwendig. (ä) (P) 70. Der Aufwand für Installation beträgt ca. 4 Stunden zuzüglich Regelerstellung. (P) 71. Der Preis für die Gauntlet in der Version 3.2 beträgt DM 21.905,-. In der Version 4.0 beträgt der Preis je nach Benutzeranzahl DM 9.650,- (weniger als 51 Benutzer), DM 21.950,- (51 - 250 Benutzer), DM 32.750,- (> 250 Benutzer). 72. Zum Aufwand für den Betrieb der Firewall hat der Hersteller keine Angaben gemacht. (k.a.) 73. Für Installation und Wartung wird Support angeboten. (ä) (D) 74. Versionspflege wird betrieben. (ä) (D) 75. Zur Filterung werden die Regelarten allow, deny und drop angeboten. (ä) (P) 76. Gauntlet bietet zusätzlich Proxies für die Dienste Oracle SQL Net, RealAudio, X11, Finger, whois und syslog an. (ä) (D) 77. Die Alarmierung des Administrators erfolgt über E-mail. (ä) (D) 78. Protokollinformationen können an einen externen Host gesendet werden (z.B. automatisch per e-mail). (ä) (D) 79. Die Gauntlet ist für die Plattformen Solaris, SunOS, BSD und HP-UX verfügbar. Es gibt auch eine SGI TRIX Version. Die Gauntlet wurde auf Solaris getestet. (ä) (P) 80. Router werden nicht unterstützt. (x) (D) 81. Netzkarten sind für die Netze SLIP, PPP, Ethernet, Fast Ethernet, Token Ring, X.25 und FDDI vorgesehen. (ä) (D) 82. Zur Benutzeridentifikation werden die Authentisierungsmethoden Access Key, APOP, Defender Security System, Digipass, Safeword Authentication Server, SecureNet, SecureID, S/Key und Reusable Passwords angeboten. (ä) (D) 83. Modem-Verbindungen können nicht gesichert werden. (x) (D) 84. Andere Protokolle wie IPX oder DECNET werden nicht unterstützt. (x) (D) 85. Network Address Translation ist möglich. (ä) (D) 86. An ausführbarem Code kann JAVA und ActiveX gefiltert werden. (ä) (D) 87. Ausführbarer Code wird in FTP oder anderen Datenübertragungsprotokollen nicht gefiltert. (x) (D) 88. Die Gauntlet unterstützt kein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integieren. (x) (D) 89. Logfiles können automatisch ausgewertet werden. (ä) (D) 90. VPNs können durch TLS/SSL geknüpft werden. (ä) (D) 91. Eine synchronisierte Zustandsübermittlung zwischen mehreren Firewalls ist nicht möglich. (x) (D) 92. Mehrere Firewalls können mit dem Zusatzprodukt Gauntlet NetExtender zentral administriert werden. (ä) (D) 93. Die Kommunikation mit einer Zertifizierungsstelle wird nicht unterstützt. (x) (D) 94. An aktuellen Standards wird lediglich TLS/SSL unterstützt. IPSec, SKIP, RADIUS, ISAKMP/Oakley und TACACs werden nicht unterstützt. (x) (D) 95. Ein generischer Proxy ist vorhanden. (x) (D) 96. Die eingesetzten Programme sind nicht ausreichend dokumentiert. (x) (P) 97. Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation der Firewall nicht notwendig. (ä) (P) 98. Multicast-Pakete werden nicht unterstützt. (x) (D) Version 4.0 TIS bietet ab Juli 97 die Gauntlet in der Version 4.0 an. Darin sind folgende Erweiterungen implementiert: • Es werden zusätzliche Proxies für SNMP, Xing Streaming, H.323 für MS Netmeeting, Netshow, VDO angeboten. Seite 152
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
• Anti-Virus-Scanning wird durch Integration von Fremdprodukten (McAfee, Symantec, TrendMicro) unterstützt, dadurch ist ausführbarer Code auch in FTP, HTTP und Gopher erkennbar. • Authenticode Software für Java/ActiveX (d.h. nur „signed applets“ werden durch die Firewall geschleust). • Audit-Tools (Telemate) und Intrusion Detection Software (Axent Omniguard) werden unterstützt. • HP OpenView wird unterstützt. • Darüberhinaus wird über ein Zusatzprodukt Verschlüsselung nach IPSec mit Unterstützung des ISAKMP/Oakley und Kommunikation mit einer Zertifizierungsauthorität unterstützt. Fazit In der Version 4.0 wird die für zukünftige Einsatzmöglichkeiten wie VPNs und kaskadierte Intranets wichtige Unterstützung des ISAKMP/Oakley bereits angeboten. Auch die Kommunikation mit einer Zertifizierungsinstanz spielt in den zukünftigen Szenarien eine wichtige Rolle und wird in der Version 4.0 abgedeckt. Von der Möglichkeit, signierte ActiveX-Controls durch eine Firewall zu schleusen, ist in den Bedrohungen zu ActiveX bereits abgeraten worden. ActiveX-Controls können jedoch vollständig abgeschaltet werden. Um den Administrator zu entlasten, sind Audit-Tools und Intrusion Detection Software in Zukunft wichtig. MIME sollte erkannt werden. Ein dynamischer Paketfilter würde die Gauntlet verbessern. Daß Gauntlet das Anwenden der Paketfilterfunktionalität nicht empfiehlt und dennoch anbietet, verwirrt den Administrator der Gauntlet unnötig. Man kann von TIS den Source Code der Gauntlet erhalten. Durch diesen sogenannten Crystal Box Approach kann man sich selbst von der Wirkungsweise bzw. Sicherheit der Firewall-Software überzeugen oder Erweiterungen vornehmen. Kontaktadresse: Trusted Information Systems GmbH, Stefan-George-Ring 29, 81929 München. http://www.tis.com.
11.09.97
Firewall-Studie
Seite 153
SIEMENS
Test ausgewählter Firewallprodukte
6.1.5 KarlBridge Version 2.0 der Firma KarlNet (D) KarlBridge ist ein Router mit statischer Paketfilterfunktionalität. 1. 2. 3.
4. 5.
6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
19.
20. 21. 22.
23.
24. 25. 26.
Die Identifikation und Authentisierung ist über einen vertrauenswürdigen Pfad (z.B. die Einschränkung des Zugriffs auf die Konsole) möglich. (ä) Die Rolle des Revisors ist nicht vorgesehen. (x) Bei einem Ausfall einer Protokollierungskomponente wird keine Warnung an den Administrator ausgegeben. Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (x) Integritätstests der eingesetzten Programme werden von der KarlBridge nicht angeboten. (x) Es ist möglich, die KarlBridge so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. Falls Komponenten (z.B. Paketfilterkomponente) abstürzen, wird die Funktion generell verweigert, die von diesen Komponenten bedient wird. Bei der zentralen Komponente der Firewall, die Verbindungsaufbauwünsche erlaubt oder ablehnt, resultiert ein Absturz in ein generelles „DENY“ aller Verbindungsaufbauwünsche. Dann ist die Firewall nur noch zur Administration erreichbar. (ä) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist. Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (x) Die KarlBridge besteht nicht aus zwei getrennten Filtern, sondern aus einem Paketfilter. (x) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) Die Struktur des zu schützenden Netzes kann nicht verdeckt werden. (x) Für die Verwaltung der Komponenten existiert eine GUI. (ä) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch die Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. (ä) Der Aufbau von Verbindungen auf der Anwendungsschicht kann nicht durch die Firewall benutzer- und zeitabhängig erlaubt oder verboten werden. (x) Zur Benutzeridentifikation werden Authentisierungsmethoden angeboten. Über die Methoden hat der Hersteller keine Angaben gemacht. (x) Mehrere Benutzer können zu einer Gruppe zusammengefaßt werden. (ä) Die Filterregeln können nicht auf ihre Widerspruchsfreiheit überprüft werden. (x) Die Protokolle Telnet, FTP, SMTP, HTTP, NNTP und RLOGIN können auf Vermittlungs- und Transportebene gefiltert werden. DNS kann nicht gefiltert werden. (ä) Für Telnet-Verbindungen vom Internet zur Firewall kann durch zusätzliche Prozesse (z.B. Knüpfen eines VPNs) eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. (ä) Für Verbindungen auf der Anwendungsschicht können Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (z.B. post bei HTTP) bewirken, nicht benutzer- und zeitabhängig erlaubt oder verboten werden. (x) Für aufgebaute und abgewiesene Verbindungen auf der Anwendungsschicht können keine Protokollierung von Benutzeridentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. (x) Die Protokollierung kann nicht auf bestimmte Verbindungen eingeschränkt werden. (x) Spezielle einstellbare Protokollmeldungen können nicht zu einer Warnung führen. (x) Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden (nur via syslog). (x) Bei der Benutzung von FTP ist es nicht möglich, den Verbindungsaufbau für die Datenverbindung (FTP-DATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (x) Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze und abhängig von Quell- und Zielport für TCP, jedoch nicht für UDP erlaubt oder verboten werden. (ä/x) Die Filterung ist gemäß voriger Forderung für jedes Interface getrennt möglich. (ä) Die Reihenfolge der Paketfilterregeln wird nicht automatisch vom Paketfilter verändert. (ä) Eine Filterung ist getrennt für kommende und gehende Pakete möglich, wenn mehr als zwei Interfaces vorhanden sind. (ä)
Seite 154
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
27. Bei TCP-Paketen ist eine Unterscheidung zwischen ACK und ACK-losen Paketen möglich. (ä) 28. Die Protokollierung von IP-Nummer, Dienst, Zeit und Datum ist für jedes Paket möglich. (ä) 29. Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) 30. Source-Routing Informationen werden standardmäßig abgewiesen. (ä) 31. Die Paketfilterkomponente verlangt keine Mindestgröße an Fragmentlänge. (x) 32. Die Paketfilterkomponente schreibt kein Minimum an Fragment-Offset vor. (x) 33. Die ICMP-Meldung Destination Unreachable wird abgewiesen, da ICMP generell abgewiesen wird. (ä) 34. Ebenso wird die ICMP-Meldung Redirect abgewiesen. (ä) 35. Inverse DNS-Anfragen können nicht abgewiesen werden. (x) 36. Zonen-Transfer-Requests von einem unbekannten Host können nicht mit REFUSED beantwortet werden. (x) 37. ARP-Tabellen können nicht fixiert werden. (x) 38. Das automatische Ablaufen von ARP kann nicht unterbunden werden. (x) 39. FTP-Befehle wie CWD, CDUP, LIST und SITE können nicht an eine Rechteverwaltung gebunden werden. 40. Eingehende Telnet-Daten können auf Port 23 abgewiesen werden. (ä) 41. S-HTTP-Daten können nicht erkannt und abgewiesen werden. (x) 42. Karlbridge bietet keine dynamische Paketfilterfunktionalität. Somit können keine dynamischen Ports verfolgt werden. (x) 43. Netzobjekte können nicht definiert werden. (x) 44. Spoof-Checking wird durchgeführt. (ä) 45. Ping-to-Death wird abgewendet, da Ping generell abgewiesen wird. (ä) 46. TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. (ä) 47. Ein Anti-Virus-Checker ist nicht integriert. (x) 48. Fragmentierte Pakete werden nicht durch den KarlBridge zusammengesetzt. (x) 49. Session-Hijacking wird nicht verhindert. (x) 50. TCP-Sequence-Number-Guessing wird nicht verhindert. (x) 51. Illegal Address Support ist nicht möglich. (x) 52. Die Administration des Karlbridge ist lediglich durch ein Paßwort geschützt. (x) 53. IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) 54. Die KarlBridge kann nicht zentral fernadministriert werden. Die Kommunikation des Administrators mit der Firewall ist nicht durch Verschlüsselung geschützt. (x) 55. Die verwendeten Verschlüsselungsverfahren unterliegen den US-Exportrestriktionen. (x) 56. Zum Key Management hat der Hersteller keine Angaben gemacht. (k.a.) 57. Die Verbindung zu einem externer Rechner kann von dem KarlBridge durch Verschlüsselung und Authentisierung geschützt werden. Zur Art der Authentisierung hat der Hersteller keine Angaben gemacht. (k.a.) 58. Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) 59. Für die Authentisierung von Benutzern auf Anwendungsebene ist nicht möglich. (x) 60. Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) 61. Eine Authentisierung ist pro Sitzung möglich. (ä) 62. An kryptographischen Algorithmen werden DES und Keyed MD5 verwendet. (ä) 63. Über die Möglichkeit, Sitzungsschlüssel wechseln zu können, hat der Hersteller keine Angaben gemacht. (k.a.) 64. Die Dienste NFS, NIS, RPC, RIP, DNS, WAIS, r-Kommanods, SNMP und OSPF werden nicht angeboten. (x) 65. BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. (ä) 66. Die RIP-Meldung Loose-Source-Routing wird wie alle RIP-Meldungen abgewiesen. (ä) 67. Der KarlBridge kann nicht transparent betrieben werden. (x) 68. Eine On-line Hilfe ist nicht vorhanden. (x) 69. Für den Betrieb der Firewall ist proprietäre Hardware notwendig. (x). 70. Über den Aufwand für Installation des KarlBridge hat der Hersteller keine Angaben gemacht. (k.a.) 71. Der KarlBridge Router ist inklusive Hardware und Verschlüsselung ab DM 3.500 erhältlich. 72. Über den Aufwand für den Betrieb des KarlBridge hat der Hersteller keine Angaben gemacht. (k.a.) 73. Für Installation und Wartung wird Support angeboten. (ä)
11.09.97
Firewall-Studie
Seite 155
SIEMENS 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98.
Test ausgewählter Firewallprodukte
Versionspflege wird betrieben. (ä) Zur Filterung werden die Regelarten allow, deny und drop angeboten. (ä) KarlBridge verwendet keine dedizierten Proxies. (m) Eine Alarmierung des Administrators ist nicht vorgesehen. (x) Protokollinformationen können an einen externen Host gesendet werden (z.B. automatisch per e-mail). (ä) Der KarlBridge ist ein Router mit proprietärer betriebssystemunabhängiger Hardware. (x) Weitere Router werden nicht unterstützt. (x) KarlBridge ist für die Netze Ethernet, Token Ring, X.25 und FDDI erhältlich. (ä) Über die Authentisierungsmethoden hat der Hersteller keine Angaben gemacht. (k.a.) Modem-Verbindungen werden nicht gesichert. (x) Es werden Schnittstellen für IP-Netze, Apple-Netze, DECNET und Novell-Netze angeboten. (ä) Network Address Translation ist nicht möglich. (x) Ausführbarer Code kann nicht gefiltert werden. (x) Ausführbarer Code wird in FTP oder anderen Datenübertragungsprotokollen nicht gefiltert. (x) KarlBridge unterstützt kein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integieren. (x) Logfiles können nicht automatisch ausgewertet werden. (x) VPNs können proprietär geknüpft werden. (x) Eine synchronisierte Zustandsübermittlung zwischen mehreren KarlBridges ist nicht möglich. (x) Dadurch können mehrere KarlBridges nicht zentral administriert werden. (x) Die Kommunikation mit einer Zertifizierungsstelle wird nicht unterstützt. (x) Aktuelle Standards werden nicht unterstützt. (x) Ein generischer Proxy ist nicht vorhanden. (x) Die eingesetzten Programme sind nicht ausreichend dokumentiert. (x) Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation des KarlBridge nicht notwendig. (x) Multicast-Pakete werden unterstützt. (ä)
Fazit Als Router mit statischer Paketfilterfunktionalität erfüllt KarlBridge sehr wenige Kriterien und sollte daher nicht als Firewall für Szenarien, die eine erhöhte Sicherheit verlangen, zum Einsatz kommen. Vorstellbar ist, daß KarlBridge als Paketfilter vor und hinter einen Applikationsfilter installiert wird, um so ein Screened Subnet aufzubauen, dessen Paketfilter von einem anderen Hersteller als der Applikationsfilter ist. Kontaktadresse: http://www.gbnet.net/kbridge
Seite 156
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
6.1.6 KryptoWall Version 2.0 der Firma KryptoKom (D) Die Firewall KryptoWall bildet ein Screened Subnet, das sich aus den Komponenten Paket-Filter, Applikationsfilter (als Dual-homed Applikationsfilter), Security Management Station (SMS) und einem oder mehreren Information Servern zusammensetzt. Die Paket-Filter stehen vor und hinter dem Applikationsfilter und bilden ein entkoppeltes, isoliertes Teilnetzwerk, das zwischen das zu schützende Netz und das unsichere Netz geschaltet wird. Die Paketfilter sind physikalisch durch LAN-Boxen, der Applikationsfilter durch eine Workstation realisiert. Innerhalb des geschützten Netzes befindet sich die Security Management Station, die durch eine zusätzliche LAN-Box gesichert ist. Diese Security Management Station ermöglicht eine zentrale Administration mehrerer Firewalls gleichzeitig. Die eigentliche Verschlüsselung der Pakete erfolgt auf den LANBoxen. 1. 2. 3.
4. 5.
6. 7. 8. 9.
10. 11. 12. 13. 14. 15. 16.
17. 18.
11.09.97
Die Identifikation und Authentisierung ist über einen vertrauenswürdigen Pfad (z.B. durch die Einschränkung des Zugriffs auf die Konsole) möglich. (ä) Die Rolle des Revisors ist vorgesehen. (ä) Bei einem Ausfall einer Protokollierungskomponente wird eine Warnung an den Administrator ausgegeben. Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (ä) Integritätstests der eingesetzten Programme werden von der KryptoWall angeboten. (ä) Es ist möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. Falls Komponenten (z.B. Proxies) abstürzen, wird die Funktion generell verweigert, die von diesen Komponenten bedient wird. Bei der zentralen Komponente der Firewall, die Verbindungsaufbauwünsche erlaubt oder ablehnt, resultiert ein Absturz in ein generelles „DENY“ aller Verbindungsaufbauwünsche. Dann ist die Firewall nur noch zur Administration erreichbar. (ä) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist. Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (x) Die Firewall besteht nicht aus zwei getrennten Filtern und einem Applikationsfilter. (ä) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) Die Struktur des zu schützenden Netzes kann durch den Einsatz der KryptoWall und durch einen gesplitteten Ansatz im Applikationsfilter (einen internen DNS-Server hinter dem Applikationsfilter und einen externen DNS-Server vor dem Applikationsfilter im Screened Subnet) gesichert werden. Die Server sind nicht Bestandteil der KryptoWall. Informationen können also nur von dem Applikationsfilter mittels eines „splitted DNS-Resolvers“ abgeholt werden. (ä) Für die Verwaltung der Komponenten existiert eine GUI. (ä) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch die Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. (ä) Der Aufbau von Verbindungen auf der Anwendungsschicht kann durch die Firewall benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) Zur Benutzeridentifikation werden starke Authentisierungsmethoden angeboten. (ä). Mehrere Benutzer können zu einer Gruppe zusammengefaßt werden. Es können die Netzobjekte Host und Subnet definiert werden. VPN-Objekte können nicht definiert werden. (ä) Die Filterregeln können auf ihre Widerspruchsfreiheit überprüft werden. (ä) Die Protokolle Telnet, FTP, SMTP, HTTP, RLOGIN, NNTP und DNS können abgesichert werden. Die KryptoWall bietet keine Proxies für neuere Dienste wie SQL, RealAudio oder Citrix an. Ein X11-Proxy ist nicht vorhanden. Diese Dienste können durch die generischen (TCP- und UDP-) Proxies zur Verfügung gestellt werden. Der generische TCP-Proxy bietet Authentisierung. Der Finger-Dienst kann durch einen speziell angepaßten Dämon auf der Bastion realisiert werden, welcher alle notwendigen Informationen (zu editierende Datei auf der Bastion) des internen Netzes extern zur Verfügung stellt. (ä) Für Telnet-Verbindungen vom Internet zur Firewall kann durch zusätzliche Prozesse (z.B. Knüpfen eines VPNs) eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. (ä) Für Verbindungen auf der Anwendungsschicht können alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (z.B. post bei HTTP) bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden. (ä)
Firewall-Studie
Seite 157
SIEMENS
Test ausgewählter Firewallprodukte
19. Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht kann eine Protokollierung von Benutzeridentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. (ä) Die Protokollierung kann auf bestimmte Verbindungen eingeschränkt werden. (ä) 20. Spezielle einstellbare Protokollmeldungen führen zu einer unverzüglichen Warnung. (ä) 21. Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden. (x) 22. Bei der Benutzung von FTP ist es möglich, den Verbindungsaufbau für die Datenverbindung (FTPDATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (ä) 23. Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze und abhängig von Quell- und Zielport für TCP, wegen des nicht dynamischen Paketfilters jedoch nicht für UDP erlaubt oder verboten werden. (ä/x) 24. Die Filterung ist gemäß voriger Forderung für jedes Interface getrennt möglich. (ä) 25. Die Reihenfolge der Paketfilterregeln wird nicht automatisch vom Paketfilter verändert. (ä) 26. Eine Filterung ist getrennt für kommende und gehende Pakete möglich, wenn mehr als zwei Interfaces vorhanden sind. (ä) 27. Bei TCP-Paketen ist eine Unterscheidung zwischen ACK und ACK-losen Paketen möglich. (ä) 28. Die Protokollierung von IP-Nummer, Dienst, Zeit und Datum ist für jedes Paket möglich. (ä) 29. Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) 30. Source-Routing Informationen werden standardmäßig abgewiesen. (ä) 31. Die Paketfilterkomponente verlangt keine Mindestgröße an Fragmentlänge, wendet aber den TinyFragment-Angriff durch die Möglichkeit, IP-Forwarding an- und abzuschalten, ab. (ä) 32. Die Paketfilterkomponente schreibt kein Minimum an Fragment-Offset vor, wendet aber auch diesen Angriff durch An- bzw. Abschalten des IP-Forwardings ab. (ä) 33. Die ICMP-Meldung Destination Unreachable wird wie gesamt ICMP abgewiesen. (ä) 34. Aus dem gleichen Grund wird die ICMP-Meldung Redirect abgewiesen. (ä) 35. Inverse DNS-Anfragen können durch den Ansatz „splitted DNS-Server“ abgewiesen werden. (ä) 36. Zonen-Transfer-Requests von einem unbekannten Host können mit REFUSED beantwortet werden. (ä) 37. ARP-Tabellen können fixiert werden. (ä) 38. Das automatische Ablaufen von ARP kann nicht unterbunden werden. (x) 39. Die FTP-Befehle CWD, CDUP, LIST und SITE können an eine Rechteverwaltung gekoppelt werden. (ä) 40. Eingehende Telnet-Daten können auf Port 23 abgewiesen werden. (ä) 41. S-HTTP-Daten können vom HTTP-Proxy nicht erkannt und somit nicht abgewiesen werden. (x) 42. Die KryptoWall bietet keine dynamische Paketfilterfunktionalität. Somit können dynamische Ports nicht verfolgt werden. (x) 43. Es können die Netzobjekte Host und Subnet definiert werden. (ä) 44. Spoof-Checking wird durchgeführt. (ä) 45. Ping-to-Death kann vom darunterliegenden Betriebssystem abgefangen werden. (ä) 46. TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. (ä) 47. Ein Anti-Virus-Checker ist nicht integriert. Er kann mit einem separaten Host zwischen Applikationsfilter und internem Paketfilter realisiert werden. (ä) 48. Fragmentierte Pakete werden zunächst zusammengesetzt und anschließend untersucht. (ä) 49. Session-Hijacking wird verhindert. (ä) 50. TCP-Sequence-Number-Guessing wird durch den Ansatz Screened Subnet verhindert. (ä) 51. Illegal Address Support nicht durch das Firewallsystem selbst realisiert, sondern durch von KryptoKom gestellte zusätzliche Komponenten. (x) 52. Die Administration der Firewall ist lediglich durch starke Authentisierungsmethoden geschützt. Die Zugänge zur SMS, dem Serviceport des SMS und der Konsole der Bastion sind remote ansprechbar. Die Fernzugänge sind durch ein kryptographisches Authentisierungsprotokoll geschützt. (ä) 53. IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) 54. Die KryptoWall kann zentral fernadministriert werden. Die Kommunikation des Administrators mit der Firewall ist durch Verschlüsselung geschützt. (ä) 55. Die verwendeten Verschlüsselungsverfahren unterliegen nicht den US-Exportrestriktionen. (ä)
Seite 158
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
56. Schlüssel werden auf Chipkarten manuell in die LAN-Boxen gebracht. Die Personalisierung der LANBoxen beinhaltet die Generierung eines System-Master-Keys (SMK) und eines Verbindungsschlüsselsatzes für jede LAN-Box (die Verbindungsschlüssel sind identisch), welche über ein serielles Kabel von der SMS auf die LAN-Boxen übertragen werden. Der SMK wird hierbei im Verschlüsselungsbaustein gespeichert. Verbindungsschlüssel können im laufenden Betrieb gewechselt werden, wobei dieser Vorgang von der SMS eingeleitet wird. Dieser Vorgang ist auch automatisiert möglich. Die Verbindungssschlüssel werden auf der SMS generiert. (ä) 57. Zur Sicherung einzelner Rechner wie auch kompletter LAN-Segmente stehen KryptoGuard-LAN-Boxen zur Verfügung. Zur Sicherung von mobilen Rechnern steht das Produkt KryptoGuard-PC zur Verfügung. Diese Lösung besteht aus einer reinen Softwarelösung oder einer Verschlüsselungskarte mit Software. Hierbei wird in das Betriebssystem des externen Rechners ein IP-Paketfilter mit Verschlüsselungsmöglichkeit integriert. Die benötigten Schlüssel und Filterinformationen können auf der SMS generiert und mittels Diskette auf das Endsystem übertragen werden. (ä) 58. Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) 59. Für die Authentisierung von Benutzern beliebiger Anwendungen ist eine Client Authentication für TCP, jedoch nicht für UDP und RPC möglich. (x) 60. Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) 61. Eine Authentisierung ist pro Sitzung möglich. (ä) 62. Die Verschlüsselung der Pakete erfolgt mit Hilfe des DES-Verfahrens im CBC-Modus mit 64 Bit, 2fach DES oder Triple-DES sind ebenfalls möglich. Andere S-Boxen36 können in die LAN-Boxen geladen werden. (ä) 63. Sitzungsschlüssel können von der SMS oder automatisiert alle zwei Minuten gewechselt werden. (ä) 64. Neben den Standarddiensten werden lediglich die Dienste DNS und WAIS angeboten. Die Dienste NFS, NIS, RPC, RIP, OSPF, r-Kommandos und SNMP werden nicht angeboten. In einer Folgeversion soll RPC angeboten werden können. (x) 65. BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. (ä) 66. RIP wird nicht unterstützt. Somit wird die RIP-Meldung Loose-Source-Routing abgewiesen. (ä) 67. Die Firewall kann transparent betrieben werden. (ä) 68. Eine On-line Hilfe ist vorhanden. (ä) 69. Für den Betrieb der Firewall ist proprietäre Hardware notwendig. (ä) 70. Über den Aufwand für die Installation hat der Hersteller keine Angaben gemacht. 71. Der Preis für die KryptoWall inklusive Hardware beträgt in der zertifizierten Version DM 220.000,72. Über den Aufwand für den Betrieb hat der Hersteller keine Angaben gemacht. 73. Für Installation und Wartung wird Support angeboten. (ä) 74. Versionspflege wird betrieben. (ä) 75. Zur Filterung wird die Regelart allow angeboten. (ä) 76. Zusätzlich zu den Standardproxies existiert ein dedizierter Finger-Proxy. (ä) 77. Die Alarmierung des Administrators erfolgt über E-mail oder Audio. (ä) 78. Protokollinformationen können an einen externen Host gesendet werden (z.B. automatisch per e-mail). (ä) 79. Die KryptoWall besteht aus dedizierter betriebssystemunabhängiger Hardware. (x) 80. Router werden nicht unterstützt. (x) 81. Die KryptoWall ist für die Netze Ethernet, Fast Ethernet und Token Ring vorgesehen. Die Anbindung an nicht Ethernet basierende Netze kann über Router erfolgen. Dabei ist jedoch die Begrenzung der Funktionalität auf das Notwendigste erforderlich. (ä) 82. Zur Benutzeridentifikation werden die Authentisierungsmethoden S/Key, Reusable Passwords und AuthentiCard angeboten. (ä). 83. Modem-Verbindungen können durch das Vorschalten einer LAN-Box gesichert werden. (ä) 84. Andere Protokolle wie IPX oder DECNET können nicht unterstützt werden. (x) 85. Network Address Translation ist möglich. (ä) 86. Ausführbarer Code kann nicht gefiltert werden. ActiveX und JAVA sollen in der Nachfolgeversion gefiltert werden können. (x) 87. Ausführbarer Code kann nicht in Datenübertragungsprotokollen gefiltert werden.
36
Die Substitution-Boxen schreiben die Permutationen der Bits vor. Diese sind z.B. beim DES standardisiert. Daneben können hier andere Softwareimplementationen von S-Boxen geladen werden. 11.09.97
Firewall-Studie
Seite 159
SIEMENS
Test ausgewählter Firewallprodukte
88. Die KryptoWall unterstützt kein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integieren. (x) 89. Logfiles können nicht automatisch ausgewertet werden. Dies wird jedoch geplant. (x) 90. VPNs mit anderen Herstellern können nicht geknüpft werden. Aufgrund der hohen Sicherheit, die KryptoKom zur Verfügung stellen möchte, werden Verschlüsselungsmechanismen und ein Schlüsselmanagement für geschlossene Benutzergruppen angeboten. Da zur Zeit keine gemeinsame sichere Infrastruktur existiert, werden Standards (wie z.B. IPSec,. TLS/SSL) zum Knüpfen von VPNs nicht unterstützt. (x) 91. Eine synchronisierte Zustandsübermittlung zwischen mehreren KryptoWalls ist möglich. (ä) 92. Dadurch können mehrere Firewalls nicht zentral administriert werden. (ä) 93. Die Kommunikation mit einer Zertifizierungsstelle wird nicht unterstützt. (ä) 94. Aktuelle Standards wie IPSec, SKIP, RADIUS, ISAKMP/Oakley, TLS/SSL und TACACs werden nicht unterstützt. (x) 95. Ein generischer Proxy ist vorhanden. (ä) 96. Die eingesetzten Programme sind nicht ausreichend dokumentiert. (ä) 97. Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation der Firewall nicht notwendig. Lediglich die Konfiguration der NNTP-, SMTP- und DNS-Server muß angepaßt werden. (ä) 98. Multicast-Pakete werden nicht unterstützt. (x) Fazit Vorteile der KryptoWall ist die unbeschränkte Schlüssellänge der Verschüsselungsalgorithmen. Somit eignet sich die KryptoWall sehr gut für den Schutz von Hochsicherheitsnetzen, die nur wenig Interoperabilität verlangen und die traditionellen Dienste sicher anbieten möchten. Ausführbarer Code soll in der Folgeversion gefiltert werden können. Die KryptoWall wird zur Zeit vom BSI nach ITSEC, E3 hoch zertifiziert. Kontaktadresse: http://www.kryptokom.de
Seite 160
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
6.1.7 PIX Firewall Version Rev 4.0 der Firma Cisco Systems (D) Die PIX-Firewall verfolgt den Ansatz eines zustandsabhängigen, verbindungsorientierten Paketfilters, der Zugangskontrolle zu internen und externen Netzen bietet. Dabei werden Sitzungen basierend auf Source- und Destination-IP-Adresse, TCP-Sequence-Nummer, Portnummern und TCP-Flags untersucht. Diese Information wird in einer Tabelle gespeichert. Jedes Paket wird mit den Einträgen in der Tabelle verglichen. Zugang wird nur dann erlaubt, wenn eine passende Verbindung besteht. Somit wird internen Nutzern und autorisierten externen Nutzern transparenter Zugang gewährt. Zusätzlich zum reinen Paketfilter-Ansatz werden Nutzer der Dienste FTP, Telnet und HTTP zu Beginn einer Verbindung mit Unterstützung eines separaten Authentisierungsservers auf Applikationsebene untersucht. Diese Kommunikation läuft über die Protokolle TACACS+ oder RADIUS. Sobald der Nutzer authentifiziert und seine Berechtigung gemäß der Sicherheitspolitik festgestellt wurde, wird ein Profil des Nutzers in eine Tabelle eingetragen und der nachkommende Datenverkehr dieser Verbindung unter Beobachtung dieser die Verbindungen überwachenden Tabelle auf Transportschicht-Ebene untersucht. PIX besitzt keine dedizierten oder generischen Proxies und erzielt somit einen höheren Datendurchsatz. 1. 2. 3.
4. 5.
6. 7. 8. 9.
10. 11. 12. 13. 14. 15. 16.
17. 11.09.97
Die Identifikation und Authentisierung ist über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole) möglich. (ä) Die Rolle des Revisors ist nicht vorgesehen. (x) Bei einem Ausfall einer Protokollierungskomponente wird keine Warnung an den Administrator ausgegeben. Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (x) Integritätstests der eingesetzten Programme werden von der PIX nicht angeboten. (x) Es ist möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. Falls Komponenten (z.B. Proxies) abstürzen, wird die Funktion generell verweigert, die von diesen Komponenten bedient wird. Bei der zentralen Komponente der Firewall, die Verbindungsaufbauwünsche erlaubt oder ablehnt, resultiert ein Absturz in ein generelles „DENY“ aller Verbindungsaufbauwünsche. Dann ist die Firewall nur noch zur Administration erreichbar. (ä) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist. Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (ä) Die Firewall besteht nicht aus zwei getrennten Filtern, sondern aus einem dynamischen Paketfilter. (x) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) Die Struktur des zu schützenden Netzes kann durch den Einsatz der Firewall-1 als Applikationsfilter und zweier DNS-Server verdeckt werden, wobei ein DNS-Server extern hinter einem Paketfilter und ein DNS-Server intern hinter dem Applikationsfilter aufgestellt wird, und diese DNS-Server Informationen nur über einen Applikationsfilter austauschen können (sog. splitted DNS-Server). Dadurch können DNS-Requests von einem unbekannten Rechner verhindert oder zu einem bestimmten DNS-Server umgeleitet werden. Ferner kann die Struktur des internen Netzes durch Network Address Translation verdeckt werden. (ä) Für die Verwaltung der Komponenten existiert eine GUI. (ä) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. (ä) Der Aufbau von Verbindungen kann von der PIX zwar nicht auf Anwendungsebene aber durch einen separaten Authentication Server benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) Zur Benutzeridentifikation werden starke Authentisierungsmethoden angeboten. (ä) Mehrere Benutzer können zu einer Gruppe zusammengefaßt werden. Es können die Netzobjekte Host, Domain, Subnet, Group, IP-Range und VPN-Objekte definiert werden. (ä) Die Filterregeln können nicht auf ihre Widerspruchsfreiheit überprüft werden. (x) PIX bietet folgende Dienste an: Archie, FTP, HTTP, Telnet, RPC, Netmeeting, X11, Gopher, RealAudio, IntelPhone, syslog, Microsoft’s Netshow, White Pines‘ CuSeeMe, Progressive Networks‘ RealAudio, VDOnet’s VDO Live, IRC, Vocaltech’s Internet Phone, Intel’s Internet Phone basierend auf H.323, Vxtreme’s Web Theater 2 und Xing Technologies‘ Streamworks. Die Vielzahl der Dienste ergibt sich durch den Ansatz dynamischer Paketfilter. (ä) Telnet-Verbindungen vom Internet zur Firewall können nicht verschlüsselt werden. (x) Firewall-Studie
Seite 161
SIEMENS
Test ausgewählter Firewallprodukte
18. Für Verbindungen auf der Anwendungsschicht können nicht alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (z.B. post bei HTTP) bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden. Der Authentication Server unterstützt lediglich die Protokolle FTP, HTTP und Telnet. Einzelne Befehle können nicht granuliert gefiltert werden. (x) 19. Eine Protokollierung von Benutzeridentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum auf Anwendungsschicht kann nicht durchgeführt werden. (x) Die Protokollierung kann nicht auf bestimmte Verbindungen eingeschränkt werden. (x) 20. Spezielle einstellbare Protokollmeldungen führen zu einer unverzüglichen Warnung. (ä) 21. Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden. (x) 22. Bei der Benutzung von FTP ist es nicht möglich, den Verbindungsaufbau für die Datenverbindung (FTP-DATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (x) 23. Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze und abhängig von Quell- und Zielport für TCP und UDP erlaubt oder verboten werden. (ä/ä) 24. Die Filterung ist gemäß voriger Forderung für jedes Interface getrennt möglich. (ä) 25. Die Reihenfolge der Paketfilterregeln wird nicht automatisch vom Paketfilter verändert. (ä) 26. Eine Filterung ist getrennt für kommende und gehende Pakete möglich, wenn mehr als zwei Interfaces vorhanden sind. (ä) 27. Bei TCP-Paketen ist eine Unterscheidung zwischen ACK und ACK-losen Paketen möglich. (ä) 28. Die Protokollierung von IP-Nummer, Dienst, Zeit und Datum ist für jedes Paket möglich. (ä) 29. Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) 30. Source-Routing Informationen werden standardmäßig abgewiesen. (ä) 31. Die Paketfilterkomponente verlangt keine Mindestgröße an Fragmentlänge. (x) 32. Die Paketfilterkomponente schreibt kein Minimum an Fragment-Offset vor. (x) 33. Die ICMP-Meldung Destination Unreachable wird, wie alle ICMP-Meldungen abgewiesen. (ä) 34. Die ICMP-Meldung Redirect wird abgewiesen. (ä) 35. Inverse DNS-Anfragen können durch den Ansatz „splitted DNS-Server“ abgewiesen werden. (ä) 36. Zonen-Transfer-Requests von einem unbekannten Host können mit REFUSED beantwortet werden. (ä) 37. ARP-Tabellen können fixiert werden. (ä) 38. Das automatische Ablaufen von ARP kann nicht unterbunden werden. (x) 39. Die FTP-Befehle CWD, CDUP, LIST und SITE können nicht an eine Rechteverwaltung geknüpft werden. (x) 40. Eingehende Telnet-Daten können auf Port 23 gefiltert werden. (ä) 41. S-HTTP-Daten können nicht erkannt und abgewiesen werden. (x) 42. Die PIX bietet dynamische Paketfilterfunktionalität. Somit können dynamische Ports verfolgt werden. (ä) 43. Es können die Netzobjekte Host, Domain, Subnet, Group, IP-Range und VPN-Objekte definiert werden. (ä) 44. Spoof-Checking wird durchgeführt. (ä) 45. Ping-to-Death kann vom darunterliegenden Betriebssystem abgefangen werden. (ä) 46. TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. (ä) 47. Ein Anti-Virus-Checker ist nicht integriert. Fremdprodukte können jedoch unterstützt werden. (x) 48. Fragmentierte Pakete werden zunächst zusammengesetzt und anschließend untersucht. (ä) 49. Session-Hijacking wird verhindert. (ä) 50. TCP-Sequence-Number-Guessing wird durch Randomisieren der Sequenznummer verhindert. (ä) 51. Illegal Address Support ist möglich. (ä) 52. Die Administration der Firewall ist lediglich durch ein zweistufiges Paßwort geschützt. (x) 53. IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) 54. Die PIX kann zentral fernadministriert werden. Managementverbindungen können per Konsole, Telnet oder HTTP unverschlüsselt ausgeführt werden. Eine Sicherung dieser Verbindungen ist durch Knüpfen eines VPNs möglich. (ä) 55. Die verwendeten Verschlüsselungsverfahren unterliegen den US-Exportrestriktionen. (ä) Seite 162
Firewall-Studie
11.09.97
SIEMENS 56. 57. 58. 59. 60. 61. 62.
63. 64. 65. 66. 67. 68. 69. 70. 71.
72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98.
11.09.97
Test auf Erfüllung der Sicherheitsanforderungen
Das Key Management erfolgt mittels Diffie-Hellmann-Algorithmus. (ä) Die Verbindung zu einem externen Rechner kann durch Knüpfen eines VPN erreicht werden. (ä) Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) Für die Authentisierung von Benutzern beliebiger Anwendungen ist eine Client Authentication sowohl für TCP, UDP als auch RPC nicht möglich. (x) Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) Eine Authentisierung ist pro Sitzung möglich. (ä) Die Verschlüsselung erfolgt mit 40 Bit DES-Algorithmus im CBC-Modus. Um einen 56 Bit DESSchlüssel zu verwenden, ist allerdings eine Hinterlegung der Schlüssel bei der herstellereigenen Schlüsselverteilzentrale notwendig. Zur Authentisierung wird der Algorithmus Keyed MD5 verwendet. (ä) Zur Möglichkeit, den Sitzungsschlüssel zu wechseln, machte der Hersteller keine Angaben. (k.a.) Die Dienste OSPF und SNMP werden nicht angeboten. Die Dienste NFS, NIS, RPC, RIP, DNS, WAIS und r-Kommanods werden angeboten. (ä) BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. (ä) Die RIP-Meldung Loose-Source-Routing kann abgewiesen werden. (ä) Die Firewall kann nicht transparent betrieben werden. (x) Eine On-line Hilfe ist vorhanden. (ä) Für den Betrieb der Firewall ist proprietäre Hardware notwendig. (x) Bezüglich Aufwand für Installation machte der Hersteller keine Angaben. (k.a.) Die PIX Firewall kostet ab DM 17.000,- inklusive Hardware. Dabei ist der Preis nicht abhängig von der User-Anzahl, sondern von der Anzahl TCP-Sessions, die gleichzeitig erwünscht sind. Die Gegenstelle benötigt zur Verschlüsselung eine PIX Private Encryption Card (DM 5.000,-) oder die Fähigkeit, IPSec zu unterstützen. (ä) Über den Aufwand für den Betrieb der Firewall machte der Hersteller keine Angaben. (k.a.) Für Installation und Wartung wird Support angeboten. (ä) Versionspflege wird betrieben. (ä) Zur Filterung werden die Regelarten allow und deny angeboten. (ä) PIX verwendet keine dedizierten Proxies. (x) Die Protokollierung erfolgt mit Hilfe der syslog-Einheit. Die Kriterien für eine Warnung können dort eingestellt werden. Die Alarmierung des Administrators erfolgt nicht über E-mail oder Audio. (x) Protokollinformationen können an einen externen Host gesendet werden (z.B. automatisch per e-mail). (ä) Die PIX besteht aus einer betriebssystemunabhängigen Hardware. (x) Router werden unterstützt. (ä) Die PIX ist für die Netze Ethernet, Fast Ethernet und Token Ring erhältlich. (ä) Zur Benutzeridentifikation werden die Authentisierungsmethoden Kerberos, RADIUS und TACACs angeboten. (ä) Modem-Verbindungen können durch das Knüpfen eines VPNs gesichert werden. (ä) Andere Protokolle wie IPX oder DECNET können nicht unterstützt werden. (x) Network Address Translation und Port Address Translation sind möglich. (ä) An ausführbarem Code kann JAVA gefiltert werden. (ä) Ausführbarer Code wird in FTP oder anderen Datenübertragungsprotokollen nicht gefiltert. (x) PIX unterstützt kein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integieren. (x) Logfiles können nicht automatisch ausgewertet werden. (x) VPNs können durch IPSec geknüpft werden. (ä) Zwischen mehreren PIX-Firewalls ist eine synchronisierte Zustandsübermittlung möglich. (ä) Dadurch können mehrere PIX-Firewalls zentral administriert werden. (ä) Die Kommunikation mit einer Zertifizierungsstelle wird nicht unterstützt. (x) An aktuellen Standards werden IPSec, RADIUS und TACACs unterstützt. ISAKMP/Oakley, und TLS/SSL werden nicht unterstützt. (ä) Ein generischer Proxy ist nicht vorhanden. (x) Die eingesetzten Programme sind nicht ausreichend dokumentiert. (x) Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation der Firewall nicht notwendig. (ä) Multicast-Pakete werden nicht unterstützt. (x)
Firewall-Studie
Seite 163
SIEMENS
Test ausgewählter Firewallprodukte
Fazit Die PIX Firewall zeichnet sich durch die dynamische Paketfilterfunktionalität und die daraus resultierende Fähigkeit, Dienste wie NFS, DNS, NIS, RPC, RIP, r-Dienste und WAIS sicher anbieten zu können aus. Für zukünftige Anwendungsszenarien wie VPNs mit IPv6 oder kaskadierte Intranets ist die Unterstützung von ISAKMP/Oakley und der Kommunikation mit einer Zertifizierungsstelle und TLS/SSL wünschenswert. Ferner sollte ActiveX und MIME erkannt und gefiltert werden können. Dazu müßte CISCO zusätzlich zu der Paketfilterfunktionalität dedizierte oder generische Proxies anbieten. Dies ginge auf Kosten des Datendurchsatzes, der von CISCO als größter Vorteil gegenüber anderen Herstellern gesehen wird. Die PIX Firewall bietet die Möglichkeit, NAT (Network Address Translation) und PAT37 (Port Address Translation) vermischt auszuführen. Kontaktadresse: http://www.cisco.com
37
PAT erlaubt, Ports auf andere abzubilden. Dadurch ist es z.B. möglich, Dienste auf bestimmte Ports umzuleiten oder die Anzahl der Ports, die überprüft werden müssen, zu verringern. Außerdem können privilegierte Ports geschützt werden, indem sie auf andere Ports abgebildet werden. Seite 164
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
6.1.8 Sidewinder Version 3.1 der Firma Secure Computing Corporation (D) Sidewinder ist ein Applikationsfilter ohne Paketfilterfunktionalität. 1. 2. 3.
4.
5.
6. 7. 8. 9.
10. 11. 12. 13. 14. 15. 16.
17. 18.
19.
20. 21.
11.09.97
Die Identifikation und Authentisierung ist über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole) möglich. (ä) Die Rolle des Revisors ist nicht vorgesehen. (x) Bei einem Ausfall einer Protokollierungskomponente wird eine Warnung an den Administrator ausgegeben. Es ist möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (ä) Integritätstests können mittels CRON-Jobs ausgeführt werden, die z.B. täglich oder stündlich die Größe der Log-Dateien überwachen. Ist eine bestimmt Kapazität erreicht, können beliebige Aktionen gestartet werden, z.B. eine Mail an einen Administrator senden oder einen Service oder Proxy unterbinden. (ä) Es ist möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. Falls Komponenten (z.B. Proxies) abstürzen, wird die Funktion generell verweigert, die von diesen Komponenten bedient wird. Bei der zentralen Komponente der Firewall, die Verbindungsaufbauwünsche erlaubt oder ablehnt, resultiert ein Absturz in ein generelles „DENY“ aller Verbindungsaufbauwünsche. Dann ist die Firewall nur noch zur Administration erreichbar. (ä) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist. Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (x) Die Firewall besteht nicht aus zwei getrennten Filtern, sondern aus einem Applikationsfilter. (x) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) Die Struktur des zu schützenden Netzes kann durch den Einsatz der Firewall als Applikationsfilter und zweier DNS-Server verdeckt werden, wobei ein DNS-Server extern hinter einem Paketfilter und ein DNS-Server intern hinter dem Applikationsfilter aufgestellt wird, und diese DNS-Server Informationen nur über einen Applikationsfilter austauschen können (sog. splitted DNS-Server). Dadurch können DNS-Requests von einem unbekannten Rechner verhindert oder zu einem bestimmten DNS-Server umgeleitet werden. Ferner kann die Struktur des internen Netzes durch Network Address Translation verdeckt werden. (ä) Für die Verwaltung der Komponenten existiert eine GUI. (ä) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. (ä) Der Aufbau von Verbindungen auf der Anwendungsschicht kann durch die Firewall benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) Zur Benutzeridentifikation werden starke Authentisierungsmethoden angeboten. (ä) Mehrere Benutzer können zu einer Gruppe zusammengefaßt werden. Es können die Netzobjekte Host, Domain, Subnet, Group, IP-Range und VPN-Objekte definiert werden. (ä) Die Filterregeln können nicht auf ihre Widerspruchsfreiheit überprüft werden. (ä) Sidewinder bietet TCP-basierte Proxies für die Protokolle Telnet, FTP, HTTP, Gopher, Usenet, News, aol, POP, WAIS, whois, syslog und X11. Zusätzlich bietet er UDP-basierte Proxies für Anwendungen, die SNMP, NTP und RealAudio verwenden, sowie einen generischen Proxy. (ä) Für Telnet-Verbindungen vom Internet zur Firewall kann durch zusätzliche Prozesse (z.B. Knüpfen eines VPNs) eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. (ä) Für Verbindungen auf der Anwendungsschicht können alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (post bei HTTP) bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht kann eine Protokollierung von Benutzeridentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. (ä) Die Protokollierung kann auf bestimmte Verbindungen eingeschränkt werden. (ä) Spezielle einstellbare Protokollmeldungen führen zu einer unverzüglichen Warnung. (ä) Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden (nur via syslog). (x)
Firewall-Studie
Seite 165
SIEMENS
Test ausgewählter Firewallprodukte
22. Bei der Benutzung von FTP ist es möglich, den Verbindungsaufbau für die Datenverbindung (FTPDATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (ä) 23. Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze, wegen der nicht vorhandenen Paketfilterfunktionalität jedoch nicht abhängig von Quell- und Zielport für TCP oder UDP erlaubt oder verboten werden. (ä/x) 24. Die Filterung ist gemäß voriger Forderung für jedes Interface getrennt möglich. (ä) 25. Die Reihenfolge der Filterregeln wird nicht automatisch vom Sidewinder verändert. (ä) 26. Eine Filterung ist getrennt für kommende und gehende Pakete möglich, wenn mehr als zwei Interfaces vorhanden sind. (ä) 27. Bei TCP-Paketen ist eine Unterscheidung zwischen ACK und ACK-losen Paketen irrelevant, da Sidewinder kein Paketfilter ist. (m) 28. Die Protokollierung von IP-Nummer, Dienst, Zeit und Datum ist für jedes Paket möglich. (ä) 29. Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) 30. Source-Routing Informationen werden standardmäßig abgewiesen. (ä) 31. Die Firewall verlangt keine Mindestgröße an Fragmentlänge. (x) 32. Die Paketfilterkomponente schreibt kein Minimum an Fragment-Offset vor. (x) 33. Die ICMP-Meldung Destination Unreachable wird wie jede ICMP-Meldung abgewiesen. (ä) 34. Die ICMP-Meldung Redirect wird wie jede ICMP-Meldung abgewiesen. (ä) 35. Inverse DNS-Anfragen können durch den Ansatz „splitted DNS-Server“ abgewiesen werden. (ä) 36. Zonen-Transfer-Requests von einem unbekannten Host können mit REFUSED beantwortet werden. (ä) 37. ARP-Tabellen können nicht fixiert werden. (x) 38. Das automatische Ablaufen von ARP kann nicht unterbunden werden. (x) 39. Die FTP- Befehle CWD, CDUP, LIST und SITE können nicht an eine Rechteverwaltung gekoppelt werden. (x) 40. Eingehende Telnet-Daten können nicht auf Port 23 abgewiesen werden. (x) 41. S-HTTP-Daten können vom HTTP-Proxy nicht erkannt und abgewiesen werden. (x) 42. Die Sidewinder bietet keine dynamische Paketfilterfunktionalität. Somit können keine dynamischen Ports verfolgt werden. (x) 43. Es können die Netzobjekte Host, Domain, Subnet, Group, IP-Range und VPN-Objekte definiert werden. (ä) 44. Spoof-Checking wird durchgeführt. (ä) 45. Ping-to-Death kann vom darunterliegenden Betriebssystem abgefangen werden. (ä) 46. TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. (ä) 47. Ein Anti-Virus-Checker ist nicht integriert. Fremdprodukte können jedoch unterstützt werden. (x) 48. Fragmentierte Pakete werden zunächst zusammengesetzt und anschließend untersucht. (ä) 49. Session-Hijacking wird nicht verhindert. (x) 50. TCP-Sequence-Number-Guessing wird nicht verhindert. (x) 51. Illegal Address Support ist möglich. (ä) 52. Die Administration der Firewall ist lediglich durch ein Paßwort geschützt. (x) 53. IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) 54. Die Sidewinder kann zentral fernadministriert werden. Die Kommunikation des Administrators mit der Firewall ist durch Verschlüsselung geschützt. (ä) 55. Die verwendeten Verschlüsselungsverfahren unterliegen den US-Exportrestriktionen. (ä) 56. Zum Key Management machte der Hersteller keine Angaben. (k.a.) 57. Die Verbindung zu einem externen Rechner kann von der Sidewinder durch IPSec bzw. RADIUS oder TACACs geschützt werden. (ä) 58. Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) 59. Für die Authentisierung von Benutzern beliebiger Anwendungen ist eine Client Authentication für TCP, jedoch nicht für UDP und RPC möglich. (x) 60. Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) 61. Eine Authentisierung ist pro Sitzung möglich. (ä) 62. Sidewinder verwendet die Algorithmen DES-56, RC4-40 und RC4-128. Exportiert werden kann jedoch nur der RC4-40 bzw. DES-56. Die Verschlüsselung vollzieht eine Software, die auf der Sidewinder installiert ist. Zur Überprüfung der Authentizität und Integrität wird der Algorithmus Keyed MD5 verwendet. (ä) Seite 166
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
63. Über die Möglichkeit, Sitzungsschlüssel wechseln zu können, hat der Hersteller keine Angaben gemacht. (k.a.) 64. Neben den Standarddiensten werden die Dienste NFS, NIS, RPC, DNS, WAIS und SNMP angeboten. Die Dienste RIP, OSPF und r-Kommandos werden nicht angeboten. (ä) 65. BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. (ä) 66. RIP wird nicht angeboten. Daher werden die RIP-Meldungen Loose-Source-Routing und Redirect abgewiesen. (ä) 67. Die Firewall kann nicht transparent betrieben werden. (x) 68. Eine On-line Hilfe ist vorhanden. (ä) 69. Für den Betrieb der Firewall ist proprietäre Hardware notwendig. (x) 70. Über den Aufwand bezüglich Installation hat der Hersteller keine Angaben gemacht. (k.a.) 71. Die Sidewinder kostet in der Version 3.1 für 100 User ab DM 15.484,- inklusive Hardware. Für eine unbegrenzte Anzahl an Usern beträgt der Preis DM 44.656,- zuzüglich Zubehör (wie die Unterstützung von IPSec für DM 4.488,-). (ä) 72. Über den Aufwand für den Betrieb der Firewall hat der Hersteller keine Angaben gemacht. (k.a.) 73. Für Installation und Wartung wird Support angeboten. (ä) 74. Versionspflege wird betrieben. (ä) 75. Zur Filterung werden die Regelarten allow und deny angeboten. (ä) 76. Zusätzlich zu den Standardproxies bietet die Sidewinder dedizierte Proxies für X11, whois und syslog an. (ä) 77. Die Alarmierung des Administrators erfolgt über E-mail oder Audio. (ä) 78. Protokollinformationen können an einen externen Host gesendet werden (z.B. automatisch per e-mail). (ä) 79. Die Sidewinder ist auf proprietärer betriebssystemunabhängiger Hardware installiert. (x) 80. Router werden nicht unterstützt. (x) 81. Die Sidewinder ist für die Netze Ethernet, Fast Ethernet und FDDI vorgesehen. (ä) 82. Zur Benutzeridentifikation werden die Authentisierungsmethoden Safeword Authentication Server, SecureID, Digital Pathways SNK, Reusable Passwords, TACACs, RADIUS und Racal WatchWord Keys angeboten. (ä) 83. Modem-Verbindungen können das Knüpfen von VPNs gesichert werden. (ä) 84. Andere Protokolle wie IPX oder DECNET werden nicht unterstützt. (x) 85. Network Address Translation ist möglich. (ä) 86. An ausführbarem Code kann JAVA gefiltert werden. (ä) 87. Ausführbarer Code wird in FTP oder anderen Datenübertragungsprotokollen nicht gefiltert. (ä) 88. Sidewinder unterstützt kein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integieren. (x) 89. Logfiles können automatisch ausgewertet werden. (ä) 90. VPNs können durch IPSec oder TLS/SSL geknüpft werden. (ä) 91. Eine synchronisierte Zustandsübermittlung zwischen mehreren Sidewindern ist nicht möglich. (x) 92. Dadurch können mehrere Sidewinder nicht zentral administriert werden. (x) 93. Die Kommunikation mit einer Zertifizierungsstelle wird unterstützt. (ä) 94. An aktuellen Standards werden IPSec, RADIUS, TACACs und TLS/SSL unterstützt. ISAKMP/Oakley wird nicht unterstützt. (ä) 95. Ein generischer Proxy ist vorhanden. (ä) 96. Die eingesetzten Programme sind nicht ausreichend dokumentiert. (x) 97. Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation der Firewall nicht notwendig. (ä) 98. Multicast-Pakete werden nicht unterstützt. (x) Fazit Verbesserungswürdig ist die Authentisierung des Administrators. Für zukünftige Anwendungen wie VPNs mit IPv6 und kaskadierte Intranets ist der Sidewinder durch die Unterstützung von IPSec, TLS/SSL und der Kommunikation mit einer Zertifizierungsstelle bereits gut gerüstet. Das Key-Management-Protokoll ISAKMP/Oakley würde diesen Aspekt vervollständigen. Kontaktadresse: http://www.entrada.de.
11.09.97
Firewall-Studie
Seite 167
SIEMENS
Test ausgewählter Firewallprodukte
6.1.9 TIS Internet Firewall Toolkit Version 2.0 der Firma Trusted Information Systems (D) Das TIS Internet Firewall Toolkit ist eine lizensierte, für den nicht kommerziellen Einsatz frei erhältliche Menge von Werkzeugen zum Bau einer Firewall. Die Komponenten des Toolkit können gemeinsam, isoliert oder in Kombination mit anderen Firewall-Komponenten eingesetzt werden. Das Toolkit ist für UNIXSysteme konzipiert und arbeitet auf TCP/IP mit einem Berkeley-ähnlichen „socket“-Interface. 1. 2. 3.
4. 5. 6. 7. 8. 9.
10. 11. 12. 13. 14. 15. 16.
17.
18.
19.
20. 21. 22.
Die Identifikation und Authentisierung ist über einen vertrauenswürdigen Pfad (z.B. durch Einschränkung des Zugriffs auf die Konsole) möglich. (ä) Die Rolle des Revisors ist nicht vorgesehen. (x) Bei einem Ausfall einer Protokollierungskomponente wird keine Warnung an den Administrator ausgegeben. Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Benutzung der Firewall unterbunden wird. (x) Integritätstests der eingesetzten Programme werden von der Firewall nicht angeboten. (x) Es ist nicht möglich, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall unterbunden wird. (x) Auf der Firewall ist Software vorhanden, die für die Funktionsfähigkeit der Firewall nicht unbedingt nötig ist. Die benutzte Software ist nicht ausführlich dokumentiert oder begründet. (x) Die Firewall besteht nicht aus zwei getrennten Filtern, sondern aus einem Applikationsfilter mit integriertem Paketfilter. (x) Alle Verbindungen, die nicht explizit erlaubt sind, werden blockiert. Bei einem Ausfall der Firewall werden alle Verbindungsaufbauwünsche abgelehnt. (ä) Die Struktur des zu schützenden Netzes kann durch den Einsatz der Firewall als Applikationsfilter und zweier DNS-Server verdeckt werden, wobei ein DNS-Server extern hinter einem Paketfilter und ein DNS-Server intern hinter dem Applikationsfilter aufgestellt wird, und diese DNS-Server Informationen nur über einen Applikationsfilter austauschen können (sog. splitted DNS-Server). Dadurch können DNS-Requests von einem unbekannten Rechner verhindert oder zu einem bestimmten DNS-Server umgeleitet werden. (ä) Für die Verwaltung der Komponenten existiert keine GUI. (x) Die Verwaltung der Komponenten kann zentral über einen vertrauenswürdigen Pfad (z.B. durch die Einschränkung des Zugriffs auf die Konsole oder über eine verschlüsselte Verbindung) erfolgen. (ä) Der Aufbau von Verbindungen auf der Anwendungsschicht kann durch die Firewall benutzer- und zeitabhängig erlaubt oder verboten werden. (ä) Zur Benutzeridentifikation werden starke Authentisierungsmethoden angeboten. (ä) Benutzer können nicht zu einer Gruppe zusammengefaßt werden. (x) Die Filterregeln können nicht auf ihre Widerspruchsfreiheit überprüft werden. (x) Für die Protokolle Telnet, FTP, SMTP, HTTP, X11 und syslog existieren Proxies. Die Dienste NFS und NIS werden angeboten. Nicht angeboten werden die Dienste RPC, RIP, OSPF, r-Kommandos, DNS, WAIS und SNMP. Ein generischer Proxy ist vorhanden. (ä) Für Telnet-Verbindungen vom Internet zur Firewall kann durch zusätzliche Prozesse (z.B. Knüpfen eines VPNs) eine Verschlüsselung der übertragenen Nutzinformationen nicht durchgeführt werden, da das TIS Firewall Toolkit keine Verschlüsselung anbietet. (x) Für Verbindungen auf der Anwendungsschicht können nicht alle Befehle, die den Import von Daten in das zu schützende Netz (z.B. retr bei FTP) oder den Export von lokalen Daten ins Internet (post bei HTTP) bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden. (x) Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht kann eine Protokollierung von Benutzeridentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. (ä) Die Protokollierung kann auf bestimmte Verbindungen eingeschränkt werden. (ä) Warnungsmechanismen werden nicht angeboten. (x) Die Protokollinformationen können nicht über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden (nur via syslog). (x) Bei der Benutzung von FTP ist es nicht möglich, den Verbindungsaufbau für die Datenverbindung (FTP-DATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). (x)
Seite 168
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
23. Die Weiterleitung von Paketen kann abhängig von IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze und abhängig von Quell- und Zielport für TCP, wegen der nicht dynamischen Paketfilterfunktionalität jedoch nicht für UDP erlaubt oder verboten werden. (ä/x) 24. Die Filterung ist gemäß voriger Forderung für jedes Interface getrennt möglich. (ä) 25. Die Reihenfolge der Paketfilterregeln wird nicht automatisch von der Firewall verändert. (ä) 26. Eine Filterung ist getrennt für kommende und gehende Pakete möglich, wenn mehr als zwei Interfaces vorhanden sind. (ä) 27. Bei TCP-Paketen ist eine Unterscheidung zwischen ACK und ACK-losen Paketen möglich. (ä) 28. Die Protokollierung von IP-Nummer, Dienst, Zeit und Datum ist für jedes Paket möglich. (ä) 29. Im Falle der Kombination der Firewall mit einem Router werden keine Routing-Einträge verändert. Es wird statisches Routing benutzt. (ä) 30. Source-Routing Informationen werden standardmäßig abgewiesen. (ä) 31. Die Paketfilterkomponente verlangt keine Mindestgröße an Fragmentlänge. (x) 32. Die Paketfilterkomponente schreibt kein Minimum an Fragment-Offset vor. (x) 33. ICMP wird abgewiesen. Somit wird die ICMP-Meldung Destination Unreachable abgewiesen. (ä) 34. ICMP wird abgewiesen. Somit wird die ICMP-Meldung Redirect abgewiesen. (ä) 35. Inverse DNS-Anfragen können durch den Ansatz „splitted DNS-Server“ abgewiesen werden. (ä) 36. Zonen-Transfer-Requests von einem unbekannten Host können mit REFUSED beantwortet werden. (ä) 37. ARP-Tabellen können fixiert werden. (ä) 38. Das automatische Ablaufen von ARP kann unterbunden werden. (ä) 39. Die FTP-Befehle CWD, CDUP, LIST und SITE können nicht an eine Rechteverwaltung gekoppelt werden. (x) 40. Eingehende Telnet-Daten können auf Port 23 abgewiesen werden. (ä) 41. S-HTTP-Daten können vom HTTP-Proxy nicht erkannt und abgewiesen werden. (x) 42. Die Firewall bietet keine dynamische Paketfilterfunktionalität. Somit können dynamische Ports nicht verfolgt werden. (x) 43. Es können die Netzobjekte Host und, Subnet definiert werden. (ä) 44. Spoof-Checking wird nicht durchgeführt. (x) 45. Ping-to-Death kann vom darunterliegenden Betriebssystem abgefangen werden. (ä) 46. TCP-SYN-Flooding wird durch Begrenzung der Anzahl der halboffenen Verbindungen verhindert. (ä) 47. Ein Anti-Virus-Checker ist nicht integriert. (x) 48. Fragmentierte Pakete werden zunächst zusammengesetzt und anschließend untersucht. (ä) 49. Session-Hijacking wird nicht verhindert. (x) 50. TCP-Sequence-Number-Guessing wird nicht verhindert. (x) 51. Illegal Address Support ist nicht möglich. (x) 52. Die Administration der Firewall ist lediglich durch ein Paßwort geschützt. (x) 53. IP-Forwarding ist auch nach einem Neustart abgeschaltet. (ä) 54. Die Firewall kann nicht zentral fernadministriert werden. (x) 55. TIS Firewall Toolkit bietet keine Verschlüsselung (x) 56. TIS Firewall Toolkit bietet keine Verschlüsselung (x) 57. Die Verbindung zu einem externen Rechner kann nicht geschützt werden. (x) 58. Für Telnet, FTP und HTTP ist eine erweiterte Login-Prozedur möglich. (ä) 59. Für die Authentisierung von Benutzern beliebiger Anwendungen ist eine Client Authentication für TCP, jedoch nicht für UDP und RPC möglich. (ä/x) 60. Die Authentisierung ist außer bei den kritischen Protokollen Telnet, FTP und HTTP transparent. (ä) 61. Eine Authentisierung ist pro Sitzung möglich. (ä) 62. Das TIS Firewall Toolkit bietet keine Verschlüsselungsalgorithmen an. (x) 63. TIS Firewall Toolkit bietet keine Verschlüsselung (x) 64. Neben den Standarddiensten werden die Dienste NFS und NIS angeboten. (ä) 65. BGP wird nicht unterstützt. Somit wird die BGP-Meldung Notification automatisch abgewiesen. 66. RIP wird nicht unterstützt. Somit werden die RIP-Meldungen Loose-Source-Routing und Redirect abgewiesen. (ä) 67. Die Firewall kann nicht transparent betrieben werden. (ä) 68. Eine On-line Hilfe ist nicht vorhanden. (x) 69. Für den Betrieb der Firewall ist keine proprietäre Hardware notwendig. (ä) 70. Über den Aufwand für Installation hat der Hersteller keine Angaben gemacht. (k.a.) 11.09.97
Firewall-Studie
Seite 169
SIEMENS
Test ausgewählter Firewallprodukte
71. Das TIS Firewall Toolkit ist ein public domain Softwarepaket, das für den nichtkommerziellen Einsatz kostenlos ist. Für den kommerziellen Einsatz ist eine Lizenz zu erwerben. 72. Über den Aufwand für den Betrieb der Firewall hat der Hersteller keine Angaben gemacht. (k.a.) 73. Für Installation und Wartung wird kein Support angeboten. (x) 74. Versionspflege wird betrieben. (ä) 75. Zur Filterung werden die Regelarten allow und deny angeboten. (ä) 76. Für die Protokolle Telnet, FTP, SMTP, HTTP, X11 und syslog existieren Proxies. Die Dienste NFS und NIS werden angeboten. Nicht angeboten werden die Dienste RPC, RIP, OSPF, r-Kommandos, DNS, WAIS und SNMP. Ein generischer Proxy ist vorhanden. (ä) 77. Alarmierung wird nicht unterstützt. (x) 78. Protokollinformationen können an einen externen Host gesendet werden (z.B. automatisch per e-mail). (ä) 79. Das TIS Firewall Toolkit ist für alle UNIX-Plattformen verfügbar. (ä) 80. Router werden nicht unterstützt. (x) 81. Die Firewall-1 ist für die Netze SLIP, Ethernet und Fast Ethernet erhältlich. (ä) 82. Zur Benutzeridentifikation werden die Authentisierungsmethoden SecureNet, SecureID, Digital Pathways SNK, Reusable Passwords und Kerberos angeboten. (ä) 83. Modem-Verbindungen können nicht gesichert werden. (x) 84. Andere Protokolle wie IPX oder DECNET werden nicht unterstützt. 85. Network Address Translation ist nicht möglich. (x) 86. An ausführbarem Code kann JAVA gefiltert werden. (ä) 87. Ausführbarer Code wird in FTP oder anderen Datenübertragungsprotokollen nicht gefiltert. (x) 88. Das TIS Firewall Toolkit unterstützt kein Protokoll, das es erlaubt, externe und third-party Inhaltsuntersuchungs-programme zu integieren. (x) 89. Logfiles können nicht automatisch ausgewertet werden. (x) 90. VPNs können nicht geknüpft werden. (x) 91. Zwischen mehreren Firewalls ist eine synchronisierte Zustandsübermittlung nicht möglich. (x) 92. Dadurch können mehrere TIS Firewall Toolkits nicht zentral administriert werden. (x) 93. Die Kommunikation mit einer Zertifizierungsstelle wird nicht unterstützt. (x) 94. Aktuelle Standards werden nicht unterstützt. (x) 95. Ein generischer Proxy ist vorhanden. (ä) 96. Die eingesetzten Programme sind nicht ausreichend dokumentiert. (x) 97. Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz ist durch die Installation der Firewall nicht notwendig. (ä) 98. Multicast-Pakete werden nicht unterstützt. (x) Fazit Das TIS Firewall Toolkit ist für Anwender gedacht, die auf dem Gebiet Firewalls und UNIX Experten sind. Aufgrund seines Minimalismus entspricht es der Philosophie von Firewalls, sowenig wie möglich Software auf der Firewall laufen zu lassen, und bietet den Vorteil der kostenlosen Nutzung für den nichtkommerziellen Einsatz. Der große Vorteil von TIS Firewall Toolkit ist seine Flexibilität und damit die Möglichkeit, für die eigene spezielle Umgebung eine maßgeschneiderte Firewall zu entwickeln. Für zukünftige Anwendungsszenarien wie VPNs mit IPSec und TLS oder kaskadierte Intranets ist das TIS Firewall Toolkit nicht geeignet.
Seite 170
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
6.1.10 Testübersicht38 Testkriterien
Forderungen zur Abwehr von Angriffen auf die Firewall-Anordnung 1 Identifikation und Authentisierung für Administrator und Revisor (falls vorhanden) nur über einen vertrauenswürdigen Pfad. 2 Die Defaulteinstellung der Rechte muß sicherstellen, daß die Rollen Administrator und Revisor realisiert sind. 3 Bei einem Ausfall der Protokollierungskomponente muß eine Warnung ausgegeben werden, die ein unverzügliches Eingreifen des Administrators ermöglicht. Es muß möglich sein, die Firewall so zu konfigurieren, daß bei einem Ausfall der Protokollierungskomponenten jegliche nicht administrative Nutzung (im Sinne von 1) der Firewall unterbunden wird. 4 Integritätstests der eingesetzten Programme und Dateien mindestens einmal täglich. Es muß möglich sein, die Firewall so zu konfigurieren, daß bei einer Integritätsverletzung jegliche nicht administrative Nutzung der Firewall (im Sinne von 1) unterbunden wird. Die für den Integritätstest notwendigen Programme und Dateien müssen auf einem Medium speicherbar sein, welches hardwaremäßig gegen Schreibzugriffe gesichert werden kann. Es muß protokolliert werden, welche Änderungen (mit Datum und Uhrzeit) an der Konfiguration der Firewall vorgenommen wurden. 5 Es muß möglich sein, die Firewall so zu konfigurieren, daß bei einem Systemabsturz jegliche nicht administrative Nutzung der Firewall (im Sinne von 1) unterbunden wird. 6 Auf den eingesetzten Komponenten darf nur Software vorhanden sein, die für die Funktionsfähigkeit der Firewall nötig ist. Die benutzte Software (inkl. aller Konfigurationsdateien) muß ausführlich dokumentiert und begründet werden.
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
x
x
x
x
ä
x
x
x
x
x
x
ä
x
ä
ä
x
x
ä
ä
ä
x
x
ä
ä
x
x
x
ä
ä
ä
ä
ä
ä
x
x
x
x
x
x
x
x
x
x
x
Legende: ä = Anforderung erfüllt, x = Anforderung nicht erfüllt, k.a. = keine Angaben, m = nicht relevant. 38
11.09.97
Firewall-Studie
Seite 171
SIEMENS
Test ausgewählter Firewallprodukte
Testkriterien
Forderungen zur Abwehr von Angriffen aus dem Internet auf das zu sichernde Netz 7 Die Firewall-Anordnung muß für den Fall des hohen und sehr hohen Schutzbedarfs aus mindestens zwei getrennten Filtern bestehen. Die Filter müssen hintereinander angeordnet sein, so daß für eine Verbindung zwischen den beiden beteiligten Netzen beide Filter passiert werden müssen. Die Filter müssen mit unterschiedlicher Hard- und Software (Betriebssystem) arbeiten und unterschiedliche Formate für die Beschreibung der Filterregeln benutzen. 8 Die Einstellung der Filterregeln bei einer Erstinstallation und die Anordnung der Komponenten muß sicherstellen, daß alle Verbindungen, die nicht explizit erlaubt sind, blokkiert werden. Auch bei einem völligen Ausfall der Firewall-Komponenten dürfen nur Verbindungen durchgelassen werden, die explizit erlaubt worden sind. 9 Die Struktur des zu schützenden Netzes muß verdeckt werden können, d.h. daß keine internen Informationen wie Benutzernamen, Rechnernummern, -namen und Mailadressen nach außen gelangen können. 10 Die Verwaltung der Komponenten muß übersichtlich sein (graphisches Interface) 11 Die Verwaltung der Komponenten muß zentral über einen vertrauenswürdigen Pfad erfolgen. 12 Der Aufbau von Verbindungen auf der Anwendungsschicht durch die Firewall muß benutzerabhängig und zeitabhängig erlaubt oder verboten werden können. 13 Zur Benutzer-Identifikation müssen starke Authentisierungsmethoden benutzt werden. 14 Es muß möglich sein, mehrere Benutzer zu einer Gruppe zusammenzufassen. 15 Die Filterregeln müssen auf ihre Widerspruchsfreiheit überprüft werden. 16 Es müssen die Protokolle Telnet, FTP, SMTP, DNS, NNTP und HTTP unterstützt werden. 17 Für Telnet-Verbindungen vom Internet zur Firewall muß durch zusätzliche Prozesse eine Verschlüsselung der übertragenen Nutzinformationen durchgeführt werden. 18 Für Verbindungen auf der Anwendungsschicht müssen zusätzlich alle Befehle, die den Import von Daten in das zu schützende Netz oder den Export von lokalen Daten ins Internet bewirken, benutzer- und zeitabhängig erlaubt oder verboten werden können.
Seite 172
x
x
x
x
x
ä
x
x
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
ä
ä
ä
x
ä
ä
ä
ä
ä
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
ä
ä
ä
ä
ä
ä
ä
ä
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
ä
x
x
x
x
ä
x
x
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
ä
x
x
ä
ä
ä
ä
ä
x
x
x
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
Testkriterien
19 Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht muß eine Protokollierung von BenutzerIdentifikation, IP-Adresse des Quell- und Zielrechners, Portnummer, Zeit und Datum durchgeführt werden. 19 Bei der Protokollierung müssen Einschränkungen auf bestimmte Verbindungen möglich sein. 20 Spezielle, einstellbare Protokollmeldungen müssen zu einer unverzüglichen Warnung führen. 21 Die Protokollinformationen können über einen vertrauenswürdigen Pfad an eine zentrale Stelle geschickt werden. 22 Bei der Benutzung von FTP muß es möglich sein, den Verbindungsaufbau für die Datenverbindung (FTP-DATA) von der Firewall ins Internet durchführen zu lassen (Benutzung des PASV-Kommandos). 23 Die Weiterleitung von Paketen muß abhängig von a) IP-Quell- und IP-Zieladresse einzelner Rechner oder kompletter Teilnetze und b) Quell- und Zielport für TCP und UDP erlaubt oder verboten werden können. Dies wird in Filterregeln festgelegt. 24 Die Filterung gemäß voriger Forderung muß getrennt für jedes Interface möglich sein. 25 Die Reihenfolge der Filterregeln darf nicht automatisch von der Firewall verändert werden. 26 Wenn mehr als zwei Interfaces vorhanden sind, muß eine Filterung getrennt für kommende und gehende Pakete möglich sein. 27 Bei TCP-Paketen muß eine Unterscheidung, ob ein Verbindungsaufbau stattfindet oder eine bestehende Verbindung benutzt wird, d.h. eine Unterscheidung zwischen ACK und ACK-losen Paketen, möglich sein. 28 Protokollierung von IP-Nummer, Dienst, Zeit und Datum für jedes Paket, wobei auch Einschränkungen auf bestimmte Pakete (z.B. nur Pakete mit einer speziellen Quell-Adresse) möglich sind. 29 Im Falle der Kombination der Firewall mit einem Router darf die Sicherheit der Firewall nicht durch eine Veränderung der RoutingEinträge gefährdet werden. Es muß statisches Routing benutzt werden. 30 Source-Routing Informationen müssen standardmäßig abgewiesen werden.
11.09.97
ä
ä
ä
ä
ä
ä
x
x
ä
x
x
ä
ä
ä
ä
x
x
ä
ä
ä
ä
ä
ä
ä
ä
x
ä
x
x
x
x
x
x
x
x
x
ä
ä
ä
ä
ä
ä
x
x
x
ä / ä
ä / x
ä / x
ä / x
ä / x
ä / x
ä / ä
ä / x
ä / x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
m
m
m
ä
ä
ä
ä
ä
x
x
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
Firewall-Studie
Seite 173
SIEMENS
Test ausgewählter Firewallprodukte
Testkriterien
Zusätzliche Sicherheitsanforderungen an Internet-Firewalls 31 Firewalls sollten eine Mindestgröße an Fragmentlänge verlangen. 32 Firewalls sollten ein Minimum an Fragment-Offset vorschreiben. 33 Firewalls sollten die ICMP Meldung Destination Unreachable filtern können. 34 Firewalls sollten die ICMP-Meldung Redirect abweisen können. 35 Inverse DNS-Anfragen sollten abgewiesen werden können. 36 Zonen-Transfer-Requests von einem unbekannten Host sollten mit Refused beantwortet werden können. 37 ARP-Tabellen sollten fixiert werden können. 38 Das automatische Ablaufen von ARP sollte unterbunden werden können. 39 Die FTP-Befehle CWD, CDUP, RETR, STOR, LIST, NLIST, SYST sollten an eine Rechteverwaltung gekoppelt werden können. 39 Der FTP-Befehl SITE sollte abgewiesen werden können. 40 Eingehende Telnet-Daten sollten auf Port 23 gefiltert werden können 41 S-HTTP- Daten sollten vom HTTP-Proxy gefiltert werden können. 42 Paket-Filter sollten dynamisch sein 43 Für die Filterung sollten folgende Netzobjekte definiert werden können. Host Domain Subnet Group IP-Range VPN-Objekte
Seite 174
x
x
x
x
x
ä
x
x
x
x
x
x
x
x
ä
x
x
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
x
ä
ä
x
ä
ä
ä
ä
x
x
ä
x
x
ä
x
x
ä
x
x
ä
x
x
x
x
ä
ä
x
x
x
x
x
x
ä
ä
x
m
ä
ä
ä
ä
ä
ä
ä
ä
x
x
ä
x
x
x
ä
x
x
x
x
x
ä
x
x
ä ä ä ä ä x
ä ä ä ä ä ä
ä x ä x x x
ä ä ä ä ä ä
ä ä x ä x ä
ä x ä x x x
ä ä ä ä ä ä
x x x x x x
ä x ä x x x
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
Testkriterien
Abwendung von Standardangriffen
ä ä ä
ä ä ä
ä ä ä
ä ä ä
ä ä ä
ä ä ä
ä ä ä
ä ä ä
x ä ä
x ä
x ä
x ä
x ä
x ä
x ä
x ä
x x
x ä
ä ä
ä ä
ä ä
x x
ä ä
ä ä
ä ä
x x
x x
ä
ä
ä
ä
ä
x
ä
x
x
x
x
ä
x
x
ä
x
x
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
x
55 Bei der Verschlüsselung sollte die Schlüssellänge nicht eingeschränkt sein (z.B. durch Exportbeschränkungen). 56 Das Key Management sollte angemessen sicher organisiert sein.
x
x
x
x
x
ä
x
x
m
57 Remote und Mobile Access Control sollten mittels starker Authentisierung und Verschlüsselung geschützt werden können. 58 Für Telnet, FTP und HTTP sollte eine erweiterte Login-Prozedur vorhanden sein. 59 Für Authentisierung von Benutzern beliebiger Anwendungen sollte eine Client Authentication möglich sein (sowohl TCP, UDP, als auch RPC-basiert). 60 Außer bei kritischen Protokollen sollte die Authentisierung transparent sein. 61 Eine Authentisierung sollte pro Sitzung möglich sein.
ä
k. a. k. a. k. a. ä ä ä ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
x
x
x
x
x
x
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
44 Spoof-Checking sollte ausgeführt werden. 45 Ping-to-Death sollte abgefangen werden. 46 TCP-SYN-Flooding sollte verhindert werden. 47 Anti-Virus Checking sollte integriert sein 48 Paket-Reassemblierung sollte an der Firewall durchgeführt werden 49 Session Hijacking sollte verhindert werden. 50 TCP-Sequence-Number-Guessing sollte verhindert werden. 51 Es sollte möglich sein, im internen Netz die gleichen IP-Adressen zu verwenden, wie im externen Netz? (Illegal Address Support) Administration 52 Die Administration der Firewall sollte durch starke Authentisierungsmechanismen geschützt sein. 53 IP-Forwarding sollte auch nach einem Neustart noch abgeschaltet sein. 54 Eine Remote-Administration sollte durch Verschlüsselung geschützt werden Verschlüsselung/Authentisierung
11.09.97
Firewall-Studie
k. a. k. a.
m x
Seite 175
SIEMENS
Test ausgewählter Firewallprodukte
Testkriterien
62 Folgende kryptographische Algorithmen sollten verwendet werden. DES DES-3 RSA RC4 Keyed MD5 DSS 63 Sitzungsschlüssel sollten mit ausreichender Häufigkeit gewechselt werden können.
ä x ä x ä x ä
ä ä x x ä x ä
ä ä x x ä x ä
ä x x ä ä x
ä x x x ä x
ä ä ä ä x ä ä ä x ä
x x x x x x ä x x ä
x x x x ä ä ä ä x ä
ä ä ä x x x ä ä ä ä
x x x x x ä x ä x ä
x x x x x x ä ä x ä
ä ä ä ä x ä ä ä x ä
x x x x x x x x x ä
ä ä x x x x x x x ä
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
x
ä
x
x
ä
x
x
x
k. a. k. a.
ä ä x x ä x ä
ä x x x ä ä
ä x x x ä x
k. a. k. a.
x x x x x x m
Sonstige Kriterien 64 Folgende Dienste sollten angeboten werden. NFS NIS RPC RIP OSPF r-Kommandos DNS WAIS SNMP 65 Die BGP-Meldung Notification sollte abgewiesen werden können. 66 Die RIP-Meldung Loose-Source-Routing sollte abgewiesen werden können. 67 Die Firewall sollte auch für Nutzer außerhalb des zu schützenden Bereichs transparent betrieben werden können.
Seite 176
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
Testkriterien
68 Eine On-line Hilfe sollte vorhanden sein. 69 Für den Betrieb der Firewall sollte keine proprietäre Hardware notwendig sein. 70 Wie hoch ist der Aufwand für die Installation?
ä ä
ä ä
ä x
ä ä
ä x
ä x
x x
x ä
k. a. k. a. k. a. k. a. k. a. k. a.
71 Wie hoch ist der Aufwand für Anschaffung? 72 Wie hoch ist der Aufwand für das Betreiben der Firewall? 73 Support in Installation und Training sollte angeboten werden. 74 Versionspflege sollte angeboten werden.
x ä
ä
k. a. k. a. k. a. k. a. k. a. k. a. k. a. ä ä ä ä ä ä ä x
ä
ä
ä
ä
ä
ä
ä
ä
ä
ä ä ä
ä ä x
ä ä ä
ä ä x
ä ä x
ä x x
ä ä x
ä ä ä
ä ä x
x x x
ä x x
ä x x
x x x
x x x
x x x
x x x
x x x
x x x
x x x x x x
x x ä x x x
x x ä ä ä ä
x x x ä x ä
x x ä x x x
x x x x ä x
x x x x x x
x x x x x x
x x x ä x x
Zusätzliche Funktionen der Produkte Filterung und Proxyauswahl 75 Folgende Regelarten sollten angeboten werden allow deny drop 76 Mindestens eines der folgenden Protokolle sollte durch dedizierte Proxies behandelt werden. Oracle SQL*Net Netscape CoolTalk Microsoft NetMeeting Citrix IntelPhone RealAudio X11 Finger whois
11.09.97
Firewall-Studie
Seite 177
SIEMENS
Test ausgewählter Firewallprodukte
Testkriterien
Protokollierung / Alarmierung 77 Die Alarmierung des Administrators sollte mindestens wie folgt geschehen können. Email Audio 78 Protokollinformationen sollten an einen externen Host gesendet werden können (z.B. automatisch per e-mail). Plattform 79 Mindestens eine der folgenden Plattformen sollte unterstützt werden. Windows95 Windows NT SINIX SunOS Solaris HP-UX BSD AIX 80 Router sollten unterstützt werden.
Seite 178
ä ä x
ä ä ä
ä x ä
ä ä ä
ä x ä
ä ä ä
x x ä
ä x ä
x x ä
x ä x ä ä ä x ä ä
x ä ä ä ä ä x x x
x x x ä ä ä ä x x
x x x x x x x x x
x x x ä ä ä ä x x
x x x x x x x x x
x x x x x x x x ä
x x x x x x x x x
x x ä ä ä ä ä x x
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
Testkriterien
81 Für folgende Netze bzw. Protokolle sollten Interfaces vorhanden sein. SLIP PPP Ethernet Fast Ethernet Token Ring X.25 ATM FDDI
ä ä ä ä ä ä x ä
x ä ä ä ä x ä ä
ä ä ä ä ä ä x ä
x x ä ä x x x ä
ä ä ä ä ä x x x
x x ä ä ä x x x
x x ä ä ä x x x
x x ä x ä ä x ä
ä x ä ä x x x x
Authentisierung 82 Mindestens eines der folgenden Verfahren sollten bei der Authentisierung unterstützt werden. Access Key APOP Defender Security System Digipass Safeword Authentication Server Secure Net SecurID S/Key Digital Pathways SNK Cryptocard Reusable Passwords Kerberos Racal WatchWord Keys AuthentiCard RADIUS TACACS+
k. a. x x x
x x x
ä ä ä
x x x
x x x
x x x
x x x
x x x
x x
x x
ä ä
x ä
x x
x x
x x
x x
ä ä ä ä
x ä ä ä
ä ä ä ä
x ä x ä
ä x ä ä
x x ä x
x x x x
ä ä x ä
x ä
ä ä
ä ä
x ä
x ä
x ä
x ä
x ä
x x
x x
x x
x ä
x x
x x
ä x
ä x
x ä x
x ä ä
x x x
x ä ä
x x x
ä x x
x ä ä
x x x
ä
ä
x
ä
ä
ä
ä
x
x
x
x
x
x
x
x
x
ä
x
ä
ä
ä
ä
ä
ä
ä
x
x
Sonstige Merkmale 83 Modem-Verbindungen sollten gesichert werden können. 84 Andere Protokolle wie IPX oder DECNET sollten unterstützt werden. 85 Network Address Translation (NAT) sollte ausgeführt werden können.
11.09.97
Firewall-Studie
Seite 179
SIEMENS
Test ausgewählter Firewallprodukte
Testkriterien
Zukünftige Sicherheitsanforderungen an Internet-Firewalls Ausführbarer Code 86 Mindestens folgende Arten an ausführbarem Code sollte gefiltert werden können JAVA MIME ActiveX 87 Mindestens folgende Arten an ausführbarem Code sollte auch in FTP erkannt und gefiltert werden können. JAVA MIME ActiveX 88 Es sollte ein Protokoll unterstützt werden, das es erlaubt, externe und third-party Inhaltsuntersuchungsprogramme zu integrieren. 89 Logfiles sollten automatisch ausgewertet werden. VPN / Sicherungsdienste / Key Management 90 VPNs sollten auf eine der folgenden Arten geknüpft werden können. IPSec TLS/SSL proprietär 91 Eine synchronisierte Zustandsübermittlung zwischen mehreren Firewalls sollte möglich sein. 92 Es sollte möglich sein, mehrere Firewalls von einer zentralen Stelle aus sicher zu verwalten. 93 Die Kommunikation mit einer Zertifizierungsstelle sollte unterstützt werden.
Seite 180
ä ä x
ä ä ä
ä x ä
ä x x
ä x x
x x x
ä x x
x x x
ä x x
x x x ä
x x x x
x x x x
x x x x
x x x x
x x x x
x x x x
x x x x
x x x x
ä
ä
ä
ä
x
x
x
x
x
ä x ä ä
ä x ä x
x ä x x
ä ä x x
x x ä x
x x ä ä
ä x x ä
x x ä x
x x x x
ä
x
ä
x
x
x
ä
x
x
ä
x
x
ä
x
x
x
x
x
Firewall-Studie
11.09.97
SIEMENS
Test auf Erfüllung der Sicherheitsanforderungen
Testkriterien
94 Folgende aktuelle Standards sollten unterstützt werden. IPSec ISAKMP/Oakley SKIP TLS/SSL RADIUS TACACS+
ä x ä x ä x
ä x x x ä ä
x x x ä x x
ä x x ä ä ä
x x x x x x
x x x x x x
ä x x x ä ä
x x x x x x
x x x x x x
ä
ä
ä
ä
ä
ä
x
x
ä
ä
x
x
x
x
x
x
x
x
ä
ä
ä
ä
ä
ä
ä
ä
ä
x
ä
x
x
x
x
x
ä
x
Sonstige Forderungen 95 Neue Protokolle sollten (z.B. durch generische Proxies) hinzugefügt werden können. 96 Die eingesetzten Programme sollten gut dokumentiert sein. 97 Eine Änderung der Software im zu schützenden Netz oder im unsicheren Netz sollte durch die Installation oder den Betrieb der Firewall nicht notwendig sein. 98 Multicast-Pakete sollten unterstützt werden.
11.09.97
Firewall-Studie
Seite 181
SIEMENS
Test ausgewählter Firewallprodukte
6.2 Penetrationstest Einem Penetrationstest wurden folgende Produkte unterzogen: • Eagle Version 4.0 der Firma Raptor Systems • FireWall-1 Version 3.0 der Firma Checkpoint • Gauntlet Version 3.2 der Firma Trusted Information Systems Der Penetrationstest zielte darauf ab, einerseits die Firewall zu überwinden, obwohl dies die durch die Firewall implementierte Sicherheitspolitik nicht zulassen soll, und andererseits die Firewall selbst zu kompromittieren. Es wurden Angriffe von einem externen Host simuliert. Die Angriffe wurden manuell und toolunterstützt (Internet Security Systems Safesuite V.03/97) durchgeführt. Im folgenden wird die verwendete Analysetopologie erläutert. Anschließend werden die Angriffe und die Ergebnisse für die einzelnen Produkte aufgeführt und in einer Übersichtsmatrix dargestellt. 6.2.1 Analysetopologie Abbildung 50 zeigt die für den Penetrationstest aufgebaute Analysetopologie. Von Host_EX aus wurden Angriffe einerseits auf die Firewall selbst aber auch Hosts im zu schützenden Bereich simuliert. Als Firewallkonzept wurde gemäß den getesteten Produkten das Konzept des Bastion-Host gewählt.
Host Y (Authorized Host)
Host_EX (Angreifer)
Sun Sparc 2 Routing Interface Internet Firewall
Interface Intranet Routing
Fan-Out
Sun Sparc 2 Host_IN
Sun Sparc 2 Host B
Windows NT PC Host C
Abbildung 50: Analyse-Labor Host_IN stellt einen zu schützenden Rechner im internen Netz dar, wohingegen Host_EX als Angriffsplattform außerhalb des zu schützenden Bereichs dient. Das Betriebssystem der Sun Sparc 2, auf der die Firewalls nacheinander installiert und getestet wurden, war Solaris 2.5.1.
Seite 182
Firewall-Studie
11.09.97
SIEMENS
Penetrationstest
6.2.2 Beschreibung der Angriffe Die ausgeführten Angriffe zielten einerseits auf einen Host hinter der Firewall und andererseits auf die Firewall selbst ab. Zuerst werden die manuell durchgeführten Angriffe chronologisch aufgeführt und erläutert. Anschließend werden die wichtigsten mittels ISS Safesuite automatisiert durchgeführten Angriffe beschrieben. 6.2.2.1 Manuell durchgeführte Angriffe 1. Vor Veränderungen an der Konfiguration von Host_EX und Host_IN wird mit Hilfe des ISS-Safesuite die Firewall auf offene Ports untersucht, mittels derer ein Angreifer in die Firewall eindringen könnte. 2. Anschließend wird versucht, das interne Interface von Host_IN aus und das äußere Interface von Host_EX aus per Ping zu erreichen. 3. Das UNIX-Kommando route wird ausgeführt, um Host_IN über die Firewall mit Host_EX zu verbinden. Das Kommando lautet: route add host IP-Adresse_Host_EX IP-Adresse_internes_Interface_Firewall 1.
4. Anschließend wird ein Telnet von Host_IN zu Host_EX initiiert. 5. Mittels des arp -a und des netstat-Kommandos wird überprüft, welche Sicht Host_EX beim Telnet auf Host_IN hat. 6. Nachdem diese Telnet-Verbindung aufgebaut ist, werden von Host_EX aus die Dienste Ping und Telnet auf die IP-Adresse von Host_IN abgesetzt. 7. Anschließend wird von Host_EX aus die IP-Adresse von Host_IN auf offene Ports überprüft. 8. Als nächstes wird mit dem ISS-Safesuite auf Host_IN, sowie dem internen und externen Interface der Firewall nach offenen Ports gesucht. 9. Um zu testen, ob die Firewall hereinkommenden IP-Datenverkehr von außen einschränken kann, wird der Telnet-Port 23 von Host_Y zu Host_IN geöffnet. 10. Als nächstes wird versucht, von Host_EX aus Host_IN per Telnet zu erreichen. 11. Während der bestehenden Telnet-Verbindung von Host_Y zu Host_IN werden die Ports der Firewall mittels ISS Safesuite gescanned, um zu sehen, ob Ports auf beiden Interfaces der Firewall durch die TelnetVerbindung geöffnet wurden. 12. Es wird untersucht, ob von Host_Y aus andere Ports als Port 23 auf Host_IN erreichbar sind. 13. Mit dem UNIX-Befehl netstat -a auf Host_IN wird überprüft, ob zu Host_IN andere connection requests außer zu Port 23 gelangt sind. 14. Um überprüfen zu können, ob die Firewall auch Angriffen während starken Netzverkehrs standhalten kann, wird ein Transfer einer großen Datei mittels FTP initiiert (37 MB). Dazu wird eine FTP-Sitzung von Host_IN aus zu Host_EX initiiert. Somit wird gleichzeitig überprüft, ob ein ordentlicher und sicherer Datentransfer per FTP über die Firewall möglich ist, der vom geschützten Bereich aus initiiert wurde. 15. Während des laufenden Datentransfers von Host_IN zu Host_EX wird von Host_EX aus versucht, Host_IN per Ping zu erreichen. Ferner wird nach offenen Ports auf den beiden Interfaces der Firewall und auf Host_IN gesucht. 16. Abschließend wird überprüft, inwieweit der Zugang von Host_IN zum Internet (Host_EX) eingeschränkt werden kann. Dazu wird eine Mail von Host_IN zu Host_EX gesendet. Anschließend wird der Zugang zu Port 25 (SMTP-Port) auf Host_EX für Host_IN explizit geöffnet und nochmals eine Mail von Host_IN zu Host_EX gesendet.
11.09.97
Firewall-Studie
Seite 183
SIEMENS
Test ausgewählter Firewallprodukte
6.2.2.2 Angriffe des ISS-Safesuite Der ISS-Safesuite Version 03/97 eingesetzt, um Angriffe inklusive Denial-of-Service automatisiert ausführen zu können. Im folgenden werden die wichtigsten Angriffe des ISS-Safesuite erläutert. 6.2.2.2.1 Angriffe des ISS-Safesuite auf die Firewall 1. Proxy Scan. Dieser Scan überprüft, welche WWW-, FTP- und E-mail-Proxies vorhanden sind. 2. Source Port. Ein Angreifer kann den Source-Port angeben, von dem eine TCP-Verbindung stammt. Ähnlich kann er den Port angeben, von dem aus er seinen Angriff fährt. Ist dies möglich, so wird der Ziel-Port auf dem Remote Host geöffnet, so daß eine Verbindung zu einer Maschine hinter der Firewall möglich wird. 3. Source Routing. Hier wird überprüft, ob die Firewall die Option Source Routing tatsächlich abgeschaltet hat. Ist dies nicht der Fall, so können Pakete mit Source Routing die Firewall umgehen. 4. Brute-Force-Attacke. Es wird überprüft, ob es gelingt, sich auf der Firewall als Server einzuloggen. Dabei werden Login-Namen, echte Namen und Namen rückwärts ausprobiert. 5. Firewall Denial-of-Service. Dabei werden die Angriffe TCP-SYN-Flooding, System Log Flood und Data Flood gefahren. (a) Beim TCP-SYN-Flooding wird eine große Anzahl an TCP-Verbindungen zur Firewall etabliert, jedoch nicht bestätigt. Es wird getestet, wieviele dieser halboffenen TCP-Verbindungen eine Firewall ertragen kann. (b) System Log Flood versucht, die System-Log-Partition der Firewall zu fluten. Dies kann zum Ziel führen, wenn die Partition zu klein gewählt wurde oder die Firewall großen Datenverkehr loggen muß. (c) Data Flood bombardiert einen bestimmten Port mit Daten, um zu erreichen, daß der jeweilige Dienst nicht mehr zur Verfügung steht. 6.2.2.2.2 Angriffe des ISS-Safesuite auf einen Host hinter der Firewall 1. Anonymous FTP. Dieser Angriff versucht über anonymous FTP die Datei /etc/passwd zu kopieren. 2. Echo, Chargen, Time und Daytime. Die Dienste Echo, Chargen, Time und Daytime können initiiert werden, um Daten von einem Dienst auf einer Maschine zu einem anderen Dienst auf einer anderen Maschine zu senden. Dies erzeugt eine Endlosschleife und führt zu einem Denial-of-Service. 3. Finger. Mit dem Befehl Finger kann ein Eindringling Informationen wie Login-Accounts erlangen. Es wird getestet, ob der Befehl Finger auf eine interne Maschine möglich ist. 4. IP-Spoofing. Mittels dieses Angriffs wird getestet, ob die TCP-Sequenz-Nummer vorhersagbar ist. Ist dies der Fall, so kann der Angreifer gefälschte Pakete einspielen, die vermeintlich von einer bekannten Maschine stammen. Dadurch können Dienste wie rsh und rlogin, deren Authentisierung auf IP-Adressen basiert, ausgenutzt werden. 5. NIS-Test. Hier wird überprüft, ob NIS angeboten wird, ob man den Domänen-Namen erraten kann und ob man das NIS-Paßwort über TCP oder UDP erhalten kann. 6. NNTP-Test. Dieser Test überprüft, ob NNTP angeboten wird, und ob Nutzer Nachrichten an Newsgroups ohne Autorisierung senden können. 7. Ping-to-Death. Hier werden überlange Ping-Nachrichten gesendet. 8. RIP-Spoofing. Indem ein Angreifer gefälschte RIP-Meldungen sendet, kann dieser das Routing für eine Netzverbindung manipulieren. Dadurch wird Sniffing, Spoofing und Hijacking ermöglicht. Wenn die Firewall kein RIP mit Authentisierung verwendet, ist sie für solche Angriffe verwundbar. Es wird getestet, ob RIP eingesetzt wird, und wenn ja ob mit Authentisierung. Seite 184
Firewall-Studie
11.09.97
SIEMENS
Penetrationstest
9. RPC/NIS-Update. Hier wird versucht, mittels NIS auf der Zielmaschine eine Datei zu erzeugen. Dies geschieht mit privilegierten Rechten. 10. Sendmail Debug Modus. Der Debug Modus erlaubt einem Angreifer, über den sendmail-Port Zugang zu einer Maschine zu erlangen. Hier wird überprüft, ob alte sendmail-Versionen, die den Debug-Modus zulassen, existieren. 11. Sendmail EXPN. EXPN erlaubt einem Angreifer zu bestimmen, ob ein Account auf einer Maschine existiert. Dadurch erhält der Angreifer genaue Informationen über ein Ziel für einen Brute-Force-Attack. 12. Sendmail Wizard Backdoor. Mittels des Steuerbefehls Wizard erhält ein Angreifer Zugang zu einer Maschine über einen sendmail-Port. Es wird getestet, ob der SMTP-Befehl Wizard erlaubt ist. 13. TFTP. Hier wird überprüft, ob mittels TFTP die Paßwort-Datei zu erhalten ist. 14. X Window System. Hier wird versucht, zu einem X-Server eines Hosts Kontakt aufzunehmen. Ist die xsetroot-Option abgeschaltet, so wird versucht, das root window bitmap zu setzen. Gelingt es, einen XServer zu kontaktieren, so kann der Angreifer remote Kommandos ausführen, als wäre er der Nutzer des X-Servers, oder Tastaturanschläge mitlesen. 6.2.3 Ergebnisse des Penetrationstests Die Ergebnisse des Penetrationstests der aktiv getesteten Produkte werden im folgenden aufgeführt. Dabei werden die manuell ausgeführten Angriffe für jedes Produkt im einzelnen erläutert. Darauf folgt die Zusammenfassung der Ergebnisse der manuell ausgeführten Angriffe und die durch ISS-Safesuite automatisierten Angriffe in einer Tabelle für alle Produkte. 6.2.3.1 Eagle Version 4.0 der Firma Raptor Systems Nach der Installation des Eagle wurden mittels des ISS-Safesuite die Ports beider Interfaces des Eagle in dessen Grundkonfiguration und die Ports von Host_IN untersucht. Anhand offener Ports könnte ein Angreifer in den Eagle eindringen. Anschließend wurde der Befehl ping auf das interne Interface des Eagle von Host_IN aus und das äußere Interface des Eagle von Host_EX aus abgesetzt. Es wurden keine offenen Ports gefunden. Somit war ein Zugang oder das Ausnutzen von Diensten nicht möglich. Das interne Interface des Eagle konnte von Host_IN aus und das äußere Interface des Eagle von Host_EX aus erfolgreich angepingt werden. Das UNIX-Kommando „route“ wurde ausgeführt, um Host_IN über den Eagle mit Host_EX zu verbinden. Das Kommando lautete: route add host IP-Adresse_Host_EX IP-Adresse_internes_Interface_Eagle 1
Dazu mußte der Befehl route zunächst über den Eagle zugelassen werden. Anschließend wurde ein Telnet von Host_IN zu Host_EX initiiert. Auch dazu mußte zunächst der Dienst Telnet von Host_IN zu Host_EX erst auf dem Eagle zugelassen werden. Dieses Telnet war erfolgreich. Nachdem NAT auf dem Eagle aktiviert wurde, konnte mittels des arp -a und netstat-Kommandos überprüft werden, ob der Eagle die IP-Adresse des internen Hosts auf die IP-Adresse seines externen Interfaces abbildet und somit die Struktur des internen Netzes verdeckt. Das arp-Kommando erzeugte die Antwort: le0 IP_Adresse_externes_Interface_Eagle Eagle versteckt also die interne IP-Adresse von Host_IN und dessen Ethernet-Adresse. Stattdessen zeigt es die Ethernet-Adresse des Eagle an. Nachdem diese Telnet-Verbindung aufgebaut war, wurden von Host_EX aus die Dienste ping und telnet auf die IP-Adresse von Host_IN versucht. Ferner wurde von Host_EX aus die IP-Adresse von Host_IN bezüglich offener Ports überprüft. 11.09.97
Firewall-Studie
Seite 185
SIEMENS
Test ausgewählter Firewallprodukte
Ping wurde nicht beantwortet. Auch wurden keine offenen Ports gefunden. Als nächstes wurde der ISS-Safesuite gegen Host_IN und das interne und externe Interface des Eagle im Heavy Scan Modus eingesetzt. Es wurden keine offenen Ports gefunden. Um zu testen, ob der Eagle hereinkommenden IP-Datenverkehr von außen einschränken kann, wurde der Telnet-Port 23 von Host_Y zu Host_IN auf dem Eagle geöffnet. Anschließend war ein Telnet von Host_Y zu Host_IN möglich. Als nächstes wurde versucht, von Host_EX zu Host_IN eine Telnet-Verbindung aufzubauen. Dies war nicht möglich. Während der bestehenden Telnet-Verbindung von Host_Y zu Host_IN wurden die Ports des Eagle gescanned, um zu sehen, ob Ports auf beiden Interfaces des Eagle durch die Telnet-Verbindung geöffnet wurden. Dies war erfolglos. Als nächstes wurde untersucht, ob von Host_Y aus andere Ports außer Port 23 auf Host_IN erreichbar sind. Außer Port 23 war kein Port von Host_EX aus auf Host_IN erreichbar. Mit dem UNIX-Befehl netstat -a auf Host_IN wurde überprüft, ob Host_IN außer zu Port 23 keinen anderen connection request erhalten hat. Der Eagle verwarf alle connection requests außer den zu Port 23. Um überprüfen zu können, ob der Eagle auch Angriffen während starken Netzverkehrs standhalten kann, wurde ein Transfer einer großen Datei mittels FTP initiiert (37 MB). Dazu wurde eine FTP-Sitzung von Host_IN aus zu Host_EX initiiert, nachdem eine solche auf dem Eagle zugelassen wurde. Somit wurde gleichzeitig überprüft, ob ein ordentlicher und sicherer Datentransfer per FTP über den Eagle möglich ist, der vom geschützten Bereich aus initiiert wurde. Beim Datentransfer traten keine Probleme auf. Während des laufenden Datentransfers von Host_IN zu Host_EX wurde von Host_EX aus versucht, Host_IN anzupingen. Ferner wurde nach offenen Ports auf den beiden Interfaces des Eagle und auf Host_IN gesucht. Während die Dateiübertragung mit ca. 170 KB/sec vonstatten ging, war kein unautorisierter Zugang weder zum Eagle noch auf Host_IN möglich. Als nächstes sollte überprüft werden, inwieweit der Zugang von Host_IN zum Internet (Host_EX) eingeschränkt werden kann. Dazu wurde versucht von Host_IN über den Port 25 zu Host_EX eine e-mail zu senden. Host_IN war es nicht möglich, e-mail an Host_EX zu senden. Danach wurde der Port 25 explizit für Verbindungen von Host_IN zu Host_EX erlaubt. Nun war des Mailen von Host_IN zu Host_EX erfolgreich. Zum Abschluß des Penetrationstests des Eagle wurde der ISS-Safesuite im Heavy-Scan-Modus inklusive Denial-of-Service auf Host_IN sowie auf die beiden Interfaces des Eagle ausgeführt. Dies ergab keine sicherheitsrelevanten Auffälligkeiten. Der Report befindet sich im Anhang (siehe Abschnitt 9).
Seite 186
Firewall-Studie
11.09.97
SIEMENS
Penetrationstest
Zusammenfassung: Der Eagle hielt allen beschriebenen Angriffen stand, die direkt auf die Interfaces der Firewall zielten. Ferner war es nicht möglich, interne (geschützte) Hosts zu kontaktieren, es sei denn der Eagle wurde für einen spezifischen Dienst geöffnet. Es wurden keine ausnutzbaren Schwächen auf dem Eagle gefunden. Auch wurden Angriffe während hohen Datenverkehrs gefahren. Während dieser Angriffe erlaubte der Eagle weder direkten Zugang noch Zugang zu einem anderen Host im geschützten Bereich. Die Tests wurden abgeschlossen mit dem Einsatz des Testtools Safesuite. Auch hier wurden keine Schwächen offenbar. Die Testergebnisse attestieren dem Eagle die Fähigkeit eines effektiven Netzwerk-Sicherheitskontrollmechanismus. Zu keinem Zeitpunkt war ein unautorisierter Zugang zum Eagle selbst oder zu einem durch ihn geschützten Host möglich. Sofern der Eagle richtig konfiguriert ist, kann er effizient Netzwerk-Sicherheit bieten. Wenn man den Eagle 4.0 entgegen der Empfehlung des Herstellers auf einem als Gateway eingerichteten Rechner installiert, so tritt folgendes Problem auf: Da auf dem Rechner die Datei /etc/gateways angelegt ist, wird beim booten unabhängig von der Anzahl der Netzinterfaces das IP-Forwarding eingeschaltet. Der Eagle setzt im Startup-Skript die Anzahl der Netzinterfaces auf 1, um gerade dies zu verhindern. Da aber /etc/gateways immer noch angelegt ist, wird trotzdem IP-Forwarding bei einem reboot eingeschaltet. Dies hebt die Funktionalität des Eagle auf. Abhilfe könnte hier die Modifikation des Startup-Skripts des Eagles schaffen, derart, daß die /etc/gateways gelöscht oder deren Existenz ignoriert wird. 6.2.3.2 FireWall-1 Version 3.0 der Firma Checkpoint Vor Veränderung der Konfiguration von Host_EX und Host_IN wurde mit Hilfe des ISS-Safesuite die Firewall-1 auf offene Ports untersucht, anhand derer ein Angreifer in die Firewall-1 eindringen könnte. Anschließend wurde das interne Interface von Host_IN aus und das äußere Interface von Host_EX aus angepingt. Es wurden keine offenen Ports gefunden. Somit war ein Zugang oder das Ausnutzen von Diensten nicht möglich. Es konnte nur das interne Interface von Host_IN aus und das äußere Interface von Host_EX aus erfolgreich angepingt werden. Das UNIX-Kommando „route“ wurde ausgeführt, um Host_IN über die Firewall-1 mit Host_EX zu verbinden. Das Kommando lautete: route add host IP-Adresse_Host_EX IP-Adresse_internes_Interface_Firewall-1 1
Dazu mußte zunächst dieser Befehl von Host_IN zu Host_EX über die Firewall-1 zugelassen werden. Anschließend wurde ein Telnet von Host_IN zu Host_EX initiiert. Dazu mußte auch der Dienst Telnet von Host_IN zu Host_EX zugelassen werden. Dieses Telnet war erfolgreich. Nachdem NAT auf der Firewall aktiviert wurde, wurde mittels des arp -a und netstat-Kommandos überprüft, welche Sicht Host_EX beim Telnet zu Host_IN hat. Das arp-Kommando erzeugte die Antwort: le0 IP_Adresse_externes_Interface_Firewall-1 Die Firewall-1 versteckt also die interne IP-Adresse von Host_IN und dessen Ethernet-Adresse. Stattdessen zeigt es die Ethernet-Adresse der Firewall-1 an. Nachdem diese Telnet-Verbindung aufgebaut war, wurde von Host_EX aus versucht, die Dienste Ping und Telnet auf die IP-Adresse von Host_IN abzusetzen. Ferner wurde von Host_EX aus die IP-Adresse von Host_IN bezüglich offener Ports überprüft. Ping wurde nicht beantwortet. Telnet wurde abgelehnt. Auch wurden keine offenen Ports gefunden. Als nächstes wurde ein Portscan mittels des ISS Safesuite gegen Host_IN und das interne und externe Interface der Firewall-1 ausgeführt. Es wurden keine offenen Ports gefunden. Um zu testen, ob die Firewall-1 hereinkommenden IP-Datenverkehr von außen einschränken kann, wurde der Telnet-Port 23 von Host_Y zu Host_IN geöffnet. Anschließend war ein Telnet von Host_Y zu Host_IN möglich. 11.09.97
Firewall-Studie
Seite 187
SIEMENS
Test ausgewählter Firewallprodukte
Als nächstes wurde versucht, von Host_EX zu Host_IN eine Telnet-Verbindung aufzubauen. Dies war nicht möglich. Während der bestehenden Telnet-Verbindung von Host_Y zu Host_IN wurden die Ports der Firewall-1 gescanned, um zu sehen, ob Ports auf beiden Interfaces der Firewall-1 durch die Telnet-Verbindung geöffnet wurden. Dies war erfolglos. Als nächstes wurde untersucht, ob von Host_Y aus andere Ports außer Port 23 auf Host_IN erreichbar sind. Außer Port 23 war kein Port von Host_EX aus auf Host_IN erreichbar. Mit dem UNIX-Befehl netstat -a auf Host_IN wurde überprüft, ob Host_IN außer zu Port 23 keinen anderen connection request erhalten hat. Die Firewall-1 wies alle connection requests außer den zu Port 23 ab. Um überprüfen zu können, ob die Firewall-1 auch Angriffen während starken Netzverkehrs standhalten kann, wurde ein Transfer einer großen Datei mittels FTP initiiert (37 MB). Dazu wurde eine FTP-Sitzung von Host_IN aus zu Host_EX initiiert. Somit wurde gleichzeitig überprüft, ob ein ordentlicher und sicherer Datentransfer per FTP über die Firewall1 möglich ist, der vom geschützten Bereich aus initiiert wurde. Beim Datentransfer traten keine Probleme auf. Während des laufenden Datentransfers von Host_IN zu Host_EX wurde von Host_EX aus versucht, Host_IN anzupingen. Ferner wurde nach offenen Ports auf den beiden Interfaces der Firewall-1 und auf Host_IN gesucht. Während die Dateiübertragung mit ca. 180 KB/sec vonstatten ging, war kein unautorisierter Zugang weder zur Firewall-1 noch auf Host_IN möglich. Als nächstes wurde überprüft, inwieweit der Zugang von Host_IN zum Internet (Host_EX) eingeschränkt werden kann. Dazu wurde versucht, von Host_IN aus eine e-mail an Host_EX zu senden. Host_IN war es nicht möglich, e-mail an Host_EX zu senden. Danach wurde der SMTP-Port 25 explizit für eine Verbindung von Host_IN zu Host_EX geöffnet. Nun war das Senden einer e-mail von Host_IN zu Host_EX erfolgreich. Abschließend wurde der ISS-Safesuite auf alle drei Interfaces (Host_IN und die beiden Interfaces der Firewall-1) im Heavy Scan Modus inklusive Denial-of-Service abgesetzt. Auch hier ergaben sich keine Auffälligkeiten. Der Report ist im Anhang beigefügt (siehe Abschnitt 9). Zusammenfassung: Die Firewall-1 bietet keine Routine zur Deinstallation an. Somit ist es notwendig, die Firewall-1 per Hand zu deinstallieren, was unter anderem auch das manuelle Einschalten des IP-Forwardings nach der Deinstallation erfordert. Die Firewall-1 hielt allen Angriffen stand, die direkt auf die Interfaces der Firewall-1 zielten. Ferner war es nicht möglich, interne (geschützte) Hosts zu kontaktieren, es sei denn die Firewall-1 wurde für einen spezifischen Dienst geöffnet. Es wurden keine ausnutzbaren Schwächen auf der Firewall-1 gefunden. Auch wurden Angriffe während hohen Datenverkehrs gefahren. Während dieser Angriffe erlaubte die Firewall-1 weder direkten Zugang noch Zugang zu einem anderen Host im geschützten Bereich. Die Tests wurden abgeschlossen mit dem Einsatz des Testtools Safesuite. Auch hier wurden keine Schwächen offenbar. Die Testergebnisse attestieren der Firewall-1 die Fähigkeit eines Netzwerk-Sicherheitskontrollmechanismus. Zu keinem Zeitpunkt war ein unautorisierter Zugang zur Firewall-1 selbst oder zu einem durch sie geschützten Host Seite 188
Firewall-Studie
11.09.97
SIEMENS
Penetrationstest
möglich. Sofern die Firewall-1 richtig konfiguriert ist, kann die Firewall-1 effizient Netzwerk-Sicherheit bieten. 6.2.3.3 Gauntlet Version 3.2 der Firma Trusted Information Systems Nach der Installation wurde in der Grundkonfiguration des Gauntlet und Host_EX und Host_IN mit Hilfe des ISS-Safesuite die Gauntlet auf offene Ports untersucht, anhand derer ein Angreifer in die Gauntlet eindringen könnte. Danach wurde der Befehl Ping auf das interne Interface von Host_IN aus und das äußere Interface von Host_EX aus abgesetzt. Der ISS Safesuite fand keine offenen Ports. Ein Zugang oder das Ausnutzen von Diensten war somit nicht möglich. Das interne Interface der Gauntlet konnte von Host_IN aus und das äußere Interface der Gauntlet von Host_EX aus erfolgreich angepingt werden. Das UNIX-Kommando „route“ wurde ausgeführt, um Host_IN über die Gauntlet mit Host_EX zu verbinden. Das Kommando lautete: route add host IP-Adresse_Host_EX IP-Adresse_internes_Interface_Gauntlet 1
Zuvor mußte der Befehl route in der Gauntlet zugelassen werden. Anschließend wurde ein Telnet von Host_IN zu Host_EX initiiert. Auch dieser Dienst mußte zunächst erlaubt werden. Dieses Telnet war erfolgreich. Nachdem NAT eingeschaltet wurde, wurde mittels des arp -a und netstat-Kommandos überprüft, ob die Gauntlet interne IP-Adressen auf die Adresse des externen Interfaces der Gauntlet abbildet. Das arp-Kommando erzeugte die Antwort: le0 IP_Adresse_externes_Interface_Gauntlet Die Gauntlet versteckt also die interne IP-Adresse von Host_IN und dessen Ethernet-Adresse. Stattdessen zeigt es die Ethernet-Adresse der Gauntlet an. Nachdem diese Telnet-Verbindung aufgebaut war, wurden von Host_EX aus die Dienste Ping und Telnet auf die IP-Adresse von Host_IN abgesetzt. Ferner wurde von Host_EX aus die IP-Adresse von Host_IN bezüglich offener Ports überprüft. Ping wurde nicht beantwortet. Auch wurden keine offenen Ports gefunden. Als nächstes wurde der ISS-Safesuite gegen Host_IN und das interne und externe Interface der Gauntlet im Heavy Scan Modus eingesetzt. Es wurden keine offenen Ports gefunden. Um zu überprüfen, ob die Gauntlet hereinkommenden IP-Datenverkehr von außen einschränken kann, wurde der Telnet-Port 23 von Host_Y zu Host_IN geöffnet. Anschließend war ein Telnet von Host_Y zu Host_IN möglich. Als nächstes wurde versucht, von Host_EX zu Host_IN eine Verbindung aufzubauen. Dies war nicht möglich. Während der bestehenden Telnet-Verbindung von Host_Y zu Host_IN wurden die Ports der Gauntlet gescanned, um zu sehen, ob Ports auf beiden Interfaces der Gauntlet durch die Telnet-Verbindung geöffnet wurden. Dies war erfolglos. Als nächstes wurde untersucht, ob von Host_Y aus andere Ports außer Port 23 auf Host_IN erreichbar sind. Außer Port 23 war kein Port von Host_EX aus auf Host_IN erreichbar.
11.09.97
Firewall-Studie
Seite 189
SIEMENS
Test ausgewählter Firewallprodukte
Mit dem UNIX-Befehl netstat -a auf Host_IN wurde überprüft, ob Host_IN außer zu Port 23 keinen anderen connection request erhalten hat. Die Gauntlet wies alle connection requests außer den zu Port 23 ab. Um überprüfen zu können, ob die Gauntlet auch Angriffen während starken Netzverkehrs standhalten kann, wurde ein Transfer einer großen Datei mittels FTP initiiert (37 MB). Dazu wurde der FTP-Dienst von Host_IN zu Host_EX an der Gauntlet erlaubt und eine FTP-Sitzung von Host_IN aus zu Host_EX initiiert. Somit wurde gleichzeitig überprüft, ob ein ordentlicher und sicherer Datentransfer per FTP über die Gauntlet möglich ist, der vom geschützten Bereich aus initiiert wurde. Beim Datentransfer traten keine Probleme auf. Während des laufenden Datentransfers von Host_IN zu Host_EX wurde von Host_EX aus versucht, Host_IN anzupingen. Ferner wurde nach offenen Ports auf den beiden Interfaces der Gauntlet und auf Host_IN gesucht. Während die Dateiübertragung mit ca. 190 KB/sec vonstatten ging, war kein unautorisierter Zugang weder zur Gauntlet noch auf Host_IN möglich. Als nächstes sollte überprüft werden, inwieweit der Zugang von Host_IN zum Internet (Host_EX) eingeschränkt werden kann. Dazu wurde der versucht, eine e-mail von Host_IN an Host_EX zu senden. Host_IN war es nicht möglich, e-mail direkt an Host_EX zu senden.
Danach wurde der SMTP-Port 25 für Verbindungen von Host_IN zu Host_EX explizit auf der Gauntlet erlaubt. Nun war das mailen von Host_IN zu Host_EX erfolgreich. Zum Abschluß des Penetrationstests der Gauntlet wurde der ISS-Safesuite im Heavy-Scan-Modus inklusive Denial-of-Service auf Host_IN und die beiden Interfaces der Gauntlet angesetzt. Dies ergab keine sicherheitsrelevanten Auffälligkeiten. Der Report ist im Anhang beigefügt (siehe Abschnitt 9). Zusammenfassung: Weil der Output der Gauntlet per default auf die Konsole geleitet wird, war ein Arbeiten mit der Konsole nach der Installation der Gauntlet nicht mehr möglich. Um dies abzuwenden, mußte in der Datei /usr/local/etc/netperm_table der Eintrag auf alerts: enable none geändert werden, damit der Bildschirm der Konsole nicht mehr mit Meldungen überflutet wurde. Die Gauntlet hielt allen Angriffen stand, die direkt auf die Interfaces der Gauntlet zielten. Ferner war es nicht möglich, interne (geschützte) Hosts zu kontaktieren, es sei denn die Gauntlet wurde für einen spezifischen Dienst geöffnet. Es wurden keine ausnutzbaren Schwächen auf der Gauntlet gefunden. Auch wurden Angriffe während hohen Datenverkehrs gefahren. Während dieser Angriffe erlaubte die Gauntlet weder direkten Zugang noch Zugang zu einem anderen Host im geschützten Bereich. Die Tests wurden abgeschlossen mit dem Einsatz des Testtools Safesuite. Auch hier wurden keine Schwächen offenbar. Die Testergebnisse attestieren der Gauntlet die Fähigkeit eines Netzwerk-Sicherheitskontrollmechanismus. Zu keinem Zeitpunkt war ein unautorisierter Zugang zur Gauntlet selbst oder zu einem durch sie geschützten Host möglich. Sofern die Gauntlet richtig konfiguriert ist, kann die Gauntlet effizient Netzwerk-Sicherheit bieten.
Seite 190
Firewall-Studie
11.09.97
SIEMENS
Penetrationstest
6.2.3.4 Analyse-Übersicht Angriff / Produkt
Manuelle Angriffe39 Erkennen des simulierten Subnetzes und Abweisen aller Verbindungen. Existenz einer Deinstallationsroutine. Output per Default auf Konsole. Firewall in der Grundkonfiguration auf offene Ports mit dem ISS-Safesuite untersuchen. Internes Interface von Host_IN und äußeres Interface von Host_EX mit ping kontaktieren. Ping zulassen. Erneut internes Interface von Host_IN und äußeres Interface von Host_EX mit ping kontaktieren. Ausführen des UNIX-Kommandos „route“, um Host_IN über die Firewall mit Host_EX zu verbinden. Zulassen des Kommandos route. Erneutes ausführen des UNIX-Kommandos „route“, um Host_IN über die Firewall mit Host_EX zu verbinden. Initiieren einer Telnet-Verbindung von Host_IN zu Host_EX. Zulassen der Telnet-Verbindung. Erneutes Initiieren einer Telnet-Verbindung von Host_IN zu Host_EX. NAT aktivieren. Überprüfen, ob die Firewall die Adresse von Host_IN verdeckt, mittels der Kommandos arp -a und netstat. Host_EX sendet die Dienste ping und telnet an IP-Adresse von Host_IN. Überprüfen von Host_EX aus IP-Adresse von Host_IN bezüglich offener Ports. Einsatz des ISS-Safesuite gegen Host_IN und das interne und externe Interface der Firewall im Heavy Scan Modus. Öffnen des Telnet-Port 23 von Host_Y zu Host_IN. Versuch, von Host_EX aus zu Host_IN eine Telnet-Verbindung aufzubauen. Scannen der Ports während der bestehenden Telnet-Verbindung von Host_Y zu Host_IN, um zu sehen, ob Ports auf beiden Interfaces der Firewall durch die Telnet-Verbindung geöffnet wurden. Untersuchen, ob von Host_Y aus andere Ports außer Port 23 auf Host_IN erreichbar sind. Überprüfung mit dem UNIX-Befehl netstat -a, ob Host_IN außer zu Port 23 noch andere connection request erhalten hat. Öffnen einer FTP-Sitzung von Host_IN zu Host_EX. Initiieren eines Datentransfers mittels FTP von Host_IN zu Host_EX. Senden des Dienstes ping von Host_EX zu Host_IN, während des FTP-Datentransfers. Suche nach offenen Ports auf den beiden Interfaces der Firewall und auf Host_IN während des FTPDatentransfers. Senden einer e-mail von Host_IN zu Host_EX. Zulassen des Zugangs zu Port 25 (SMTP-Port) auf Host_EX für Host_IN. Erneutes Senden einer e-mail von Host_IN zu Host_EX.
--
ä + ä ä --
X + X ä --
+ + -+ +
+ + -+ +
+ + -+ +
-+ + + + + -ä
-+ + + + + -ä
-+ + + + + -ä
+ -ä
+ -ä
+ -ä
ä ä
ä ä
ä ä
+ + + ä
+ + + ä
+ + + ä
-+ +
-+ +
-+ +
X -ä ä
39
Legende: + = erfolgreich bzw. vorhanden, -- = nicht erfolgreich bzw. nicht vorhanden, X = sicherheitsrelevante Auffälligkeit, ä = keine sicherheitsrelevante Auffälligkeit. Die Zahlen verweisen auf die Überprüfung der Anforderungen des entsprechenden Produktes (siehe 6.1.1 - 6.1.9). 11.09.97
Firewall-Studie
Seite 191
SIEMENS
Test ausgewählter Firewallprodukte
Angriff / Produkt
Einsatz des ISS-Safesuite40 ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä
Proxy Scan Source Port Source Routing Brute-Force-Attack TCP-SYN-Flooding System Log Flood Data Flood Anonymous FTP Echo, Chargen, Time und Daytime Finger IP-Spoofing NIS-Test NNTP-Test Ping-to-Death RIP-Spoofing RPC/NIS-Update Sendmail Debug Modus Sendmail EXPN Sendmail Wizard Backdoor TFTP X. Window System
40
ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä
Legende: = ä keine sicherheitsrelevante Auffälligkeit, X = sicherheitsrelevante Auffälligkeit.
Seite 192
Firewall-Studie
11.09.97
ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä ä
SIEMENS
Preis - Leistungsübersicht
6.3 Preis - Leistungsübersicht41 Angesichts der verschiedenen Konfigurationsmöglichkeiten und der Vielzahl von Kombinationsmöglichkeiten werden Paketpreise hier nicht angegeben. Die Tabelle gibt eine Übersicht über den Typ des Produkts (d. h., welche Komponenten in der Basisversion enthalten sind) sowie über den Minimalpreis (d. h. bei geringster Anzahl von lizensierten Benutzern oder Rechnern). Leistung / Produkt
Statischer Paketfilter Dynamischer Paketfilter Applikationsfilter
ä
ä
ä ä
ä
ä
ä
ä
ä ä ä
7
12
10
16
4,3
220
Screened Subnet Hardware im Preis enthalten Einzelpreis ab TDM (ca.)
ä
ä ä
ä 17
3,5
Tabelle 27: Preis-Leistungsmatrix
41
Legende: = ä vorhanden.
11.09.97
Firewall-Studie
Seite 193
0
SIEMENS
Abkürzungsverzeichnis
7 Abkürzungsverzeichnis ACK ACL AFT AH AIX API ARP AS ASC ASCII ASN.1 ATM BGP BSD BSI CA CBC CERT CGI CHAP CLNP COM CR CRAM CSCW DCC DCOM DECNET DES DES-CBC DES-ECB DM DMZ DNS DOS DSS EBCDIC ECB EIT EOT ESP FDDI FF FIN FSP FTP ftpd FW FWTK GIF GUI Seite 194
Acknowledgement Access Control List Authenticated Firewall Traversal Authentication Header UNIX-Betriebssystem von IBM Application Programming Interface Address Resolution Protocol Autonome Systeme Application Sharing Component American Standard Code for Information Interchange Abstract Syntax Notation 1 Asynchronous Transfer Mode Border Gateway Protocol Berkeley Software Distribution Bundesamt für Sicherheit in der Informationstechnik CERT-Advisory Cypher Block Chaining Computer Emergency Response Team Common Gateway Interface Challenge-Handshake Authentication Protocol Connectionless Network Protocol Component Object Model (von Microsoft) Carriage Return Challenge-Response Authentication Method Computer Supported Coorporative Work Direct Client Connection Distributed Component Object Model (von Microsoft) Netzsoftware für DEC-VMS-Rechner Data Encryption Standard Data Encryption Standard Cypher Block Chaining Mode Data Encryption Standard Electronic Codebook Mode Deutsche Mark Demilitarisierte Zone Domain Name System Disk Operating System Digital Signature Standard Extended Binary Coded Decimal Interchange Code Electronic Codebook Mode Enterprise Integration Technologies End of Transmission Encapsulation Security Payload Fiber Distributed Data Interface Form Feed Final File Service Protocol File Transfer Protocol FTP-Dämon Firewall Firewall Toolkit Graphics Interchange Format Graphical User Interface Firewall-Studie
11.09.97
SIEMENS HMAC HTML HTRQ HTTP I/O IAB IANA ICMP ICV ID IETF IKMP IP IPSec IPSec-ESP IPv4 IPv6 IPX IRC ISAKMP ISS LAN LF LPR MAC MD5 MD2 MIB MIME MO NAT NFS NIS NIS+ NLRI NNTP NTP OS OSPF PAT PDU PEM PGP PI PKCS-7 POP PPP QoS RADIUS RARP RC2 RC4 RECV RFC RIP RNR RPC RR 11.09.97
Kaufempfehlung Hashing Message Authentication Hyper Text Markup Language Hypertext Transfer Request Hyper Text Transfer Protocol Input/Output Internet Activities Board Internet Assigned Numbers Authority Internet Control Message Protocol Integrity Check Value Identity Internet Engineering Task Force Internet Key Management Protocol Internet Protocol Internet Protocol Security Protocol Internet Protocol Security Protocol Encapsulating Security Payload Internet Protocol version 4 Internet Protocol version 6 Internet Packet Exchange Protocol Internet Relay Chat Internet Security Association and Key Management Protocol Internet Security Systems Local Area Network Line Feed Line Printer Spooler Message Authentication Code Message Digest 5 Message Digest 2 Management Information Database Multipurpose Internet Mail Extensions Managed Object Network Address Translation Network File System Network Information System Network Information System + Network Layer Reachability Information Network News Transfer Protocol Network Time Protocol Operating System Open Shortest Path First Port Address Translation Protocol Data Unit Privacy Enhanced Mail Pretty Good Privacy Protocol Interpreter Public Key Cryptography Standards No. 7 Post Office Protocol Point to Point Protocol Quality of Service Remote Authentication Dial-In User Service Reverse Address Resolution Protocol Rivest’s Cipher 2 Rivest’s Cipher 4 Receive Request For Comments Routing Information Protocol Receive Not Ready Remote Procedure Call Resource Record Firewall-Studie
Seite 195
SIEMENS RSA Secure-RPC SHA S-HTTP SLIP S-MIME SMS SMTP SNAP SNK SNMP SNMPv2 SNP Spec SPI SSL SSLv3 SYN TACACS TCB TCP TFTP TIS TLS ToS TTL UDP ULP URL US USD UUCP VM VPN VT WAIS WAN WWW ZT IK
Seite 196
Abkürzungsverzeichnis Rivest-Shamir-Adleman-Algorithmus Secure Remote Procedure Call Secure Hash Algorithm Secure Hyper Text Transfer Protocol Serial Line Internet Protocol Secure Multipurpose Internet Mail Extensions Security Management Station Simple Mail Transfer Protocol Subnetwork Access Protocol Secure Net Key Simple Network Management Protocol Simple Network Management Protocol version 2 Subnet Protocol Specification Security Parameter Index Secure Socket Layer Secure Socket Layer version 3 Synchronize Terminal Access Controller Access Control System Transmission Control Block Transmission Control Protocol Trivial File Transfer Protocol Trusted Information Systems Transport Layer Security Type of Service Time to Live User Datagram Protocol Upper Layer Protocol Uniform Resource Locator United States US-Dollar Unix to Unix Copy Protocol Virtual Machine Virtual Private Network Vertical Tab Wide Area Information System Wide Area Network World Wide Web Zentralabteilung Technik Abteilung Information und Kommunikation der Siemens AG
Firewall-Studie
11.09.97
SIEMENS
Kaufempfehlung
8 Literatur [Atkinson 95] [Atkinson 97] [Bad, Kohli 96]
[Bellovin 89] [Bellovin 94] [Bellovin 96]
[Black 95] [BSI 96] [Chapman, Zwicky 96] [Cheswick, Bellovin 94] [Data82 97] [Dr. Dobb's 96] [Ellermann 93] [Ellermann 96]
[ITU_T 93] [ITU_T 95] [Joncheray 95]
[Lu 95] [Martin, Rajagopalan, Rubin 97]
[Metzger et al. 95] [Morris 85]
[MSST 96]
[Munzert, Wolff 96] [Orman 96] [Pfaff 96]
11.09.97
R. Atkinson. "IP Encapsulating Security Payload (ESP)". RFC 1827, August 1995. Randall J. Atkinson "Toward a More Secure Internet", Computer, pages 57 - 61, January 1997. L. Badger, M. S. Kohli "Java: Holds Great Potential - But Also Security Concerns", Data Security Letter, Number 69, March 1996. S.M. Bellovin: "Security Problems in the TCP/IP Protocol Suite", ACM Comput. Commun. Rev. 19 (2), p. 32 - 48, 1989. Steven M. Bellovin. "Security Concerns for IPng". RFC 1675, August 1994. Steven M. Bellovin. "Problem Areas for the IP Security Protocols". Internet Draft, (http://www.ietf.cnri.reston.va.us/ids.by.wg/ipsec.html) 1996. Uyless Black: “TCP/IP and Related Protocols” McGraw-Hill, Inc. 1995. Bundesamt für Sicherheit in der Informationstechnik: „Sicherheitsanforderungen an Internet-Firewalls“ März 1996 D. B. Chapman, E. D. Zwicky "Einrichten von Internet Firewalls", O'Reilly, 1996. W.R. Cheswick, S.M Bellovin: “Firewalls and Internet Security - Repelling the Wily Hacker” Addison Wesley 1994. Data Security Letter, Number 82, May 1997 Dr. Dobb's Journal, Jan. 1996, Seite 66-70. Uwe Ellermann. "Ein Firewall am Fachbereich Informatik". Universität Hamburg, Dezember 1993. IPv6 und Firewalls "SECURICOM -- 14th International Congress on Computer and Communications Security Protection" 5. and 6. June 1996, Paris, France. ITU-T Recommendations X.509 – X.511, 11/93 „The Directory: Authentication Framework“ ITU-T Q15/7 Rapporteur, 04/95 „Draft Amendments on Extensions to X.509 | ISO/IEC 9594-8 Certificate Definitions“ Joncheray, L. "A Simple Active Attack Against TCP", The 5th USENIX UNIX Security Symp., Conf. Proc., Salt Lake City, USA, Jun 5-7, 1995 Berkeley: USENIX Association ISBN 1880446-70-7, S. 7-19. A. Luotonen, "Tunneling SSL Through a WWW Proxy". Internet Draft, December 14, 1995. Martin, Rajagopalan, Rubin "Blocking Java Applets at the Firewall" Internet Society Symposium on Network and Distributed System Security, February 10-11, 1997. Perry Metzger, Phil Karn and William Allen Simpson. "The ESP DES-CBC Transform". RFC 1829, August 1995. Robert T. Morris. A weakness in the 4.2BSD UNIX TCP/IP software. Computing Science Technical Report 117, AT&T Bell Laboratories, Murray Hill, NJ, February 1985. Maughan, DD., Schertler, M., Schneider, M., Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)". Internet draft of the IPSec WG, June 13, 1996. M. Munzert, C. Wolff, "Firewalls - Schutz vor Angriffen aus dem Internet", DuD 2/96. Orman, H. K., "The Oakley Key Determination Protocol". Internet draft of the IPSec WG, May 1996. Pfaff, O., „Secure Application Sharing under X“. The X Resource, Issue Seventeen, 10th Annual X Technical Conference, San Jose, California, February 12-14, 1996
Firewall-Studie
Seite 197
SIEMENS [Ramsey 94] [RFC 782] [RFC 791] [RFC 792] [RFC 793] [RFC 821] [RFC 822] [RFC 959] [RFC 977]
[RFC 1058] [RFC 1094] [RFC 1213]
[RFC 1247] [RFC 1267] [RFC 1305] [RFC 1416] [RFC 1813] [RFC 1825] [RFC 1826] [RFC 1827] [RFC 1828] [RFC 1829] [RFC 1851] [RFC 1852] [RFC 1858] [RFC 1928] [Schel 94] [Schlüter, Übelacker, 96] [SSL_Web]
Seite 198
Literatur R. Ramsey, „NIS+ - Aufbau, Installation, Administration“ Verlag Heinz Heise, 1994 J. Nabielsky, A. Skelton, "Virtual Terminal management model", 01/01/1981. J. Postel, "Internet Protocol", 09/01/1981. J. Postel, "Internet Control Message Protocol", 09/01/1981. J. Postel, "Transmission Control Protocol", 09/01/1981. J. Postel, "Simple Mail Transfer Protocol", 08/01/1982. D. Crocker, "Standard for the format of ARPA Internet text messages", 08/13/1982. J. Postel, J. Reynolds, "File Transfer Protocol", 10/01/1985. B. Kantor, P. Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", 02/01/1986. C. Hedrick, "Routing Information Protocol", 06/01/1988. Sun Microsystems, Inc, "NFS: Network File System Protocol specification", 03/01/1989 K. McCloghrie, M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", 03/26/1991. J. Moy, "OSPF Version 2", 08/08/1991. K. Lougheed, Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", 10/25/1991. D. Mills, "Network Time Protocol (v3)", 04/09/1992. D. Borman, "Telnet Authentication Option", 02/01/1993. B. Callaghan, B. Pawlowski, P. Staubach, "NFS Version 3 Protocol Specification", 06/21/1995. Randall Atkinson. "Security Architecture for the Internet Protocol". RFC 1825, August 1995. Randall Atkinson. "IP Authentication Header". RFC 1826, August 1995. Randall Atkinson. "IP Encapsulating Security Payload (ESP)". RFC 1827, August 1995. P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", 08/09/1995. P. Metzger, P. Karn, W. Simpson, "The ESP DES-CBC Transform", 08/09/1995. P. Metzger, P. Karn, W. Simpson, "The ESP Triple DES-CBC Transform", 10/02/1995. P. Metzger, W. Simpson, "IP Authentication using Keyed SHA", 10/02/1995. P. Ziemba, D. Reed, P. Traina, "Security Considerations for IP Fragment Filtering", 10/25/1995. M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones, "SOCKS Protocol Version 5", 04/03/1996. Scheller, Boden, Geenen, Kampermann, „Internet: Werkzeuge und Dienste“, ASK 1994 O. Schlüter, H.K. Übelacker "Die Schwächen von FirewallLösungen", ntz, Heft 11/1996. SSL-Internet-Draft: http://home.netscape.com/newsref/Std/SSL.html
Firewall-Studie
11.09.97
SIEMENS
Kaufempfehlung
9 Anhang Im folgenden sind die Reports des ISS-Safesuite aufgeführt. Die Reports sind aufgeteilt in •
Vulnerability
•
Services
• •
Host Inventory
zeigt Konfigurationen und Anomalien, die von ISS-Safesuite entdeckt wurden. gibt Informationen über TCP, sowie Versionsinformationen für SMTP, FTP und Telnet konsolidiert die Informationen pro Host gibt an, welche Hosts untersucht wurden, welche Hosts aktiv waren, welche Hosts welche Dienste anboten und ob ein DNS-Hostname existiert.
Jeder Report gibt an, welche Hosts gefunden wurden, denen die untersuchten Hosts trauen.
Report des ISS-Safesuite42 Internet Security Scanner ©1992-1997 ISS SAFEsuite Version 4.2.0 By Internet Security Systems, Inc. Analysis Report Summary Report of Vulnerabilities Summary Information Hosts Scanned: 3 Hosts with Active Services: 0 Hosts with No Services: 3 Start Time: Tue Jul 1 15:13:26 1997 End Time : Tue Jul 1 15:14:42 1997 Total Time: 1 minute 16 seconds Scan Completed Normally Total Number of Vulnerability Risks: 0 Maximum License Number Reached: 0 Out of Range: 0 Open Ports via Socks Service [High Risk]: 0 Open Defaults found through Telnet [High Risk]: 0 Open Defaults found through Rexec [High Risk]: 0 Open Defaults found through FTP [High Risk]: 0 Open Defaults found through POP3 [High Risk]: 0 Accounts accessible through Rsh [High Risk]: 0 X Check [High Risk]: 0 Sendmail Vulnerable Version [High Risk]: 0 Uudecode Alias in Sendmail [High Risk]: 0 Remote Execution Hole in Sendmail [High Risk]: 0 Wizard Backdoor in Sendmail [High Risk]: 0 Debug in Sendmail [High Risk]: 0 Remote Execution Hole through Identd [High Risk]: 0 INND Vulnerable Version [High Risk]: 0 FTP Site Exec Vulnerable [High Risk]: 0 Rlogin -froot Vulnerability [High Risk]: 0 Rsh Vulnerable in hosts.equiv [High Risk]: 0 Rexd [High Risk]: 0 HTTP (WWW) vulnerable server [High Risk]: 0 Rsh Vulnerable through TCP Seq Prediction Spoofing [High Risk]: 0 Rsh Null Vulnerable [High Risk]: 0 Rlogin Vulnerable through TCP Seq Prediction Spoofing: 0 Admind [High Risk]: 0 Mountable [High Risk]: 0 42
Hier ist nur das Testergebnis für den Eagle wiedergegeben. Der Einsatz des ISS-Safesuite auf die Firewall1 und die Gauntlet erzeugte den gleichen Report. 11.09.97
Firewall-Studie
Seite 199
SIEMENS
Anhang Mountable via Portmapper [High Risk]: 0 NFS Mountable via Ultrix Remount Bug [High Risk]: 0 NFS Writable [High Risk]: 0 NFS UID Vulnerability [High Risk]: 0 NFS CD Vulnerability [High Risk]: 0 NFS MKNOD Vulnerability [High Risk]: 0 NFS Guess Vulnerability [High Risk]: 0 NFS Access Files [Medium Risk]: 0 Dynamic Linker Telnet Vulnerability [High Risk]: 0 Netbios SMB Easy Password [High Risk]: 0 Open Defaults found on Cisco device [High Risk]: 0 Open Administrative Account found on Cisco device [High Risk]: 0 Remote Execution Hole through Syslog Buffer Overflow [High Risk]: 0 RPC Statd file creation and removal vulnerability [High Risk]: 0 HTTP Proxy Penetrated [High Risk]: 0 FTP Proxy Penetrated [High Risk]: 0 HTTP (WWW) known vulnerable server [High Risk]: 0 Exploit of phf program in /cgi-bin executed an arbitrary command [High Risk]: 0 Server indicated presence of potentially exploitable program in /cgi-bin [High Risk]: 0 A CGI program executed an arbitrary command [High Risk]: 0 Server allowed exploit of .bat and .cmd bug [High Risk]: 0 A password-protected WWW resource was accessed by brute force [High Risk]: 0 Server returned a file listing for a directory that had no index [Low Risk]: 0 Open Defaults found through Telnet on TIS firewall [High Risk]: NA Open Defaults found through Telnet on Checkpoint Firewall [High Risk]: NA Open Defaults found through FTP On Catapult [High Risk]: NA Open Defaults found through Telnet on Raptor firewall [High Risk]: NA Files Obtained [Medium Risk]: 0 Routed service active [Medium Risk]: 0 UUCP available [Medium Risk]: 0 Host susceptible to UDP bomb packet [Medium Risk]: 0 Finger Bomb [Medium Risk]: 0 Host susceptible to huge ping packets [Medium Risk]: NA TCP Sequence Predictable [Medium Risk]: 0 Anonymous FTP with writable directories [Medium Risk]: 0 Wall Daemon [Medium Risk]: 0 Selection_Svc Vulnerable [Medium Risk]: 0 TFTP [Medium Risk]: 0 TFTP Output [Medium Risk]: 0 NIS passwd via TCP [Medium Risk]: 0 NIS passwd via UDP [Medium Risk]: 0 Domainnames and NIS Server [Medium Risk]: 0 NIS Maps [Low Risk]: 0 Anonymous FTP [Low Risk]: 0 Netbios SMB Root Share [Medium Risk]: 0 Netbios SMB Dot Dot Bug [Medium Risk]: 0 Netbios SMB NT Dot Dot Bug [Medium Risk]: 0 Chargen Service [Medium Risk]: 0 Echo Service [Medium Risk]: 0 Windows 95 Password Cache Files [Medium Risk]: 0 RIP tables modified [Medium Risk]: 0 Sync Storm [Medium Risk]: 0 Syslog Flood [Medium Risk]: 0 Data Flood [Medium Risk]: 0 Exploit of test-cgi script returned listing of /cgi-bin [Medium Risk]: 0 WWW server returned a listing of the directory above ServerRoot [Medium Risk]: 0 Netstat [Low Risk]: 0 Sysstat [Low Risk]: 0 Bootparam [Low Risk]: 0 BootparamDom [Low Risk]: 0 Finger [Low Risk]: 0 Rusers Output [Low Risk]: 0
Seite 200
Firewall-Studie
11.09.97
SIEMENS
Kaufempfehlung Finger Output [Low Risk]: 0 SNMP Public Information [Low Risk]: 0 Old Sendmail Version [Low Risk]: 0 Verify Account Information About Users with Sendmail [Low Risk]: 0 Expand Account Information About Users with Sendmail [Low Risk]: 0 NNTP Daemon [Low Risk]: 0 Trace Routing of Packets [Low Risk]: 0 Open/Close Connection Flood [Low Risk]: 0 Old INND Version [Low Risk]: 0 RWHO Daemon Overflow [Low Risk]: 0 SMTP Timer Abort: 0 Netbios Tests Disabled: 0 Unable to Bind to Ident: 0 Unable to Listen on Ident: 0
========== End of Report =========
Internet Security Scanner ©1992-1997 ISS SAFEsuite Version 4.2.0 By Internet Security Systems, Inc. Analysis Report Report of Vulnerabilities Summary Information Hosts Scanned: 3 Hosts with Active Services: 0 Hosts with No Services: 3 Start Time: Tue Jul 1 15:13:26 1997 End Time : Tue Jul 1 15:14:42 1997 Total Time: 1 minute 16 seconds Scan Completed Normally Information by Vulnerability ========== End of Report =========
Internet Security Scanner ©1992-1997 ISS SAFEsuite Version 4.2.0 By Internet Security Systems, Inc. Analysis Report Host Inventory Summary Information Hosts Scanned: 3 Hosts with Active Services: 0 Hosts with No Services: 3 Start Time: Tue Jul 1 15:13:26 1997 End Time : Tue Jul 1 15:14:42 1997 Total Time: 1 minute 16 seconds Scan Completed Normally No Response, Inactive with Host Names IP Address: 146.180.13.7 Host Name: dorifer.mchp.siemens.de IP Address: 146.180.10.55 Host Name: poing.mchp.siemens.de IP Address: 146.180.1.198 Host Name: m68945pp.mchp.siemens.de
Hosts Trusted by scanned Hosts No trusted hosts found. ========== End of Report ========= 11.09.97
Firewall-Studie
Seite 201
SIEMENS
Anhang
Internet Security Scanner ©1992-1997 ISS SAFEsuite Version 4.2.0 By Internet Security Systems, Inc. Analysis Report Report of Services Summary Information Hosts Scanned: 3 Hosts with Active Services: 0 Hosts with No Services: 3 Start Time: Tue Jul 1 15:13:26 1997 End Time : Tue Jul 1 15:14:42 1997 Total Time: 1 minute 16 seconds Scan Completed Normally Information by Service Port Failure Was found on the following hosts: IP Address: 146.180.13.7
Hostname: dorifer.mchp.siemens.de
Service Failure 13326 („crossfire[game]“ service) : Non-responding socket. Service Failure 9000 („unknown“ service) : Non-responding socket. Service Failure 8000 („unknown“ service) : Non-responding socket. Service Failure 8080 („httpd“ service) : Non-responding socket. Service Failure 7002 („backdoor?“ service) : Non-responding socket. Service Failure 7001 („backdoor?“ service) : Non-responding socket. Service Failure 7000 („afsserv or dos“ service) : Non-responding socket. Service Failure 6667 („irc“ service) : Non-responding socket. Service Failure 6666 („irc-serv“ service) : Non-responding socket. Service Failure 6000 („X“ service) : Non-responding socket. Service Failure 5858 („netrek[game]“ service) : Non-responding socket. Service Failure 5000 („unknown“ service) : Non-responding socket. Service Failure 4557 („fax“ service) : Non-responding socket. Service Failure 4000 („unknown“ service) : Non-responding socket. Service Failure 3000 („unknown“ service) : Non-responding socket. Service Failure 2592 („netrek[game]“ service) : Non-responding socket. Service Failure 2048 („dls-monitor“ service) : Non-responding socket. Service Failure 2003 („cfinger“ service) : Non-responding socket. Service Failure 2000 („callbook“ service) : Non-responding socket. Service Failure 1999 („tcp-id-port“ service) : Non-responding socket. Service Failure 1525 („oracle“ service) : Non-responding socket. Service Failure 1524 („ingreslock“ service) : Non-responding socket. Service Failure 1080 („SOCKs“ service) : Non-responding socket. Service Failure 1024 („old_finger“ service) : Non-responding socket. Service Failure 888 („CDDataBase“ service) : Non-responding socket. Service Failure 767 („phonebook“ service) : Non-responding socket. Service Failure 765 („webster“ service) : Non-responding socket. Service Failure 666 („doom“ service) : Non-responding socket. Service Failure 600 („ipcserver“ service) : Non-responding socket. Service Failure 566 („remotefs“ service) : Non-responding socket. Service Failure 565 („whoami“ service) : Non-responding socket. Service Failure 541 („uucp-rlogin“ service) : Non-responding socket. Service Failure 540 („uucp“ service) : Non-responding socket. Service Failure 532 („netnews“ service) : Non-responding socket. Service Failure 531 („conference“ service) : Non-responding socket. Service Failure 530 („courier“ service) : Non-responding socket. Service Failure 518 („ntalk“ service) : Non-responding socket. Service Failure 517 („talk“ service) : Non-responding socket. Service Failure 515 („printer“ service) : Non-responding socket.
Seite 202
Firewall-Studie
11.09.97
SIEMENS
Kaufempfehlung Service Failure 514 („shell“ service) : Non-responding socket. Service Failure 513 („login“ service) : Non-responding socket. Service Failure 512 („exec“ service) : Non-responding socket. Service Failure 450 („tserver“ service) : Non-responding socket. Service Failure 444 („snpp“ service) : Non-responding socket. Service Failure 443 („https“ service) : Non-responding socket. Service Failure 177 („xdmcp“ service) : Non-responding socket. Service Failure 170 („print-srv“ service) : Non-responding socket. Service Failure 162 („SNMPTRAP“ service) : Non-responding socket. Service Failure 161 („SNMP“ service) : Non-responding socket. Service Failure 144 („NeWS“ service) : Non-responding socket. Service Failure 143 („imap“ service) : Non-responding socket. Service Failure 139 („netbios-ssn“ service) : Non-responding socket. Service Failure 138 („netbios-dgm“ service) : Non-responding socket. Service Failure 137 („netbios-ns“ service) : Non-responding socket. Service Failure 133 („statsrv“ service) : Non-responding socket. Service Failure 123 („ntp“ service) : Non-responding socket. Service Failure 119 („nntp“ service) : Non-responding socket. Service Failure 117 („uucp-path“ service) : Non-responding socket. Service Failure 115 („sftp“ service) : Non-responding socket. Service Failure 113 („ident“ service) : Non-responding socket. Service Failure 111 („sunrpc“ service) : Non-responding socket. Service Failure 110 („pop3“ service) : Non-responding socket. Service Failure 109 („pop“ service) : Non-responding socket. Service Failure 105 („csnet-ns“ service) : Non-responding socket. Service Failure 104 („x400-snd“ service) : Non-responding socket. Service Failure 103 („x400“ service) : Non-responding socket. Service Failure 102 („iso-tap“ service) : Non-responding socket. Service Failure 101 („hostnames“ service) : Non-responding socket. Service Failure 95 („sudup“ service) : Non-responding socket. Service Failure 87 („link“ service) : Non-responding socket. Service Failure 80 („httpd“ service) : Non-responding socket. Service Failure 79 („finger“ service) : Non-responding socket. Service Failure 77 („rje“ service) : Non-responding socket. Service Failure 70 („gopher“ service) : Non-responding socket. Service Failure 57 („mtp“ service) : Non-responding socket. Service Failure 43 („whois“ service) : Non-responding socket. Service Failure 37 („time“ service) : Non-responding socket. Service Failure 25 („smtp“ service) : Non-responding socket. Service Failure 23 („telnet“ service) : Non-responding socket. Service Failure 22 („ssh“ service) : Non-responding socket. Service Failure 21 („ftp“ service) : Non-responding socket. Service Failure 20 („ftp-data“ service) : Non-responding socket. Service Failure 19 („chargen“ service) : Non-responding socket. Service Failure 15 („netstat“ service) : Non-responding socket. Service Failure 13 („daytime“ service) : Non-responding socket. Service Failure 11 („sysstat“ service) : Non-responding socket. Service Failure 9 („discard“ service) : Non-responding socket. Service Failure 7 („echo“ service) : Non-responding socket. Service Failure 1 („tcp-mux“ service) : Non-responding socket. Service Failure 53 („domain“ service) : Connection refused. IP Address: 146.180.10.55
Hostname: poing.mchp.siemens.de
Service Failure 13326 („crossfire[game]“ service) : Non-responding socket. Service Failure 9000 („unknown“ service) : Non-responding socket. Service Failure 8000 („unknown“ service) : Non-responding socket. Service Failure 8080 („httpd“ service) : Non-responding socket. Service Failure 7002 („backdoor?“ service) : Non-responding socket. Service Failure 7001 („backdoor?“ service) : Non-responding socket. 11.09.97
Firewall-Studie
Seite 203
SIEMENS
Anhang Service Failure 7000 („afsserv or dos“ service) : Non-responding socket. Service Failure 6667 („irc“ service) : Non-responding socket. Service Failure 6666 („irc-serv“ service) : Non-responding socket. Service Failure 6000 („X“ service) : Non-responding socket. Service Failure 5858 („netrek[game]“ service) : Non-responding socket. Service Failure 5000 („unknown“ service) : Non-responding socket. Service Failure 4557 („fax“ service) : Non-responding socket. Service Failure 4000 („unknown“ service) : Non-responding socket. Service Failure 3000 („unknown“ service) : Non-responding socket. Service Failure 2592 („netrek[game]“ service) : Non-responding socket. Service Failure 2048 („dls-monitor“ service) : Non-responding socket. Service Failure 2003 („cfinger“ service) : Non-responding socket. Service Failure 2000 („callbook“ service) : Non-responding socket. Service Failure 1999 („tcp-id-port“ service) : Non-responding socket. Service Failure 1525 („oracle“ service) : Non-responding socket. Service Failure 1524 („ingreslock“ service) : Non-responding socket. Service Failure 1080 („SOCKs“ service) : Non-responding socket. Service Failure 1024 („old_finger“ service) : Non-responding socket. Service Failure 888 („CDDataBase“ service) : Non-responding socket. Service Failure 767 („phonebook“ service) : Non-responding socket. Service Failure 765 („webster“ service) : Non-responding socket. Service Failure 666 („doom“ service) : Non-responding socket. Service Failure 600 („ipcserver“ service) : Non-responding socket. Service Failure 566 („remotefs“ service) : Non-responding socket. Service Failure 565 („whoami“ service) : Non-responding socket. Service Failure 541 („uucp-rlogin“ service) : Non-responding socket. Service Failure 540 („uucp“ service) : Non-responding socket. Service Failure 532 („netnews“ service) : Non-responding socket. Service Failure 531 („conference“ service) : Non-responding socket. Service Failure 530 („courier“ service) : Non-responding socket. Service Failure 518 („ntalk“ service) : Non-responding socket. Service Failure 517 („talk“ service) : Non-responding socket. Service Failure 515 („printer“ service) : Non-responding socket. Service Failure 514 („shell“ service) : Non-responding socket. Service Failure 513 („login“ service) : Non-responding socket. Service Failure 512 („exec“ service) : Non-responding socket. Service Failure 450 („tserver“ service) : Non-responding socket. Service Failure 444 („snpp“ service) : Non-responding socket. Service Failure 443 („https“ service) : Non-responding socket. Service Failure 177 („xdmcp“ service) : Non-responding socket. Service Failure 170 („print-srv“ service) : Non-responding socket. Service Failure 162 („SNMPTRAP“ service) : Non-responding socket. Service Failure 161 („SNMP“ service) : Non-responding socket. Service Failure 144 („NeWS“ service) : Non-responding socket. Service Failure 143 („imap“ service) : Non-responding socket. Service Failure 139 („netbios-ssn“ service) : Non-responding socket. Service Failure 138 („netbios-dgm“ service) : Non-responding socket. Service Failure 137 („netbios-ns“ service) : Non-responding socket. Service Failure 133 („statsrv“ service) : Non-responding socket. Service Failure 123 („ntp“ service) : Non-responding socket. Service Failure 119 („nntp“ service) : Non-responding socket. Service Failure 117 („uucp-path“ service) : Non-responding socket. Service Failure 115 („sftp“ service) : Non-responding socket. Service Failure 113 („ident“ service) : Non-responding socket. Service Failure 111 („sunrpc“ service) : Non-responding socket. Service Failure 110 („pop3“ service) : Non-responding socket. Service Failure 109 („pop“ service) : Non-responding socket. Service Failure 105 („csnet-ns“ service) : Non-responding socket. Service Failure 104 („x400-snd“ service) : Non-responding socket. Service Failure 103 („x400“ service) : Non-responding socket.
Seite 204
Firewall-Studie
11.09.97
SIEMENS
Kaufempfehlung Service Failure 102 („iso-tap“ service) : Non-responding socket. Service Failure 101 („hostnames“ service) : Non-responding socket. Service Failure 95 („sudup“ service) : Non-responding socket. Service Failure 87 („link“ service) : Non-responding socket. Service Failure 80 („httpd“ service) : Non-responding socket. Service Failure 79 („finger“ service) : Non-responding socket. Service Failure 77 („rje“ service) : Non-responding socket. Service Failure 70 („gopher“ service) : Non-responding socket. Service Failure 57 („mtp“ service) : Non-responding socket. Service Failure 43 („whois“ service) : Non-responding socket. Service Failure 37 („time“ service) : Non-responding socket. Service Failure 25 („smtp“ service) : Non-responding socket. Service Failure 23 („telnet“ service) : Non-responding socket. Service Failure 22 („ssh“ service) : Non-responding socket. Service Failure 21 („ftp“ service) : Non-responding socket. Service Failure 20 („ftp-data“ service) : Non-responding socket. Service Failure 19 („chargen“ service) : Non-responding socket. Service Failure 15 („netstat“ service) : Non-responding socket. Service Failure 13 („daytime“ service) : Non-responding socket. Service Failure 11 („sysstat“ service) : Non-responding socket. Service Failure 9 („discard“ service) : Non-responding socket. Service Failure 7 („echo“ service) : Non-responding socket. Service Failure 1 („tcp-mux“ service) : Non-responding socket. Service Failure 53 („domain“ service) : Connection refused. IP Address: 146.180.1.198
Hostname: m68945pp.mchp.siemens.de
Service Failure 13326 („crossfire[game]“ service) : Non-responding socket. Service Failure 9000 („unknown“ service) : Non-responding socket. Service Failure 8000 („unknown“ service) : Non-responding socket. Service Failure 8080 („httpd“ service) : Non-responding socket. Service Failure 7002 („backdoor?“ service) : Non-responding socket. Service Failure 7001 („backdoor?“ service) : Non-responding socket. Service Failure 7000 („afsserv or dos“ service) : Non-responding socket. Service Failure 6667 („irc“ service) : Non-responding socket. Service Failure 6666 („irc-serv“ service) : Non-responding socket. Service Failure 6000 („X“ service) : Non-responding socket. Service Failure 5858 („netrek[game]“ service) : Non-responding socket. Service Failure 5000 („unknown“ service) : Non-responding socket. Service Failure 4557 („fax“ service) : Non-responding socket. Service Failure 4000 („unknown“ service) : Non-responding socket. Service Failure 3000 („unknown“ service) : Non-responding socket. Service Failure 2592 („netrek[game]“ service) : Non-responding socket. Service Failure 2048 („dls-monitor“ service) : Non-responding socket. Service Failure 2003 („cfinger“ service) : Non-responding socket. Service Failure 2000 („callbook“ service) : Non-responding socket. Service Failure 1999 („tcp-id-port“ service) : Non-responding socket. Service Failure 1525 („oracle“ service) : Non-responding socket. Service Failure 1524 („ingreslock“ service) : Non-responding socket. Service Failure 1080 („SOCKs“ service) : Non-responding socket. Service Failure 1024 („old_finger“ service) : Non-responding socket. Service Failure 888 („CDDataBase“ service) : Non-responding socket. Service Failure 767 („phonebook“ service) : Non-responding socket. Service Failure 765 („webster“ service) : Non-responding socket. Service Failure 666 („doom“ service) : Non-responding socket. Service Failure 600 („ipcserver“ service) : Non-responding socket. Service Failure 566 („remotefs“ service) : Non-responding socket. Service Failure 565 („whoami“ service) : Non-responding socket. Service Failure 541 („uucp-rlogin“ service) : Non-responding socket. Service Failure 540 („uucp“ service) : Non-responding socket. 11.09.97
Firewall-Studie
Seite 205
SIEMENS
Anhang
Service Failure 532 („netnews“ service) : Non-responding socket. Service Failure 531 („conference“ service) : Non-responding socket. Service Failure 530 („courier“ service) : Non-responding socket. Service Failure 518 („ntalk“ service) : Non-responding socket. Service Failure 517 („talk“ service) : Non-responding socket. Service Failure 515 („printer“ service) : Non-responding socket. Service Failure 514 („shell“ service) : Non-responding socket. Service Failure 513 („login“ service) : Non-responding socket. Service Failure 512 („exec“ service) : Non-responding socket. Service Failure 450 („tserver“ service) : Non-responding socket. Service Failure 444 („snpp“ service) : Non-responding socket. Service Failure 443 („https“ service) : Non-responding socket. Service Failure 177 („xdmcp“ service) : Non-responding socket. Service Failure 170 („print-srv“ service) : Non-responding socket. Service Failure 162 („SNMPTRAP“ service) : Non-responding socket. Service Failure 161 („SNMP“ service) : Non-responding socket. Service Failure 144 („NeWS“ service) : Non-responding socket. Service Failure 143 („imap“ service) : Non-responding socket. Service Failure 139 („netbios-ssn“ service) : Non-responding socket. Service Failure 138 („netbios-dgm“ service) : Non-responding socket. Service Failure 137 („netbios-ns“ service) : Non-responding socket. Service Failure 133 („statsrv“ service) : Non-responding socket. Service Failure 123 („ntp“ service) : Non-responding socket. Service Failure 119 („nntp“ service) : Non-responding socket. Service Failure 117 („uucp-path“ service) : Non-responding socket. Service Failure 115 („sftp“ service) : Non-responding socket. Service Failure 113 („ident“ service) : Non-responding socket. Service Failure 111 („sunrpc“ service) : Non-responding socket. Service Failure 110 („pop3“ service) : Non-responding socket. Service Failure 109 („pop“ service) : Non-responding socket. Service Failure 105 („csnet-ns“ service) : Non-responding socket. Service Failure 104 („x400-snd“ service) : Non-responding socket. Service Failure 103 („x400“ service) : Non-responding socket. Service Failure 102 („iso-tap“ service) : Non-responding socket. Service Failure 101 („hostnames“ service) : Non-responding socket. Service Failure 95 („sudup“ service) : Non-responding socket. Service Failure 87 („link“ service) : Non-responding socket. Service Failure 80 („httpd“ service) : Non-responding socket. Service Failure 79 („finger“ service) : Non-responding socket. Service Failure 77 („rje“ service) : Non-responding socket. Service Failure 70 („gopher“ service) : Non-responding socket. Service Failure 57 („mtp“ service) : Non-responding socket. Service Failure 43 („whois“ service) : Non-responding socket. Service Failure 37 („time“ service) : Non-responding socket. Service Failure 25 („smtp“ service) : Non-responding socket. Service Failure 23 („telnet“ service) : Non-responding socket. Service Failure 22 („ssh“ service) : Non-responding socket. Service Failure 21 („ftp“ service) : Non-responding socket. Service Failure 20 („ftp-data“ service) : Non-responding socket. Service Failure 19 („chargen“ service) : Non-responding socket. Service Failure 15 („netstat“ service) : Non-responding socket. Service Failure 13 („daytime“ service) : Non-responding socket. Service Failure 11 („sysstat“ service) : Non-responding socket. Service Failure 9 („discard“ service) : Non-responding socket. Service Failure 7 („echo“ service) : Non-responding socket. Service Failure 1 („tcp-mux“ service) : Non-responding socket. Service Failure 53 („domain“ service) : Connection refused. ========== End of Report =========
Seite 206
Firewall-Studie
11.09.97
