![[externer Link]](../../images/link.gif)
www.kossakowski.de), der bereits ab 1992 mit dem Aufbau des ersten CERT in Deutschland betraut und bis Juni 2005 Vorsitzender des internationalen Dachverbands FIRST ( www.first.org) war.IPsec (RFC 4301) und DNSsec (RFC 4033) sind schon vor vielen Jahren von der IETF verabschiedet worden, aber bei Weitem noch nicht flächendeckend im Einsatz – noch immer ist nicht einmal klar, ob ein solcher Einsatz überhaupt erfolgversprechend sein kann. Doch anders als man erwarten mag, liegen die dafür zu lösenden Probleme nicht in den konkreten Protokollen, Sicherheitsfunktionen oder Leistungsparametern. Vielmehr sorgen drei gewichtige Aspekte für Unsicherheit: Mangelnde Transparenz für den Benutzer, Unvereinbarkeit mit existierenden Sicherheitslösungen und vor allem die Notwendigkeit einer breiten Unterstützung.
IPsec ist ursprünglich für die flächendeckende Authentifizierung und Verschlüsselung von IP-Verkehr im Rahmen von IPv6 entwickelt worden. Hierbei werden zwei Modi unterstützt: Ende-zu-Ende und der Aufbau von Tunneln. Damit ergeben sich im Prinzip die gleichen Möglichkeiten wie beim Einsatz von SSH, um von einem Client eine gesicherte Verbindung zu einem Server (z. B. zwecks Administration) aufzubauen, oder bei beliebigen VPN-Lösungen, die beispielsweise mehrere Standorte eines Unternehmens sicher miteinander verbinden. Konzeptionell stellt IPsec keine VPN-/SSH-Konkurrenz dar, sondern will bereits auf der Ebene von IP und ohne individuelle Zusatzprodukte eine globale, minimale Verfügbarkeit von Mechanismen für Vertraulichkeit und Authentifizierung sicherstellen. Es wurde erst später aus dem "IPv6-Universum" herausgelöst, um seine Mechanismen unabhängig von der konkreten Protokollversion nutzbar zu machen.
Aber selbst wenn ein Server seine IP-Pakete verschlüsselt und sogar mit einer Authentifizierung versehen weitergibt, bedeutet dies noch lange nicht, dass es sich auch um den "richtigen" Server handelt, den der Benutzer ansprechen wollte. IP-Adressen eingegebener Rechnernamen aufzulösen und die korrekten Einträge für eine Domain zu bestimmen, ist Aufgabe des Domain-Name-System-Service (DNS). Auch dieser Dienst ist hinlänglich für seine Unsicherheit bekannt, seien es neuere Schwachstellen in den gängigen Implementierungen oder die grundsätzlich fehlenden Sicherheitseigenschaften. DNSsec hat Erweiterungen definiert, die es einem Hostmaster ermöglichen, autorisierte Namens- und Adressauflösungen digital zu unterschreiben. Damit lässt sich unabhängig davon, ob das Ergebnis von einem Cache-Server stammt oder direkt aufgelöst wurde, prüfen, ob eine Autorisierung vorliegt oder an der Auflösung manipuliert wurde.
Es ist unstrittig, dass das Abfangen von IP-Paketen seit mehr als 15 Jahren vielen Benutzern und Organisationen Ärger, finanzielle Verluste und Überstunden eingebracht hat. Doch ist gerade in den letzten vier Jahren der Benutzer direkt ins Fadenkreuz der Computer-Kriminellen gerückt und es wird heutzutage auf sehr viel mehr Wegen versucht, seine Daten zu erlangen: direktes Kopieren auf Servern, Trojaner und Bots auf den Clients, Spam/Phishing über E-Mail, Drive-By-Exploits über den Browser und so weiter.
Gleichzeitig hat sich auch eine Menge von Sicherheitssystemen verbreitet, die Vertraulichkeit zumindest zwischen Clients und einem als sicher angesehenen Netzwerk oder Server gewährleisten – angefangen bei VPN-Lösungen bis hin zu in Anwendungen eingebauter Verschlüsselung auf Basis von SSL/TLS (z. B. HTTPS, IMAPS oder SMTP/TLS). Dennoch ist es angesichts der Sensitivität der übertragenen Daten und der Bedrohung durch langfristiges Datensammeln und dem Anlegen von Verkehrsprofilen weiterhin sinnvoll, durchgängig jedweden IP-Verkehr zu verschlüsseln.
Dringender ist jedoch tatsächlich der Schutz der Namens- und Adressauflösungen, wo es derzeit praktisch keine alternativen Lösungsansätze gibt und der Korrektheit der Auflösung mehr oder minder blind vertraut werden muss. Natürlich könnte man ins Feld führen, dass mit SSL-Server-Certificates geschützte Web-Server (gerade mit den neuen "härteren" Regeln) ausreichend authentifiziert sind; doch auch ein Computer-Krimineller kann sich mit einem legitimen Zertifikat einer der zahlreichen Zertifizierungsstellen "maskieren" oder kann ein legitimes Zertifikat von einem kompromittierten Server kopieren. Denkbar ist auch Malware, die den Zertifikatspeicher eines Clients manipuliert, um ein illegitimes Zertifikat zu installieren – ganz zu schweigen von anderen Anwendungsprotokollen, die keine Web-Server-Zertifikate nutzen können.
Es bleibt zu betonen: Wir brauchen sowohl IPsec als auch DNSsec in der Basis-Infrastruktur des Internets, flächendeckend und weltweit, sodass beide regelmäßig und durchgängig angewendet werden und eben nicht optional sind für die trotz ständiger Datenschutzverstöße unsicher surfenden Internet-Nutzer!
Jede Sicherheitsmaßnahme hat – direkt oder indirekt – auch Auswirkungen auf die Benutzer. Dies gilt umso mehr, wenn die Endgeräte selbst "verändert" werden, was bei einer Ende-zu-Ende-Verschlüsselung unumgänglich ist, ebenso bei Änderungen am Domain-Name-System.
Bei der Entwicklung neuer Sicherheitsmechanismen, die sich in existierende Infrastrukturen einpassen sollen, gilt es regelmäßig, möglichst wenige andere Komponenten in Mitleidenschaft zu ziehen. So ist beispielsweise DNSsec einsatzfähig, ohne dass die Anwendung den Benutzer über die Ergebnisse der Auswertung informieren müsste oder eine Auswertung überhaupt zwingend notwendig wäre. Anwendungen und Benutzeroberflächen müssen also nicht angepasst werden, aber damit entfällt dann für den Benutzer auch die zusätzliche Kontrolle.
Eine weitere pragmatische Möglichkeit besteht darin, zwar die Sicherheitserweiterungen von DNS intern einzusetzen und auszuwerten, allerdings den Benutzer nicht mit den Ergebnissen zu konfrontieren. Wenn also ein gefälschter DNS-Eintrag gefunden wird oder ein anderer Fehler auftritt, wird das Ergebnis einfach nicht verwendet. Dieser Ansatz verhindert zwar eine Gefährdung des Benutzers, aber ist für ihn überhaupt nicht zu nachvollziehbar. Das heißt, aus für den Benutzer nicht nachzuvollziehenden Gründen lässt sich dann plötzlich keine Verbindung zu einer Adresse aufbauen, die womöglich gestern noch problemlos funktioniert hatte. Und eine simple Meldung, dass der angegebene Rechnername nicht aufgelöst werden konnte, führt den Anwender im Zweifel in die Irre – die Anfragen bei den Hotlines kann man sich dann gut vorstellen.
Doch selbst wenn die Programme um geeignete Fehlermeldungen erweitert werden, bleibt es schwierig: Erfahrungen mit Web-Browsern zeigen, wie oft Meldungen nicht verstanden werden oder die Benutzer so irritieren, dass sie diese schlichtweg ignorieren ("wegklicken").
Firewalls und Intrusion-Detection-Systeme (IDS) beruhen auf der Grundidee, an möglichst zentralen Punkten (oder besonders wichtigen Netzsegmenten) Datenpakete zu inspizieren und – bei der Firewall – eventuell zu unterdrücken oder – bei IDS – Alarm auszulösen. Dies ist vor allem dadurch möglich, dass die Netzwerkpakete ungeschützt übertragen werden und so erkennbar ist, wenn sie beispielsweise einen Buffer-Overflow-Exploit enthalten.
Bei einer Ende-zu-Ende-Verschlüsselung entfällt die Möglichkeit, auf Netzwerkebene Pakete zu inspizieren. Diese Probleme sind nicht neu und treten heute bereits bei HTTPS-Verbindungen auf, die weitgehend ungefiltert Firewalls passieren, sofern sie nicht gänzlich verboten werden. Die Prüfung und Angriffserkennung muss dann ebenso wie die Verschlüsselung auf das Endgerät verschoben werden, wobei dies viele unterschiedliche Nachteile bedeutet: erhöhter Betriebsaufwand, neue Software auf den Endgeräten et cetera. Wird das Endgerät erfolgreich angegriffen, kann eventuell sogar ein Alarm unterdrückt oder das lokale IDS ausgeschaltet werden – ähnlich wie dies bei Anti-Viren-Programmen schon häufig zu beobachten war.
Auch andere Sicherheitslösungen – Spam-, Viren- oder Content-Filter – werden in ihrer Wirkung beeinträchtigt, wenn komplett Ende-zu-Ende verschlüsselt wird. Allerdings steht nicht zu erwarten, dass der großflächige Schutz, wie ihn eine Firewall vor einem Unternehmensnetzwerk darstellt, aufgegeben wird, wie es einige Sicherheitsforscher in der Vergangenheit propagiert hatten. Es müssen vielmehr Übergänge für Lösungen geschaffen werden, die es ermöglichen, die Netzwerkpakete zwecks Überprüfung "unterwegs" zu entschlüsseln.
Kein Mensch – und auch kein Computer – kann Auskunft darüber geben, wie viele unterschiedliche Betriebssysteme und Systemkomponenten weltweit im Einsatz sind. Auch wenn einzelne Organisationen oder ganze (Forschungs-)Netze sich entscheiden, in ihrem Bereich eine neue Technik einzusetzen, werden diese nicht riskieren, sich vom weltweiten Internet abzuschneiden. Vergleichbare Erwägungen werden bei den System-Herstellern vorherrschen, wenn man über die Standardkonfiguration nachdenkt.
Dieses in der IT vielfach bekannte Problem, alte Standards zu unterstützen – entweder als Legacy oder positiver als Abwärtskompatibilität bezeichnet – wird so lange vorherrschen, bis die überwiegende Mehrheit sich für den neuen Standard entschieden hat. Da aber die alten Protokolle nach wie vor funktionieren, entsteht eben kein großer Druck, schnell etwas zu ändern.
Wie bereits erwähnt, gibt es zahlreiche andere Möglichkeiten, erfolgreich Angriffe gegen Benutzer und Organisationen zu vereiteln oder zumindest zu erschweren. Aber das ist kein Argument gegen die Verbreitung sinnvoller Sicherheitsmechanismen und ihre mittelfristige Etablierung als Standard. Nur zeigt sich, dass dies in der Praxis schwierig ist – wie immer, wenn Sicherheit quasi als "noch ein Feature" hinzukommt und nicht von Anfang an mit dabei ist.
Die <kes>-Rubrik CERT News berichtet über aktuelle Entwicklungen aus dem Umfeld von Computer Emergency bzw. Security Incident Response Teams (CERTs/CSIRTs). Betreuer dieser Kolumne ist Klaus-Peter Kossakowski ( www.kossakowski.de), der bereits ab 1992 mit dem Aufbau des ersten CERT in Deutschland betraut und bis Juni 2005 Vorsitzender des internationalen Dachverbands FIRST ( www.first.org) war.
Die mangelnde Transparenz führt bei den Benutzern zu Unsicherheit oder Fehlentscheidungen und unterminiert damit die ohnehin schon schwache Bereitschaft, die "lästige" Sicherheit zu akzeptieren. Die Bedenken der Sicherheitsverantwortlichen sind berechtigt – aber hier geht es nicht um ganz oder gar nicht: Die Notwendigkeit flächendeckender Verschlüsselung als Mittel zur Datensparsamkeit muss vielmehr zu einer Weiterentwicklung traditioneller Sicherheitswerkzeuge wie Firewalls und IDS führen. Die kontrollierte Entschlüsselung zur Überprüfung ist eine Lösung, die zwar ein Aufweichen der Ende-zu-Ende-Sicherheit erfordert, aber zumindest funktionieren kann.
Nicht zu lösen bleibt die Frage, wie ein weltweiter Roll-out organisiert werden kann. Da das Internet auf Verfahren beruht, die entweder dem kleinsten gemeinsamen Nenner entsprechen oder aber von der Mehrheit mitgetragen werden, dürfte "das Internet" noch viele Jahre unsicher bleiben. Ob die genannten Techniken in einzelnen Bereichen eingeführt werden, hängt wie bisher wohl vom Engagement der Sicherheitsexperten und wohl auch von staatlichen Grundsatzentscheidungen ab – hier hat sich über die Jahre wenig geändert.
Jedenfalls ist es an der Zeit, vor allem DNSsec zu erproben und durch den Erfolg ein Beispiel zu geben – und natürlich das notwendige Know-how aufzubauen und zu verbreiten, damit der Einsatz in anderen Organisationen und Netzwerken reibungsloser erfolgen kann. Mal sehen, wer den Anfang macht.
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2008#5, Seite 66
tag:kes.info,2007:lp:2008-5-B
| 