Das DNS ist mit der wichtigste Dienst in internen Netzwerken und im Internet sowieso. Ohne eine funktionierende Namensauflösung funktioniert in der IT nichts mehr. Daher ist es wichtig eine stabile und solide DNS Infrastruktur aufzubauen. Die Überschrift DNS Security ist bewusst so gewählt, denn zum einen ist es wichtig, den DNS zuverlässig zu betreiben und vor Cyberattacken zu schützen und zum anderen lässt sich der Dienst als weitere Maßnahme zum Schutz vor Cyberattacken selbst nutzen.
Der Stellenwert des DNS ist oft nicht der, welcher er sein müsste, in Anbetracht seiner Wichtigkeit und diese wird in vielen IT Umgebungen unterschätzt bzw. nicht entsprechend beachtet. Sehr häufig wird der DNS irgendwie so mitgemacht, und in der Standardkonfiguration belassen, weil es ja auch irgendwie funktioniert. Aber das ist kein sinnvoller Ansatz für den Betrieb eines so wichtigen Dienstes für die gesamte IT Infrastruktur im Unternehmen, wenn es nur irgendwie funktioniert und es hier kein passendes Konzept gibt. Aber wie sollte man vorgehen, um den Dienst die notwendige Wertigkeit auch zukommen zu lassen. Zunächst einmal sollte man sich einen Überblick über die eigene DNS Infrastruktur verschaffen und auf dieser Basis eine sinnvolle DNS Hierarchie entwickeln und dabei die DNS Server entsprechend kaskadieren, sowie gleichzeitig ein Sicherheitskonzept umzusetzen, um den Dienst zu schützen und als Synergieeffekt mit den DNS einen weiteren Cyber Security Layer der eigenen Infrastruktur hinzuzufügen. In diese Überlegungen spielen natürlich Split-DNS Szenarien mit hinein, vor allem im Hinblick auf die vielen Remote Zugriff per VPN aus dem Home Office oder von anderen Standorten mobiler Clients. Das Thema Split-DNS ist wichtiger als man vielleicht denken mag, vor allem dann, wenn zentrale DNS Server zur Auflösung in einer Region der Welt verwendet werden. Die Problematik, die dahintersteckt, alle Auflösungen zentral abzubilden wird sofort ersichtlich, wenn man sich folgendes Szenario vor Augen führt. Ein Mitarbeiter ist auf Dienstreise und nutzt das VPN zum zentralen Rechenzentrum seines Unternehmens und löst auch alle DNS Anfragen mit den zentralen DNS Servern auf. Bei den Services des eigenen Unternehmens soll das ja auch so sein, aber es gibt immer mehr Cloud Services, die genutzt werden und diese basieren auf GSLB (Global Server Load Balancing), was bedeutet, dass man immer das für seinen jeweiligen Standort nächste Cloud Datacenter zugewiesen bekommt. Sehr oft wird dies an der Quelle der DNS Anfrage festgemacht, in welcher Region man sich befindet. Bei diesem Beispiel ist dann die Region immer die, in der sich die DNS Server des Unternehmens befinden, ganz egal, wo der Client gerade wirklich ist. Befindet sich der mobile Client in der geografischen Nähe der zentralen DNS Resolver tritt das Problem nicht auf, ist aber der Client auf einen ganzen Kontinent entfernt, hat man ein Problem. Das einfache Beispiel zeigt, wie wichtige eine funktionierende Split-DNS Konfiguration und eine passende DNS Hierarchie ist. Dies gilt aber nicht nur für mobile Clients per VPN, sondern auch für alle Standorte eines Unternehmens die entsprechend verteilt auf dem Globus aufgestellt sind. Daran lässt sich auch erkennen, dass das DNS keine Sache ist, die man in der Standardkonfiguration einfach mal so nebenbei mitlaufen lässt und ein Konzept hier wirklich wichtig ist.
Die DNS Hierarchie und Split-DNS Konfiguration ist eine Sache, eine andere ist die Absicherung der eigenen Anfragen, der Schutz der eigenen DNS Server und die entsprechende hochverfügbare Bereitstellung des Dienst. Es macht durchaus Sinn die DNS Anfragen seiner Clients über Load Balancer zu seinen DNS Servern zu leiten. Wenn sich Anwender melden, dass es “so langsam” ist, dann sind es oft DNS Probleme, wenn der Client bei jeder Anfrage auf den Timeout des primären DNS wartet, weil dieser nicht antwortet und er den zweiten DNS nochmal fragen muss, um den Namen entsprechend aufzulösen. Setzt man hier auf Load Balancer und ihren Prüfungen der Server im Backend, erspart man sich so manchen Anruf in der IT, weil aus Sicht der Anwender der Service bzw. seine Anwendung schnell und zuverlässig sind. Als Gimmick können dann selbst die primären DNS Server im Tagesbetrieb gewartet werden. Dabei müssen nicht immer kommerzielle Load Balancer zum Einsatz kommen, in vielen Fällen kann man das gewünschte Ergebnis auch mit lizenzkostenfreien OpenSource Systemen erreichen. Zudem stellen solche Systeme auch die ideale Basis für den Einsatz eines DNS Upstream Proxy oder Proxy Cluster in der DMZ dar. Aus Gründen der IT Sicherheit sollte man es vermeiden, dass die internen Server einfach selbst irgendwo im Internet DNS Anfragen auflösen. Aber dies gehört mit in das Thema zum Aufbau einer passenden und durchdachten DNS Hierarchie. Zu bedenken sind hier ebenfalls Techniken wie DNS over TLS (DoT) oder DNSSEC. Aber grundsätzlich ist eine gut durchdachte Hierarchie und eine entsprechend gesicherte Kommunikation per DNS Gateway in der DMZ zum Internet ein großer Schritt zu mehr Sicherheit beim Betrieb des so wichtigen Dienstes. Werden dann auch noch sinnvolle Load Balancer Konzepte für eine entsprechende Verfügbarkeit des Service genutzt gewinnt die DNS Konfiguration zusätzlich an Stabilität und Verfügbarkeit. Zudem hilft diese in Zukunft bei Update oder Austausch von DNS Backend Systemen, da es aus Sicht der anfragenden Systeme durch die Load Balancer keine Veränderungen gibt. Werden statt der DNS Server selbst die Load Balancer konfiguriert, so muss bei Upgrade oder Austausch der eigentlichen DNS Server keine statische Konfiguration angepasst werden und man kann zentral auf den Load Balancern einfach auf die neuen DNS Server schwenken. Ob man hier nun entsprechende Load Balancer oder ADC als HA Cluster betreibt oder einfach zwei Systeme, die jeweils auf alle DNS im Backend zeigen, entscheidet sich je nach Szenario und den jeweiligen Anforderungen.
Zentrale Upstream DNS, natürlich je Standort, wenn man an das Split-DNS Szenario denkt, bieten eine weitere Option sich gegen Cyber Angriffen zu schützen. Durch den Einsatz von DNS Filter lassen sich Anfragen an bekannte Domains von zum Beispiel C&C Servern oder Systemen die anderweitig Schadcode verteilen filtern und damit eine weitere Ebene zum Schutz vor Cyber Attacken einführen. Dieser Ansatz ist sehr effizient und wenig invasiv, wie zum Beispiel das Aufbrechen von TLS Verbindung. Fortigate Firewalls bieten diese Option schon seit FortiOS 5.4 und die ist seit gut vier Wochen EOS. OpenDNS, die von Cisco 2015 gekauft wurden, sind ein kommerzieller Anbieter in diesem Bereich, der u.a. Endpoints durch ein solches Szenario schützt. Statt die Zugriffe auf das Internet mobiler Clients über Proxy Systeme umzuleiten und zu filtern, werden bei diesem Szenario die DNS Anfragen gegen entsprechende Kategorien geprüft. Gerade bei zentralisierten Szenarien in Verbindung und dem Einsatz einer Fortigate Firewall mit entsprechender URL-Filter Lizenz, die sowieso Bestandteil einer Bundle- oder Enterprise-Lizenz ist, bietet es sich sofort an, den DNS Schutz zu aktivieren. Vor allem macht es durchaus Sinn, bekannte FQDN’s schon bei der DNS Anfrage zu filtern, statt darauf zu warten, dass ein Client diese Seite aufruft und dann der Aufruf erst im URL Filter unterbunden wird. Dies setzt aber voraus, dass der Zugriff auch per URL auf den unerwünschten Host stattfinden muss, da sonst der URL-Filter ja nicht greift. Demzufolge bietet der DNS-Filter einen echten Mehrwert und ist zudem noch einfach und global zu implementieren, wenn die eigene DNS Hierarchie stimmt. Der Einsatz von DNS Filtern ist ein sehr eleganter und effektiver Schutz, der zudem noch verhältnismäßig einfach umsetzbar ist gegenüber einem reinen URL Filter einen Mehrwert bietet.
Wie immer sind wir bei Fragen zu diesem Thema wie gewohnt zu erreichen.