Sicherheit

Die große Debatte: Sicherheit durch Verschleierung

Jesper M. Johansson and Roger Grimes

Auf einen Blick:

• Sicherheit durch Verschleierung
• Evaluierung von Maßnahmen auf dem Gebiet Sicherheit durch Verschleierung
• Bewertung des Nutzens der Umbenennung des Administratorkontos
• Treffen fundierter Entscheidungen zum Risikomanagement

Der Begriff „Sicherheit durch Verschleierung“ wird von Sicherheitsverantwortlichen oft belächelt, insbesondere von denjenigen, die sich für Experten halten. In manchen Kreisen wird „Sicherheit

durch Verschleierung“ beinahe als anstößiger Ausdruck betrachtet, und wie bei Wikipedia zu lesen ist (en.wikipedia.org/wiki/Security_through_obscurity), handelt es sich um ein äußerst umstrittenes Sicherheitskonzept. Man hört oft spöttische Bemerkungen über Personen, deren Bemühungen mit „nichts als Sicherheit durch Verschleierung“ abgetan werden.

Sicherheit durch Verschleierung ist, kurz gesagt, ein Verstoß gegen Kerckhoffs Prinzip, das besagt, dass ein System aufgrund seines Designs sicher sein sollte, und nicht, weil das Design dem Angreifer unbekannt ist. Die Prämisse von Kerckhoffs Prinzip ist, dass Geheimnisse nicht lange Geheimnisse bleiben.

Ein gutes Beispiel hierfür ist das NTLM-Authentifizierungsprotokoll (Windows NT®-LAN-Manager), das anfangs als Designgeheimnis erachtet wurde. Um das Samba-Interoperabilitätsprodukt für UNIX-basierte Betriebssysteme zu implementieren, musste das Samba-Team das Protokoll rekonstruieren. Das Ergebnis war die umfassendste Dokumentation zu NTLM, die es gibt (monyo.com/technical/samba/translation/ntlm.en.html), und es wurde eine Reihe von Fehlern entdeckt. Da im Bereich Sicherheit so vieles aus der Kryptografie erwachsen ist und eine so große Anzahl geheimer Designs offengelegt wurde, glauben viele Sicherheitsfachleute, dass Informationssicherheit voll und ganz auf Kerckhoffs Prinzip basieren sollte.

Aber ist Sicherheit durch Verschleierung immer etwas Schlechtes? In diesem Artikel wird erklärt, was Sicherheit durch Verschleierung bedeutet. Es wird erläutert, weshalb dieses Konzept von vielen als Zeitverschwendung betrachtet wird (und von anderen nicht), und es wird aufgezeigt, warum die Antwort, wie es so oft der Fall ist, deutlich komplizierter ausfällt, als es zunächst den Anschein hat.

Einführung in Sicherheit durch Verschleierung

„Kein Ändern von Standardeinstellungen“ von Steve Riley

Ich vertrete beim Thema Umbenennung den Standpunkt „Keine Änderung“. Dabei handelt es sich nicht um eine Sicherheitsfrage, sondern eine Frage der Systemverwaltung. Je mehr ich über Systemverwaltung nachdenke (weil Verwaltung und Sicherheit miteinander verschmelzen), desto mehr werde ich zum Anhänger des Ansatzes, nichts zu tun, was die Stabilität eines Systems u. U. beeinträchtigen könnte. Eine sichere Möglichkeit, die Stabilität zu beeinträchtigen, ist das Ändern von Standardeinstellungen. Es gibt zwei (oder auch drei) Gründe, weshalb Benutzer Standardeinstellungen ändern:

• Die durch die Änderung ermöglichte Funktionalität ist erforderlich.
• Es besteht die Annahme, dass durch die Änderung die Sicherheit verbessert wird.
• (Achtung: Dummheit!) Die Änderung wird aufgrund der Lektüre eines Zeitschriftenartikels vorgenommen.

Wenn Sie einen Standardnamen aus Grund 1 ändern müssen, lassen Sie sich davon nicht abhalten. Diese Arten von Änderungen führen selten zu Systeminstabilität, was oft daran liegt, dass sie zuvor getestet wurden.

Wenn Sie eine Standardeinstellung aus Grund 2 ändern, überdenken Sie dies noch einmal. Diese Arten von Änderungen werden fast nie vom Softwarehersteller getestet, und deshalb kann der Hersteller nicht voraussagen, wie das System sich nach der Änderung verhalten wird. Außerdem gibt es meist viel bessere Alternativen, die wirkliche Sicherheit bieten.

Was macht es schon, wenn ein Angreifer einen Kontonamen kennt? Es sind das Kennwort und die Stärke des Kennworts, die den Angreifer von Ihrem System fernhalten. Der Drang, Standardkontonamen wie „Administrator“ und „Gast“ in etwas zu ändern, das nicht so leicht zu erraten ist, ist oft in Wirklichkeit Ausdruck des Wunschs, starke Kennwörter oder Kennsätze zu vermeiden. Beheben Sie das eigentliche Problem (schlechte Geheimnisse), und Sie können Instabilität (infolge der Änderung von Standardnamen) vermeiden.

Sicherheit durch Verschleierung beinhaltet keine Maßnahmen, die nicht zum Verringern eines Problems beitragen. Eine Organisation, die das Network News Transfer-Protokoll (NNTP) an den Grenzroutern blockiert, um Mitarbeiter am Lesen von Newsgroups zu hindern, aber das ausgehende Secure Shell (SSH) zulässt, handelt nicht nach dem Prinzip der Sicherheit durch Verschleierung. Da SSH jedes Protokoll tunneln kann, wird das Problem nicht verschleiert. Die sinnlosen Schutzmaßnahmen, die implementiert wurden, hindern legitime Benutzer lediglich daran, legitime Aufgaben ohne Verstoß gegen die Sicherheitsrichtlinien auszuführen. Solche zwecklosen Maßnahmen bieten keinerlei Sicherheit durch Verschleierung.

Wie das Wort „Sicherheit“ im Ausdruck „Sicherheit durch Verschleierung“ impliziert, bietet die Maßnahme Schutzfunktionen. Ebenfalls impliziert ist aber, und darin liegt das Problem, dass Sie in Wirklichkeit nichts tun, um eine Sicherheitslücke zu beseitigen. (Eine Sicherheitslücke gibt einem Angreifer die Möglichkeit, auf ein System zuzugreifen.)

Angenommen Sie verfügen über einen anfälligen Webserver, der mithilfe einer öffentlich bekannten Sicherheitsanfälligkeit über TCP-Port 80 angegriffen werden kann. Um diese Sicherheitslücke zu schließen, können Sie das beim Webserver vorliegende Problem beheben, oder Sie können ihn abschalten. Durch beide Aktionen würde die Sicherheitslücke beseitigt. Sie könnten die Sicherheitslücke teilweise beseitigen, indem Sie eine Firewall oder IPsec verwenden, um Port 80 für alle außer für einige ausgewählte Computer zu schließen. Dadurch würde die Sicherheitsanfälligkeit nicht vollständig behoben, aber das Problem deutlich verringert.

Sicherheit durch Verschleierung andererseits beinhaltet das Ergreifen von Maßnahmen, durch die die Sicherheitslücke nicht beseitigt, sondern lediglich verborgen wird. Sie können dem Webserver z. B. Port 81 statt Port 80 zuweisen, sodass der Webserver nur von Benutzern gefunden werden kann, denen dies bekannt ist. Das ist zumindest die Idee. Ihrem Webserver Port 81 zuzuweisen, verhindert in Wirklichkeit nur bestimmte Angriffe und verursacht hauptsächlich Unannehmlichkeiten für den Endbenutzer. Ein fähiger Angreifer würde einfach einen Portscanner und einen so genannten Webbannergrabber auf eine große Zahl von Ports ansetzen, um Webserver auf nicht standardmäßigen Ports zu finden. Sobald ein Webserver entdeckt wird, kann über die Sicherheitsanfälligkeit ein Angriff auf den Server durchgeführt werden, weil Sie die Sicherheitslücke nicht wirklich beseitigt, sondern nur (vorübergehend) verschleiert haben.

Bedeutet das, dass Sie es gar nicht erst versuchen sollten? Das kommt ganz darauf an. Wie bei allem im Bereich Informationssicherheit läuft es auf das Risikomanagement hinaus. Um die Hauptfaktoren zu verstehen, die dabei berücksichtigt werden müssen, werfen wir einen kurzen Blick auf einige weitere Maßnahmen im Bereich Sicherheit durch Verschleierung und erörtern dann eine solche Maßnahme – das Umbenennen des Administratorkontos – ausführlicher.

Bewertung von Sicherheitsmaßnahmen

Beispiele für Sicherheit durch Verschleierung sind reichlich vorhanden. Es kann sich um Maßnahmen handeln, die von System- und Netzwerkmanagern oder von Softwareentwicklern ergriffen werden. Alle diese Maßnahmen haben jedoch gemeinsam, dass sie eine Sicherheitsanfälligkeit beseitigen sollen, indem diese vor potenziellen Angreifern verborgen wird.

Könnten nicht einige dieser Verfahren zumindest eine positive Wirkung haben? Ist es wirklich angemessen zu behaupten, dass Sicherheit durch Verschleierung immer schlecht ist? Sie werden sicherlich Befürworter zumindest einiger dieser Maßnahmen finden. In Windows® ist es z. B. möglich, Laufwerkbuchstaben in Windows-Explorer auszublenden. In vielen Umgebungen, besonders in Computerpools von Schulen, werden Benutzer mithilfe dieses Verfahrens daran gehindert, Daten auf der Festplatte zu speichern. Selbstverständlich können die meisten Anwendungen weiterhin Daten auf der Festplatte speichern. Deshalb bietet dieses Verfahren als ultimative Sicherheitsmaßnahme nur geringen Wert. Die Institutionen, die zu dieser Maßnahme gegriffen haben, behaupten aber oft, dass dadurch die Datenmenge auf der Festplatte verringert wurde.

Eine andere Art von Maßnahme im Rahmen von Sicherheit durch Verschleierung, die unter Windows oft implementiert wird, besteht im Abschalten administrativer Netzwerkfreigaben (z. B. C$, Administrator$ usw.). Dadurch soll ein Angreifer daran gehindert werden, von einem Remotestandort aus eine Verbindung zum Computer herzustellen. In Wirklichkeit ist dies nicht nur unrichtig, sondern ein Angreifer, der über ein Konto verfügt, das die administrativen Freigaben verwenden kann, kann von einem Remotestandort aus genau diese Freigaben reaktivieren. Trotzdem bestehen viele Organisationen darauf, dass durch das Deaktivieren dieser Freigaben die Zahl der Fälle von Malware auf ihren Netzwerken verringert wird.

Eines unserer Lieblingsbeispiele für unangebrachte Bemühungen ist die Windows-Einstellung „Entfernen ohne vorherige Anmeldung erlauben“. Wenn diese Einstellung deaktiviert wird, wird die Schaltfläche „Computer abdocken“ nicht im Anmeldebildschirm angezeigt. Die Idee hierbei besteht darin, dass ein Angreifer den Computer dann nicht ordnungsgemäß abdocken kann. Selbstverständlich kann ein Angreifer den Computer und die Dockingstation einfach in eine Tasche stecken und davonspazieren, unabhängig davon, ob die Schaltfläche sichtbar ist oder nicht. Diese Möglichkeit bietet im Grunde nicht einmal Sicherheit durch Verschleierung.

Ein anderes klares Beispiel ist die Einstellung „Serveroperatoren das Einrichten von geplanten Tasks erlauben“. Wie der Name schon sagt, wird Benutzern, die Mitglieder der Gruppe der Serveroperatoren sind, hierdurch ein Planen von Aufgaben ermöglicht. Dies ist ein erhebliches Problem, weil solche Aufgaben u. U. als lokales System ausgeführt werden, und nur Administratoren sollten Aufgaben planen können, die als lokales System ausgeführt werden. Selbstverständlich können sich Serveroperatoren theoretisch durch eine ganze Reihe verschiedener Angriffsmethoden zu Administratoren machen. Sie auf diese Weise am Planen von Aufgaben zu hindern, ist daher ziemlich wertlos.

Trotzdem mögen viele Organisationen diese Einstellung, weil dadurch Technikern ermöglicht wird, als Serveroperatoren statt Administratoren zu agieren, was es weniger wahrscheinlich macht, dass sie unbeabsichtigt den Server zerstören. Dies könnte somit von Vorteil sein.

Wie lautet also der Urteilsspruch? Offensichtlich können einige dieser Probleme äußerst kompliziert sein. Wir haben viele schöne Stunden damit verbracht, diese Arten von Maßnahmen zu diskutieren. Roger Grimes gehört zu denjenigen, die solche Maßnahmen für sinnvoll halten. Jesper Johansson dagegen meint, dass es sich dabei in den meisten Fällen bestenfalls um Zeitverschwendung handelt. Werfen wir einen Blick auf einen der am häufigsten genannten – und diskutierten – Fälle für Sicherheit durch Verschleierung: die Umbenennung des Administratorkontos. Roger Grimes argumentiert für diese Maßnahme, Jesper Johansson dagegen. Die bekannten Sicherheitsexperten Aaron Margosis und Steve Riley kommen in den Randleisten „Umbenennen des Administratorkontos“ und „Kein Ändern von Standardeinstellungen“ ebenfalls zu Wort.

Ausblenden des Administratorkontos

Die Maßnahme, dem Administratorkonto, relativer Bezeichner (RID) 500, einen der Allgemeinheit unbekannten Namen zu geben, wird von Sicherheitsfachleuten oft empfohlen und ist in mehreren Microsoft-Absicherungshandbüchern enthalten. Die Gruppenrichtlinie enthält sogar eine Einstellung zum Umbenennen des Administratorkontos (siehe Abbildung 1). Der Gedanke dabei ist, dass es bei Umbenennung des Administratorkontos für einen Angreifer schwieriger wird, sich als echter Administrator anzumelden. Das offensichtliche Problem beim Verwenden der Gruppenrichtlinie für diesen Vorgang besteht darin, dass das umbenannte Administratorkonto auf jedem Computer, auf den dieses Gruppenrichtlinienobjekt angewendet wurde, den gleichen Namen hat. Dadurch wird der Verschleierungswert dieser konkreten Sicherheitsmaßnahme verringert.

Abbildung 1** Umbenennung des Administratorkontos. **(Zum Vergrößern auf das Bild klicken)

In diesem Kontext muss auch erkannt werden, dass jeder Benutzer mit einem legitimen Konto den Namen des Administratorkontos abrufen kann, unabhängig davon, ob es umbenannt wurde oder nicht. Das Administratorkonto hat immer die RID 500. Wenn Benutzer mit einem Konto also einfach nach dem Namen des Kontos mit der RID 500 fragen, können sie den tatsächlichen Namen ermitteln (siehe Abbildung 2).

Abbildung 2** Suchen des umbenannten Administratorkontos **(Zum Vergrößern auf das Bild klicken)

Der Standpunkt von Roger Grimes

Das mir bekannte Hauptargument gegen das Umbenennen des Administratorkontos lautet, dass es so einfach ist, den Kontonamen eines Sicherheitsprinzipals in seine verwandte Sicherheits-ID (SID) zu konvertieren und die RID zu ermitteln. Das echte Administratorkonto hat immer die RID 500. Was macht es schon, wenn ein Angreifer problemlos Benutzerkontonamen in die SID/RID-Kombination konvertieren und die RID mit dem Wert 500 ermitteln kann?

Aber so einfach ist es nicht. Um Benutzerkontonamen in SID/RID-Kombinationen zu übersetzen, müssen Sie auf die NetBIOS- oder die LDAP-Ports zugreifen können. Die meisten Umkreisfirewalls lassen diese Art von Zugriff über das Internet nicht zu. Solange der Angreifer die Firewall also nicht vollständig umgeht, kann er auch nichts übersetzen. Außerdem funktionieren anonyme SID-Übersetzungen nicht bei Windows XP und höheren Windows-Versionen, außer auf Domänencontrollern (DCs). Bei den meisten von außen zugänglichen Computern (den am meisten gefährdeten) benötigt der Angreifer authentifizierte Anmeldeinformationen, um Namen in SIDs zu übersetzen.

Es gibt eine erhebliche Zahl echter Tiefenverteidigungsmaßnahmen, die umgangen werden müssen, um einen Übersetzungsangriff zu starten. Selbst wenn der Angreifer es so weit schafft, befindet er sich an der gleichen Stelle, an der er auch ohne eine Umbenennung des Kontonamens gelandet wäre. Das Umbenennen des Administratorkontos kann die Sicherheit nur verbessern. Es kann ihr sicherlich nicht schaden.

Ein weiteres Geheimnis Wenn ein Angreifer den Namen des Administratorkontos nicht kennt, wird dieser zu einer weiteren „geheimen“ Bezeichnung, ähnlich wie ein Kennwort, das ein Angreifer kennen muss. Zugegeben, es ist wenig wahrscheinlich, dass Benutzerkontonamen ebenso komplex sind wie ein Administratorkennwort, aber es ist immerhin eine weitere Hürde, die das Ermitteln des Kennworts exponentiell erschwert. Wenn Sie jemals Kennwortpenetrationstests durchgeführt haben, wissen Sie bereits, wie viel mehr Arbeit es erfordert, sowohl den Benutzernamen als auch das Kennwort zu erraten. Dadurch wird eine ohnehin schwierige Aufgabe nur noch schwieriger.

Wehrt automatisierte Malware und Skriptkiddies ab Ich wende seit 22 Jahren Windows-Sicherheitsstrategien an und unterhalte seit 5 Jahren acht Windows-Honeypots, die über das Internet zugänglich sind. In der ganzen Zeit ist es nie vorgekommen, dass automatisierte Malware (die die große Mehrheit aller Angriffsarten darstellt) jemals eine andere Benutzerkontobezeichnung als „Administrator“ (oder „root“ im Fall von *NIX-Systemen) verwendet hätte. Wenn Sie Ihr Administratorkonto umbenennen, wehren Sie damit alle Malware ab, die auf dem Administratornamen basiert. Das ist gleichbedeutend mit einem verringerten Sicherheitsrisiko.

Dasselbe gilt für Skriptkiddies. Jedes „angesagte“ Windows-Hackerhandbuch, das ich kenne, erwähnt Verfahren zur Übersetzung von Namen in SIDs, aber aus irgendeinem Grund habe ich ein solches Verfahren noch nie bei einem meiner Honeypots festgestellt, wenn zur Abwehr auch ein „gefälschtes“ Administratorkonto vorhanden war. Gute Hacker sollten immer überprüfen, ob das Administratorkonto, das sie gefunden haben, das wirkliche Administratorkonto ist (RID 500), aber sie tun es aus unerfindlichen Gründen nicht. Es ist wohl auf die Faulheit der Hacker und auf gewöhnliche menschliche Verhaltensweisen zurückzuführen.

Hält auch die meisten Profis fern Dies ist für die meisten überraschend. Wenn Sie einige Jahre lang Honeypots unterhalten haben, erkennen Sie schnell den Unterschied zwischen automatisierten Angriffen, Skriptkiddies und Profis. In den vergangenen fünf Jahren gab es Millionen gemeldeter Angriffe auf meinen Honeypots, aber Profis haben nie SID-Übersetzung verwendet, wenn das gefälschte Administratorkonto vorhanden war.

Ich bin sicher, dass einige der professionellen Kriminellen SID-Übersetzung verwenden, aber mit Sicherheit ist dies nur eine kleine Minderheit, die mir in der Realität nie begegnet ist. Weshalb tun Profis dies nicht? Sie sehen wohl keinen Grund darin, etwas zu versuchen, das von der Mehrheit der anderen Profis nicht verwendet wird.

Erleichtert Warnungen Die andere Seite mag behaupten, dass das Administratorkonto seinen Wert als Verschleierungsverfahren verlieren würde, wenn ein Umbenennen dieses Kontos weit verbreitet wäre. Das Argument lautet, dass Malware, Skriptkiddies und Profis ihre Standardtaktiken ändern und nach anderen Namen als nur nach „Administrator“ suchen würden. Das ist ein berechtigter Einwand. Glücklicherweise ändert dies nichts am wesentlichen Aspekt. Wenn das extrem privilegierte Windows-Konto nicht „Administrator“ heißt, müssen Hacker härter arbeiten. Das ist eine Tatsache. Wenn Hacker härter arbeiten müssen, ist es etwas weniger wahrscheinlich, dass sie es mit dieser Angriffsmethode versuchen, was vielleicht dazu führt, dass ein anderes Tiefenverteidigungsverfahren schädliche Aktivitäten noch schneller erkennt.

Das führt zu meinem letzten Argument zugunsten des Umbenennens. Wenn Ihr Administratorkonto nie „Administrator“ genannt wird und Sie ein anderes Konto mit diesem Namen erstellen (siehe Abbildung 3), verfügen Sie über einen guten Warnmechanismus. Wenn die Ereignisüberwachung dann eine versuchte Anmeldung mithilfe des Standardnamens erkennt, ist dies ein Ereignis, das sofort untersucht werden sollte.

Abbildung 3** Anmeldeversuche bei einem Köderkonto namens „Administrator“ können als frühe Warnung dienen **(Zum Vergrößern auf das Bild klicken)

Unsere Ereignisprotokolle sind voll von „falschen“ Anmeldungen, die nichts bedeuten. In der Regel sind es nur Benutzer (oder Windows), die versuchen, sich mithilfe eines falschen Kennworts oder Ähnlichem anzumelden. Wenn Ihr Administratorkonto aber den Namen „Administrator“ trägt, wie können Sie dann problemlos ordnungsgemäße Anmeldeversuche von Anmeldeversuchen eines Angreifers unterscheiden? Wenn Sie kein Anmeldekonto namens „Administrator“ haben und eine versuchte Anmeldung mithilfe dieses Kontonamens feststellen, wissen Sie, dass wahrscheinlich eine böswillige Absicht dahintersteckt. Frühe unauffällige Warnungen sind heutzutage für Sicherheitsbelange von großem Wert.

Die Meinung von Jesper Johansson

„Umbenennen des Administratorkontos“ von Aaron Margosis

In einer idealen Welt hätte Jesper Johansson vollkommen Recht. Kennwörter wären immer stark genug, um ein Erraten durch Brute-Force-Angriffe unmöglich zu machen, und lokale Administratorkonten mit der RID 500 würden ausschließlich für die Notfallwiederherstellung verwendet. In der Praxis trifft aber keines von beidem zu.

Obwohl Jesper Johansson so viel Öffentlichkeitsarbeit im Interesse der Sicherheit geleistet hat, und insbesondere angesichts seiner großartigen Artikelreihe zu Kennsätzen („Die großen Debatten: Kennsätze oder Kennwörter“, Teile 1, 2 und 3, unter go.microsoft.com/fwlink/?LinkId=113157, go.microsoft.com/fwlink/?LinkId=113159 und go.microsoft.com/fwlink/?LinkId=113160), wissen viele Systemadministratoren nicht, was heutzutage ein starkes Kennwort ausmacht.

Vor nicht allzu langer Zeit war ein Kennwort, das aus acht zufälligen Zeichen aus mehreren Zeichensätzen bestand, ein starkes Kennwort. Aufgrund des Mooreschen Gesetzes ist diese Auffassung veraltet. Die Schulung von Benutzern (und Systemadministratoren) ist ein Schwachpunkt und wird dies höchstwahrscheinlich auch bleiben, zumindest so lange wie das Thema Kennwortstärke nicht in den Schlagzeilen der Kabelnachrichtenkanäle erscheint.

In Anbetracht der Tatsache, dass das Erraten eines Kennworts in der heutigen Praxis keine 600 Milliarden Jahre dauert, sondern oft während der Mittagspause durchgeführt werden kann, kann das Hinzufügen des Faktors 1.000 wirklich nützlich sein. Ein Umbenennen würde das Administratorkonto für die vielen automatisierten Angriffe, die auf das Konto abzielen, unverwundbar machen.

Der Zeit- und Arbeitsaufwand, der in der Regel mit dem Umbenennen des Administratorkontos verbunden ist, ist meist gering. Wie bereits erwähnt, ist dafür meist nur eine einfache GPO-Einstellung erforderlich. Der Federal Desktop Core der US-Regierung (csrc.nist.gov/fdcc) erfordert in der Tat ein Umbenennen des Kontos mit der RID 500. Das Umbenennen ist nur eine von vielen erforderlichen Einstellungen und keine, die nach meiner Erfahrung übermäßig viel Zeit oder Aufmerksamkeit erfordert. Mir ist auch nicht bekannt, dass jemand deshalb ein falsches Gefühl der Sicherheit entwickelt hätte – ich habe noch nie jemanden sagen hören: „Wir benötigen keine Patchverwaltung, weil wir unsere Administratorkonten umbenannt haben.“

Ist das Umbenennen von Nutzen, wenn das Konto in der gesamten Organisation den gleichen Namen erhält? Der Nutzen ist nicht groß, aber vorhanden: Zum einen werden automatisierte Angriffe, die den Namen „Administrator“ erwarten, dadurch blockiert, und zum anderen ist die Menge potenzieller Angreifer nicht unbedingt eine Teilmenge all derer, die den neuen Namen kennen. (Das größere Risiko besteht, wenn lokale Administratorkonten – ob umbenannt oder nicht – innerhalb einer Organisation das gleiche Kennwort verwenden. Ihre Verwaltung bleibt das größere und wichtigere Problem. Das Konto mit der RID 500 zu deaktivieren, ist eine Möglichkeit zur Behandlung des Problems, aber dadurch wird eine wichtige Wiederherstellungsmethode blockiert, wenn Domänenkonten nicht verwendet werden können.) Es soll auch darauf hingewiesen werden, dass unsere Sicherheitshandbücher seit langem das Umbenennen von Standardkonten empfehlen. Deshalb wurde diese Maßnahme gründlich getestet und wird vollständig unterstützt.

Es ist inzwischen wohl allgemein bekannt, dass Verschleierungsmaßnahmen für sich allein keine angemessene Verteidigung darstellen. Dadurch können jedoch andere Sicherheitsmaßnahmen unterstützt werden, und die Daten von Roger Grimes zeigen dies recht deutlich. Solange die Implementierungskosten gering sind, sollten Organisationen diese Maßnahmen in Erwägung ziehen.

Es gibt nicht nur Argumente für, sondern auch gegen das Umbenennen des Administratorkontos. Bevor ich darauf eingehe, muss ich aber zugestehen, dass das letzte Argument von Roger Grimes ziemlich plausibel ist. In einer intensiv verwalteten Umgebung sollte aber jede Anmeldung beim Administratorkonto untersucht werden, weil dieses Konto wirklich nur für eine Notfallwiederherstellung dient.

Es ist überflüssig Das Hauptrisiko, das durch das Umbenennen des Administratorkontos verringert werden soll, besteht darin, dass jemand das entsprechende Kennwort von einem Remotestandort aus erraten könnte. Es würde aber nur ein Benutzer, der kein anderes autorisiertes Konto auf dem Computer besitzt, durch das Umbenennen des Administratorkontos ferngehalten werden. Solch ein Angreifer versucht in der Regel, sich mithilfe einer Reihe zufälliger Kennwörter beim Administratorkonto anzumelden. Er erhält dabei aber stets die gleiche Fehlermeldung, unabhängig davon, ob er den Kontonamen oder das Kennwort falsch geraten hat.

Daraus folgt, dass eines der Hauptargumente für das Umbenennen des Administratorkontos – dass die Skriptkiddies ferngehalten werden – fehlerhaft ist. Es spielt keine Rolle, ob das Administratorkonto umbenannt wurde oder ob es noch den ursprünglichen Namen trägt, weil der Unterschied nicht festgestellt werden kann! Die Skriptkiddies verwenden in beiden Fällen den gleichen Satz zufälliger Kennwörter und wenden sich dann dem nächsten potenziellen Opfer zu.

Ein Umbenennen des Kontos bietet also keinen zusätzlichen Nutzen, solange das Kennwort des Administratorkontos stark genug ist, um Angriffe abzuwehren. Angenommen das Administratorkonto hätte ein aus 15 Zeichen bestehendes Kennwort, das sich aus Groß- und Kleinbuchstaben, Ziffern und Symbolen der Tastatur zusammensetzt. Das Erraten dieses Kennworts über das Netzwerk würde ungefähr 591.310.404.907 Jahre dauern. Das ist ungefähr 43 Mal länger als das Universum alt ist.

Weiterhin wird angenommen, dass das Administratorkonto umbenannt und ihm einer von 1.000 möglichen Namen zugewiesen wird. Die Zeit, die für das Erraten des Kennworts erforderlich ist, würde damit auf 591.310.404.906.787 Jahre verlängert. Das ist 43.161 Mal so lange wie das Universum bereits existiert. Bietet dies erhöhte Sicherheit? Ja, die Sicherheit erhöht sich um drei Zehnerpotenzen. Wird es dadurch weniger wahrscheinlich, dass ein Angreifer das Kennwort errät? Die Wahrscheinlichkeit ist beiden Fällen unendlich klein. Praktisch gesehen stehen Sie nicht besser da als mit dem ursprünglichen Administratorkontonamen. Nur weil durch das Umbenennen des Kontos Malware abgewehrt wird, die versucht, dieses Konto zu verwenden, bedeutet das nicht, dass diese Malware erfolgreich gewesen wäre, hätten Sie das Konto nicht umbenannt. Wenn Sie ein starkes Kennwort verwenden, wie es empfohlen wird, können Sie praktisch garantieren, dass ein Malwareangriff keinen Erfolg hat, unabhängig vom Namen des Kontos.

In vielen Sicherheitsleitfäden wird ein Umbenennen des Administratorkontos gefordert, aber das macht es nicht zu einer nützlichen oder berechtigten Sicherheitsmaßnahme. Es nimmt Ihnen einfach die Möglichkeit, eine fundierte Entscheidung für das Risikomanagement zu treffen. Sicherheitshandbücher fordern oft Einstellungen, die keinen Unterschied machen, und in vielen Fällen sogar Einstellungen, die gar nicht existieren. Um Verbesserungen im Bereich Sicherheit zu erzielen, müssen Sie diese Forderungen überdenken, die Probleme analysieren sowie einschätzen, ob die Schutzmaßnahmen wirklich sinnvoll sind. An dieser Stelle sollten Sie sich einen wichtigen Punkt in Erinnerung rufen – die Tatsache, dass ein Angreifer auf ein Feature abzielt, ist für sich allein kein ausreichender Grund, das Feature zu ändern. Sie sollten ein Feature nur ändern, wenn Sie berechtigterweise erwarten können, dass ohne Änderung des Features ein erfolgreicher Angriff durchgeführt werden kann.

Unter Verwendung eines starken Kennworts ist die Erfolgswahrscheinlichkeit praktisch null, unabhängig davon, ob das Konto umbenannt wurde oder nicht. Solange Sie also ein starkes Kennwort verwenden, haben Sie keinen Grund, das Konto umzubenennen. Wenn Sie außerdem wie ich nach dem Prinzip vorgehen, dass ein Computer wahrscheinlich umso stabiler ist, je weniger Feinabstimmungen und Änderungen vorgenommen werden (was eine wohlbelegte Tatsache ist), ist das ein weiterer Grund, das Administratorkonto nicht umzubenennen.

Verschieben des Schwerpunkts auf Schutzmaßnahmen mit geringem Nutzen Ein Problem bei geringwertigen Schutzmaßnahmen durch Verschleierung besteht darin, dass sich der Schwerpunkt der Sicherheitsstrategie von Organisationen dadurch möglicherweise so verlagert, dass höherwertige Schutzmaßnahmen vernachlässigt werden. Der Zeit und die Arbeit, die in das Umbenennen des Administratorkontos investiert wird, kann nicht für andere Aufgaben verwendet werden. Wenn diese anderen Aufgaben einen höheren Nutzen bieten als das Umbenennen der Administratorkonten, hat die Organisation eine Gelegenheit verschenkt. Dies mag nicht nach wirklichen Kosten klingen, aber stellen Sie sich einmal vor, es müssten 50.000 Administratorkonten umbenannt werden.

Noch schlimmer ist die sehr reale Möglichkeit, dass die Organisationsleitung ihre Bemühungen ruhen lässt, sobald die Schutzmaßnahmen mit geringem Nutzen implementiert sind. Die Verantwortlichen für das Management verstehen möglicherweise nicht immer den geringen Wert, den Schutzmaßnahmen nach dem Prinzip Sicherheit durch Verschleierung bieten, und unterlassen es, zusätzliche Maßnahmen zu ergreifen. Dies stellt für eine Organisation möglicherweise ein erhebliches Risiko dar. Dieses Risiko lässt sich aber durch Einsatz von etwas Zeit und Arbeit von Seiten des Managements, um den Nutzen der Schutzmaßnahmen zu verstehen, relativ leicht vermeiden.

Teure Verwaltung Abhängig davon, wie gut die Schutzmaßnahmen implementiert werden, kann ihre Verwaltung ziemlich teuer sein. Wenn Sie einfach ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) für das Umbenennen des Administratorkontos einrichten, sind die Kosten sehr gering. Jeder kennt den Namen, und die Kosten der Bereitstellung sind nahezu null. Der Nutzen ist allerdings ebenfalls ziemlich gering, weil, wie gesagt, jeder Benutzer mit einem Konto den Namen kennt. Um also wirklich großen Nutzen aus diesen Schutzmaßnahmen zu ziehen, müssen Sie verschiedene Namen auf verschiedenen Hosts verwenden, und das macht die Verwaltung des Systems ziemlich teuer.

Erheblich besser wäre es, wenn Sie mithilfe eines Tools wie „passgen“ (protectyourwindowsnetwork.com/tools.htm) auf allen Administratorkonten im Netzwerk ein vollkommen zufälliges Kennwort aus 100 Zeichen einrichten und verschiedene Konten für alltägliche Verwaltungsaufgaben verwenden. In Anbetracht der Tatsache, dass das Administratorkonto allein für die Notfallwiederherstellung gedacht ist (außer unter Windows Small Business Server 2003), dürfte dies keinerlei Einfluss auf Ihr Netzwerkverwaltungssystem haben. Außerdem hätte der Angreifer bessere Chancen, eine Nadel auf dem Grund des pazifischen Ozeans zu finden, als das Kennwort eines Ihrer Administratorkonten zu erraten. Bei Verwendung starker, eindeutiger Kennwörter können die Skriptkiddies raten, solange sie wollen.

Alles dreht sich um das Risikomanagement

Praktisch jede Maßnahme nach dem Prinzip Sicherheit durch Verschleierung kann so analysiert werden, wie es hier erfolgt ist. Es gibt Argumente für und gegen jedes Schema, und der richtige Ansatz für eine Organisation ist nicht unbedingt auch für eine andere Organisation geeignet. Letzen Endes handelt es sich um ein Risikomanagementproblem. Überwiegen die Risiken die Implementierungskosten für die Lösung? Jede Entscheidung, die Sie beim Schutz Ihrer Informationsressourcen treffen, muss eine informierte Risikomanagemententscheidung sein, und es ist selten eine Frage von Schwarz oder Weiß.

Einige Entscheidungen wurden zwar bereits für Sie getroffen. Sie können sich z. B. dafür entscheiden, Kreditkarteninformationen nicht zu verschlüsseln oder die Überprüfungscodes von Kreditkarten nicht zu speichern, allerdings nehmen Ihnen beide Maßnahmen wahrscheinlich die Möglichkeit, Kreditkarten als Zahlungsmethode zu akzeptieren. Die negativen Auswirkungen dieser Entscheidung auf Ihr Geschäft lassen Ihnen hierbei wahrscheinlich keine Wahl. Dies ist also sicherlich eine Risikomanagemententscheidung, die sich ziemlich leicht treffen lässt.

Ebenso stimmt es auch, dass niemand, der noch bei Trost ist, ein offenes Drahtlosnetzwerk mit dem Back-End des speicherinternen Netzwerks in einem physischen Speicher verbinden würde. Das bedeutet aber nicht, dass die Entscheidung keine Risikomanagemententscheidung ist. Sie ist es. Wenn eine solche Entscheidung getroffen wird, müssen eben die Konsequenzen getragen werden (was leider nie der Fall zu sein scheint).

Der wichtigste Schritt besteht hierbei darin, das vorliegende Problem, die vorgeschlagenen Problemlösungen sowie die Argumente für und gegen jede Lösung eingehend zu untersuchen. Nur so erhalten Sie die Informationen, die für eine informierte Risikomanagemententscheidung erforderlich sind. Andernfalls treffen Sie Entscheidungen einzig und allein auf der Grundlage von Vermutungen, und das sind selten gute Entscheidungen.

Jesper M. Johansson ist Softwarearchitekt mit dem Schwerpunkt Sicherheitssoftware und schreibt redaktionelle Beiträge für das TechNet Magazin. Er hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist Microsoft MVP im Bereich Unternehmenssicherheit. Sein aktuelles Buch heißt Windows Server 2008 Security Resource Kit.

Roger Grimes (CPA, CISSP, MCSE: Sicherheit), leitender Sicherheitsberater für das Microsoft-ACE-Team, hat acht Bücher über Computersicherheit geschrieben oder mitverfasst und mehr als 200 Artikel veröffentlicht. Er hält oft Vorträge auf Sicherheitskonferenzen und schreibt für InfoWorld Beiträge zum Thema Sicherheit.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.