Das Konzept der "Dateischleuse"

Grundprinzipien des Schleusen-Transfers

Die Umsetzung der Schleusenfunktionalität auf TightGate-Pro folgt dem Grundprinzip: Kein Automatismus zur Durchleitung und Weiterverarbeitung von Inhalten. Benutzer sollen aktiv (also bewusst) die Übergabe steuern.

Kopieren und Einfügen (Copy&Paste)

Zur komfortablen Übertragung von Textpassagen dient die Funktion zum Kopieren und Einfügen (Copy&Paste) über die Zwischenablage. Sie kann sowohl auf TightGate-Pro Server als auch am VNC-Klienten TightGate-Pro Client auf eine Richtung beschränkt oder ganz deaktiviert werden.

Dateischleuse

Als Dateischleuse dient das benutzereigene Transferverzeichnis, in welches die zu transferierenden Dateien kopiert werden müssen. Jeder Benutzer kann dies mittels des Dateibrowsers bewerkstelligen. Die Nutzung des Dateitransfers kann wiederum durch die Administration auf TightGate-Pro Server für jeden Benutzer individuell freigegeben oder gesperrt werden.

Aufseiten des internen Netzes erfolgt der Zugriff mittels SFTP1) .

Sicherheitsmerkmale der Schleusenfunktion

Die Berechtigungen zur Nutzung des Datentransfers zwischen TightGate-Pro Server und internem Netzwerk können in verschiedenen Abstufungen und für einzelne Benutzer eingestellt werden. Alle die Transfer-Ordner passierenden Dateien können optional mittels On-Access-Scanner geprüft werden. Die Ausführung von Programmen im Transfer-Ordner wird unterbunden, so auch das Anlegen von speziel­len Dateien (FiFOs, Devices, etc.).

Transfer über die Zwischenablage

Über die Zwischenablage können nur Inhalte mit dem Formatmerkmal TEXT2) transferiert werden. Per Vorgabewert kann der Transfer über die Zwischenablage in eine Richtung beschränkt werden. Der Transfer über die Zwischenablage kann global oder benutzerindividuell zugelassen oder gesperrt wer­den.

Für CC-konforme Umgebungen ist der Transfer über die Zwischenablage so eingestellt, dass jede Datenübertragung durch den Benutzer explizit auszulösen ist.

Transfer per SFTP-Dienst

Der SFTP-Server-Dienst auf TightGate-Pro Server ist mittels RSBAC-Rechten so gekapselt, dass er

  • nur in die zugelassenen Transfer-Verzeichnisse transferieren kann
  • nur normale Files erzeugen kann (also keine Pipes/FIFOs oder Devices)
  • keine Kommandos übergeben kann
  • keine Programme starten kann
  • keine Ports umleiten kann
  • selbst in einem RSBAC-Jail gestartet wird, also andere Prozesse nicht „sieht"

Der Filetransfer per SFTP kann für jeden Benutzer einzeln freigegeben oder gesperrt werden.

Wenn auf TightGate-Pro Server ein Virenscanner aktiviert ist, werden alle Dateien, welche das Schleusenverzeichnis passieren, automatisch gescannt. Wird dabei eine Virusinfektion erkannt, wird der Zugriff auf diese Datei gesperrt. Nur das Löschen der Datei ist dann noch möglich.

Das Filter-Prinzip

Das Filtern oder Scannen ist ein Pattern-Vergleich. Virenscanner sind ein gutes Beispiel: Von bekann­ten Viren, Würmern und Trojanern werden als relevant betrachtete Codesegmente zum Vergleich be­reitgehalten (die sog. Virenpattern oder Virensignaturen). Auf dem gleichen Prinzip basieren URL- und Web-Content-Filter und auch Paketfilter-Firewalls. Unterschieden werden die Filter-Systeme nach ihrer Grundregel in Positivlisten (Whitelist) oder Negativlisten (Blacklist). Die Whitelist-Systeme folgen dabei dem Prinzip "Alles was nicht explizit erlaubt, ist verboten." Die Listen enthalten die erlaubten Pattern. Diese Filterart ist bei Paketfiltern die Regel.

Anders die Blacklists: Hier ist alles erlaubt, was nicht explizit auf der „schwarzen Liste" steht und damit verboten ist. Dies ist das Prinzip von Virenscannern. Beim URL- und Web-Content-Filter sind beide Methoden verbreitet. Mit Hilfe von Listen lassen sich bestimmte Seitenaufrufe recht wirksam verhin­dern. Als verlässliches Sicherheitssystem genügen sie nicht, da sie schädliche Inhalte nicht als solche identifizieren können. Selbst wenn beispielsweise eine ausnutzbare Sicherheitslücke im Browser be­kannt ist, kann man nicht zuverlässig vorhersehen, wie ein zu erwartender Angriff (Exploit) aussehen wird.

Eine URL-Whitelist wäre eine rigorose Maßnahme, deren Einsatz meist schon ob der massiven Be­schränkungen bei der Internetnutzung in der Regel unmöglich ist. Doch auch ein solches Vorgehen vertraute auf die Unversehrtheit anderer Systeme, wie z.B. des DNS-Systems und der Anbieter-Web­site.

Risikoabschätzung

Für eine Risikoabschätzung (tragbar oder nicht tragbar) ist zuvor eine umfassende Analyse und Risi­kobewertung vorzunehmen. Hierbei sind nicht nur einzelne Risiken und Gegenmaßnahmen zu unter­suchen, sondern diese immer im Kontext des Gesamtsystems zu sehen.

Beispiel 1: URL-Whitelist und DNS-spoofing Die URL-Whitelist, welche den Abruf von unerwünschten Inhalten unterbinden soll, kann mittels DNS-Spoofing ausgehebelt werden. Ist also die Beschränkung mittels URL-Whitelist ein Sicherheitsfeature, so muss das Gefahrenpotenzial von DNS-Spoofing deutlich höher bewertet werden als im Normalfall, bei dem die Sicherheit auf anderen Mechanismen beruht.

Beispiel 2: (Provoziertes) „Verklicken" des Benutzers Zu bewerten ist das Risiko eines erfolgreichen Angriffs (oder einer Systemstörung), welche keine pro­grammtechnische Sicherheitslücke ausnutzt, sondern eine Benutzerinteraktion benötigt. Bekannte Beispiele hierfür sind z. B. Werbelinks, auf denen ein "Schließen"-Button gezeigt wird - ein Klick auf das Bild aber direkt zum Werbeangebot führt.

Die Gefahr ist umso größer zu bewerten, je weniger Schritte durch den Benutzer benötigt werden. In der Regel sind viele Angriffe in einem direkt angebundenen System mit einem Klick erfolgreich. In TightGate-Pro muss der Benutzer immer auf beiden Seiten (intern und auf TightGate-Pro Server) aktiv werden und mindestens zwei Klicks in zwei verschiedenen Umgebungen ausführen.

Beispiel 3: Temporäre Gefahren durch bekannte Sicherheitslücken in Softwarekomponenten Bekannte Sicherheitslücken in internen Programmen (insbesondere in Interpretern) können solange durch gezielte Angriffe ausgenutzt werden, bis ein Sicherheitspatch eingespielt ist. Dieser Zeitraum ist nicht nur vom Hersteller und der Reaktionszeit der internen Administration abhängig, sondern auch von der Kompatibilität (des Patches) mit bestehenden Anwendungen. Insbesondere Fachanwendungen sind oft auf eine bestimmte Softwareversion zugeschnitten und nicht mit aktualisierten Versionen zu betreiben.

In direkt angebundenen Netzwerken müsste bei Nutzung bekannt unsicherer Softwarekomponenten die Internetfunktionalität bis zur Schließung der Sicherheitslücken abgeschaltet werden. Die Zeit bis zur Bereitstellung eines Patches kann längere Zeit dauern - im Fall von Inkompatibilitäten wäre der Auf­wand zur Problemlösung noch höher.

Folgerungen für die Nutzung der Schleusenfunktionalität

Man muss das Risiko abschätzen, welcher Schaden für das interne Netz entstehen kann, wenn die Schleuse geöffnet wird und wenn sie geschlossen bleibt.

Einige Gefahren werden beispielhaft untersucht:

Risiko Direkte Anbindung TightGate -Pro ohne Schleuse TightGate -Pro mit Schleuse
Virusinfektion im in­ternen Netz hoch sehr gering gering (Virus-Datei muss aktiv transferiert werden)
Wurminfektion (Mail­zugriff per Skript) hoch gering (Mail-Skripte kaum ausführbar, Browser hat kei­nen Zugriff auf Mail-Server oder Mail-Prozess) gering (Mail-Skripte kaum ausführbar, Browser hat kei­nen Zugriff auf Mail-Server oder Mail-Prozess)
Datenspionage oder Hintertür-Programme (Rückkanal) im inter­nen Netz mittel (Rück­kanal z.T. per Firewall blo­ckierbar) sehr gering (kein Zugang zum internen Netz) gering (Schadprogramm muss aktiv transferiert werden, di­rekter Internetzugang muss bestehen)
Datenspionage oder Hintertür-Programme (Rückkanal) auf TightGate-Pro Server n. a. sehr gering (keine Ausführung unbekannter Programme, kein Netzwerkzugriff für normale Benutzerprogramme, außer E-Mail keine vertraulichen Daten) gering (keine Ausführung un­bekannter Programme, kein Netzwerkzugriff für normale Benutzerprogramme, vertrau­liche Daten müssen aktiv transferiert werden)
Datenlöschung oder -veränderung im in­ternen Netzwerk mittel sehr gering (kein Zugang zum internen Netz) gering (Schadprogramm muss aktiv transferiert werden)
"Verklicken" des Be­nutzers mittel bis hoch (z. B. gef. Menüs) sehr gering (Benutzer müsste mehrschrittiger "Anleitung" folgen) gering (Schadfunktion müsste auf beiden Seiten aktiv sein!)
Sicherheitslücken in anderen eingesetzten Softwarekomponenten mittel bis sehr hoch (umstandsabh­ängig) sehr gering (interne Pro­gramme haben keine Inter­netkommunikation) gering (Transfer kann bis zum Update temporär unterbrochen werden)

Die Tabelle zu Risiken kann nur als Orientierungshilfe dienen. Sie erhebt keinen Anspruch auf Voll­ständigkeit und ersetzt nicht die Risikoanalyse im internen Netz.

1)
SFTP steht für “Secure File Transfer Protocol” und ermöglicht den authentifizierten und verschlüsselten Zugriff auf die freigegebenen Ressourcen.
2)
Das bedeutet nicht, dass nur Texte transferiert werden können. So kann theoretisch jeglicher Inhalt transferiert werden, wenn dieser zuvor in ein TEXT-Format konvertiert wurde z.B. nach base64, welches aber auf der Gegenseite wieder decodiert werden muss.