Bundesamt für Sicherheit in der Informationstechnik

M 4.222 Festlegung geeigneter Einstellungen von Sicherheitsproxies

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

Verantwortlich für Umsetzung: Administrator

In dieser Maßnahme werden Empfehlungen zu Standardeinstellungen der wichtigsten Sicherheitsproxies zusammengestellt. Die vorgeschlagenen Einstellungen können allerdings die Funktionalität der betreffenden Inhalte einschränken (z. B. können eventuell Web-Seiten aufgrund des fehlenden JavaScript nicht mehr bedient werden) und müssen deshalb auf die eigenen Bedürfnisse angepasst werden.

HTTP

Die Filterung aktiver Inhalte in Webseiten ist ein zentraler Punkt bei der Sicherheit der Clients (siehe auch M 4.100 Sicherheitsgateways und aktive Inhalte ). Für Clients mit hohem Schutzbedarf bezüglich der Vertraulichkeit sollten aktive Inhalte in Webseiten grundsätzlich ausgefiltert werden. Gegebenenfalls können in Einzelfällen für vertrauenswürdige Websites aktive Inhalte zugelassen werden (Whitelist Strategie). Die entsprechenden Whitelists dürfen aber nicht zu umfangreich werden und müssen regelmäßig überprüft und gepflegt werden.

Folgende weitergehende Einstellungen werden für HTTP-Proxies empfohlen:

  • Sperrung des HTTPS-Verkehrs, falls kein HTTPS-Proxy eingesetzt wird,
  • Komplette Sperrung von Cookies (eventuell Freischaltung einzelner Webseiten),
  • Filtern bzw. Ersetzen der Browserkennung,
  • Filtern folgender Informationen aus dem Request-HTTP-Header:
    • Referer (falls beim Surfen eine Domain verlassen wird)
    • Via
    • From
  • Filtern folgender Informationen aus dem Response-HTTP-Header:
    • Server
  • Prinzipiell Freigabe aller URLs. Ggf. Sperrung einzelner, bedenklicher URLs und
  • Einschränkung auf notwendige MIME-Typen.
    Hinweis: Die Whitelist-Strategie "Alles sperren, was nicht explizit erlaubt ist" kann auf die Sperrung bzw. Freigabe von MIME-Typen nur schlecht angewendet werden. Aufgrund der Vielzahl der von Web-Seiten verwendeten MIME-Typen ist sehr schwierig, die relevanten Typen zu sperren und gleichzeitig die Funktionalität des Dienstes WWW wenigstens einigermaßen zu erhalten. Eine pragmatische Vorgehensweise ist die Sperrung besonders bedenklicher MIME-Typen. Um einen hohen Schutz zu erhalten, muss eine solche Sperrliste allerdings ständig vom Administrator auf dem Laufenden gehalten werden.

HTTPS

Bezüglich der Filterung von Schadprogrammen sollte wie beim HTTP-Proxy verfahren werden.

Ein HTTPS-Proxy ist die zentrale Entscheidungsinstanz für die Akzeptanz von Zertifikaten und nimmt den Benutzern weitgehend die Kontrolle über die Zertifikate ab. Aus diesem Grunde sind die Einstellungen des HTTPS-Proxies bezüglich der Vorgehensweise bei "problematischen" Zertifikaten besonders wichtig. Die folgende Tabelle gibt Vorschläge zur Einstellung in verschiedenen Fällen:

Entscheidung Vorschlag zur Einstellung
Akzeptieren von Zertifikaten, die von einer Zertifizierungsstelle ausgestellt wurden. Den in weit verbreiteten Browsern eingetragenen Zertifizierungsstellen kann vertraut werden. Dabei wird davon ausgegangen, dass die Vertrauenswürdigkeit der Zertifizierungsstellen durch den Hersteller der Browser überprüft wurde.
Trotzdem sollte regelmäßig geprüft werden, ob alle Zertifizierungsstellen noch vertrauenswürdig sind.
Gegebenenfalls können zusätzliche Zertifizierungsstellen hinzugefügt werden. Dies darf aber nur nach sorgfältiger Prüfung der Vertrauenswürdigkeit der Zertifizierungsstelle geschehen.
Akzeptieren von Zertifikaten, die nicht von einer Zertifizierungsstelle ausgestellt wurden ("self signed certificates"). Selbst erstellte Zertifikate dienen ausschließlich zur Verschlüsselung und bieten keine Funktionen zur Sicherstellung der Authentizität einer Web-Site.
Solche Zertifikate sollten nur in Ausnahmefällen nach einer expliziten Überprüfung akzeptiert werden.
Tunneln von Webseiten (d. h. bei diesen besteht Ende-zu-Ende-Verschlüsselung). Beim Tunneln wird die Filterung auf Schadprogramme umgangen. Daher sollte Tunneln nur ausnahmsweise zugelassen werden, wenn zu der betreffenden Gegenseite ein besonders hohes Vertrauen besteht.
Akzeptieren von Zertifikaten, bei denen der "Common Name" des Zertifikats nicht mit der aufgerufenen URL übereinstimmt. Stimmen der "Common Name" des Zertifikats und URL nicht überein, so ist dies prinzipiell ein Indiz für eine Manipulation.
Solche Zertifikate sollten prinzipiell nicht akzeptiert werden.
Akzeptieren von Zertifikaten trotz abgelaufenen Gültigkeitszeitraums. Vertrauenswürdige Web-Sites sind gut betreut und besitzen immer ein gültiges Zertifikat.
Zertifikate mit abgelaufenen Gültigkeitszeitraum sollten daher prinzipiell nicht akzeptiert werden.

Tabelle: Vorschläge zur Einstellung

SMTP

Auch im Zusammenhang mit SMTP (d. h. dem Dienst E-Mail) sollte M 4.100 Sicherheitsgateways und aktive Inhalte beachtet werden.

In verschiedene Sicherheitsproxies sind Spam-Filter integriert. Allerdings reichen die Fähigkeiten dieser Filter oft nicht an die Funktionalität dedizierter Spam-Filter (d. h. eigenständiger Komponenten) heran. Die Integration eines dedizierten Spam-Filters in das Sicherheitsgateway ermöglicht somit oft eine effektivere Filterung von E-Mails.

Derzeit existieren keine Verfahren, die "nützliche" E-Mails von Spam-Mails sicher unterscheiden können. Der Einsatz eines Spam-Mail-Filters ist deshalb nur dann zu empfehlen, wenn die Liste der verworfenen E-Mails ständig (in der Regel täglich) von einem Mitarbeiter nach versehentlich verworfenen E-Mails ("false positives") durchsucht wird.

Vorschläge zu Konfiguration und Betrieb des Spam-Filters:

  • Der Spam-Filter sollte gesperrte E-Mails nicht an den Absender zurückschicken bzw. eine Meldung über die Tatsache der Sperrung ausgeben, da der Spam-Absender in diesem Fall weitere Informationen über die Existenz seiner Adressaten erhält.
  • Ein automatisches Löschen von E-Mails kann aus verschiedenen (unter anderem aus rechtlichen) Gründen problematisch sein. Der Spam-Filter sollte daher keine E-Mails automatisch löschen, sondern sie stattdessen mit einem Hinweis versehen, dass es sich vermutlich um eine Spam-Mail handelt. Anhand dieses Hinweises kann der Mail-Client bzw. der Benutzer selbst eine Sortierung in unterschiedliche Postfächer oder Verzeichnisse vornehmen.
  • Die Betreuung des Spam-Filters sollte durch organisationsinterne Mitarbeiter erfolgen. Wird die Filterung als Dienst eingekauft, ergeben sich eventuell (datenschutz-) rechtliche Probleme.
  • Vor dem Einsatz von Spam-Filtern sollte eine umfassende rechtliche Zulässigkeitsprüfung im Einzelfall vorgenommen werden. Die allgemeine rechtliche Lage beim Einsatz von Spam-Filtern ist derzeit noch unklar. Die Einführung von Spam-Filtern sollte zudem mit der Betriebsleitung und dem Betriebsrat abgesprochen werden.
  • Appliances zur Spam-Filterung können den Installationsaufwand verringern. Diese Produkte bieten oft umfassende Updatemöglichkeiten zur Verbesserung der Erkennungsrate.
  • Bei eingehenden E-Mails sollte kontrolliert werden, ob Server des vertrauenswürdigen Netzes als Mail-Relay missbraucht werden. Dabei wird bei eingehenden E-Mails überprüft, ob die Empfängerdomain zum vertrauenswürdigen Netz gehört. Bei ausgehenden E-Mails sollte die Absenderdomain zum vertrauenswürdigen Netz gehören.
  • Ausgehende E-Mails sollten ebenfalls kontrolliert werden. Dadurch kann der Schaden begrenzt werden, wenn trotz aller Sicherheitsmaßnahmen ein Client im internen Netz mit einem E-Mail-Wurm infiziert wird. Auf diese Weise kann eine Infektion oft auch sofort entdeckt werden.
  • Auffällige E-Mail-Adressen sollten gesperrt werden.

Wird kein Spam-Filter in das Sicherheitsgateway integriert, so sollten die Mitarbeiter beim sicheren Umgang mit Spam-Mails geschult werden. Hinweise an die Mitarbeiter könnten sein:

  • Spam-Mails ungelesen löschen,
  • Unsubscribe-Funktion von Spam-Mails nicht verwenden,
  • Mit dem Absender "fraglicher" vor dem Öffnen Rücksprache halten, falls dieser bekannt ist und
  • Einige Provider wünschen die Zusendung von besonders auffälligen bzw. gefährlichen Spam-Mails. In Ausnahmefällen kann auch eine Benachrichtigung des Providers sinnvoll sein.

Filterung von Dateianhängen

Folgende Dateianhänge werden in den meisten Arbeitsumgebungen nicht benötigt und könnten gefiltert werden (geordnet nach der Art der Bedrohung):

Zugriff auf das gesamte System:

  • * .bat ( DOS -Batch-Datei)
  • * .vbx (Visual-Basic-Datei)
  • * .com (Windows-Anwendung)
  • * .hta (HTML-Applikationen)
  • * .inf (Installationsskript)
  • * .js (Jscript-Datei)
  • * .jse (Kodierte Jscript-Datei)
  • * .wsh (Windows-Scripting-Host-Skript)
  • * .vbs (Visual-Basic-Datei)
  • * .vbe (Kodierte Visual-Basic-Datei)

Ausführung beliebiger Anwendungen:

  • * .lnk (Link-Datei)
  • * .chm (Kompilierte HTML-Datei)
  • * .pif (Programm-Information-File)
  • * .rm (RealMedia-Datei)

Weitere Probleme:

  • * .mdb (Access-Datenbank. Können Makroviren beinhalten.)
  • * .reg (Registry-Datei. Kann Veränderungen an der Registry vornehmen.)

Diese Liste ist zwangsläufig unvollständig. Es existieren viele weitere Dateitypen, mit denen ein Endgerät kompromittiert werden kann, die teilweise für Arbeitsvorgänge unbedingt benötigt werden (z. B. .html, . xls , .pdf). Das Filtern von Dateien alleine anhand von Dateiendungen oder MIME-Typen kann alleine keine ausreichende Sicherheit erzeugen, da Dateien mit Schadprogrammen oft mit unbedenklichen Endungen versehen und trotzdem ausgeführt werden.

Telnet

Telnet sollte nur noch in Ausnahmefällen verwendet und nach Möglichkeit durch ein sichereres Protokoll wie beispielsweise SSH ersetzt werden. Muss Telnet aus zwingenden Gründen trotzdem noch eingesetzt werden, so müssen mit Hilfe des ALG oder der Paketfilter die erlaubten Verbindungen auf ein Minimum beschränkt werden.

FTP

FTP sollte wie Telnet ebenfalls nur noch in Ausnahmefällen verwendet und die erlaubten Verbindungen müssen ebenfalls mit entsprechenden Filterregeln oder Access-Control-Lists auf ein Minimum beschränkt werden.

Folgende Protokollbefehle sollten gefiltert werden:

  • PORT (Filterung verhindert aktives FTP)

POP3

Bei POP3 sollte M 4.100 Sicherheitsgateways und aktive Inhalte beachtet werden.

Prüffragen:

  • Sind die Einstellungen der Sicherheitsproxies zur Nutzung der unterschiedlichen Protokolle mit den Bedürfnissen der Organisation abgestimmt?

  • Erfolgt die Nutzung von SMTP über die Integration eines dedizierten Spam-Filters in das Sicherheitsgateway?

  • Erfolgt eine Filterung von Dateianhängen durch das Sicherheitsgateway?

  • Sind die umgesetzten Sicherheitsmaßnahmen bei der Nutzung von Proxies und zur Filterung von Dateianhängen nachvollziehbar dokumentiert?

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