Hardening Checkliste. Microsoft SQL Server 2000. 6. Januar 2004

Hardening Checkliste Microsoft SQL Server 2000 6. Januar 2004 Name des Dokument: Checkliste_Win2K3_SQL2000_V1.1.doc Version: V 1.1 Autor: Adrian Leuenberger, Compass Security AG Erstellungsdatum: 5. September 2003 Anpassungsdatum: 6. Januar 2004 Lizenznehmer: [Name des Kunden]

Inhaltsverzeichnis 1 ÜBERSICHT...1 1.1 Audienz 1 1.2 Dokumentstruktur 1 1.3 Weitere Checklisten 1 1.4 Versionskontrolle 2 2 EINFÜHRUNG...3 2.1 Disclaimer 3 2.2 Lokale-, Netzwerk- und Applikationssicherheit 1 2.3 Hardening (Get Secure) 1 2.3.1 Vorgehen 2 2.3.2 Top Schwachstellen bei Windows Systemen 1 3 PLANUNG...2 3.1 Hinweise zur Topologie 2 3.2 Berechtigungen 2 3.3 Applikatorische Aspekte 2 3.4 OU-Plan 4 3.5 Priorität der Group Policy 6 3.6 Security Management (Stay Secure) 6 3.7 Hinweise zu den Skripten 8 4 HARDENING SQL 2000...9 4.1 System Services 10 4.2 User / Gruppen 12 4.3 Installation SQL 2000 15 4.4 Patches und Updates 17 4.5 Default Settings 18 4.6 Audit / Logging 26 4.6.1 Normales Auditing 26 4.6.2 C2 Auditing 28 4.6.3 SQL Server-Side Traces 29 4.7 Installation Client Tools 30 5 ANHANG...31 5.1 Security Templates 31 5.1.1 Default Templates 31 5.1.2 Import von Security Templates (Standard) 31 5.1.3 Group Policy Management Console (GPMC) 32 5.2 Relevante Servicepacks und Hotfixes 35 5.3 Links 35 Datum: 6. Jan. 2004

1 Übersicht 1.1 Audienz Diese Checkliste richtet sich an technische Sachverständige. Grundwissen im Bereich von Windows 2003 und SQL 2000 wird vorausgesetzt. 1.2 Dokumentstruktur Kapitel Inhalt 1 Übersicht über dieses Dokument. 2 Einführung in das Vorgehen beim Hardening 3 Vorschläge zur Planung 4 Hardening-Massnahmen für SQL Server 2000 5ff Anhang 1.3 Weitere Checklisten Compass Security bietet nebst dieser Hardeninganleitung folgende verwandte Listen an. Alle diese Listen sind für Intranet-Systeme optimiert. Wenden Sie sich bei Interesse an info@csnc.ch. Hardeninganleitung Windows 2003 Intranet Basis Exchange 2003 SQL 2003 Internet Information Server 6.0 for Intranet Windows XP Professional Beschreibung Hardeningempfehlungen für Memberserver, Domaincontroller sowie ADS. Hardeningempfehlungen für Exchange 2003 Server. Vorausgesetzt wird das Hardening des Betriebsystems (siehe Intranet Basis Liste) Hardeningempfehlungen für SQL 2003 Server. Vorausgesetzt wird das Hardening des Betriebsystems (siehe Intranet Basis Liste) Hardeningempfehlungen für IIS 6.0 Server. Vorausgesetzt wird das Hardening des Betriebsystems (siehe Intranet Basis Liste) Hardeningempfehlungen für domänenzugehörige Workstations mit Windows XP Proffessional Seite: 1 Datum: 6. Jan. 2004

1.4 Versionskontrolle Version Datum Änderungen Autor 1.0 05.09.2003 Erste Version Adrian Leuenberger 1.1 06.01.2004 Hinzufügen von zusätzlich Kapiteln & Lizenznehmber in Kopfzeile Jan P. Monsch Seite: 2 Datum: 6. Jan. 2004

2 Einführung Dieses Dokument beschreibt das Hardening eines SQL 2000 Servers, der auf einem gemäss unserem Dokument Hardening Checkliste Windows 2003 Intranet Basis aufgesetzten Windows 2003 Member-Server im Intranet aufgesetzt ist. Die in diesem Dokument beschriebenen Massnahmen sind für Systeme, die im Internet exponiert sind, ungenügend! Die Liste sollte lediglich für Systeme im Intranet verwendet werden. Es wird lediglich auf eine Neuinstallation eingegangen. Upgrades von bestehenden Windows 2000 Servern werden nicht beschrieben und sollten auch nicht gemacht werden, um Altlasten zu eliminieren statt diese mitzuschleppen. 2.1 Disclaimer Im folgenden ein Auszug aus den Vertragsvereinbarungen zwischen dem Kunden und Compass bezüglich Gewährleistung und Haftung: Compass gewährleistet, dass der Vertragsgegenstand sämtlichen Compass zum Zeitpunkt des Vertragsschlusses bekannten technischen Standards entspricht. Compass übernimmt jedoch keinerlei Gewähr dafür, dass der Vertragsgegenstand fehlerfrei ist; dass durch den Einsatz des Vertragsgegenstandes sämtliche Angriffsmöglichkeiten in das System des Kunden ausgeschlossen werden; dass das System des Kunden nach dem Einsatz des Vertragsgegenstandes in jedem Falle einwand-frei funktioniert. Compass lehnt sodann jede Gewährleistung ab, falls der Kunde den Vertragsgegenstand entgegen ausdrücklichen Anweisungen von Compass eingesetzt hat. Compass lehnt jede Haftung für direkte oder indirekte Schäden, die beim Einsatz des Vertragsgegenstandes entstanden sind, ab. Vorbehalten bleiben Fälle, bei de-nen Compass Absicht oder Grobfahrlässigkeit nachgewiesen werden kann. Seite: 3 Datum: 6. Jan. 2004

2.2 Lokale-, Netzwerk- und Applikationssicherheit Um ein Netzwerk sicher zu konfigurieren müssen folgende Stufen betrachtet werden. Diese Stufen beschreiben die verschiedenen Problembereiche, welche von Hackern angegriffen werden. Stufe Definition Gegenmassnahmen Lokale Sicherheit Netzwerk Sicherheit Applikationssicherheit Überwachung Der Angreifer hat bereits Zugriff auf das System. Nun versucht er seine Privilegien zu erweitern. (Lokale Exploits) Der Angreifer hat noch keinen Zugriff auf dem Opfersystem. Nachdem scannen versucht er Schwachstellen auszunutzen um Zugriff zu erlangen. (Remote Exploits) Der Angreifer sucht den Zugriff auf eine E-Business Applikation. Findet er diesen versucht er die Daten eines anderen Benutzers einzusehen. Analyse (automatische wie auch manuelle) der Logfiles und des Netzwerkverkehrs. Hardening Patchen Hardening Firewall Sicherheitsbewusste Entwicklung von Webapplikationen Loganalyse Tools Intrusion Detection Systeme Seite: 1 Datum: 6. Jan. 2004

2.3 Hardening (Get Secure) Standardinstallationen bergen eine Unmenge von sicherheitstechnischen Problemen. Die Ursachen dazu sind: Rückwärts Kompatibilität Funktionalität Hinzu kommen weitere Sicherheitslücken, die von Administratoren und Benutzern während dem Betrieb geschaffen werden: Schlechte Rechtevergabe Schwache Passwörter Sicherheitstechnisch schwache Konfigurationen Veralteter Patchlevel usw. Man sieht eine Unmenge von Bereichen die von Hackern ausgenutzt werden können. Brisant ist, dass auch ein Nichts tun Probleme verursachen kann (z.b. Installation des neusten Servicepacks). Um ein neu installiertes System auf einen sicheren Stand zu bringen, wird es einem Hardening unterzogen. Beim Hardening werden unter anderem die oben genannten Punkte angegangen. Dabei erscheinen die einzelnen Schritte als unnötig. Die Güte von Sicherheit kann mittels Anreihung von Hürden definiert werden. Jede noch so kleine Hürde ist eine weitere Massnahme, die den Weg eines Angreifers erschwert resp. versperrt. Seite: 1 Datum: 6. Jan. 2004

2.3.1 Vorgehen Weil beim Hardening oftmals die Funktionalität gegen Sicherheit ersetzt wird, können vielseitige und komplexe Probleme auftreten. Wenn nicht genau verstanden wird, was welche Einstellung bezweckt und blind einer Checkliste gefolgt wird, könnten Applikationen den Dienst quittieren. Deshalb ist es wichtig das Hardening auf das entsprechende Unternehmungsnetzwerk anzupassen. Obwohl die vordefinierten Sicherheitsvorlagen (.inf-dateien) und weiteren Skripte zu einem zügigen Vorgehen einladen, wird dringend empfohlen, die in dieser Checkliste aufgeführten Punkte durchzugehen und zu hinterfragen. Folgende Punkte sollten bei einem Hardening beachtet werden: Adaption von Empfehlungen auf das eigenen Unternehmensnetzwerk Strukturiertes Vorgehen in Teilschritten Vorgängiges Überprüfen (Testumgebung) Dokumentation von geprüften Konfigurationen (Sicherstellen der Wiederverwendbarkeit) Hilfestellungen bei Problemen: Einkreisung des Problems Was könnte dieses Problem verursachen (Vergleich mit der Checkliste) Strukturierte Suche und Unhardening in Teilschritten (Achtung: Keine zusätzliche Sicherheitsprobleme schaffen wie z.b. Zuordnung von Administrator-Rechten oder Everyone-Zugriffen) Eventlogs und Fehlermeldungen auswerten und in der Technet Knowledgebase nach Lösungen suchen Seite: 2 Datum: 6. Jan. 2004

2.3.2 Top Schwachstellen bei Windows Systemen Die grosse Mehrheit von erfolgreichen Attacken nützt eine kleine Anzahl von Schwachstellen aus. Es wird immer der Weg des geringsten Widerstandes gesucht. Oftmals existieren für solche Schwachstellen einfache Tools, die von jedem Hobby-Hacker angewendet werden können. Werden auf dieser Basis Würmer gebaut resultieren daraus fatale Folgen. SANS hat in Zusammenarbeit mit dem FBI eine Liste zusammengestellt, in welcher auf die grössten und meist ausgenutzten Schwachstellen für Unix und Windows hingewiesen wird. Untenstehend sind die entsprechenden Punkte für Windows Systeme abgedruckt. http://www.sans.org/top20/ # Schwachstelle Gegenmassnahmen 1 Internet Information Services (IIS) Hardening Regelmässiges Patchen 2 Microsoft SQL Server (MSSQL) Hardening Regelmässiges Patchen 3 Windows Authentication Hardening 4 Internet Explorer (IE) Hardening Regelmässiges Patchen Proxy mit Content Filter und Virenscanner 5 Windows Remote Access Services Hardening 6 Microsoft Data Access Components (MDAC) -- Remote Data Services Patchen oder Deinstallation 7 Windows Scripting Host (WSH) Content Filtering (Blocken von Scripts und Executables auf dem Mail-GW) 8 Microsoft Outlook and Outlook Express Deinstallation von Outlook Express. Hardening von Outlook. 9 Windows Peer to Peer File Sharing (P2P) Interne Richtlinien sollten den Gebrauch solcher Software verbieten. Firewall sollte die benutzen Protokolle blocken. 10 Simple Network Management Protocol (SNMP) Hardening Seite: 1 Datum: 6. Jan. 2004

3 Planung 3.1 Hinweise zur Topologie SQL Server sollten wenn möglich nicht direkt im Intranet plaziert werden, sondern durch eine Firewall davon abgetrennt werden. Damit kann einfach verhindert werden, dass er durch jeden erreicht werden kann. Er muss dann nur noch für den häufig vorhandenen vorgeschalteten Applikations-Server und die Administratoren erreichbar sein. Ein weiterer Punkt, der beachtet werden sollte ist, dass Applikations-Server, IIS-Server und SQL- Server nicht auf dem selben Server laufen sollen. Dies erleichtert die Wartbarkeit und verbessert die Verfügbarkeit. Wenn es die Daten verlangen, sollte eine Verschlüsselung des Netzwerkverkehrs per SSL oder IPSec in Betracht gezogen werden, um die Daten bei der Übertragung vor Belauschen zu schützen. 3.2 Berechtigungen Auf Berechtigungen auf Freigabeebene wird hier nicht genauer eingegangen. A folgende goldene Regel der Sicherheit soll hier aber aufmerksam gemacht werden. Least Privilege Prinzip - Nur so viel wie tatsächlich nötig So kann nicht nur Datenklau und unberechtigter Dateneinsicht verhindert werden, sondern auch der Wirkungskreis von Viren eingegrenzt werden. Z.b. Iloveyou (Loveletter virus) überschrieb viele Dateien auch auf gemappten Laufwerken. 3.3 Applikatorische Aspekte Die Sicherheit des SQL Servers selbst ist wichtig. Allerdings liegt ein sehr grosser Teil der Gesamtsicherheit in der Hand der Applikations-Programmierer, die mit Ihren Applikationen auf den SQL Server zugreifen. Aus diesem Grunde wird an dieser Stelle auf einige wichtige Punkte hingewiesen, die diejenigen, die auf den SQL-Server zugreifen, zu beachten haben. Die Business-Logik sollte, wo immer möglich, als Stored Procedures implementiert werden. Die Applikation, die auf den Datenbankserver zugreift braucht dann nur Berechtigungen auf diejenigen Stored Procedures, die von Aussen erreichbar sein müssen, sowie auf definierte Views und Funktionen. Dies hat folgende Vorteile: Einerseits ist die Performance besser, als wenn einzelne Abfragen durchgeführt werden. Andererseits kann ein potentieller Angreifer nur über wohl definierte Schnittstellen auf den SQL Server zugreifen. Dies erschwert einen erfolgreichen Angriff ungemein. ALLE Usereingaben MÜSSEN auf Ihre Gültigkeit geprüft werden. Absolut NIE dürfen Eingaben von Benutzern ohne Check übernommen werden. Dies gilt für SQL-Server insbesondere für die Zeichen/Kombinationen: < ' " - > (ohne die eckigen Klammern). Seite: 2 Datum: 6. Jan. 2004

Rule 1: Alle Usereingaben sind als Fehlerhaft und Manipuliert zu betrachten, bis das Gegenteil durch eine Validierung bewiesen ist! Der User, der von der Applikation für die Verbindung zum Datenbankserver verwendet wird, sollte nur über die minimal nötigen Rechte verfügen und ist in der Regel nur ein technischer User. Dieser User darf NIE die Rechte eines Datenbankadministrators haben. Sind diese trotzdem nötig, dann ist die Applikation schlecht designt oder implementiert! Rule 2: Das "least privilege" Prinzip. Der technische User darf NIE ein Datenbankadministrator sein, sondern nur die minimal nötigen Rechte besitzen! Die beiden Kommandozeilen Programme osql.exe und bcp.exe verlangen nach einem Passwort für den Zugriff auf den SQL Server. Mit Parametern können sie angewiesen werden, die eingebaute Windows-Authentisierung zu verwenden. Bei osql.exe ist es der Parameter E, bei bcp.exe der Parameter T. Rule 3: Es sollten NIE hart codierte Passworte verwendet werden. Statt dessen sollte die eingebaute Windows Authentisierung verwendet werden! Sensitive Daten wie Kreditkartennummern sollten verschlüsselt in der Datenbank abgelegt werden. Dazu muss aber auf Produkte von Drittherstellern zurückgegriffen werden, da dies nicht durch Microsoft implementiert wurde. Alternativ ist es möglich, per Eigenentwicklung auf das CryptoAPI zuzugreifen und so einzelne Felder zu verschlüsseln. Seite: 3 Datum: 6. Jan. 2004

3.4 OU-Plan Mittels Organisationseinheiten (Organizational Unit) werden Objekte im Active Directory organisiert. Gleiches wird dabei gruppiert. Es handelt sich dabei um: Benutzer Computer Drucker andere OUs OU s werden für folgende Tätigkeiten eingesetzt: Delegieren der Verwaltung an AD-Objekte (Admin Gruppen Rechte zuweisen) OUs sind keine sind keine Sicherheitsprincipals Organisieren von Ressourcen, nicht Festlegen von Berechtigungen (Dies wird über Gruppen bewerkstelligt) Gruppenrichtlinien wird auf OU Gruppenrichtlinien festgelegt OU s sind für die Verwaltung bestimmt und für Benutzer unsichtbar Wie nun die OU Struktur festgelegt wird, muss im Einzelnen entschieden werden. Rudimentär betrachtet müssen folgende Punkte beachtet werden (untenstehende Aufteilung soll lediglich als Beispiel betrachtet werden): Erstellen von OU s zum Delegieren von Verwaltungsaufgaben o OU s nach physischen Standort (Vorteilhaft für Drucker und Computer) o OU s nach Geschäftsbereich (Geeigneter für Benutzerkonten) Erstellen von OU s für die Zuweisung von Gruppenrichtlinien (Security Templates) o OU s nach Funktion oder Aufgabe (Benutzer und Server) Untenstehende Abbildung zeigt ein Beispiel für die Anwendung der Security Templates auf Server auf. Seite: 4 Datum: 6. Jan. 2004

Domain Root Domain Policy Member Server Baseline Policy Member Server OU Domain Controllers Domain Controller Policy File File Server Baseline Policy Print Printserver Baseline Policy Infra Infrastr. Server Baseline Policy IIS Web Server Baseline Policy SQL SQL Server Baseline Policy Exchange Mail Server Baseline Policy Seite: 5 Datum: 6. Jan. 2004

3.5 Priorität der Group Policy Mittels Group Policies können die einzelnen Einstellungen angewendet werden. Da diese Policy einer Gruppe (OU) zugeordnet wird, werden die Einstellungen auf allen Servern in der entsprechenden OU übernommen. Werden neue Objekte in OU s mit aktiven Group Policies verschoben, erhalten diese Objekte automatisch die definierten Einstellungen. Group Policies können auf verschiedenen Stufen angelegt werden. Folgende Liste zeigt die Reihenfolge der Zuordnung der Policies. 1. Local Policy 2. Site Policy 3. Domain Policy 4. Parent OU Policy 5. Child OU Policy (geschachtelte OU) Werden die gleichen Einstellungen in verschiedenen Stufen festgelegt, entspricht die zu letzt Zugeordnete der effektiven Einstellung. In den Eigenschaften der Group Policy kann die Option No Override angewählt werden. In diesem Fall wird die entsprechende Policy nicht überschrieben. 3.6 Security Management (Stay Secure) Das Hardening und somit die Empfehlungen in diesem Dokument konzentrieren sich auf die Sicherung eines Systems zu einem bestimmten Zeitpunkt. Da im Laufe der Zeit neue Erkenntnisse und Schwachstellen auftauchen, schwindet der Sicherheitslevel. Zudem ist das System selber einem Wandel ausgesetzt. D.h. Software wird installiert und Konfigurationen werden geändert. Aus diesen Gründen ist ein Security Management, welches folgende Tätigkeiten beinhaltet, unablässig. Zweckmässiges Logging und Kontrolle der Logs (siehe Anhang) Installation und Betrieb eines IDS Abonnieren aller relevanten Security Newsletter (siehe Anhang) Regelmässige Updates (Hotfixes, Updates) Regelmässige Vulnerability Scans im Intranet (z.b. Nessus, LanGuard, ) Regelmässige Passwort Audits (z.b. L0pht, Cain, ) Die in diesem Dokument beschriebenen Massnahmen zielen auf die sichere Installation des Microsoft SQL-Servers 2000. Es sollten aber auch regelmässige Checks durchgeführt werden, damit sicher gestellt werden kann, dass die Sicherheit noch gewährleistet ist. Auf Checks auf Betriebssystem Level wird hier nicht eingegangen. Die wichtigste Massnahme in diesem Zusammenhang ist es, sich regelmässig über neu verfügbare Servicepacks, Kumulative Patches und Security Hotfixes zu informieren und diese zu installieren. Hier bieten sich durch Microsoft automatisch verschickte Mails an (Siehe Links in Kapitel 5.3). Man sollte sich allerdings nicht zu sehr auf das Rating verlassen, da Microsoft dazu neigt, die Schwere der Auswirkungen eher etwas unter zu bewerten. Ein weiteres Hilfsmittel ist der sog. Microsoft Baseline Security Analyzer (kurz MBSA). Er dient dazu, die momentanen Einstellungen mit einer Datenbank zu vergleichen, die jeweils vor dem Test Seite: 6 Datum: 6. Jan. 2004

neu heruntergeladen werden sollte. Die Links zu MBSA befinden sich im Anhang, Kapitel 5.3. Der Output nach dem Scan eines gehärteten Servers sieht dann in etwa wie folgt aus: Es sollte regelmässig überprüft werden, dass nur tatsächlich berechtigte User Mitglieder der sysadmin Rolle sind. MBSA prüft alle User, ob sie leichte oder keine Passworte gesetzt haben. Wenn die Windows Authentisierung verwendet wird, wird dies durch die Domain Policy sichergestellt. Aus diesem Grunde sollten keine oder nur wirklich benötigte User direkt im SQL Server definiert werden. Wenn Mitarbeiter das Unternehmen verlassen, muss sichergestellt werden, dass deren allfällige Berechtigungen auch im SQL Server entfernt werden. Wenn die Mixed mode authentication verwendet wird, also Passworte direkt im SQL Server gespeichert sind, sollte die Stored Procedure sp_password so erweitert werden, dass es nicht mehr möglich ist, einfache Passworte zu setzen. sp_password sollte dann auch regelmässig darauf geprüft werden, dass keine Passworte gesammelt oder an anderer Stelle gespeichert werden. Die Rolle "public" sollte keine Rechte im SQL Server haben. Diese Rolle ist in etwas vergleichbar mit der Windows-Gruppe "Everyone". Die Berechtigungen für diese Gruppe sollte überall wenn möglich entzogen oder sonst stark eingeschränkt werden. Die Stored Procedure xp_cmdshell ist sehr mächtig. Es sollte regelmässig überprüft werden, wer alles darauf Zugriff hat. Nur Datenbank Administratoren darf das Recht zur Ausführung haben. Seite: 7 Datum: 6. Jan. 2004

3.7 Hinweise zu den Skripten Integraler Bestandteil diese Hardening Guides sind die folgenden drei zusätzliche Files: Intranet-Baseline-SQLServer-CSNC-V1.0.inf Group Policy. Die durch den SQL Server zusätzlich benötigten Services. Intranet-Baseline-Printserver-CSNC-V1.0.cmd Dient dazu, nach der Installation des SQL-Servers verbliebene Setup-Files zu löschen. Das Skript kann über die Eingabeaufforderung gestartet werden. Intranet-Baseline-SQLServer-CSNC_V1.0.sql Diejenigen Hardening-Massnahmen des SQL-Servers, die direkt im Server eingestellt werden können. Das Skript kann in SQL Query Analyzer geladen und ausgeführt werden. Sämtliche gelieferten Files sollten zuerst begutachtet und auf deren Plausibilität hin untersucht werden! Gewisse Parameter müssen vor der Ausführung an die lokalen Gegebenheiten angepasst werden. Seite: 8 Datum: 6. Jan. 2004

4 Hardening SQL 2000 Änderungen in den Einstellungen sollten, wenn immer möglich, mit dem SQL Server Enterprise Administrator gemacht werden. Dadurch wird sichergestellt, dass Änderungen keine negativen Einflüsse auf die Sicherheit haben. Der SQL Server Enterprise Administrator stellt sicher, dass z.b. User nur die nötigen Rechte haben, dass Registry- und NTFS-Permissions stimmen etc. Für alle nicht beschriebenen Konfigurations-Optionen gilt: Sie können je nach Bedarf gewählt werden. Es gibt keine Security-relevanten Einflüsse dadurch. Alle Usernamen und Passworte in diesem Dokument dienen als Beispiel und zur Verdeutlichung von Zusammenhängen. Sie sollten nicht in dieser Form in der produktiven Installation verwendet werden. Wenn möglich sollten keine Usernamen verwendet werden, die auf den Einsatzzweck schliessen lassen. Dieses Kapitel ist derart aufgebaut, dass es von Vorne nach Hinten durchgearbeitet werden kann und jeweils die Voraussetzungen für die späteren Schritte erfüllt sind. Seite: 9 Datum: 6. Jan. 2004

4.1 System Services Auf einem gemäss unserem Guide Checkliste_Win2K3_Intranet_Basis_V1.0 gehärteten System sind einige Services, die der SQL Server für den Betrieb benötigt aktiviert. Während der Installation werden lokal weitere Services konfiguriert und gestartet. Diese werden nicht über die Group Policy gesteuert, da die Service-Namen jeweils den konfigurierten Instanz-Namen des installierten SQL Servers enthalten. Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4100 Taskplaner Ermöglicht einem Benutzer, automatische Vorgänge auf diesem Computer zu konfigurieren und zu planen. Wenn dieser Dienst beendet wird, werden diese Vorgänge nicht zu den geplanten Zeiten ausgeführt werden. Wenn dieser Dienst deaktiviert wird, werden alle von diesem Dienst explizit abhängigen Dienste nicht gestartet werden können. Task Scheduler Enabled Wird benötigt, wenn ntbackup eingesetzt wird. Security Template (Automatisch) 4101 Distributed Transaction Coordinator Koordiniert Transaktionen, die sich über mindestens zwei Ressourcenverwaltungen wie Datenbanken, Nachrichtenwarteschlangen oder Dateisysteme erstrecken. Wenn der Dienst beendet ist, treten diese Transaktionen nicht auf. Wenn der Dienst deaktiviert ist, können abhängige Dienste nicht gestartet werden. Distributed Transaction Coordinator Manual Security Template (Automatisch) 4102 MSSQL$UUDI Stellt eine Hauptkomponente für Webservices dar. Benutzer können Anfragen bezüglich Daten in der SQL-Datenbank stellen. MSSQL$UUDI Manual Security Template (Automatisch) Seite: 10 Datum: 6. Jan. 2004

Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4103 MSSQLServerADHelper Wird benötigt, wenn Informationen ins Active Directory gespeichtert werden möchten, jedoch der SQL Server nicht unter dem System Konto läuft. MSSQLServerADHelper Manual Security Template (Automatisch) 4104 SQLAgent$ (UDDI or WebDB) SQLAgent$ (UDDI or WebDB) Manual Security Template (Automatisch) Seite: 11 Datum: 6. Jan. 2004

4.2 User / Gruppen Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4200 Domain: Eine OU für alle Datenbank Administratoren erstellen. Active Directory Users and Computers Domain New Organizational Unit Name = <wie gewünscht> Bsp. SQL_DBAs Manuelle Einstellung Dieser Schritt dient lediglich der Übersichtlichkeit und soll die Verwaltung vereinfachen. 4201 Domain: Pro Datenbank-Server eine globale Gruppe mit den Datenbank-Administratoren erstellen. Name = <wie gewünscht> Bsp. <servername>_sqldbas Manuelle Einstellung Active Directory Users and Computers Domain SQL_DBAs New Group Seite: 12 Datum: 6. Jan. 2004

Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4202 Domain: Domain-User, die auf dem entsprechenden Server DBA-Rechte erhalten sollen, können der vorher erstellten globalen Gruppe hinzugefügt werden. Alle Domain-User, die auf dem entsprechenden Server DBA-Rechte erhalten sollen. Manuelle Einstellung Active Directory Users and Computers Domain SQL_DBAs <servername>_dbas Properties Members Add... 4203 Lokal: Einen User ohne administrative Privilegien für den SQL-Service erstellen. Computer Management Local Users and Groups Users Action New User... Name = <wie gewünscht> Bsp. SQL_service_user Passwort = Sehr komplexes Passwort mit 25 oder mehr Zeichen (Gross- und Kleinbuchstaben, Zahlen, Sonderzeichen). Username und Passwort sollten zudem auf jedem SQL-Server unterschiedlich sein. Manuelle Einstellung 4204 Lokal: Eine lokale Gruppe für den SQL-Service erstellen. Name = <wie gewünscht> Bsp. SQL_local_service Manuelle Einstellung Computer Management Local Users and Groups Groups New Group... Seite: 13 Datum: 6. Jan. 2004

Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4205 Lokal: Den erstellten Service-User der neuen lokalen Gruppe zuordnen. Computer Management Local Users and Groups Groups SQL_local_service Add to group... Username wie gerade vorher erzeugt. Also nach Beispiel SQL_service_user Manuelle Einstellung Seite: 14 Datum: 6. Jan. 2004

4.3 Installation SQL 2000 SQL Server sollen gemäss dieser Hardening-Liste IMMER auf Member-Server installiert werden. Eine Installation auf Domain Controller sollte vermieden werden. Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4300 Installation Wizard Computer Name Local Computer = Enabled Manuelle Einstellung 4301 Installation Wizard Installation Selection Create a new instance of SQL Server, or install Client Tools = Enabled Manuelle Einstellung 4302 Installation Wizard Installation Definition Server and Client Tools = Enabled Manuelle Einstellung 4303 Installation Wizard Instance Name Instance name: <wie gewünscht> Manuelle Einstellung 4304 Installation Wizard Setup Type Setup Type: Custom Program Files: C:\Program Files\Microsoft SQL Server Data Files: D:\SQL-data Manuelle Einstellung Die Daten sollten in keinem Fall auf der System- Partition gehalten werden. 4305 Installation Wizard Select Components Komponenten wie gewünscht auswählen. Manuelle Einstellung 4306 Installation Wizard Service Accounts Customize the settings for each service. Manuelle Einstellung Seite: 15 Datum: 6. Jan. 2004

Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4307 Installation Wizard Service Accounts SQL Server = Enabled Use a Domain User account = Enabled Username = <wie unter 4.2 erzeugt> Password = <wie gesetzt> Domain = <lokaler Computername> Auto Start Service = Enabled Manuelle Einstellung 4308 Installation Wizard Service Accounts SQL Server Agent = Disabled Use a Domain User account = Enabled Username = <wie unter 4.2 erzeugt> Password = <wie gesetzt> Domain = <lokaler Computername> Auto Start Service = Disabled Manuelle Einstellung 4309 Installation Wizard Authentication Mode Windows Authentication Mode = Enabled oder (wenn möglich zu vermeiden): Manuelle Einstellung Mixed Mode (Windows Authentication and SQL Server Authentication) = Enabled Enter password for the sa accout = <Sehr komplexes Passwort mit 25 oder mehr Zeichen (Gross- und Kleinbuchstaben, Zahlen, Sonderzeichen)> Blank Password (not recommended) = DISABLED!!! 4310 Installation Wizard Network Libraries Named Pipes = Enabled Named Pipe name = \\.\MSSQL$<computername> TCP/IP Seite: 16 Datum: 6. Jan. 2004

4.4 Patches und Updates Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4400 Installation des SP3a für SQL Server 2000 Connect to Server The Windows account information I use to log on to my computer (Windows Authentication) = Enabled Manuelle Einstellung 4401 Installation des SP3a für SQL Server 2000 SQL Server 2000 Service Pack 3 Setup Enable cross-database ownership chaining for all databases (not recommended) = Disabled Upgrade Microsoft Search and apply SQL Server 2000 SP3 (required) = Enabled Manuelle Einstellung 4402 Installation des SP3a für SQL Server 2000 Error Reporting Automatically send fatal error reports to Microsoft = DISABLED!!! Manuelle Einstellung 4403 Installation des Hotfixes für MS03-031 Hotfix Installer Windows Authentication = Enabled Manuelle Einstellung Seite: 17 Datum: 6. Jan. 2004

4.5 Default Settings Nach der Installation des SQL Servers 2000 sind noch diverse Grundeinstellungen zu konfigurieren und Komponenten zu entfernen. Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4500 Konfiguration genereller Server-Einstellungen SQL Server Enterprise Manager Expand server group Servername Properties Tab: General Autostart SQL Server = Enabled Ganzer Rest = Disabled Network Configuration: Tab: General Enabled protocols: Named Pipes, TCP/IP TCP/IP Properties: Port = <egal, ausser 1433> Hide Server = Enabled Force protocol encryption = Disabled, wenn kein SSL verwendet wird. Enabled, wenn die Verbindungen verschlüsselt sein sollen. Es müssen dann aber auf allen beteiligten Geräten SSL-Zertifikate installiert werden. Manuelle Einstellung Seite: 18 Datum: 6. Jan. 2004

Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4501 Konfiguration genereller Server-Einstellungen SQL Server Enterprise Manager Expand server group Servername Properties Tab: Security Authentication: SQL Server and Windows = Enabled Audit level: All oder Failure = Enabled Allow cross-database ownership chaining = Disabled Service Account: This account = Enabled User = <Username wie unter 4.2 erzeugt> Passwort = <wie gesetzt> Manuelle Einstellung Tab: Memory Keine Änderungen aus Security-Sicht Tab: Processor Keine Änderungen aus Security-Sicht Tab: Connections Allow other SQL Servers to connect remotely to this SQL Server using RPC = DISABLED. Rest = Keine Änderungen aus Security-Sicht Tab: Server Settings Keine Änderungen aus Security-Sicht Tab: Database Settings Default data directory: Nicht auf dem System- Laufwerk. z.b. D:\sqldata Default log directory: Nicht auf dem System- oder Daten-Laufwerk. z.b. E:\sqllogs Tab: Replication Keine Änderungen aus Security-Sicht Seite: 19 Datum: 6. Jan. 2004

Nr. Sicherheitseinstellung Empfehlung Gewichtung Referenz 4502 Permissions der Model Datenbank härten. Diese Datenbank wird bei der Erzeugung neuer Datenbanken als Grundlage genommen. Damit erhalten dann alle neuen Datenbanken die hier konfigurierten Default Permissions. Tab: Data Files Automatically grow file = Enabled Restrict file growth = Die Summer aller Datenbanken sollte kleiner als der zur Verfügung stehende Platz auf der Festplatte sein. Manuelle Einstellung SQL Server Enterprise Manager Expand server group Expand server Databases model Properties Tab: Transaction Log Gleiche Einstellungen wie im Tab Data Files. Tab: Filegroups Read-Only = Disabled Default = Enabled Tab: Options Restrict access = Enabled Members of db_owner, dbcreator, or sysadmin = Enabled Read-only = Enabled Model = Full ANSI NULL default = Disabled Recursive triggers = Disabled Auto update statistics = Enabled Torn page detection = Enabled Allow cross-database ownership chaining = DISABLED Auto close = Disabled Auto shrink = Disabled Auto create statistics = Enabled Use quoted identifiers = Enabled Level = Database compatibility level 80 Tab: Permissions Role public = Alles Disabled Seite: 20 Datum: 6. Jan. 2004