M 5.118 Integration eines DNS-Servers in ein Sicherheitsgateway
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: IT-Sicherheitsmanagement, Administrator
Der Domain Name Service (DNS) dient zur Umsetzung von Rechnernamen in IP-Adressen und umgekehrt und stellt ferner Informationen über im Netz vorhandene Rechnersysteme zur Verfügung. Diese Informationen sind teilweise für die korrekte Funktion der Internetanbindung erforderlich, beispielsweise Informationen über DNS-Server oder Mail-Exchanger für eine Domain. Andererseits können DNS-Informationen auch von potentiellen Angreifern bei der Vorbereitung von Angriffen ausgenutzt werden. Hat ein Rechner beispielsweise einen Namen wie "mssql01", so kann ein Angreifer daraus schließen, dass es sich vermutlich um einen Rechner mit Microsoft-Betriebssystem handelt, auf dem ein Microsoft SQL-Server läuft.
Bei DNS sollte daher eine Trennung zwischen der Namensauflösung für interne Zwecke und der Namensauflösung "nach außen" eingeführt werden. Interne DNS-Informationen sollten vor dem nicht-vertrauenswürdigen Netz verborgen werden. Rechner im internen Netz sollten selbst dann keinen von außen auflösbaren DNS-Namen erhalten, wenn sie eine "öffentliche" IP-Adresse besitzen. Werden im internen Netz private IP-Adressen aus den Adressbereichen des RFC 1918 verwendet, so müssen diese ohnehin durch einen internen Nameserver aufgelöst werden.
Gerade DNS-Server-Programme waren in der Vergangenheit wegen Sicherheitslücken immer wieder eine Quelle von Problemen. Wegen der besonderen Bedeutung der DNS-Informationen und der erhöhten Anfälligkeit der DNS-Software als Grundlage für Angriffe ist ein besonderer Aufbau notwendig, um DNS-Informationen sicher bereitstellen und nutzen zu können.
DNS-Server in einem dreistufigen Sicherheitsgateway
Für eine sichere Integration von DNS in ein dreistufiges Sicherheitsgateway bietet sich der in der folgenden Abbildung gezeigte Aufbau an, bei dem keine direkte Verbindung zwischen einem Client im vertrauenswürdigen Netz und einem DNS-Server im nicht-vertrauenswürdigen Netz (und umgekehrt) stattfindet. Es werden zwei getrennte DNS-Server eingesetzt:
- Der "öffentliche" DNS-Server, der die extern verfügbaren Informationen enthält, wird in einer DMZ des äußeren Paketfilters angesiedelt. Er ist als "Primary Nameserver" für die Domain des vertrauenswürdigen Netzes eingerichtet und enthält nur die unbedingt notwendigen Informationen, beispielsweise:
- Name und IP-Adresse des externen Mailservers (MX-Eintrag)
- Namen und Adressen von Informationsservern, die Informationen für die Öffentlichkeit anbieten. Dabei muss zwischen den Servern, die vor dem ALG angesiedelt sind und denen, die hinter dem ALG angesiedelt sind, unterschieden werden. Bei ersteren muss die Adresse des Servers selbst eingetragen sein, bei letzteren die Adresse des ALG.
- Der "private" DNS-Server wird in einer DMZ des inneren Paketfilters aufgestellt. Er enthält die Informationen über die Rechner des internen Netzes. Für Rechner des internen Netzes wird dieser Server als DNS-Server eingetragen: Alle Clients des vertrauenswürdigen Netzes nutzen ausschließlich den privaten DNS-Server (z. B. bei Unix-Rechnern mittels Einträgen in der Datei /etc/resolv.conf). Benötigt ein Client im vertrauenswürdigen Netz eine DNS-Information aus dem nicht-vertrauenswürdigen Netz, so stellt er die DNS-Anfrage an den privaten DNS-Server. Als "Forwarder" nutzt dieser den öffentlichen DNS-Server für Anfragen, die externe Namen betreffen. Der direkte Zugriff auf den privaten DNS-Server aus dem nicht-vertrauenswürdigen Netz sollte durch Paketfilterregeln unterbunden werden, so dass die DNS-Informationen des vertrauenswürdigen Netzes nur im vertrauenswürdigen Netz sichtbar sind.
Abbildung 1: Integration der DNS-Server zur sicheren Kommunikation von vertrauenswürdigem und nicht-vertrauenswürdigem Netz
Der eingesetzte Paketfilter muss so konfiguriert werden, dass zwischen den Servern nur der DNS-Dienst gestattet ist, d. h. DNS-Port 53 als (je nach betrachteter Richtung) Quell- bzw. Zielport. Vom öffentlichen DNS-Server sollten keinerlei Verbindungen ins interne Netz zugelassen werden. Die Administration des Servers sollte über entsprechend abgesicherte Verbindungen (SSH) erfolgen.
In der folgenden Tabelle wird eine mögliche Konfiguration für Zugriffsregelungen beschrieben, die über entsprechende Paketfilterregeln umgesetzt werden kann. Dabei wird davon ausgegangen, dass die Administration der Server über eine SSH-Verbindung aus dem internen Netz erfolgt und dass für DNS als Trägerprotokoll UDP verwendet wird. Protokolldaten werden über Syslog auf einen Logserver übertragen.
Quelle | Ziel | Entscheidung | Bemerkungen |
---|---|---|---|
Kommunikation des öffentlichen DNS-Servers mit dem Internet | |||
Externes Netz |
Öffentlicher DNS-Server UDP Port 53 |
erlauben |
DNS-Anfragen und Antworten aus dem öffentlichen Netz |
Externes Netz |
andere Ports des öffentlichen DNS-Servers |
verbieten |
|
Externer DNS-Server |
DNS-Server im Internet, Port 53 TCP und UDP |
erlauben |
Auflösung von externen Namen durch den DNS-Server |
Externer DNS-Server |
Alle anderen Verbindungen ins Internet |
verbieten |
|
Kommunikation des externen DNS-Servers mit dem internen Netz
|
|||
Externer DNS-Server |
Alle Verbindungen ins interne Netz |
verbieten |
|
Internes Netz (ggfs. Einschränkung auf Administrationsnetz) |
Öffentlicher DNS-Server Port 22 (SSH) |
erlauben |
Administration und Datenübertragung erfolgen per SSH und SCP |
Internes Netz |
Alle anderen Zugriffe auf den öffentlichen DNS-Server |
verbieten |
DNS-Anfragen aus dem internen Netz erfolgen über den internen Server |
Kommunikation der beiden DNS-Server untereinander |
|||
Interner DNS-Server |
Öffentlicher DNS-Server UDP Port 53 |
erlauben |
Der interne DNS-Server leitet Anfragen an den öffentlichen Server weiter |
Externer DNS-Server |
Interner DNS-Server UDP Port 53 |
erlauben |
Der externe DNS-Server löst externe Namen für den internen Server auf |
Kommunikation des internen DNS-Servers mit dem internen Netz
|
|||
Internes Netz |
Interner DNS-Server UDP Port 53 |
erlauben |
DNS-Anfragen aus dem internen Netz erfolgen über den internen Server |
Interner DNS-Server, UDP Port 53 |
Internes Netz |
erlauben |
DNS-Antworten in das interne Netz |
Interner DNS-Server, sonstige Quellports |
Internes Netz |
verbieten |
|
Internes Netz (ggfs. Einschränkung auf Administrationsnetz) |
Interner DNS-Server Port 22 (SSH) |
erlauben |
Administration und Datenübertragung erfolgen per SSH und SCP |
Protokollierung
|
|||
Interner und externer DNS-Server |
Loghost UDP-Port 514 |
erlauben |
Übertragung der Protokolldaten zum Loghost |
Tabelle: Konfiguration für Zugriffsregeln
DNS-Server in einem einfachen Sicherheitsgateway
Wird nur ein einfaches Sicherheitsgateway (Paketfilter) eingesetzt, so wird empfohlen, trotzdem zwei getrennte DNS-Server einzusetzen. Wenn die beiden DNS-Server in zwei getrennten DMZs des Paketfilters angesiedelt werden, können die selben Regeln eingesetzt werden, wie oben beschrieben.
Ist der Aufwand für die Einrichtung zweier getrennter DMZs zu groß oder können aus technischen Gründen keine zwei getrennten DMZs eingerichtet werden, so kann gegebenenfalls auf einfachere Konstruktionen zurückgegriffen werden. Diese bieten allerdings nur einen geringeren Schutz und es muss daher im Einzelfall abgewogen werden, ob das Sicherheitsniveau noch akzeptabel ist.
Der öffentliche DNS-Server sollte in jedem Fall in einer DMZ des Paketfilters angesiedelt werden. Der interne DNS-Server kann gegebenenfalls im internen Netz stehen.
Wenn nur ein DNS-Server zur Verfügung steht, der sowohl die interne als auch die externe Namensauflösung übernehmen muss, so sollte dieser in einer DMZ des Paketfilters aufgestellt werden. Wenn möglich sollte in diesem Fall das DNS-Server-Programm so konfiguriert werden, dass zwischen Anfragen aus dem internen und solchen aus dem externen Netz unterschieden wird und gegebenenfalls unterschiedliche Daten geliefert werden. Diese Lösung bietet jedoch nur für kleine Netze ohne besondere Anforderungen an die Sicherheit einen ausreichenden Schutz.
Domain-Registrierung bei externem Dienstleister
Bei dieser Alternative werden wichtige DNS-Informationen bei einem externen Dienstleister gespeichert und nicht mehr durch einen eigenen DNS-Server bereitgestellt. Der Unterschied zu den eben beschriebenen Szenarien besteht im Wesentlichen im Wegfall des externen DNS-Servers. DNS-Anfragen aus dem externen Netz nach DNS-Informationen aus dem internen Netz werden nicht an den organisationsinternen DNS-Server, sondern an den DNS-Server des externen Dienstleisters gesendet und von diesem beantwortet. Der interne DNS-Server greift bei Anfragen nach externen DNS-Namen oder IP-Adressen direkt über das Sicherheitsgateway hinweg auf einen DNS-Server im externen Netz zu.
Auch bei dieser Integrationsvariante sollten nur die unbedingt notwendigen DNS-Informationen extern angeboten werden, z. B. Name und IP-Adresse des Mail-Servers und des ALG. Bei besonders unbedenklichen organisationsinternen Nutzern kann der interne DNS-Server auch im internen Netz, anstatt in einer DMZ des inneren Paketfilters betrieben werden, was die Administration des Paketfilters (wenn auch nur in geringem Maße) erleichtert.
Vorteile dieser Variante sind die geringen Investitionskosten und die geringe Komplexität bei der Integration in ein Sicherheitsgateway. Zudem verfügt ein Dienstleister möglicherweise über redundante Systeme, was bei einer organisationsinternen Lösung oftmals nicht der Fall ist.
Ergänzende Kontrollfragen:
- Welche Informationen über das Netz können von extern über DNS abgefragt werden?
- Welche Anordnung der DNS-Server wurde gewählt?
- Welche Kommunikationsverbindungen für die DNS-Server sind zugelassen?