Bundesamt für Sicherheit in der Informationstechnik

M 5.39 Sicherer Einsatz der Protokolle und Dienste

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter

Die folgenden kurzen Beschreibungen häufig im Internet verwendeter Protokolle und Dienste sollen als Hinweis dienen, welche Informationen von diesen Protokollen übertragen werden und somit für eine Filterung durch ein Sicherheitsgateway zur Verfügung stehen. Des weiteren ist kurz beschrieben, welche Randbedingungen beim Einsatz der verschiedenen Protokolle und Dienste zu beachten sind.

Grundlegende Protokolle der tieferen Schichten des ISO/OSI Schichtenmodells

IP

Das Internet Protocol (IP) ist das Protokoll, auf dem praktisch alle gebräuchlichen Protokolle in lokalen Netzen aufbauen. IP ist ein verbindungsloses Protokoll. Ein IP-Header enthält u. a. zwei 32-Bit Adressen (IP-Adressen) für Ziel und Quelle der kommunizierenden Rechner.

Da die IP-Adressen leicht gefälscht werden können (siehe auch G 5.48 IP-Spoofing ), können sie nur in ganz bestimmten Topographien zur Authentisierung benutzt werden, also nur wenn sichergestellt ist, dass die Adressen nicht geändert werden können. Beispielsweise dürfen Pakete, die von außen kommen, aber als Quelladresse eine Adresse aus dem zu schützenden Netz haben, von dem Sicherheitsgateway nicht durchgelassen werden.

ARP

Das Address Resolution Protocol (ARP) dient dazu, zu einer 32-Bit großen IP-Adresse die zugehörige 48-Bit lange MAC-Adresse ("Media Access Control", auch Hardware- oder Ethernet-Adresse genannt) zu finden. Jeder Rechner führt für andere Stationen in seiner Broadcast-Domain eine Tabelle, in der die Zuordnung zwischen IP- und Hardware-Adressen gespeichert ist. Falls in dieser Tabelle kein entsprechender Eintrag gefunden wird, wird ein ARP-Broadcast-Paket mit der IP-Adresse ausgesandt, zu der die MAC-Adresse gesucht wird. Der Rechner mit dieser IP-Adresse sendet dann ein ARP-Antwort-Paket mit seiner MAC-Adresse zurück. ARP-Antwort-Pakete sind nicht manipulationssicher ("ARP-Spoofing", siehe auch G 5.112 Manipulation von ARP-Tabellen ).

ICMP

Das Internet Control Message Protocol (ICMP, spezifiziert in RFC 792) hat die Aufgabe, Fehler- und Diagnoseinformationen für IP zu transportieren. Es wird intern von IP, TCP oder UDP angestoßen und verarbeitet. ICMP kennt eine Anzahl verschiedener sogenannter Nachrichtentypen für verschiedene Zwecke.

Je nach Einsatzszenario sollten bestimmte ICMP Nachrichtentypen selektiv zugelassen beziehungsweise blockiert werden. Zur Behandlung von ICMP am Sicherheitsgateway siehe M 5.120 Behandlung von ICMP am Sicherheitsgateway .

Routing Protokolle

Routing Protokolle wie RIP (Routing Information Protocol) oder OSPF (Open Shortest Path First) dienen dazu, Veränderungen der Routen zwischen zwei vernetzten Systemen an die beteiligten Systeme weiterzuleiten und so eine dynamische Änderung der Routing-Tabellen zu ermöglichen. Es ist leicht möglich, falsche RIP-Pakete zu erzeugen und somit unerwünschte Routen zu konfigurieren. Dynamisches Routing sollte daher nur in ganz bestimmten Topographien angewendet werden.

Am Sicherheitsgateway sollten Routing-Protokolle nur im unbedingt notwendigen Umfang eingesetzt werden. Wo dies möglich ist sollten nur sichere Routing-Protokolle eingesetzt werden. Mehr Informationen finden sich in M 5.112 Sicherheitsaspekte von Routing-Protokollen .

UDP

Das User Datagram Protocol (UDP) ist ein verbindungsloses Protokoll der Transportschicht. Es gibt keine Transportquittungen oder andere Sicherheitsmaßnahmen für die Korrektheit der Übertragung. Der Header enthält (analog zu TCP) unter anderem zwei 16-Bit Portnummern, die aber unabhängig von den bei TCP benutzten Portnummern sind. Da sie leicht gefälscht werden können, können sie nur in ganz bestimmten Topographien zur Authentisierung benutzt werden.

Da in der Protokolldefinition keine Unterscheidung zwischen einem Verbindungsaufbau und einer Datenübertragung vorgesehen ist, muss diese Unterscheidung von einer Komponente des Sicherheitsgateways übernommen werden. Es muss eine Kontrolle über den Zustand der Verbindung möglich sein, und es muss möglich sein, die Zugehörigkeit eines Paketes zu einer Verbindung eindeutig festzustellen.

Dies kann z. B. erreicht werden, indem bei einem UDP-Verbindungsaufbau der Zielport gespeichert und temporär freigegeben wird, Antwortpakete nur zu diesem Port durchgelassen werden und nach der Beendigung der Verbindung oder nach einem Timeout der Port wieder gesperrt wird.

Protokolle der Anwendungsschicht

DNS

Der Domain Name Service ( DNS ) dient zur Umsetzung von Rechnernamen in IP-Adressen und umgekehrt und stellt ferner Informationen über im Netz vorhandene Rechnersysteme zur Verfügung. DNS kann sowohl über TCP als auch über UDP abgewickelt werden, der Server benutzt bei beiden Träger-Protokollen standardmäßig den Port 53. Meist wird UDP als Trägerprotokoll verwendet.

Die übertragenen Informationen sind nicht durch kryptographische Verfahren geschützt, so dass durch gefälschte Daten Spoofing-Angriffe möglich sind (siehe auch G 5.78 DNS-Spoofing ). Dies sollte insbesondere bei DNS-Antworten aus dem Internet berücksichtigt werden.

Prinzipiell muss beachtet werden, dass alle von DNS zur Verfügung gestellten Informationen missbraucht werden können.

Zur Integration von DNS ist ein Sicherheitsgateway erforderlich (siehe auch M 2.77 Integration von Servern in das Sicherheitsgateway und M 5.118 Integration eines DNS-Servers in ein Sicherheitsgateway .

SMTP

Das Simple Mail Transfer Protocol (SMTP) wird für die Übertragung von E-Mail benutzt. SMTP-Server (Mail-Server, auch Mail Transport Agents (MTAs) genannt) benutzen standardmäßig den TCP-Port 25. SMTP, das im RFC 821 definiert wird, besteht aus einer geringen Zahl von Kommandos, die teilweise aus Sicherheitssicht bedenklich sind.

Mit den Befehlen VRFY und EXPN können beispielsweise interne Informationen über Benutzer abgerufen werden, daher sollte die Verwendung dieser Befehle nur innerhalb des geschützten Netzes erlaubt werden. Für nicht vertrauenswürdige Benutzer, insbesondere für Anfragen aus dem Internet, sind VRFY und EXPN entweder am ALG (Application-Level-Gateway) oder direkt auf dem MTA (Mail Transport Agent, Mail-Server) zu sperren.

Idealerweise sollte ein Sicherheitsgateway in der Lage sein, SMTP-Verbindungen zwischen vertrauenswürdigen Benutzern zu verschlüsseln. Sinnvoll ist dies aber nur dann, wenn ein starker Authentisierungsmechanismus benutzt wird.

HTTP

Das Hypertext Transfer Protokoll (HTTP) wird für die Übertragung von Daten zwischen WWW-Clients (meist Webbrowsern) und Webservern benutzt. HTTP und diverse Erweiterungen werden in einer Reihe von RFCs definiert, der RFC 2616, in dem die aktuelle Variante HTTP 1.1 spezifiziert wird, enthält eine Reihe von Referenzen auf ältere Dokumente. Standardmäßig benutzt ein Webserver den TCP-Port 80.

HTTP ist ein Klartextprotokoll, das keine Unterstützung für eine sichere Authentisierung und keine Gewährleistung für die Vertraulichkeit und Integrität der übertragenen Daten bietet. Dies sollte bei der Entscheidung, welche Transaktionen über HTTP abgewickelt werden können, berücksichtigt werden.

Weitere Informationen über Maßnahmen im Zusammenhang mit HTTP finden sich in M 4.222 Festlegung geeigneter Einstellungen von Sicherheitsproxies und M 4.100 Sicherheitsgateways und aktive Inhalte .

HTTPS

HTTPS (HTTP über SSL bzw. HTTP über TLS) ist eine Variante von HTTP, bei der Authentisierung und Datenübertragung durch Verschlüsselung und Zertifikate geschützt werden können. HTTPS wird im RFC 2818 spezifiziert. Meist benutzt ein Webserver, der HTTPS unterstützt, den TCP-Port 443.

Beim Einsatz von HTTPS muss beachtet werden, dass TLS auch einen Betriebsmodus kennt, in dem keine Verschlüsselung stattfindet. Bei entsprechenden Sicherheitsanforderungen sollte am HTTPS-Proxy verhindert werden, dass entsprechende Verbindungen aufgebaut werden können.

Weitere Informationen finden sich in M 4.222 Festlegung geeigneter Einstellungen von Sicherheitsproxies und M 4.100 Sicherheitsgateways und aktive Inhalte , sowie in M 5.66 Clientseitige Verwendung von SSL/TLS .

Secure Shell / Secure Copy

Das Secure Shell (SSH) Protokoll erlaubt den Aufbau einer gesicherten Kommandozeilen-Verbindung zu einem entfernten Rechner. Das SSH-Protokoll erlaubt eine gesicherte Authentisierung mit einer Reihe verschiedener Authentisierungsmechanismen (unter anderem über Benutzername und Passwort, mit speziellen Zertifikaten, über eine zentral verwaltete PKI-Infrastruktur oder über Kerberos). SSH eignet sich daher als Ersatz für Telnet. Wo immer möglich sollte Telnet durch SSH ersetzt werden. Standardmäßig benutzt ein SSH-Server den TCP-Port 22.

Zur SSH-Protokollfamilie gehört auch das Protokoll SCP (Secure Copy Protocol), das zur Übertragung von Dateien die Authentisierungs- und Verschlüsselungsmechanismen von SSH benutzt. SCP stellt eine sichere Alternative zu FTP dar.

Für SSH existiert eine Reihe verschiedener Implementierungen für praktisch alle gebräuchlichen Betriebssysteme, sowie zusätzlich betriebssystemunabhängige Implementierungen beispielsweise in Java. Die verschiedenen Implementierungen unterscheiden sich jedoch teilweise bei der Anzahl der unterstützten Authentisierungsmechanismen und in anderen Details.

Die meisten SSH-Clients bieten zusätzlich die Möglichkeit, andere Protokolle über eine bestehende SSH-Verbindung zu "tunneln" und so die Nachteile beispielsweise von Klartextprotokollen zu vermeiden. Andererseits stellt diese Option auch ein gewisses Risiko dar, da auf diese Weise Datenübertragungen "versteckt" werden können. Beim Einsatz von SSH sollte daher sorgfältig geprüft werden, mit welchen Kommunikationspartnern Verbindungen zugelassen werden. Gegebenenfalls sollte ein entsprechender Sicherheitsproxy eingesetzt werden, der die verschlüsselte Verbindung am Sicherheitsgateway unterbricht.

Die ursprüngliche Version des SSH-Protokolls (ssh1) besitzt einen Designfehler, der einen Man-in-the-Middle Angriff zulässt. Aus diesem Grund wurde eine neue Version des Protokolls (ssh2) entwickelt, die diese Schwachstelle beseitigt. Die Protokollversion ssh1 sollte zumindest über öffentliche Netze hinweg nicht mehr verwendet werden. Wird für SSH ein Sicherheitsproxy auf dem Sicherheitsgateway eingesetzt, so sollte der Proxy die Möglichkeit bieten, ssh2-Verbindungen zu erzwingen und keine ssh1-Verbindungen zuzulassen.

Telnet

Das Telnet-Protokoll wird in RFC 854 spezifiziert. Es erlaubt (analog zu SSH) den Aufbau einer Terminalsitzung auf einem entfernten Rechner. Telnet ist ein Klartextprotokoll, das keine Mechanismen zur Sicherung der Authentisierungsinformationen und der übertragenen Daten und Kommandos bietet. Ein Telnet-Server benutzt standardmäßig den TCP-Port 23.

Da Telnet einen vollständigen Kommandozeilenzugriff auf einen Rechner erlaubt, jedoch keine Sicherungsmechanismen bietet, sollte Telnet wo immer möglich durch SSH ersetzt werden. Alternativ können Telnet-Verbindungen über SSH getunnelt werden. Falls aus zwingenden Gründen ein Ersatz von Telnet durch SSH oder ein Tunneln nicht möglich ist, kann im internen Netz weiterhin Telnet eingesetzt werden. Dabei sollten jedoch die erlaubten Kommunikationsverbindungen über entsprechende Paketfilterregeln auf das unbedingt notwendige Maß beschränkt werden. Für Administrationstätigkeiten sollte Telnet allenfalls noch in einem besonders abgeschotteten Administrationsnetz eingesetzt werden.

Telnet-Verbindungen können von einem Angreifer übernommen werden, der Zugriff auf eine Netzkomponente besitzt, über die die betreffende Verbindung läuft (siehe G 5.89 Hijacking von Netz-Verbindungen ). Auf ungesicherten Verbindungen (öffentliche Netze) sollte Telnet daher auch dann nicht mehr eingesetzt werden, wenn der eingesetzte Telnet-Server erweiterte Authentisierungsmechanismen wie Einmalpasswörter unterstützt.

FTP

Das File Transfer Protocol (FTP) wird im RFC 959 spezifiziert. Es ermöglicht den Austausch von Dateien zwischen entfernten Rechnern. Wie Telnet ist FTP ein Klartextprotokoll, das keine Sicherung der übertragenen Authentisierungsinformationen und Daten bietet.

Bei Benutzung von FTP werden zwei Verbindungen aufgebaut, wobei die Kommandos über den TCP-Port 21 übertragen werden und die Daten über TCP-Port 20. Telnet definiert eine Anzahl an Standard-Befehlen, mit denen Art und Format der Datenübertragung gesteuert werden und die einem FTP Client eine Navigation im Dateibaum eines FTP-Servers erlauben. Für das Sicherheitsgateway sind diese Standardbefehle relevant, da nur diese tatsächlich übertragen werden.

Eine FTP-Kommandoverbindung wird vom Client zum Port 21 des Servers aufgebaut. Für die Datenverbindungen gibt es bei FTP zwei Betriebsmodi, den Active und den Passive Mode. Beim Active Mode baut der FTP-Server die Datenverbindung zum Client auf, beim Passive Mode wird auch die Datenverbindung vom Client aus aufgebaut.

Der Active Mode stellt eine Sicherheitslücke dar, da sich ein Angreifer als Server ausgeben kann und auf diese Weise die Möglichkeit bekommen würde, eine Verbindung ins interne Netz aufzubauen. Falls FTP eingesetzt wird, so sollte stets der Passive Mode verwendet werden, bei dem sowohl die Kommando- als auch die Datenverbindung vom zu schützenden ins externe Netz stattfinden.

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.

Auch der Befehl SYST, mit dem ein Client nach der Betriebssystem-Version des Servers fragt, sollte an eine Rechteverwaltung gekoppelt sein bzw. für nicht vertrauenswürdige Benutzer gesperrt werden.

Ferner muss es möglich sein, die Übertragung der Dateien, der Verzeichnisinformationen und der Passwörter zu verschlüsseln.

FTP sollte nicht zur Übertragung schutzbedürftiger Daten über öffentliche Netze verwendet werden. Sollen schutzbedürftige Daten über eine externe FTP-Verbindung übertragen werden, müssen sie auf andere Weise geschützt (beispielsweise verschlüsselt) werden. Nach Möglichkeit sollte FTP durch ein sicheres Protokoll wie SCP ersetzt werden.

Häufig wird FTP eingesetzt, um Dateien von öffentlich zugänglichen Servern abzurufen. Sofern dafür keine Authentisierungsinformationen benutzt werden, die auch auf anderen Systemen verwendet werden (beispielsweise beim anonymous FTP), ist dies so lange unkritisch, wie keine Anforderungen an die Integrität und Authentizität der abgerufenen Daten gestellt werden (beispielsweise Abruf von Informationsmaterial). Sind die Integrität und Authentizität der Daten wichtig (beispielsweise beim Herunterladen von Programmpaketen, Patches oder wichtiger Dokumente), so sollten vom Anbieter digitale Signaturen zur Verfügung gestellt werden, mit denen die Unverfälschtheit der Daten geprüft werden kann.

POP3 und IMAP

Die Protokolle POP3 (Post Office Protocol Version 3, spezifiziert in RFC 1939) und IMAP (Internet Message Access Protocol, spezifiziert in RFC 3501) werden von E-Mail-Clients eingesetzt, um E-Mails von einem Mailserver abzurufen (POP3) oder auf dem Mailserver zu verwalten (IMAP).

Die Standard-Ports für diese Protokolle sind die Ports 110/TCP (POP3) und 143/TCP (IMAP). Beide Protokolle sind Klartextprotokolle und sollten daher nicht über öffentliche Netze verwendet werden. Für beide Protokolle existieren Varianten, bei denen die Verbindungen durch Verschlüsselung (SSL bzw. TLS) gesichert werden: POP3s (Standard-Port 995/TCP) und IMAPs (Standard-Port 993/TCP).

Auch wenn nur im internen Netz E-Mails abgerufen werden sollen wird empfohlen, möglichst nur die abgesicherten Varianten POP3s oder IMAPs einzusetzen. Sollen E-Mails von einem externen POP3 oder IMAP-Server (etwa bei einem E-Mail-Provider) abgerufen werden, so sollten unbedingt die abgesicherten Versionen der Protokolle verwendet werden, gegebenenfalls mit einer Unterbrechung der verschlüsselten Verbindung an einem entsprechenden Sicherheitsproxy.

Weitere Dienste

Verteilte Dateisysteme

Verteilte Dateisysteme, bei denen Daten nicht lokal auf einem Rechner, sondern auf einem Dateiserver gespeichert sind, auf den über das Netz zugegriffen wird, existieren seit langem und sind aus der IT-Welt nicht mehr wegzudenken.

Das verbreitetste Beispiel ist die Laufwerksfreigabe unter Microsoft Windows, das zu Grunde liegende Protokoll ist SMB /  CIFS (Server Message Block / Common Internet File System). Für dieses Protokoll existiert mit SAMBA auch eine Implementierung für diverse Unix-Derivate.

In der Unix-Welt werden verteilte Dateisysteme seit langem über NFS (Network File System) realisiert. Für NFS existieren auch Implementierungen für Windows. Außerdem gibt es eine Reihe anderer verteilter Dateisysteme wie AFS.

Verteilte Dateisysteme sollten nach Möglichkeit nicht über Sicherheitsgateways hinweg eingesetzt werden, da sie eine Reihe von Problemen mit sich bringen (Sicherheit der Authentisierung, Sicherheit der übertragenen Daten), die einen sicheren Einsatz über ein Sicherheitsgateway hinweg schwierig machen.

Ist in Einzelfällen doch ein Zugriff auf ein verteiltes Dateisystem notwendig, so sollte dieser prinzipiell durch eine VPN-Lösung abgesichert werden.

Remote-Desktop Protokolle (Window Terminal Server, X-Windows etc.)

Sowohl Microsoft Windows als auch das X-Window-System, mit dem unter Unix graphische Oberflächen realisiert werden, bieten die Möglichkeit, einzelne Fenster oder die gesamte Arbeitsoberfläche auch auf einem entfernten Rechner darzustellen.

Ein Remote-Desktop Protokoll, das keine oder nur schwache Sicherheitsfunktionen bietet, sollte auch im internen Netz nur in Ausnahmefällen eingesetzt werden, über das Sicherheitsgateway hinweg sollten Remote-Desktop Protokolle prinzipiell nicht verwendet werden. Muss dies in Ausnahmefällen trotzdem geschehen, so sollten unbedingt zusätzliche Maßnahmen ergriffen werden, etwa der Einsatz eines geeigneten VPN, das eine entsprechend gesicherte Verbindung zur Verfügung stellt.

Streaming-Protokolle

Für die Übertragung von Multimedia-Daten (Audio- und Video-Streaming) existiert eine Reihe von Protokollen mit unterschiedlichen Charakteristiken im Bezug auf Bandbreiten und verwendete Ports. Diese Protokolle sind meist für Sicherheitsgateways nicht unproblematisch, da sie teilweise schlecht über Paketfilterregeln abzusichern sind. Im Zweifelsfall sollte daher auf Streaming-Anwendungen verzichtet werden oder entsprechende Angebote können über gesonderte Internet-PCs (siehe Baustein B 3.208 Internet-PC ) abgerufen werden.

Voice over IP

Es existieren verschiedene Lösungen, die es ermöglichen, Sprachkommunikation über IP-Netze zu übertragen (Voice over IP, VoIP). Bei VoIP-Lösungen sind normalerweise mehrere verschiedene Protokolle notwendig, beispielsweise unterschiedliche Protokolle für die Signalisierung und für die Übertragung der Gesprächsdaten selbst.

VoIP-Lösungen, (beispielsweise solche, die dem H.323 Standard entsprechen) sind für Sicherheitsgateways oft problematisch, da verwendete Ports teilweise dynamisch zwischen Endgeräten ausgehandelt werden und daher keine einfache Absicherung über Paketfilter möglich ist.

Soll eine VoIP-Lösung eingesetzt werden, bei der auch eine Kommunikation über VoIP mit Gesprächspartnern außerhalb des eigenen Netzes stattfinden soll, so ist in jedem Fall eine zusätzliche Sicherheitsbetrachtung notwendig um zu vermeiden, dass durch die Anforderungen der VoIP-Lösung die Sicherheit des Netzes dadurch gefährdet wird, dass die Einstellungen des Sicherheitsgateway zu sehr "geöffnet" werden müssen.

NTP

Das in RFC 1305 spezifizierte Network Time Protocol (NTP) dient dazu, von einem Zeitserver ein genaues Zeitsignal zu beziehen.

Wird im internen Netz, von Servern oder von Komponenten des Sicherheitsgateways NTP zur Zeitsynchronisation genutzt, so sollte nach Möglichkeit entweder ein eigener Zeitserver im internen Netz oder im Sicherheitsgateway eingesetzt werden. Gegebenenfalls kann ein NTP-Proxy genutzt werden, der seine Zeitinformationen von einem der zentralen Zeitserver bezieht und der dann für die internen Rechner als Zeitserver agiert. Siehe auch M 4.227 Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation .

NNTP

Das in RFC 977 spezifizierte Network News Transfer Protocol (NNTP) wird für die Übertragung von Newsartikeln benutzt. Ein Newsserver benutzt standardmäßig den TCP-Port 119. Wie die meisten anderen "frühen" Internetprotokolle ist auch NNTP ein Klartextprotokoll.

Wird ein interner Newsserver betrieben oder soll vom internen Netz auf einen externen Newsserver zugegriffen werden, so muss das Sicherheitsgateway in der Lage sein, den Transport bestimmter Newsgruppen ganz zu verhindern oder nur für einige Rechner zuzulassen. Es muss sichergestellt werden, dass beim Versenden eigener News keine Informationen über das zu schützende Netz (z. B. die Rechnernamen) ins externe Netz gelangen.

"r-Dienste"

Die so genannten "r-Dienste" wie rlogin, rsh, rcp und andere basieren auf UDP und bieten keine Möglichkeiten für eine sichere Authentisierung und für die Absicherung der Verbindung.

Diese Dienste sollten auch im internen Netz nur noch in Ausnahmefällen benutzt werden. Über ein Sicherheitsgateway hinweg sollten sie keinesfalls eingesetzt werden. Das Sicherheitsgateway sollte entsprechende Pakete blockieren.

Für die meisten Anwendungsfälle bietet SSH einen vollwertigen Ersatz für die "r-Dienste".

Hinweis zu den so genannten "Privilegierten Ports"

Bei einer TCP/IP-Kommunikation baut in der Regel ein Client-Prozess von einem zufälligen Port mit einer Portnummer > 1023 eine Verbindung zu einem Server-Prozess mit einer Portnummer < 1024 (well-known-port) auf. Die Ports mit einer Nummer < 1024 werden auch als privilegierte Ports bezeichnet, da sie beispielsweise unter Unix nur von Prozessen mit Root-Berechtigung benutzt werden dürfen.

Diese Einschränkung, dass Ports < 1024 nur von Prozessen mit Root-Berechtigung benutzt werden dürfen, ist aber nur eine Konvention, die auch umgangen werden kann und die ohnehin in dem Fall keine Rolle spielt, wenn ein Angreifer die Kontrolle über einen Rechner übernommen hat. Daher darf in einem Sicherheitskonzept nicht vorausgesetzt werden, dass tatsächlich alle IT-Systeme ihre privilegierten Ports auf diese Weise schützen. Auch wenn z. B. mit FTP auf die Ports 20 oder 21 zugegriffen wird, darf dies also nicht als sichere Verbindung angesehen werden.

Prüffragen:

  • Werden von extern gesendete Pakete, die mit einer Quelladresse aus dem internen Netz versehen sind (Stichwort: IP-Spoofing) auf dem Sicherheitsgateway geblockt?

  • Werden auf dem Sicherheitsgateway ausschließlich sichere Routing-Protokolle eingesetzt?

  • Findet auf dem Sicherheitsgateway eine Zustands- und Zugehörigkeitskontrolle für UDP -Verbindungen statt?

  • Betrifft das Protokoll SMTP : Werden VRFY- und EXPN-Anfragen aus dem Internet durch das Application-Level-Gateway oder den Mail-Server blockiert?

  • Erfolgen SMTP -Vebindungen über das Sicherheitsgateway zwischen vertrauenswürdigen Benutzern verschlüsselt und mit starken Authentisierungsmechanismen?

  • Ist festgelegt mit welchen Kommunikationspartnern Verbindungen via SSH zugelassen sind?

  • Werden bei Einsatz eines Sicherheitsproxies auf dem Sicherheitsgateway für SSH SSHv2 -Verbindungen erzwungen und SSH Version 1-Verbindungen unterbunden?

  • Wird auf den Einsatz von TELNET soweit möglich verzichtet und werden stattdessen verschlüsselte Protokolle wie beispielsweise SSHv2 genutzt?

  • Wird bei FTP ausschließlich der Passive Mode verwendet?

  • Sind alle FTP -Befehle an eine Rechteverwaltung gekoppelt?

  • Wird der Einsatz von verteilten Dateisystemen über das Sicherheitsgateway hinweg verhindert?

  • Werden erforderliche Zugriffe auf verteilte Dateisysteme über das Sicherheitsgateway hinweg durch ein VPN abgesichert?

  • Wird der Einsatz von direkten Remote-Desktop Verbindungen über das Sicherheitsgateway hinweg verhindert?

  • Wird der erforderliche Einsatz von Remote-Desktop Protokollen über das Sicherheitsgateway hinweg durch eine VPN -Lösung abgesichert?

  • Werden Streaming-Protokolle, sofern nicht durch Streaming-Anwendungen zwingend erforderlich, durch das Sicherheitsgateway blockiert?

  • Existiert für die Nutzung von VoIP eine zusätzliche Sicherheitsbetrachtung, die den Sicherheitsanforderungen der Organisation entspricht?

  • Ist auf dem Sicherheitsgateway festgelegt, welche NNTP -Kommunikation zugelassen oder zu blockieren sind?

  • Werden auf dem Sicherheitsgateway Pakete der r-Dienste wie beispielsweise rlogin , rsh , rcp blockiert?

  • Existiert eine Übersicht der auf dem Sicherheitsgateway zugelassenen Protokolle?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK