Grundprinzipien des Schleusen-Transfers
Die Umsetzung der Schleusen-Funktionalität des TightGate™-Pro folgt zwei Prinzipien:
Cut&Paste
Zur komfortablen Übertragung von Textpassagen dient die Cut&Paste-Funktion über die Zwischenablage. Sie kann sowohl auf TightGate™-Pro als auch am VNC-Client auf eine Richtung beschränkt oder ganz deaktiviert werden.
Datei-Schleuse
Als Datei-Schleuse dient das benutzereigene Transfer-Verzeichnis, in welches die zu transferierenden Dateien kopiert werden müssen. Auf dem TightGate™-Pro kann dies jeder Benutzer mittels des Dateibrowsers machen.
Die Nutzung des Dateitransfers kann wiederum durch die Administration auf dem TightGate™-Pro für jeden Benutzer individuell freigegeben werden (s. Abschnitt Sicherheitsmerkmale der Schleusenfunktion).
Von Seiten des internen Netzes erfolgt der Zugriff mittels SFTP1).
Sicherheitsmerkmale der Schleusenfunktion
Die Berechtigungen zur Nutzung von Transfermöglichkeiten vom und zum TightGate™-Pro können durch die Administration in verschiedenen Abstufungen und für einzelne Benutzer eingestellt werden. Dem Benutzer selbst obliegt es dann, die ihm möglichen Optionen zu aktivieren. Alle die Transfer-Ordner passierenden Files können optional mittels on-access-Scanner geprüft werden. Die Ausführung von Programmen im Transfer-Ordner ist ebenso verhindert, wie das Anlegen von speziellen Files (FiFOs, Devices, etc).
Transfer über die Zwischenablage
Über die Zwischenablage können nur Inhalte mit dem Format-Merkmal TEXT transferiert werden.2) Der Transfer über die Zwischenablage muss in jeder Sitzung einmal durch den Benutzer aktiviert werden. So wird nur bei Bedarf transferiert. Per Vorgabewert kann der Transfer über die Zwischenablage in eine Richtung beschränkt werden. Die Möglichkeit den Transfer über die Zwischenablage für einzelne Benutzer individuell sperren zu können ist wegen der besseren Übersichtlichkeit nicht per Menü einstellbar, kann aber auf Wunsch eingebaut werden.
Transfer per SFTP-Dienst
Der SFTP-Server-Dienst auf TightGate™-Pro ist mittels RSBAC-Rechten so gekapselt, dass er
Der Filetransfer per SFTP kann für jeden User einzeln freigegeben oder gesperrt werden.
Wenn auf dem TightGate-Pro ein Virenscanner aktiviert wird, werden alle Files, welche das Schleusenverzeichnis passieren, automatisch gescannt. Wird dabei eine Virusinfektion erkannt, wird der Zugriff auf diese Datei gesperrt, nur das Löschen ist dann noch möglich.
| Das Filter-Prinzip |
|---|
| Das Filtern oder Scannen ist ein Pattern-Vergleich. Virenscanner sind ein gutes Beispiel: Von bekannten Viren, Würmern und Trojanern werden als relevant betrachtete Codesegmente zum Vergleich bereitgehalten (die sog. Virenpattern oder Virensignaturen). Auf dem gleichen Prinzip basieren URL- und Web-Content-Filter und auch Packetfilter-Firewalls. Unterschieden werden die Filter-Systeme nach ihrer Grundregel in Positiv-Listen (whitelist) oder negativlisten (blacklist). Die Whitelist-Systeme folgen dabei dem Prinzip “Alles was nicht explizit erlaubt ist ist verboten!” und die Listen enthalten die erlaubten Pattern. Diese Filter-Art ist beispielsweise bei Packetfiltern die Regel. Anders die Blacklists: hier ist alles erlaubt, was nicht explizit “auf der Liste steht”. Dies ist z. B. das Prinzip von Virenscannern. Beim URL- und Web-Content-Filter sind beide Methoden bekannt. Mit Hilfe der Listen lassen sich zwar bestimmte Seitenbesuche (z.B. Ebay) recht wirksam be- oder verhindern. Als verlässliches Sicherheitssystem gereichen sie aber nicht. Grund dafür ist vor allem die Unmöglichkeit der Identifikation von schädlichen Inhalten. Selbst wenn z. B. eine ausnutzbare Sicherheitslücke im Browser bekannt ist, kann man oft nicht definieren, wie ein zu erwartender Angriff (exploit) darauf aussehen wird. Selbst eine URL-Whitelist (deren Einsatz meist schon ob der massiven Beschränkungen bei der Internetnutzung unmöglich ist) vertraut auf die Unversehrtheit anderer Systeme, wie z.B. des DNS-Systems und der Anbieter-Website. |
Risikoabschätzung
Für eine Risikoabschätzung (tragbar oder nicht tragbar) ist zuvor eine umfassende Analyse und Risikobewertung vorzunehmen. Hierbei sind nicht nur einzelne Risiken und Gegenmaßnahmen zu untersuchen, 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 sicherstellen soll, kann mittels DNS-Spoofing ausgehebelt werden.
Ist also z.B. 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 programm-technische Sicherheitslücke ausnutzt, sondern eine Benutzerinteraktion benötigt. Bekannte Beispiele hierfür sind z. B. Werbe-Links 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) aktiv werden und mindestens 2 Klicks in 2 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 Behebung der Sicherheitslücken abgeschaltet werden. Die Zeit bis zur Bereitstellung eines Patches kann schon mal mehrere Wochen dauern. Treten hiermit allerdings Inkompatibilitäten auf, kann es bis zur Lösung auch Monate dauern. |
|---|
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 | Anbindung TightGate™-Pro ohne Schleuse | Anbindung TightGate™-Pro mit Schleuse |
|---|---|---|---|
| Virusinfektion im internen Netz | hoch | sehr gering | gering (Virus-Datei muss aktiv transferiert werden) |
| “Wurminfektion” (Mailzugriff per Skript) | hoch | gering (Mail-Skripte kaum ausführbar, Browser hat keinen Zugriff auf Mail-Server oder Mail-Prozess) | gering (Mail-Skripte kaum ausführbar, Browser hat keinen Zugriff auf Mail-Server oder Mail-Prozess) |
| Datenspionage oder Hintertür-Programme (Rückkanal) im internen Netz | mittel (Rückkanal z.T. per Firewall blockierbar) | sehr gering (kein Zugang zum internen Netz) | gering (Schadprogramm muss aktiv transferiert werden, direkter Internetzugang muss bestehen) |
| Datenspionage oder Hintertür-Programme (Rückkanal) auf der TightGate-Pro | 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 unbekannter Programme, kein Netzwerkzugriff für normale Benutzerprogramme, vertrauliche Daten müssen aktiv transferiert werden) |
| Datenlöschung oder -veränderung im internen Netzwerk | mittel | sehr gering (kein Zugang zum internen Netz) | gering (Schadprogramm muss aktiv transferiert werden) |
| “Verklicken” des Benutzers | mittel bis hoch (z.B. gef. Menüs) | sehr gering (Benutzer müsste mehrschrittiger “Anleitung” folgen) | gering (Schadfunktion müsste auch auf beiden Seiten aktiv sein!) |
| Sicherheitslücken in anderen eingesetzten Softwarekomponenten | mittel bis sehr hoch (Umstands-abhängig) | sehr gering (interne Programme haben keine Internetkommunikation) | gering (Transfer kann bis zum Update temporär unterbrochen werden) |
Die Tabelle zu Risiken kann nur als Orientierungshilfe dienen. Sie erhebt keinen Anspruch auf Vollständigkeit und ersetzt nicht die Risikoanalyse im internen Netz.