In diversen FAQ-Artikeln unserer Website beleuchten wir ausführlich die technologischen Wesenszüge der Client/Server-Topologie, etwa in faq?77 bzw. in faq?93, wo wir die Folgen deren Ausbleibens an einigen aus der Praxis hergenommenen Beispielen schildern, oder aber in faq?=99, wo es um die verteilten Datenbanksysteme geht. In dem vorliegenden Artikel gehen wir auf die Aspekte der Sicherheit ein, auch unter dem Blickwinkel der Client/Server-Topologie.
Im Zuge von dramatisch fallenden Kosten für Internetanbindungen, bei gleichzeitig explosionsartig zunehmenden Bandbreiten, wird das Internet immer mehr als das physikalische Medium für die Client/Server-Verbindungen bzw. Standortvernetzungen eingesetzt. Was aber im Netz der Netze ebenfalls explosionsartig zunimmt, ist die Quantität und die Qualität von Attacken, denen ein Internet-angebundenes System pausenlos ausgesetzt ist. Folglich müssen auch unsere Abwehrmechanismen mit dieser Entwicklung Schritt halten, was im Laufe der Zeit immer ausgefeiltere Firewalls bis hin zu VPN’s hervorgebracht hat. Doch ist insbesondere Letzteres wirklich ein besonders ausgeklügelter Schutzmechanismus oder nicht vielleicht eher eine Ultima Ratio aufgrund von topologischen Unzulänglichkeiten in dem zu schützenden System?
Man kann sich eine Internet-Verbindung als ein Kabel mit sehr vielen Adern vorstellen; konkret gibt es gut 65000 logische Kanäle und eine Vielzahl von Protokollen, unter denen dasjenige mit der Nr. 6, das Transport Control Protocol (TCP), wohl am bekanntesten ist. Über jede dieser „Adern“ können Daten vom Internet z.B. auf einen unserer Rechner fliessen – leider nicht nur solche, die es gut mit uns meinen. Somit ist zunächst einmal das Sperren einzelner Kanäle die Hauptaufgabe jeder Schutzvorrichtung (Firewall), egal, ob diese eine Hard- oder Softwarevorrichtung ist oder eine Mischung aus beidem. Wenn nun das Gros dieser Kanäle zumindest für eingehenden Datenverkehr gesperrt ist, kann man von einer recht guten Absicherung des Systems gegenüber Attacken von aussen sprechen.
Die K&S GmbH setzt je nach Gegebenheiten zwei mögliche Produkte als Software-Firewall ein: den Linux-basierten Astaro sowie den Microsoft ISA-Server (Internet Security and Acceleration Server). Beide Produkte können einen im topologischen Frontend placierten Server zu einem brauchbaren Schutzwall machen; der erste der beiden ein wenig preisgünstiger, der zweite dafür noch ein Stück ausgefeilter. Aber grundsätzlich ermöglichen es beide Produkte sowie eine Vielzahl anderer, die Freigaben und Routings auf der Firewall sehr punktuell vorzunehmen und diese nur entsprechend autorisierten Hosts oder Benutzern in frei definierbaren Zeitfenstern etc. zu gewähren.
Wie arbeitet und was erfordert in diesem Zusammenhang eine transObjects®-Vorrichtung? Nun, wie jede andere lupenreine Client/Server-basierte Technologie, die zudem als „internetfest“ gilt, erfordert der im transObjects® bevorzugte Caché-Server einen einzigen frei definierbaren Kanal (Port), über den die Clients via Internet Verbindung zu ihm aufbauen oder auch mehrere Datenbankserver Daten in einem verteilten System austauschen können:
Verwaltungskonsole von MS Internet Security and Acceleration (ISA) Server 2004. mit publishing rule für den Caché-Server
Entgegen dem allerersten Eindruck, der sich einem vielleicht aufdrängen mag, ist eine solche Konstruktion gerade unter sicherheitsrelevanten Gesichtspunkten als sehr hochwertig einzustufen. Der Hauptgrund ist eben in dem exklusiven Port zu suchen, an dem jenseits der Barrikade einzig und alleine die Datenbankinstanz ansprechbar ist. Dies schränkt den Spielraum eines potentiellen Hackers dramatisch ein und ermöglicht uns wiederum weitergehende Schutzmechanismen zu implementieren, darunter einen Authentifizierungsmechanismus, Paketfilterung bis hin zu einer Demilitarisierung, was letztendlich die „sauberste“ Sache ist, da es den Ernstfall mit einkalkuliert und einen destruktiven Zugriff auf isolierte Server (und hier auch isolierte Protokolle und Kanäle) umleitet.
Dies ist beispielsweise im Falle einer anderen sehr bekennten Client/Server-Topologie, nämlich dem MS Exchange Server und dem MS Outlook, gerade nicht der Fall. Outlook benötigt nämlich eine Vielzahl von Ports, um den Exchange-Server ansprechen zu können, darunter auch so sicherheitsrelevante Ports wie z.B. den für die sog. RPC (Remote Procedure Call). Eine Öffnung all dieser Ports würde dem potentiellen Angreifer eine Vielzahl an Zugangskanälen bieten, die er dann in aller Ruhe darauf, was diese evtl. zu „bieten“ haben, abklappern könnte. Dies würde ein völlig unkalkulierbares Risiko darstellen.
Eine der Möglichkeiten, diesen Risiken teilweise zu entrinnen, besteht in einer Art Rückbesinnung auf die gewissermassen „natürliche“ Umgebung, in der zumindest ältere Systeme zuhause sind, d.h. auf das lokale Netzwerk, in dem man nicht mehr von aussen attackiert werden kann, jedenfalls nicht mehr so akut gefährdet ist. So kamen dann auch VPN’s (Virtual Private Networking) bei vielen Standortvernetzungen als „Leitungen“ zum Einsatz. Da die Bandbreite von Telefon- oder Datenleitungen (etwa X.25) sehr bescheiden war, traten irgendwann einmal die Internet-basierten VPN’s auf den Plan.
Wie funktioniert nun ein „VPN over IP“, wie es sich auf Neudeutsch schimpft? In einem Satz gesagt, es werden auf den jeweiligen Firewalls eines Verbundes Bündelungs- und Adressübersetzungstools installiert, so dass sich jeder Rechner „virtuell“ im lokalen Netzwerk befindet. Jede Anfrage, die dem lokalen Netzwerk gilt, wird durch die lokale VPN-Firewall übersetzt und via Internet zu einer anderen VPN-Firewall geschickt, wo sie wieder rückübersetzt wird.
Für zwei Rechner an zwei unterschiedlichen Standorten stellt sich alles so dar, als würden beide Daten über das lokale Netzwerk austauschen: der eine sendet Daten ins lokale Netzwerk und interessiert sich nicht weiter dafür, dass diese durch die VPN-Wall abgefangen und ins Internet geroutet werden, der andere empfängt sie zwar wiederum von „seiner“ VPN-Wall, diese versieht aber alles mit Adressen, als käme alles aus dem lokalen Netz!
Das hört sich zunächst einmal sehr gut an, ist aber in Wahrheit der eigentliche Schwachpunkt von VPN’s. Denn wie zuvor erwähnt, die beste Strategie zur Abwehr von destruktiven Aktivitäten im System, insbesondere Attacken von aussen übers Internet, besteht in deren gezielter Lenkung auf wenig sensible Subnets oder einzelne wenig sensible (Dummy-) Server, kurzum in der Demilitarisierung. VPN ist aber das genaue Gegenteil dazu: Geographisch getrennte Systeme werden zu logischen Einheiten zusammengefasst und somit als Ganzes entsprechenden Gefährdungen ausgesetzt.
VPN erhöht somit zunächst das Gefährdungspotential und senkt es nicht, wie manchmal (allerdings selten) suggeriert. Um diesen so gestiegenen Risiken beizukommen, bieten alle besseren Firewalls, die auch VPN und dessen Schutz zu bieten haben (so auch Astaro und ISA), diverse Tools zur Zugriffsauthentifizierung und Daten-Verschlüsselung, zum Teil sogar mit Unterstützung für zusätzliche kryptische Vorrichtungen, wie z.B. Smartcards. Dieser Aufwand ist keineswegs überzogen, wenn man bedenkt, was man zu verhindern sucht, nämlich die völlige Entblössung des unternehmensweiten Systems!
Der beste Schutz allerdings ist und bleibt, bestimmte Risiken gar nicht erst aufkommen zulassen. Aus diesem Grund ist eben bei vielen Unternehmen der Trend weg von VPN hin zu anderen Strategien zu beobachten, unter denen die zuvor erwähnte Demilitarisierung eine zentrale Rolle spielt. Anhand von zwei Fällen aus der Praxis wollen wir es nun festmachen – Ähnlichkeiten mit real existierenden Fällen sind wie immer rein zufällig…
Fall 1: Ein Unternehmen aus der Schweiz unterhält 3 Standorte, jedoch nur einen zentralen Mailserver, den MS Exchange 2000. In der täglichen Arbeit möchte man die Features des MS Outlook nicht missen also stellt sich die Frage, wie stellt man die Verbindung von Outlook zu Exchange via Internet her. Der Sysop vor Ort forciert fortan VPN, das er schlussendlich auf Basis von Astaro-Firewalls implementiert, die an den jeweiligen Standorten placiert werden.
Hat er eine Alternative gehabt? Und ob! In dem hier zitierten Falle hatte der Kunde am Standort A einen MS ISA-Server 2000 laufen. Seinerzeit
entwickelte Microsoft im Rahmen eines sog. Feature-Packs eine interessante Möglichkeit, über einen einzigen Port auf den MS Exchange zugreifen zu können. Dies war der Vorläufer des RPC over HTTP, einer Lösung, die unter Windows 2003 / Exchange 2003 standardmässig vorhanden ist! (ab Exchange 2007 „Outlook Anywhere“ – nachtr. Anm. d. Verf.).
Aus diesem Fall lernen vor allem, dass VPN offensichtlich nicht als das Ei des Kolumbus angesehen wird. Vielmehr entwickelt die Softwarebranche Alternativen zu VPN und das wohl nicht von ungefähr.
Fall 2: Ein mittelständisches Unternehmen in Deutschland kann auf eine „Linux-XY“-Software (Name frei erfunden) nicht verzichten, obwohl diese nicht internetfest ist, insbesondere mehrere Kanäle in den bestehenden Firewalls für sich beansprucht. Die für ihn einzig gangbare Lösung, das VPN, kommt somit zum Zuge.
Natürlich ist es in diesem Falle die einzig gangbare Lösung, sozusagen Ultima Ratio; dies zumindest solange sich der Hersteller der Linux-XY-Software nicht etwas in Richtung eines Tunneling einfallen lässt. Aber Ultima Ratio heisst eine letzte gangbare Option und das unter dem knappstmöglichen Kompromiss. Dieser Kompromiss, nämlich die tangierte Systemsicherheit, ist allerdings nicht mehr knapp…
Fazit: VPN ist eindeutig eine Rückzugstechnologie und zwar der sicherheitsrelevanten Schwächen wegen. Aus diesem Grunde scheut die Softwarebranche keine Mühe und keine Kosten, um das sichere Anwenden deren Produkte via Internet zu ermöglichen, ohne dabei das unternehmensweite System wegen VPN als Ganzes angreifbar zu machen. So besteht beispielsweise inzwischen eine Zugriffsmöglichkeit aus dem Internet über einzelne zusätzlich abgesicherte Kanäle auf nahezu alle Serverprodukte, wie Datenbank- oder Mailserver.
VPN kann allerdings eine Ultima Ratio sein, etwa dann, wenn das zu schützende System kein „Tunneling“ zu bieten hat. Man sollte allerdings tunlichst zusehen, dass dies möglichst nur vorübergehend der Fall ist…
Unser FAQ-Artikel „transObjects® vs. LinuxXY oder warum ist VPN eine Rückzugstechnologie?“ hat insofern seine Zielsetzung verfehlt, als dass er anstatt Fragen zu beantworten, was die eigentliche Aufgabe dieser Sparte ist, eine Lawine derselben aufgeworfen hat J; jedenfalls haben wir selten zuvor eine so lebhafte, teils leidenschaftliche Diskussion losgetreten, wie mit der ganzen „Rückzugstechnologie“. Allerdings, dass eine solche (Dis-) Qualifizierung die gesamte VPN-Gemeinde gegen uns aufbringen wird, hätten wir uns im Prinzip denken können.
Auch wenn wir vorliegend Eure Einwände in gewohnter Klarheit qualifizieren, habt vielen Dank für jeden Diskussionsbeitrag. Auch in Zukunft freuen wir uns über Eure kritischen Fragen und Anregungen!
Eure Einwände – nennen wir es einfach Fragen – lassen sich im Wesentlichen in zweierlei Gruppen gliedern:
1. Wie kommt Ihr denn darauf, VPN als eine „Rückzugstechnologie“ zu bezeichnen, wo doch immer mehr Firmen – z.B. Fa. XY – nach und nach auf das VPN einschwenken?
2. Wie kommt Ihr denn darauf, VPN als ein „Sicherheitsrisiko“ zu qualifizieren, wo doch diese und jene Vorrichtung eines so bekannten Herstellers das VPN doch so unglaublich sicher macht?
Beginnen wir nun mit letzterem der beiden Fragenkomplexe. Viele unter Euch, die sich als „security professionals“ (oder so ähnlich) bezeichnen, wenden ein, dass Eure VPN’s (die Ihr einsetzt oder vertreibt) doch so sicher seien, da alles Mögliche für den notwendigen Schutz sorge – von dynamischer 156-Bit-Verschlüsselung über Radius bis hin zu irgendwelchem kryptischen Zusatzequipment. Einer von Euch hat sogar „seine“ VPN (den Hersteller lassen wir hierbei unerwähnt) als „absolut sicher“ bezeichnet.
Zu diesem Fragenkomplex ist zunächst anzumerken, dass unser FAQ-Artikel auf VPN’s als solche abzielt, jedoch nicht auf konkrete Schutzvorrichtungen von Checkpoint, Cisco, Telekom und weiss der Kuckuck von wem noch, die im Produktnamen das Kürzel „VPN“ mit verbrämt haben. Diesen Produktbezeichnungen ist auch das grösste Missverständnis zuzuschreiben, worüber unser Artikel handelt, nämlich, dass VPN etwas mit Sicherheit zu tun habe, dass es die beste Firewall sei ;-).
In Wahrheit hat VPN per se mit dem einen wie dem anderen rein gar nichts zu tun. Gewiss ist einem System, das auf Smartcards aufbaut, die einem wiederum an die Hose gepappt werden (wodurch bei jedem Gang auf Toilette eine Trennung vom VPN erfolgt ;-)) ein ausgesprochen hohes Mass an Sicherheit zu bescheinigen… Nur: Diese Sicherheit besteht nicht aufgrund oder gar dank VPN sondern vielmehr trotz des VPN! Anders ausgedrückt: VPN macht gewisse Sicherheits-Vorrichtungen erst zwingend erforderlich, denn das zu Schützende ist nun nicht mehr nur eine „kleine“ DMZ sondern bereits das unternehmensweite System. Noch anders ausgedrückt, für diejenigen, die mathematisch fundierte Beweise benötigen: Würden wir die Wahrscheinlichkeit der Korrumpierung einer Schutzvorrichtung mit den entsprechend quantifizierten Folgen derselben, etwa den finanziellen Folgen, multiplizieren, so erhielten wir durch:
den stochastischen Erwartungswert für die finanziellen Verluste, die aufgrund von destruktiver Nutzung unserer Anlage einzukalkulieren wären. Da wir bei unserem Modell der Einzelkanal-Freigabe absolut die gleichen Schutzvorrichtungen verwenden können, die in Euren so genannten VPN’s drinnen stecken, erreichen wir genau das gleiche p, jedoch ein ungleich geringeres V. Die Folgen der Korrumpierung eines einzelnen Datenbankkanals, der womöglich noch auf eine demilitarisierte Zone geroutet wird, sind überhaupt nicht mit denen einer völligen Entblössung des gesamten Systems zu vergleichen!
Natürlich werdet Ihr jetzt einwenden, dass Euer p doch so klein sei – und einer hat wie gesagt behauptet, dieses sei gleich Null! Wir wollen die Binsenweisheit, wonach es eine absolute Sicherheit nicht gebe, nicht diskutieren. Der Kollege mit dem „absolut sicheren VPN“ möge jedoch bedenken, dass eine destruktive Nutzung des Systems nicht unbedingt von aussen generiert sein muss. Wenn jemand seine Smartcard stecken lässt und Kaffe trinken geht, kann jemand anders Verschiedenes anstellen. Die Frage ist, ob Ihm dabei das weltweite Unternehmensnetzwerk offen „zur Verfügung“ steht oder nicht.
Nein, an den gnadenlosen Zwängen könnt Ihr einfach nicht vorbei. Um ein Produkt zweier Zahlen gering zu halten, müssen beide Faktoren möglichst klein gehalten werden. Für den ersten der beiden habt Ihr alle viel zu bieten, für den zweiten nicht unbedingt. Hier darf man keine getrennten Standorte zu einem einzigen zusammenfassen und auch nicht getrennte IP-Kanäle zu einer logischen „Leitung“ bündeln. Mit anderen Worten: Weg mit dem VPN!
Als Fazit muss die unsererseits ausgemachte Sicherheitsschwäche des VPN’s als solchen ohne jeden Abstrich bestehen bleiben.
Was den ersten Fragenkomplex anbelangt, so können wir Euch teilweise Recht geben. Denn VPN’s als „Rückzugstechnologie“ zu qualifizieren ist – zumindest unter markettingtechnischen Gesichtspunkten – derzeit (Ende 2005) noch nicht belastbar und von daher kann man es durchaus als zu kategorisch bezeichnen. Dieses Prädikat entsprang einfach der Beobachtung, dass Alternativen zu VPN mit hohem Aufwand entwickelt werden.
Aber ansonsten muss an der Relativierung festgehalten werden, dass VPN eine Konzession an veraltete Software oder Systeme darstellt und das auf Kosten (und nicht etwa zu Gunsten) der Sicherheit. Inwieweit das bereits als ein „Rückzug“ unsererseits zu werten ist, kann vortrefflich diskutiert werden. Sofern Ihr aber als weiteres Argument „namhafte Unternehmen“ ins Feld führt, darunter solche, die in der jüngsten Vergangenheit ihre „Klasse“ gezeigt haben, so werdet Ihr verstehen, dass wir darin als alles Mögliche sehen, aber nicht den Beweis für die Zukunftsträchtigkeit des VPN. Bedenkt bitte, dass die Lagerhallen bei so machen IT-Grossunternehmen mit Ladenhütern gefüllt sind, die nicht selten das „VPN“ mit in der Produktbezeichnung tragen. Und diese Unternehmen verfügen über exzellente Marketingabteilungen 😉 !!!