Bundesamt für Sicherheit in der Informationstechnik

M 4.432 Sichere Konfiguration von Serverdiensten

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Nachdem das Betriebssystem des Servers installiert (siehe M 2.318 Sichere Installation eines IT-Systems ) und konfiguriert wurde, muss der eigentliche Serverdienst eingerichtet werden. Bei Serverdiensten handelt es sich um ausgeführte Prozesse, die den Clients bestimmte Funktionen zur Verfügung stellen. Beispiele hierfür sind Web-, E-Mail- und Verzeichnisdienste.

Serverdienste können in zwei unterschiedlichen Kategorien aufgeteilt werden. Serverdienste der ersten Kategorie stellen ihre Funktion frei im Netz zur Verfügung, ohne dass sich die Benutzer hierfür authentisieren müssen. Beispiele hierfür sind DNS -, DHCP - oder NTP -Server. Die zweite Kategorie erfordert hingegen eine Authentisierung der Benutzer vor der Benutzung des Dienstes, z. B. um vertrauliche Informationen vor unbefugtem Zugriff zu schützen. Beispiele hierfür sind Datei-, E-Mail-, SSH - oder RDP -Server. Ob und welche Form der Authentisierung für die Nutzung eines Serverdienstes erforderlich ist, hängt von der Art des Dienstes, der Konfiguration des jeweiligen Dienstes und dem Schutzbedarf der Daten ab.

Generell sollten alle vorhandenen, aber nicht benötigten Serverdienste deinstalliert werden, der Server sollte nur die zwingend benötigten Dienste zur Verfügung stellen. Neben dem eigentlichen Serverdienst wird in der Regel zusätzlich ein Serverdienst zur Administration auf dem IT -System benötigt. Vertiefende Informationen hierzu sind in M 4.97 Ein Dienst pro Server zu finden.

Bevor der neue Serverdienst z. B. aus der Paketverwaltung oder aus anderen Quellen installiert wird, sollte dessen Dokumentation gesichtet werden, falls dies noch nicht geschehen ist. Hierbei sollte unter anderem ermittelt werden, welche Dateien für den Betrieb des Dienstes benötigt und welche Prozesse gestartet werden. Erst hiernach sollte mit der Konfiguration des eigentlichen Serverdienstes begonnen werden.

Restriktive Vergabe von Rechten

Damit ein Server den Clients bestimmte Informationen oder Funktionen bereitstellen kann, benötigt der Serverdienst in der Regel zahlreiche Informationen, die im Dateisystem des Servers abgelegt werden müssen. Hierzu gehören:

  • ausführbare Dateien, mit denen der Serverdienst gestartet oder verwaltet werden kann, sowie diverse Hilfsapplikationen, die für den Betrieb des Servers hilfreich sein können,
  • Konfigurationsdateien oder -Einträge, die das Verhalten des Serverdienstes steuern,
  • Protokolldateien, in denen der Serverdienst bestimmte Ereignisse, die eingetreten sind, ablegt, und
  • Nutzdaten mit den eigentlichen Informationen, die der Serverdienst bereitstellt.

Die Rechte auf diese Informationen müssen so restriktiv wie möglich vergeben werden. Nur Prozesse und Benutzer, die auf diese Informationen zugreifen müssen, sollten hierauf auch zugreifen können. Der Zugriff sollte auf ein Mindestmaß beschränkt werden. Um Zugriffsrechte ressourcenschonend an eine Vielzahl von Benutzern zu vergeben, empfiehlt sich die Einrichtung von Gruppen oder Rollen. Rechte können jedoch auch an einzelne Benutzerkonten oder auf Grundlage vordefinierter IP-Adressen oder -Adressbereiche zur Authentisierung vergeben werden.

Damit ein Serverdienst Funktionen anbieten kann, muss ein Prozess, der auf die benötigten Informationen und anderen Ressourcen zugreifen kann, gestartet werden. Die Zugriffsrechte des Prozesses werden in der Regel von den Zugriffsrechten des Benutzers, der den Prozess gestartet hat, abgeleitet. Normalerweise benötigt ein Prozess keine Schreibrechte auf Betriebssystem-Verzeichnisse und sollte deshalb diese auch nicht besitzen. Oft ist es aber so, dass ein privilegierter Benutzer mit Schreibrechten in Betriebssystem-Verzeichnissen den Prozess starten muss, um beispielsweise TCP - oder UDP -Ports zu öffnen. Wenn möglich, ist in diesem Fall dafür zu sorgen, dass der Prozess nach dem Start an einen unprivilegierten Benutzer übergeben wird.

Kann nur ein privilegierter Benutzer den Prozess und somit den Serverdienst starten, sollte der Prozess nach Möglichkeit in eine chroot-Umgebung, Sandbox oder ähnliche Umgebung "eingesperrt" werden. Bei einer chroot-Umgebung handelt es sich um einen abgeschotteten Bereich innerhalb des Computersystems, die es einem Angreifer erschwert, nach der Kompromittierung des Serverdienstes Zugriff auf das gesamte System zu erlangen. Eine chroot-Umgebung erfordert allerdings, dass alle vom Serverdienst benötigten Dateien ebenfalls im Verzeichnis des Serverdienstes und somit im abgeschotteten Bereich abgelegt werden. Vertiefende Informationen hierzu sind in M 4.198 Installation einer Applikation in einem chroot Käfig zu finden.

Abhängigkeiten zu Bibliotheken, Betriebssystemaufrufe und externe Ressourcen

In den Installationspaketen von Serverdiensten sind zahlreiche Dateien integriert, die bei der Installation auf das Zielsystem kopiert werden. Darüber hinaus werden in der Regel oft weitere Dateien benötigt, um den Serverdienst ausführen zu können. Hierzu gehören beispielsweise Applikationen und Bibliotheken von Drittentwicklern oder aus dem Betriebssystem. Obwohl in der Regel schon bei der Installation des Serverdienstes automatisch geprüft wird, ob alle benötigten Dateien vorhanden sind, sollte vorab zusätzlich manuell überprüft werden, ob diese wirklich vorhanden sind.

Wird beispielsweise ein vorhandener Serverdienst durch eine aktuellere Version ersetzt, ist darauf zu achten, dass weiterhin alle Dateien, die zu dessen Nutzung benötigt werden, vorhanden sind. Durch eine Aktualisierung kann es auch passieren, dass der Serverdienst Zugriff auf zusätzliche Dateien benötigt, die vor der Aktualisierung noch nicht erforderlich waren. Eine Aktualisierung kann auch dazu führen, dass neuere Versionen einer Bibliothek zwingend benötigt werden. Im Allgemeinen sollte im Zuge einer Aktualisierung nicht nur der Serverdienst, sondern alle zugehörigen Applikationen und Bibliotheken aktualisiert werden. Nutzt beispielsweise der Serverdienst eine Bibliothek, von der Schwachstellen bekannt sind, kann hierdurch ebenfalls der Serverdienst anfällig für Angriffe sein.

Betriebssystemaufrufe durch den Serverdienst sollten so weit wie möglich vermieden werden. Wenn sie nötig sind, ist darauf zu achten, dass z. B. durch Command-Injection-Angriffe keine kompromittierenden Anweisungen auf dem Server ausgeführt werden. Diese Anweisungen sollten so restriktiv wie möglich gefiltert werden.

Oft werden Serverdienste nicht autark eingesetzt, sondern sind auf externe Ressourcen angewiesen. Hierzu gehören beispielsweise

  • Serverdienste, die von Authentisierungsservern, Webservern oder Web-Anwendungsservern, abhängig sind,
  • Web-Anwendungsserver, die von Datenbankservern abhängig sind, oder
  • Fileserver, die von Speichernetzen abhängig sind.

Bei einem Ausfall solcher Serverdienste oder der Anbindung hieran kann unter Umständen auch der darauf zugreifende Serverdienst ausfallen. Besonders bei einem höheren Schutzbedarf bei Verfügbarkeit kann eine redundante Anbindung oder eine redundante Auslegung der nachgelagerten Serverdienste nötig sein.

Einschränkung der Erreichbarkeit

Viele Serverdienste, die Informationen in einem Netz bereitstellen, können so konfiguriert werden, dass sie nur an einer oder wenigen Netzschnittstellen lauschen, beziehungsweise dass sie hieran "gebunden" werden. Netzschnittstellen können physische Netzkarten oder logische Verknüpfungen, wie virtuelle Netzkarten oder loopback-Schnittstellen, sein. Verfügt ein IT-System über mehrere Schnittstellen und wird der Netz-Serverdienst nur an eine gebunden, nimmt der Netz-Serverdienst keine Verbindungsanfragen an einer anderen Netzschnittstelle an, solange keine Portweiterleitungen oder Ähnliches erfolgen. Dadurch kann der Zugriff auf Netz-Serverdienste so eingeschränkt werden, dass nur Benutzer aus bestimmten Netzbereichen zugreifen können. Daher sollte generell ein Netz-Serverdienst nur an so wenige Netzschnittstellen wie möglich gebunden werden. Soll ein Netz-Serverdienst nur innerhalb des lokalen IT-Systems genutzt werden, darf dieser Dienst nur an der loopback-Schnittstelle gebunden werden. Beispiele für lokale Netzdienste können Super- (wie inetd), X-, Druck- oder Zeitserver sein.

Der Zugriff auf einen Netzdienst kann auch über Paketfilter beschränkt werden. Generell sollten nur berechtige IT-Systeme auf einen Netzdienst zugreifen dürfen. Soll das IT-System, auf dem der Netzdienst betrieben wird, nur Verbindungsanfragen von bestimmten IT-Systemen über festgelegte Portnummern annehmen dürfen, kann mit Paketfiltern der Verbindungsaufbau reguliert werden. Der Zugriff auf einen Backendserver kann beispielsweise so mit Paketfilterregeln beschränkt werden, dass nur der zugehörige Applikationsserver hierauf zugreifen kann. Paketfilter können in der Regel auch so konfiguriert werden, dass sie alle oder ausgewählte Verbindungsanfragen protokollieren. Vertiefende Informationen zu Paketfiltern sind in M 2.74 Geeignete Auswahl eines Paketfilters und M 4.98 Kommunikation durch Paketfilter auf Minimum beschränken auf Minimum beschränken zu finden.

Verschlüsselung der Authentisierung und Nutzdaten

Je nach Serverdienst und bereitgestellten Ressourcen kann unterschieden werden, ob diese allen Benutzern oder nur einen ausgewählten Benutzerkreis zur Verfügung gestellt werden sollen. Abhängig vom Schutzbedarf müssen hierfür geeignete Authentisierungsverfahren ausgewählt werden. Typische Authentisierungsverfahren sind unter anderem (fälschbare) IP -Adressen, Benutzername und Passwort oder Zertifikate. Generell sollten alle Informationen, die für eine Authentisierung gegenüber dem Serverdienst benötigt werden, verschlüsselt übertragen werden.

Werden Nutzdaten über unsichere Netze übertragen, sollte geprüft werden, ob diese ebenfalls verschlüsselt übertragen werden sollen. In der Regel werden z. B. DNS-, Routing- oder NTP-Informationen nicht verschlüsselt übertragen, hingegen HTTP - oder IMAP / POP3 -Informationen öfter, um deren Vertraulichkeit zu schützen. Es ist daher zu entscheiden, welche Nutzdaten verschlüsselt werden sollen. Generell wird empfohlen, immer zu verschlüsseln, wenn dies möglich ist, da der Aufwand oft nur unwesentlich höher ist.

Vertiefende Informationen zur Verschlüsselung sind unter anderem in M 5.68 Einsatz von Verschlüsselungsverfahren zur Netzkommunikation zu finden.

Einschränken der Versionsinformationen

Standard-Fehlermeldungen bergen oft die Gefahr in sich, zu viel Information preiszugeben. Beispielsweise könnte ein Angreifer mit Hilfe von ausgegebenen Versionsinformationen nach Serverdiensten mit Schwachstellen suchen und diese ausnutzen.

Aus diesem Grund sollten, wenn möglich, alle Systemmeldungen so konfiguriert werden, dass sie keine Rückschlüsse auf die eingesetzte Softwareversion oder Konfiguration zulassen. Auch selbst erstellte Fehlermeldungen sollten die Benutzer über aufgetretene Fehler informieren, aber keine Details dazu preisgeben.

Datensicherung

Alle Informationen, die für eine Datenwiederherstellung benötigt werden, müssen regelmäßig gesichert werden, damit z. B. bei einem Hardwaredefekt oder einem unbeabsichtigten Löschen von Steuerdateien der Serverdienst zeitnah wieder in Betrieb genommen werden kann. Hierzu gehören mindestens

  • Konfigurationsdateien,
  • Nutzdaten und
  • Protokolldaten.

Bei vielen Arten von Serverdiensten spielt die Verfügbarkeit der Nutzdaten eine besondere Rolle. Bei Datei-, E-Mail- oder Webservern sind dies Informationen, die im Gegensatz zu Konfigurationsdateien nicht ohne Weiteres neu erstellt werden können.

Bei einigen Serverdiensten ist es nicht ausreichend, die zu sichernden Dateien nur zu kopieren. Insbesondere wenn die zu sichernden Informationen in Datenbanken abgelegt werden, müssen alternative Sicherungsverfahren genutzt werden. Ein Beispiel hierfür sind TDB-Dateien unter Samba, deren Inhalte vom Serverdienst oft für längere Zeit zwischengespeichert und nicht immer auf der Festplatte zur Laufzeit aktualisiert werden (siehe auch M 6.135 Regelmäßige Sicherung wichtiger Systemkomponenten eines Samba-Servers ). Daher muss die Dokumentation des Serverdienstes für die korrekte Datensicherung konsolidiert werden.

Updates

Der eingesetzte Serverdienst sollte immer auf dem aktuellen Stand sein. Wurden Schwachstellen der eingesetzten Software entdeckt und diese mit einer neueren Version behoben, sollte zeitnah auf die fehlerbereinigte Version gewechselt werden. Bevor eine neue Version ausgerollt wird, sollte diese getestet werden. Nicht nur der eigentliche Serverdienst, auch nachgelagerte Serverdienste, das Betriebssystem und alle weiteren installierten Applikationen, sollten regelmäßig aktualisiert werden. Vertiefende Informationen sind in M 2.273 Zeitnahes Einspielen sicherheitsrelevanter Patches und Updates zu finden.

Protokollierung

Sicherheitsrelevante Aktivitäten an Serverdiensten sollten aus vielen Gründen protokolliert werden. Zum einen hilft eine aktivierte Protokollierung, potentielle Schwachstellen frühzeitig erkennen und damit beseitigen zu können. Zum anderen kann Protokollierung dabei helfen, Verstöße gegen Sicherheitsvorgaben zeitnah zu erkennen oder Nachforschungen über einen Sicherheitsvorfall vorzunehmen.

Die Protokollierung des Serverdienstes sollte im Protokollierungskonzept integriert werden (siehe M 2.500 Protokollierung von IT-Systemen ).

Je nach Serverdienst sollten mindestens folgende Ereignisse aufgezeichnet werden:

  • Fehlgeschlagene Anmeldeversuche
  • Fehlgeschlagene Zugriffe auf Ressourcen aufgrund von:
    • mangelnder Berechtigungen
    • nicht vorhandener Ressourcen
    • Server-Fehlern
    • Hardware-Engpässe und -Ausfälle
    • Sonstige Fehlermeldungen

Prüffragen:

  • Wurden die Zugriffsrechte, die für den Betrieb eines Serverdienstes auf ausführbare Dateien, Konfigurations- und Protokolldateien sowie Nutzdaten benötigt werden, restriktiv vergeben?

  • Sind alle Ressourcen, die für den Betrieb eines Serverdienstes benötigt werden, in einer aktuellen Version vorhanden?

  • Kann der Netz-Serverdienst nur Verbindungen über notwendige Netzschnittstellen beantworten?

  • Werden Authentisierungsinformationen für Serverdienste immer verschlüsselt übertragen?

  • Werden alle für einen Serverdienst relevanten Informationen regelmäßig gesichert?

  • Werden die sicherheitsrelevanten Ereignisse des Serverdienstes protokolliert?

Stand: 13. EL Stand 2013