Glengamoi (Forum) · AspHeute · .NET Heute (RSS-Suche) · AspxFiles (Wiki) · .NET Blogs
ASP German Homepage Homepage
 

Liste

.NET 2.0 (1)
.NET Allgemein (16)
.NET Fu (5)
ADO.NET (11)
Aprilscherz (3)
ASP Grundlagen (44)
ASP Tricks (83)
ASP.NET (44)
ASPIntranet.de (5)
C# (28)
Datenbank (44)
Dokumentation (4)
IIS 6.0 (1)
Komponenten (29)
Optimierung (10)
Server (21)
Sicherheit (34)
Tee Off (6)
VB.NET (6)
WAP (8)
Web Services (11)
XML (9)

RSS 2.0 - Die neuesten fünf Artikel auf AspHeute.com


 

Suchen





 

English Articles
Chinese Articles
Unsere Autoren
 
Link zu AspHeute
Impressum
Werben
Anfragen

Schritt-für-Schritt Debuggen von Sicherheitsproblemen

Geschrieben von: Christoph Wille
Kategorie: Sicherheit

Eines der lästigsten Probleme beim Entwicklen und Administrieren von Web Sites ist das Troubleshooten von Sicherheitsproblemen. Die absolute #1 ist hierbei Access Denied - Zugriff verweigert. Effizient herauszufinden warum man einen solchen Fehler erhält ist Ziel des heutigen Artikels. Und wenn man den Grund kennt, ist die Lösung auch nicht mehr weit.

Wodurch ensteht ein Access Denied Fehler

Was sind die Gründe für Access Denied bei der Verwendung von ASP und IIS? Nun, grundsätzlich kommt Sicherheit bei beiden von Windows NT / 2000. Dieses bietet die Benutzerverwaltung, sowie verschiedenste Sicherheitsmechanismen. Für unsere Betrachtung sind Privilegien und ACL's (Access Control Lists), die auf Dateien (bekannt als NTFS Zugriffsberechtigungen) oder in der Registrierdatenbank gesetzt sein können, von Interesse.

NTFS Zugriffsberechtigungen (ACL's) sind jedem bekannt, der schon einmal mit Windows Explorer sich den Security Tab einer Datei angesehen hat:

Hier ist die unsicherste Variante zu sehen - Vollzugriff (Full Control) für Jeder (Everyone). Das sollte durch entsprechende Berechtigungen ersetzt sein, nur können eben restriktive Berechtigungen - auf ASP Dateien oder Komponenten und deren abhängigen Dateien - unter Umständen zu Access Denied Fehlern führen.

Das Konzept der NTFS Zugriffsberechtigungen erschließt sich relativ leicht für den Programmierer, etwas ungewohnter sind die Privilegien (User Rights), mit denen überlicherweise nur der Netzwerkadministrator zu tun bekommt. Hier ein Screenshot der Local Security Settings:

Hier sind sehr viele Rechte "vergraben", die Kopfweh bereiten können, so zB die verschiedenen Varianten von Log on as..., die man als User für das Logon an lokale FTP Server brauchen kann. In den meisten aller Fälle denkt man als Programmierer gar nicht daran, daß man unter Umständen an einem fehlenden Recht scheitert.

Stolperstein Diese Security Settings sind doppelt gefährlich, da diese in sogenannten Policies verwendet werden. Und diese Policies können an folgenden Orten vergeben werden: Local (lokaler Computer), Site (Active Directory), Domain (Active Directory) und Organizational Unit (Active Directory). Das Problem ist, daß Policies in dieser Reihenfolge angewandt werden, und die letzte Einstellung "greift". Das heißt, daß unter Umständen die lokale Einstellung zwar korrekt ist, aber von einer nicht passenden Group Policy "überstimmt" wird.

Debuggen des Access Denied Fehlers

Raten woher der Fehler kommt ist immer die schlechteste Idee, auch wenn es hin und wieder zum Ziel führt. Vorzuziehen ist eine Checkliste, anhand derer man vorgeht. Erstens vergisst man nichts, zweitens verändert man nichts durch "herumprobieren".

Folgende Schritte sollten ausgeführt werden, damit man in grob einer Stunde (spätestens) den Fehler gefunden hat:

  1. Auditing von Privilegienverwendung (fehlgeschlagener) einschalten & kontrollieren
  2. ACL Problem am Dateisystem
  3. ACL Problem in der Registry

Findet man den Fehler in einem der oberen Schritte, sind die nachfolgenden natürlich nicht mehr durchzuführen.

Auditing von Privilegienverwendung

Am schnellsten herauszufinden ist ob ein fehlendes Privileg (User Right) den Fehler verursacht hat. Dazu muß man zuerst das Auditing für Privilegien einschalten. Dies geschieht über Local Security Settings, oder über Group Policies (Active Directory).

Achtung Es gelten die genau gleichen Probleme wie für die Zuweisung von Privilegien - wer zuletzt kommt gewinnt.

Um nun herauszufinden, ob ein fehlendes Privileg schuld an unserem Access Denied Fehler war, muß man nur im Security Log des Event Logs nachsehen. Dort steht dann, welches Privileg gefehlt hat. Bevor man an den Privilegien herumdreht, sollte man allerdings den Netzwerkadministrator zu Rate ziehen, welche Nebenwirkungen eine solche Umstellung haben könnte!

ACL Problem am Dateisystem

Bei einem ACL Problem auf einer Datei wird die Suche schon ein wenig interessanter - einerseits könnte man es mit Auditing erledigen, nur allerdings ist das ziemlich aufwendig. Ein schnellerer Weg zum Ziel ist FileMon von SysInternals.

Das Tool startet das Mitloggen sofort nach dem Start (Achtung: man benötigt Administratorenrechte um dieses Tool ausführen zu können):

Das Mitloggen kann mittels Ctrl+E gestoppt werden. Ob etwas schiefgegangen ist, kann man mittels der Result Spalte ermitteln, einfacher ist es jedoch, das Log als Textdatei zu speichern, und in Notepad ganz einfach nach "Access Denied" zu suchen.

Wie kuriert man ein Access Denied auf einer Datei? Nun, hierzu lockert man die NTFS Berechtigungen solange, bis der Access Denied Fehler nicht mehr auftritt. Die Radikalkur des Vollzugriffs für Jeder ist sicherlich keine Lösung!

ACL Problem in der Registry

Auch wenn es viele Leute nicht wissen, auch die Registrierungsdatenbank ist mit ACL's abgesichert. Man sieht dies mit regedit.exe nicht, diese ACL's werden erst mit regedt32.exe sichtbar:

Um einem Registry-ACL-Fehler auf die Schliche zu kommen hilft nur eines - RegMon von Sysinternals. Auch dieses Tool ist wie FileMon gratis, und man kann sogar den Sourcecode downloaden.

Die Verwendung ist ident zu Filemon - zuerst mitloggen, dann nach "Access Denied" suchen. Am wahrscheinlichsten findet sich das Problem für Access Denied im Zweig HKEY_LOCAL_MACHINE.

Schlußbemerkung

Es gibt drei Gründe für Access Denied Fehler: fehlende Privilegien, ACL's auf Dateien und ACL's auf Registrierungsschlüsseln. Mit der richtigen Strategie zur Fehlersuche erspart man sich Zeit und kann den Fehler gezielt einkreisen und eliminieren.

Verwandte Artikel

Dateizugriff auf Netzlaufwerken
Impersonation mit ASP.NET
Komponentenverwendung einschränken
NT Account Management via ASP
Schluß mit lustig - das IIS Lockdown Tool
Schluß mit lustig Teil 2 - das URLScan Tool
Schluß mit lustig Teil 3 - das Hfnetchk Tool
Verzeichnissicherheit mit NTFS und IIS Authentifizierung

Links zu anderen Sites

FileMon
RegMon

Wenn Sie jetzt Fragen haben...

Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.

Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.

 

Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.

Bewerten Sie diesen Artikel
 Sehr gut   Nicht genügend  
   1  2  3  4  5  
 

  
   Für Ausdruck optimierte Seite

©2000-2006 AspHeute.com
Alle Rechte vorbehalten. Der Inhalt dieser Seiten ist urheberrechtlich geschützt.
Eine Übernahme von Texten (auch nur auszugsweise) oder Graphiken bedarf unserer schriftlichen Zustimmung.