Sicherheit am Anschluss: Application Level Gateways (ALG)

Version 1.0, 18.05.2002

Hauke Laging, Grazer Platz 22, 12157 Berlin, Tel.: 030/32603660, mobil: 0172/7630883, E-Mail: hauke@laging.de

Problem

Alle wollen Internet, nicht alle können Internet. Immer mehr kleine Firmen und Institutionen haben einen Internetanschluss, den sie auch für Zugriff von außen (Web, Mail, SSH) nutzen (wollen). Das ist problematisch, weil sie keine Leute mit Ahnung haben und daher nur hoffen können, dass die betroffenen Rechner immer sauber durchgepatcht sind.

Das Problem erstreckt sich in leichter Abwandlung auf den Schutz von Diensten durch SSL/TLS. Jeder möchte gern, aber kaum jemand kann.

Lösung

Der eingehende Traffic des Kunden wird durch ein ALG geleitet. Das würde für die "gebuchten" Protokolle und Anwendungen nach Angriffen suchen und die Verbindung ggf. abbrechen. Dies könnte auf zwei Arten geschehen: Es könnte alles verworfen werden, was "komisch" aussieht (klassisches ALG). Das kann aber kritisch werden, wenn der jeweilige Zugriff mal gewollt ist, und wäre keinesfalls ausreichend, weil Softwarefehler auch durch aus Protokollsicht legale Zugriffe getriggert werden können. Andererseits würde man für jeden beschriebene Sicherheitslücke Suchfilter definieren. Das hätte den generellen Vorteil, dass Angriffe schon vor der Verfügbarkeit eines Patches zuverlässig abgewehrt werden könnten – sobald das Problem bekannt ist, weiß man, wie es prinzipiell ausgenutzt werden könnte und kann darauf filtern. Die Entwicklung eines Patches ist nicht immer trivial, gerade wenn es sich um ein strukturelles Problem handelt. Und dann kommt – Gruß an MS – noch die Zeitspanne bis zur Veröffentlichung des Patches hinzu. Der Kunde hätte seine "Zahlen sie xy EUR im Monat und schlafen sie ruhig"-Lösung.

Die Beschränkung auf einzelne Protokolle und Anwendungen diente der drastischen Reduzierung der nötigen Rechenleistung. Denkbar wäre, dem Kunden jedes Protokoll und jede unterstützte Anwendung einzeln in Rechnung zu stellen.

Dieser Dienst funktionierte sowohl mit statischen als auch mit dynamischen IP-Adressen.

Verschlüsselung / Zertifikatverwaltung

Dies würde bei SSL u.ä. wohl nicht funktionieren bzw. nur gegen Angriffe der "Verhandlungsphase" des verschlüsselnden Protokolls. Dieses Problem und das der Kunden, dass SSL/TLS alles verkompliziert, könnte man dadurch umgehen, dass das ALG das SSL/TLS-Interface zum Netz wäre. Soll heißen: Die Schlüssel würden auf den ALGs verwahrt, so dass diese komplett den ganzen Traffic (auch den verschlüsselten) überwachen können, und die Kommunikation zwischen ALG und Kundenrechner wäre dann unverschlüsselt. Der Dienstleister könnte dann auch die Zertifikaterstellung für den Kunden übernehmen, so dass umfassende Sicherheit für technisch ahnungslose Kunden nur eine Unterschrift und einen Knopfdruck entfernt wäre.

Nutzen/Vorteile für den Kunden

Sicherheit ist für kommerzielle und institutionelle Kunden wichtig, dafür zahlen die gerne, zumal sie intern um einiges "schlampiger" sein könnten. Anders formuliert: Sie könnten deutlich mehr Geld sparen, weil sie mit einer weitaus weniger fähigen IT-Truppe auskämen (unter Sicherheitsaspekten).

Risiko für den Kunden

Man mag ein Risiko darin sehen, dass der Kunde dem Dienst zu sehr vertraut. Welcher Schaden kann entstehen, wenn mal etwas schiefgeht? Hier wären Haftungsfragen zu bedenken und zu klären. Vielleicht kann man in dem Zusammenhang gleich noch eine Versicherung gegen entsprechende Schäden verkaufen.

Neben den "false negatives" (den nicht erkannten Angriffen) besteht ein (geringes) Risiko an "false positives" (Fehlalarmen), die durch den Zeitdruck der Entwicklung sicher begünstigt werden. Allerdings könnte man die Suchmuster sehr leicht automatisiert testen. Für den Kunden hieße das, dass bestimmte legitime Verbindungen nicht aufgebaut werden könnten.

organisatorische Umsetzung

Die große Herausforderung dieses Dienstes liegt in der nötigen Reaktionszeit, die muss man erst mal gewährleisten. Die extremen Anforderungen an die Verfügbarkeit des Programmierteams stehen in großem Gegensatz zur geringen Auslastung. Glücklicherweise gibt es nicht genügend bekannte Sicherheitslöcher, um Entwickler damit permanent auf Trab zu halten. Das Ziel wäre also vermutlich, sich den zeitlich unmittelbaren Zugriff auf geeignete Experten bei anderen Firmen zu sichern. Durch Partner in verschiedenen Teilen der Welt wäre das Uhrzeitproblem leicht zu lösen. Zu bedenken ist auch, dass dieser Dienst für ISPs in anderen Ländern interessant wäre, mit denen ein Dienstleister bedenkenlos kooperieren könnte, da sie keine Wettbewerber von ihm sind. Dadurch könnten die Kosten der Programmierteams auf alle Nutzer verteilt werden – die Technik wäre überall identisch.

Die Investitionen in diesen Dienst wären also recht gering. Die ALG-Rechner würden nach Nachfrage angeschafft, die Entwicklungs-Kooperationspartner würden nach Laufzeit und Tätigkeit bezahlt. Versunkene Kosten gäbe es also eher wenig.

Erweiterung

Als Gimmick könnte man noch unerwünschte ausgehende Verbindungen (mit einem ganz trivialen Paketfilter) blocken, etwa solche, die von Viren aufgebaut werden (SMTP, SMB usw.). Schlimm genug, dass man sich was eingefangen hat, aber es müssen dann ja nicht noch alle merken. Bei entsprechenden Versuchen könnte das System irgendwie Alarm schlagen. Eine weitere Maßnahme, die keinen Eingriff ins lokale Netz erfordert: Alle Rechner des Kunden bekommen gelegentlich eine Testmail mit individueller Absenderadresse. Wenn jemals Mail an diese Adresse geschickt wird, weiß man, welcher Rechner sich was eingefangen hat.