Bundesamt für Sicherheit in der Informationstechnik

M 2.75 Geeignete Auswahl eines Application-Level-Gateways

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

Verantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter

Die Funktionen eines Sicherheitsgateways auf Anwendungsebene werden von den so genannten Application-Level-Gateways (ALG) übernommen. Implizit nehmen ALGs auch Funktionen auf den Schichten 1-3 wahr. ALGs werden oft auch Sicherheitsproxies genannt, im Folgenden wird aber abkürzend der Begriff "Proxy" verwendet. Proxies unterbrechen den direkten Datenstrom zwischen Quelle und Ziel. Bei einer Kommunikation zwischen Client und Server über einen Proxy hinweg nimmt der Proxy die Anfragen des Clients entgegen und leitet sie an den Server weiter. Bei einem Verbindungsaufbau in umgekehrter Richtung, also vom Server zum Client, verfährt der Proxy analog. Sämtliche Kommunikationsbeziehungen zwischen den beiden Rechnern verlaufen in diesem Fall also mittelbar über den Proxy.

Einige Vor- und Nachteile von Sicherheitsproxies werden in der folgenden Tabelle zusammengestellt:

Vorteile von Proxies

  • Oft geringere Anzahl von Programmierfehlern als in den vom Proxy geschützten Client- bzw. Serverdienstprogrammen.
  • Filterung einzelner Protokollbefehle (z. B. bei HTTP der Befehl POST) in Abhängigkeit von der Parametrisierung der Befehle, der Zeit und des Benutzer möglich.
  • Entfernung unerwünschter Inhalte in den übertragenen Daten.
  • Abwehr von Angriffen, die auf fehlerhaften Header-Daten beruhen.
  • Ersetzung der Absender-Adresse eines weitergeleiteten IP-Pakets durch die IP-Adresse der Netzschnittstelle, über die das Paket den Proxy verlässt. Dadurch werden IP-Adressen des vertrauenswürdigen Netzes verheimlicht. Im DNS braucht zudem nur eine IP-Adresse eingetragen werden.
  • Erzwingen einer starken Authentisierung möglich.
  • Umfangreiche Protokollierungsmöglichkeiten. Für jede Verbindung auf der Anwendungsebene kann protokolliert werden:
    • Benutzeridentifikation
    • IP-Adresse des Quell- und Zielrechners
    • Portnummern
    • Zeit und Datum

In Abhängigkeit vom Dienst können weitergehende Informationen protokolliert werden (z. B. URL bei HTTP).

Nachteile von Proxies

  • Verringerung des maximalen Datendurchsatzes.
  • Längere Antwortzeiten (Latenzzeiten) beim Abruf von Informationen.

Eventuell Einschränkung der Funktionalität der Clientprogramme (z. B. durch Filterung aktiver Inhalte).

Proxies können in zwei verschiedenen Betriebsarten arbeiten, dem sogenannten transparenten und dem nicht-transparentem Modus. Ein transparenter Proxy braucht den Clients nicht mitgeteilt zu werden. Er liest alle im Netz befindlichen IP-Pakete mit und entscheidet anhand von IP-Adresse und Portnummer, welche davon in ein anderes Netz weitergeleitet werden sollen. Bei Verwendung eines nicht-transparenten Proxies hingegen muss dessen IP-Adresse und Portnummer in der Client-Software (z. B. dem Webbrowser) eingetragen werden, um eine Verbindung über den Proxy hinweg zu ermöglichen.

Vor der Beschaffung sollte überprüft werden, welche der folgenden Anforderungen das ALG erfüllt. Je nach Anwendungszusammenhang kann dabei auf einige Anforderungen verzichtet werden.

Die aufgelisteten Anforderungen müssen im Anwendungszusammenhang bewertet werden. Wenn ein bestimmtes Protokoll nicht genutzt wird, braucht das ALG keine Unterstützung für das Protokoll zu bieten. Unterstützt das ALG Protokolle, die nicht genutzt werden, so sollte die Möglichkeit bestehen, das betreffende Protokoll zu deaktivieren.

Wurde für einige der im folgenden aufgeführten Protokolle in der Policy des Sicherheitsgateways festgelegt, dass sie nicht erlaubt sein sollen, so brauchen sie natürlich auch nicht unterstützt zu werden.

Die Kriterien der Bewertung und die getroffenen Entscheidungen müssen nachvollziehbar dokumentiert werden.

Allgemein

  • Unterstützung der wichtigsten verwendeten Protokolle (beispielsweise Telnet, FTP , SMTP, NNTP, HTTP und HTTPS) auf Anwendungsschicht. Für die Nutzung anderer Dienste sollten generische Proxies für TCP- und UDP vorhanden sein.
  • Die Proxies des Application-Level-Gateways sollten transparent betrieben werden können.
  • Es sollte ein eigener MTA auf dem ALG integriert werden können, um gegebenenfalls mehrere MTAs in verschiedenen vertrauenswürdigen Netzen bedienen zu können.
  • Es sollte eine Schnittstelle zum Anbinden von externen Analyseprogrammen zum Auffinden von Schadsoftware (z. B. Virensuchprogramme) vorhanden sein.
  • Die Kommunikation mit einem Directory-Dienst für die Authentisierung der Anwender sollte unterstützt werden.
  • Für jedes unterstützte Protokoll muss eine Filterung nach den in M 2.76 Auswahl und Einrichtung geeigneter Filterregeln spezifizierten Kriterien möglich sein. Insbesondere müssen die Filterregeln benutzerabhängig formulierbar sein, und es muss möglich sein, mehrere Benutzer zu einer Gruppe zusammenzufassen.
  • Eine Filterung in Abhängigkeit von Inhalten sollte unterstützt werden, damit eine zentrale Virenprüfung und das Blockieren aktiver Inhalte möglich ist (siehe G 5.23 Schadprogramme bzw. G 5.88 Missbrauch aktiver Inhalte ).
  • Bei dem Einsatz eines Application-Level-Gateways sollte keine Änderung der Software im zu schützenden Netz oder im externen Netz nötig sein.
  • Für jede aufgebaute und abgewiesene Verbindung auf der Anwendungsschicht muss eine Protokollierung von IP-Adresse des Quell- und Zielrechners, Portnummern, Zeit, Datum und der zutreffenden Regel durchgeführt werden, wobei auch Einschränkungen auf bestimmte Verbindungen möglich sein müssen.
  • Die übertragene Datenmenge sollte protokolliert werden können.
  • Die Uhrzeit des Verbindungsaufbaus und des Verbindungsabbaus sollten protokolliert werden können.

Im Folgenden werden spezifischere Anforderungen für einige häufig genutzte Protokolle zusammengestellt:

HTTP:

  • Filtern anhand der Request-Methode, z. B. GET, HEAD, PUT oder CONNECT
  • Sperren von Web-Seiten bzw. Web-Sites anhand der URL
  • Filtern anhand des MIME-Types
  • Entfernen von aktiven Inhalten und Cookies aus Web-Seiten
  • Filtern anhand von HTTP-Header-Daten
  • Filtern der folgenden Header-Felder sollte möglich sein:
    • Referrer
    • Via
    • From
    • Server
  • Filtern von "Web-Bugs"
  • Erzwingen einer starken Authentisierung am Proxy
  • Accounting zur Feststellung der von einen Nutzer abgerufenen Datenmenge
  • Unterstützung zur Signaturprüfung von signierten aktiven Inhalten
  • Protokollierung der abgerufenen Web-Seite
  • Protokollierung der Nutzung von gesperrten Request-Methoden

HTTPS:

  • Temporäre Entschlüsselung des Datenverkehrs, um das Entfernen aktiver Inhalte aus Web-Seiten, die mittels HTTPS abgerufen werden, zu ermöglichen. Temporäre Entschlüsselung bedeutet, dass übermittelte Daten erst entschlüsselt, nach der Filterung auf aktive Inhalte aber wieder verschlüsselt werden.
  • Protokollierung der abgerufenen Web-Seite
  • Benachrichtigung des Administrators bei automatischem Update abgelaufener oder ungültiger Zertifikate

SMTP:

  • Entfernen von aktiven Inhalten aus HTML-E-Mails
  • Filtern anhand des MIME-Types
  • Filtern anhand der Absender- und Empfängeradresse
  • Filtern anhand der IP-Adresse des MTAs
  • Kontrolle auf Mail-Relaying anhand des Domain-Namens
  • Überprüfung auf Zustellbarkeit der E-Mail anhand des Domain-Namens
  • Entfernung bedenklicher E-Mailanhänge anhand der Dateiendung. Zu blockierende Anhänge sollen frei vorgegeben werden können.
  • Erkennung von Spam-Mails mit Hilfe einer Kombination verschiedener Filter-Verfahren.
  • Erkannte Spam-Mails sollten wie folgt behandelt werden können:
    • Löschen
    • Isolierung ("Quarantäne")
    • Markieren
  • Erkannte E-Mails mit nicht spezifikationskonformen Headern ("Bad-Mails"), sollten wie folgt behandelt werden können:
    • Löschen
    • Isolierung ("Quarantäne")
    • Markieren
  • Bereitstellung einer Schnittstelle, die die Anbindung eines Spam-Filters ermöglicht.
  • Blockieren von (ausgehenden) E-Mails aufgrund der Erkennung von Schlüsselwörtern
  • Protokollierung der E-Mail-Adressen des Absenders und des Adressaten
  • Protokollierung des Erfolgs bzw. des Fehlschlagens der E-Mail- Weiterleitung
  • Möglichkeit zur Einrichtung eines
    • Mail-Relay (Weiterleitung von einem MTA im vertrauenswürdigen Netz zu einem MTA im nicht-vertrauenswürdigen Netz)
    • Mail-Server (Möglichkeit zum Abruf mit POP3 oder IMAP und zur Weiterleitung mit SMTP)

FTP (passiv und aktiv):

  • Filterung anhand von FTP-Befehlen (z. B. GET, PUT, PASV, PORT)
  • Nutzerbasierte Freigabe bzw. Sperrung von FTP-Befehlen
  • Restriktionen anhand des Dateinamens (z. B. Sperrung von *.exe)
  • Erzwingen einer starken Authentisierung am Proxy
  • Protokollierung der Nutzung von gesperrten Request-Methoden
  • Protokollierung des Benutzernamens im Falle einer Authentisierung und des Dateinamens

NNTP:

  • Filtern anhand der Request-Methode, z. B. ARTICLE, BODY, HEAD und STAT
  • Protokollierung der Nutzung von gesperrten Request-Methoden
  • Entfernen von aktiven Inhalten und Cookies aus Web-Seiten
  • Erzwingen einer starken Authentisierung am Proxy
  • Gezielte Sperrung einzelner Foren

Telnet:

  • Erzwingen einer starken Authentisierung am Proxy
  • Protokollierung des Benutzernamens im Falle einer Authentisierung

POP:

  • Filtern anhand der Request-Methode, z. B. STAT, LIST, RETR oder DELE
  • Entfernen von aktiven Inhalten und Cookies aus HTML-E-Mails
  • Protokollierung der Nutzung von gesperrten Request-Methoden

UDP- und TCP-Relays:

  • Erzwingen einer starken Authentisierung am Proxy
  • Protokollierung des Benutzernamens im Falle einer Authentisierung

IP-Relay:

  • Der Aufbau von VPNs über das Application-Level-Gateway sollte mittels IP-Relays unterstützt werden.

DNS:

  • Bereitstellung einer integrierten Lösung bestehend aus öffentlichem und privatem DNS-Server
  • Sichere Abschottung des DNS-Proxies vom Rest des Betriebssystems des ALGs

Klartextprotokolle wie Telnet und FTP sollten nach Möglichkeit nicht mehr in öffentlichen Netzen benutzt werden und durch sicherere Alternativen (SSH / SCP) ersetzt werden. Auch im internen Netz sollten sie nur dann noch verwendet werden, wenn aus zwingenden Gründen ein Umstieg auf SSH oder ein anderes sicheres Protokoll nicht möglich ist.

Auch POP sollte nach Möglichkeit allenfalls noch intern verwendet werden. Sollen von einem externen Mailserver (etwa bei einem Provider) E-Mails abgerufen werden, so sollte der Variante "POP über SSL" der Vorzug gegeben werden. In diesem Fall ist allerdings ein SSL-Proxy (analog zum HTTPS-Proxy) nötig, der die verschlüsselte Verbindung am Sicherheitsgateway unterbricht und es so ermöglicht, E-Mails zentral auf Viren und andere schädliche Inhalte zu prüfen.

Prüffragen:

  • Wurde die Auswahl und Bewertung der Anforderungen an das ALG dokumentiert?

  • Erfüllen die eingesetzten Proxies die aufgeführten Anforderungen?

Stand: 13. EL Stand 2013