presentation
Werbung
Sicherheit oder Praxis? Michael Willers http://staff.newtelligence.net/michaelw/ 1 In diesem Abschnitt… • • • • • Stand der Dinge ACL vs. Privileg Secure Deployment SQL Server Security Debuggen mit Visual Studio .NET 2 Stand der Dinge • Die meisten Anwendungen laufen mit Administratorrechten – Eine offene Einladung für Angreifer • Nur: Anwender haben keine Wahl – Installation setzt meistens Administatorrechte voraus – Anwendungen laufen nicht ohne Administratorrechte – Oder schlimmer: Wichtige Funktionen gehen nicht • OS bietet keine Hilfestellung – Beispielsweise per Wizard 3 Ohne Admin geht‘s auch... • Erstellen Sie einen eigenen Account, der lediglich der Gruppe Users angehört • Legen Sie Verknüpfungen für administrative Tasks auf dem Desktop an – runas.exe – Rechtsklick auf die Anwendung fragt automatisch • Für das Development mit Visual Studio. NET brauchen Sie zusätzliche Einstellungen – Dazu später mehr • Ein Wizard wäre schön... 4 ...aber eben nicht immer ;-) • Möglicherweise schreibt die Anwendung in die Registry – HKEY_LOCAL_MACHINE anstelle von HKEY_CURRENT_USER • Möglicherweise schreibt die Anwendung „wild“ ins Dateisystem – Windows- oder Systemverzeichnis (System32) – Programmverzeichnis – Oder der GAU: Ins Root • Interop-Szenarien mit COM-Komponenten – Zugriff auf HKEY_CLASSES_ROOT notwendig 5 Wo gehört was in die Registry? • In .NET eigentlich nichts mehr ;-) • Bei vorhandenen Anwendungen Code so ändern das er grundsätzlich nur auf HKEY_CURRENT_USER schreibt! 6 Wo gehört was ins Dateisystem? • .config Dateien sind – Anwendungsbezogen und by Design Read-Only – Werden vom Hersteller mitgeliefert • Benutzerbezogene Daten zur Anwendung (Fenstereinstellungen, Fonts, etc) – Environment.SpecialFolders.ApplicationData • Allgemeine benutzerbezogene Daten gehören in – My Documents – Environment.SpecialFolders.Personal • Weitere Hinweise in der MSDN Dokumentation – Environment.SpecialFolders 7 Und was nun? • Rausfinden was da los ist – Wer schreibt wann mit welchen Rechten wohin? – Regmon, Filemon, Process Explorer und Konsorten • Eigener Code – Fix this! • Fremde Anwendungen – ggf. Installer bauen, der Rechte gezielt freischaltet – Testen und dann per Group Policy verteilen – Natürlich das alte Problem: Sicherheit ist unbequem • Wenn die Rechte da sind aber trotzdem nix geht fehlt vielleicht ein Privileg 8 ACL vs. Privileg • Eine Access Control List (ACL) erlaubt oder verbietet den Zugriff auf eine Ressource – Datei, Registy, ... • Ein Privileg erlaubt oder verweigert die Durchführung einer Aufgabe – Backup, Debugging, ... 9 Wie finde ich gute ACLs? • Wie sieht der Use Case aus? • Ein Beispiel: – Alle User müssen Daten lesen können • Interactive Users = Read – Administratoren müssen in der Lage sein sämtliche Aktionen auf den Daten ausführen zu können • Administrators = Full Control – Die Marketing-Abteilung darf keinen Zugriff auf die Daten haben • ggf. Benutzergruppe Marketing anlegen • Marketing = Deny All Access 10 Wie finde ich gute ACLs? • Achtung: Manchmal sind Privilegien die bessere Lösung • Beispiel: – Ein einzelner User muss immer Zugriff auf sämtliche Dateien haben – SeBackupPrivilege • Lesezugriff auf sämtliche Dateien – SeRestorePrivilege • Schreibzugriff auf sämtliche Dateien 11 Security Identifier (SID) • identifiziert Benutzer oder Gruppe • eindeutig in Raum und Zeit (vgl. GUID) • variable Länge relative Identifier Aufbau: S-1-5-21-....-....-....-.... Revison NT-Trustee maschinenspezifischer Wert eindeutig innerhalb Maschine 21 für nicht vordefinierte Trustees 12 ACLs und ACEs Die Access-Control List ist ein Container für Access-Control Entries (ACEs) ACL 1 n ACE ACCESS_MASK SID ACCESS_ALLOWED ACCESS_DENIED 13 ACL, Attributes, Descriptor wird zugeordnet Security Attributes Ressource Security Descriptor Access Control List 17 Prüfen von ACLs 18 Kein „Happy Coding“ • Ohne .NET entweder mit C++ – Win32-API – ab VC 7.1 einfacher über ATL-Klassen • Oder per WMI – Allerdings kein Hinzufügen von Privilegen, die ein Benutzer nicht hat • Mit .NET – Version 1.1 keine Unterstützung – Version 2.0 hat eingebaute Unterstützung, zumindest für ACLs • Nur: Viele Klassen, viele Methoden aber kein lösungsgetriebener Ansatz 20 ACLs und Privilegien 21 SQL Server – Standardsetup • Standardmäßig läuft der SQL Server mit dem lokalen Systemaccount – Eigenen Account anlegen – Gastaccount ist oft ausreichend • Standardmäßig sind alle lokalen Administratoren in der Serverrolle sysadmin eingetragen – Lokale Benutzerguppe anlegen und hinzufügen – Lokale Administratoren entfernen • Ein Wizard wäre schön... 24 SQL Server – Authentication Login Request Integrated Security: SSPI ansonsten : Lookup in master.sysxlogin Kontextwechsel zur Datenbank Zugriffe auf Datenbankobjekte (Tabellen, Stored Procedures,..) Authorization innerhalb der Datenbank 25 SQL Server – Hinweise • SQL-Server sollte grundsätzlich nur mit „Integrated Security“ arbeiten – sa nur als Notanker mit „strong password“ • Beim Erstellen einer Datenbank sollten grundsätzlich Berechtigungen eingerichtet werden • Serverseitiges Installationsprogramm wäre schön... 31 SQL Server – DB per MSI aufsetzen 32 VS.NET ohne Adminrechte • Setup legt eigene Gruppen an – Debugger Users • Nur Mitglieder dieser Gruppe können mit Visual Studio .NET debuggen • KEINE Zuordnung von OS-Privilegien! • Hängt mit dem Machine Debug Manager zusammen – VS Developers • User haben Lese- und Schreibzugriff im Root des lokalen IIS-Webserver und können dort WebAnwendungen anlegen • Ein Wizard wäre schön... 33 Non-Admin Debugging • Benutzer können Prozesse, die Ihnen gehören ohne Einschränkung entwanzen • Um fremde Prozesse zu debuggen, wird das OS-Privileg SeDebugPrivilege benötigt 34 Non-Admin Debugging • Problem: Unter .NET kann ein Benutzer nur die Prozesse debuggen, die Ihm gehören. – ASP.NET – Windows Services – Enterprise Services • Gilt selbst dann, wenn der Benutzer das OS-Privileg SeDebugPrivilege besitzt! • Ausnahme: Admin-Account • Ein generelles CLR-Problem, das so nicht umgangen werden kann 35 Non-Admin Debugging 37 Zusammenfassung • Standardmäßig keine Administratorrechte für Anwendungen – LUA – Limited User Account • Least privileged user access – Annahme „full trust“ vermeiden wo immer es geht • Sorgen Sie für „saubere“ Installer – Install, Uninstall, Commit und Rollback implementieren 38 Danke für Ihre Aufmerksamkeit http://staff.newtelligence.net/michaelw 40
