Netzwerkdienste – unerreichbar gut

Auch in Zeiten von Cloud-Diensten nimmt die Komplexität nicht ab, sondern zu. Nach Jahren des Customizings von Softwarelösungen wurde eine neue Abstraktion gesucht, um den Lifecycle von Produkten und den Herstellerwechsel zu vereinfachen. In der Folge setzte man vermehrt auf die Standardkomponenten von Software, und die Hersteller entwickelten eigene As-a-Code-Lösungen. Die Konfigurationen werden nicht mehr tief in die Software eingebettet oder über eine grafische Oberfläche eingegeben, sondern als Code.

Das führte zu einer zusätzlichen Ebene, der Konfigurationsebene, die eigenständig ist und leicht verständlich sowie einfach versionierbar und replizierbar sein soll.

Die ersten grösseren weltweiten Erfolge durfte DevOps verbuchen. Sie waren es, die As-a-Code-Lösungen etablierten. Aber warum ist dies so wichtig? DevOps ging den Weg des geringsten Widerstandes und führte zuerst mehrere Iterationen durch. Man startete mit der Konfiguration der Applikation, erweiterte die Möglichkeiten, virtuelle Maschinen zu starten und zu stoppen, und ist nun im Begriff, nach all den Iterationen Infrastructure-as-a-Code (IaaC) zu vervollständigen. Während Ressourcen wie CPU, RAM und Diskspeicher fast immer von IaaC abgedeckt wurden ist dies bisher für Netzwerkinfrastruktur kaum der Fall.

Netzwerke in eigener Verantwortung

Vielerorts werden das Netzwerk und Basis-Services wie DHCP (Dynamic Host Configuration Protocol) v4/v6, DNS (Domain Name System), NTP (Network Time Protocol), IPAM (IP Address Management), Routing und Firewall getrennt verwendet. Einträge werden manuell verwaltet und es werden Excel-Listen geführt, die bestenfalls in einem Ticketsystem nachverfolgbar sind.

Die wiederkehrenden Aufräumarbeiten sind mühsam und werden entsprechend selten durchgeführt. Das birgt Risiken, frustriert die Dienstbetreiber und führt zu Mehraufwand bei den Nutzern. Ein Webserver-Verantwortlicher, der einen DNS-Eintrag immer wieder bestätigen muss, erhält hierdurch keinen Mehrwert. Bei der x-ten Nachfrage wird der Eintrag auch kaum mehr geprüft, sondern schnell abgehakt – was soll sich denn schon geändert haben? Hacker, die Zugang erhalten haben, können auf diese Weise über Monate oder Jahre unentdeckt bleiben. Einer der grössten Chatanbieter (der Name tut hier nichts zur Sache) wies einen veralteten DNS-Eintrag auf, der auf eine IP-Adresse zeigte, die nicht mehr dem Hersteller gehörte. Dies nutzt ein Nutzer aus, indem er seine Instanz auf dieser IP-Adresse bereitstellte und Daten sammelte. Gibt es bei Ihnen veraltete Einträge? Wie schnell wussten Sie davon? Es ist Zeit, zu handeln.

Netzwerkdienste as-a-Code

Zunächst muss definiert werden, welche Dienste zukünftig zu welchen Gruppen gehören sollen. Jede Gruppe wiederum muss die Aufgabe erhalten, ihren Service möglichst as-a-Code oder als REST-API verfügbar zu machen. Ziel ist es nicht, jede Änderung direkt in die produktive Umgebung zu übernehmen, sondern vielmehr gute Freigabeprozesse zu ermöglichen.

Dies soll mittels Iterationen erreicht werden. Als Beispiel für DNS:

1. Iteration

• Anlegen einer zentralen DNS-Konfiguration in GIT o. Ä.
• Freigabe durch die DNS-Service-Verantwortlichen
• Übernahme der Konfiguration jeweils um 19.00 Uhr, damit fremde Einträge überschrieben werden

2. Iteration

• DNS-Konfigurationsordner, jede TLD erhält eine Konfigurationsdatei
• Freigabe durch DNS-Service-Verantwortlichen, Vier-Augen-Prinzip
• Übernahme der Konfiguration 15 Minuten nach Freigabe, damit noch Zeit bleibt, allfällige Fehler zu korrigieren

3. Iteration

• Es soll stündlich geprüft werden, ob die Konfiguration aus dem IaaC der effektiven Antworten des DNS-Service übereinstimmt. Ein Alarm soll bei Abweichung ausgelöst werden.

Die Umstellung der Netzwerkdienste kann nur über Iterationen erfolgen. In einem ersten Schritt ist ein grober Entwurf möglicher Iterationen zu erstellen und danach die nächste Iteration gründlich zu planen. Denken Sie dabei an eine klare Kommunikation. Nehmen Sie die Planung in Ihr Wiki auf, informieren Sie über den Iterationsplan und fragen Sie nach Pilotgruppen. Besonders im Netzwerkbereich kann es je nach Umstellung Tage dauern, bis klar ist, dass die Schuld nicht bei der Applikation, beim Benutzer oder beim Betriebssystem liegt, sondern beim Netzwerk.

Die Schritte nochmals als Checkbox:

On-Prem-Netzwerkdienste

Bei On-Prem-Netzwerkdiensten ist die Rede von Diensten, die für Komponenten im On-Prem-Netzwerk zur Verfügung stehen, auch wenn diese allenfalls aus der Cloud weitergereicht werden. Hier ist ein Start wahrscheinlich schwieriger, da eher Endbenutzer betroffen sind und noch viele historische Einträge wie auch Komponenten eingesetzt werden. Es empfiehlt sich daher, in der Cloud durchzustarten und Standards zu etablieren, die für On-Prem übernommen werden.

Cloud-Netzwerkdienste

Bei Cloud-Netzwerkdiensten handelt es sich um Dienste, die für Komponenten im Cloud-Netzwerk zur Verfügung stehen, auch wenn diese allenfalls aus On-Prem weitergereicht werden. Das wohl Schwierigste ist, eine Cloud-agnostic Infrastructure zu ermöglichen. Heutige Cloud-Anbieter erlauben es, alle virtuellen Maschinen zu erstellen, zu konfigurieren und danach zu starten. Das ist im Netzwerkbereich anders. Alleine IPv6 wird Ihnen Probleme bereiten, denn es ist nicht bei allen Anbietern verfügbar. Aber solche Hürden können überwunden werden und gerade Neuanfänge sind dazu prädestiniert, IPv6 im Jahr 2022 endlich als Standard zu etablieren.

Gesondert zu betrachten sind aber gerade in der Cloud zwei Themen, die bei On-Prem kaum oder keine Beachtung fanden. Das erste Thema sind die Kosten. Der eingehende und der ausgehende Netzwerk-Traffic werden verrechnet, der Traffic in der gleichen Cloud-Region aber nicht. Je nach Anbieter sind auch die effektiven Kosten unterschiedlich hoch. Insbesondere ist dies deshalb wichtig, sollten Sie Netzwerkdienste betreiben die ein hohes Datenaufkommen im Netzwerk verursachen und nicht in der gleichen Region befinden (Cross-Region Kosten). Auch wenn nicht wegen der Netzwerkdienste, sondern anderer Services viel Traffic anfällt, müssen Sie möglicherweise Hilfe bieten. Es gilt abzuklären, welche Dienste überhaupt Traffic verursachen und welche Soft- (Alarm) und Hard-Limits (Blockieren von Traffic) weshalb gesetzt wurden. Auch hier ist es wichtig, in Iterationen zu denken und Verbesserungen vorzunehmen, anstatt alles bis zum Tag X aufzuschieben. Auch Fehler lassen sich nicht vermeiden. Wenn wegen einer Deny All Rule auf der Firewall plötzlich das Netzwerk stillsteht, so ist es besser, diesem Problem frühestmöglich zu begegnen. Gerade Logikfehler sind auf dem Papier nicht auffindbar, zeigen sich aber im Betrieb.

Das zweite Thema sind die Cloud-native Services. Diese wurden vom Hersteller zur Verfügung gestellt, und oftmals fehlt noch eine Funktion für das Geschäft, die sehr praktikabel wäre. So etwa erweiterte Filtermöglichkeiten oder eine Regelaktivierung bei bestimmten Aktionen. Auch sind diese Dienste oftmals gar nicht optional, auch wenn sie gerne so wahrgenommen werden. IPAM fällt besonders auf, da keine eigenen Tools genutzt werden, weil keine eigenen Agents als Master dienen; vielmehr kann IPAM nur über diesen Cloud-native IPAM überhaupt gesteuert werden. Die einfachste und schnellste Lösung besteht darin, mit Scripts zu arbeiten. Das führt dann wieder zu direkten Abhängigkeiten vom Cloud-Anbieter. Denn anderswo werden die Dienste nicht gleich ansprechbar sein. Inzwischen gibt es Tools, um die Infrastruktur Cloud-agnostic zu bauen, was wiederum zu einer Abhängigkeit von genau diesem Tool führt. Ob dem Hersteller des Tools oder den Cloud-Anbietern vertraut werden soll und welche Abhängigkeiten sich daraus ergeben, ist zu eruieren.

Monitoring und Alarming

Weniger ist mehr: Dies trifft insbesondere bei Netzwerkdiensten zu. Überlegen Sie sich gut, was überhaupt von Relevanz ist und wie dies messbar gemacht werden kann. Gerade beim Monitoring können sich auch auf Betriebssystemseite plötzlich neue Anforderungen an die Servicebetreiber ergeben. Wie prüfen Sie DNS-Einträge? Es ist oft gar nicht so klar, wer für die Prüfung überhaupt zuständig ist und eine Aussage treffen kann. Exotische Installationen wie etwa Webserver die HTTPS nicht auf Port 443 ausliefern, sondern auf anderen Ports müssen eine angepasste Monitoring erhalt. Weitere Konfigurationen bei Server die zum Beispiel dazu führen keine Ping-Befehle zu beantworten erhöhen allesamt die Aufwände. Vielleicht sind auch gerade Wartungsarbeiten im Gang und der Dienst ist bewusst nicht verfügbar. Spätestens hier wird es Ihnen nur teilweise gelingen, ein Monitoring zu ermöglichen Als Kontrast zum Normalbetrieb kann die Frage gestellt werden, was auf keinen Fall eintreten darf.

Das wären etwa ungültige Einträge. Oder der Dienst übernimmt Änderungen nicht (z. B. Zeitstempel nicht älter als X Stunden). Das einfache Keep-Alive als Information (System oder Service antwortet) ist wichtiger über alle Basiskomponenten zu erhalten, als sich für gewisse Dienste spezielle Metriken (Stwichwort Tracing) zu erstellen.

Bei einem Alarm müsste diese Information im Sinne eines Ampelsystems im internen Wiki allen zur Verfügung stehen. Dies bedeutet weniger Frust für alle und mehr Zeit, sich um die Probleme zu kümmern. Häufig wurde auch die Frage gestellt, wie Alarmmeldungen zu den Service-Verantwortlichen gelangen sollen. Mit E-Mail wären im Notfall zu viele Abhängigkeiten verbunden, es würde nichts versendet werden, war einer der Gründe für diese Frage. Hier gibt es keine allgemeingültige Antwort. Mit jeder zusätzlichen Massnahme, etwa die Erstellung eines RSS-Feeds, wächst die Komplexität. Auch bieten manche Hersteller eine App für das Smartphone an welches Push-Benachrichtigungen direkt vom Monitoringsystem erhalten kann. Es bleibt das Restrisiko, dass ein Alarm trotz aller Bemühungen nicht durchkommt.

Unerreichbar gut

Möchten Sie die Netzwerkdienste in Ihrem Unternehmen unerreichbar gut gestalten, etwa im Einklang mit dem NIST Cybersecurity Framework? Dann kontaktieren Sie uns unverbindlich.

Cloud Security

Über den Autor

Über den Autor

Daniel Brunner ist seit 2011 in der Cybersecurity Branche und Spezialisiert auf Risikomanagement, agiles Projektmanagement und Implementierung robuster Hochververfügbarkeitslösungen in hybriden Umgebungen (Cloud- und On-Premises). Er ist Experte in der effektiven Realisierung technisch anspruchsvoller und komplexer Lösungen.

Daniel Brunner, Senior Security Consultant