21. August 2024

Unser erstes MikroTik-Projekt

Migration der Firewall eines Kunden auf ein neues System

Neben Softwareentwicklung und Datenschutz bieten wir bekanntlich auch IT-Security und damit zusammenhängende Dienstleistungen an. Heute berichten wir über die Umstellung der Firewall eines Kunden.

Ausgangslage

Bislang haben wir bei Kunden als Firewall in der Regel Hardware von Sophos, vornehmlich die Serien XG und XGS, verbaut. Sophos baut unserer Erfahrung nach zuverlässige Hardware zu einem durchaus akzeptablen Preis. Allerdings sind selbst für Firmware-Updates inzwischen Subscriptions nötig. Kauft man eine neue Sophos XGS sind nur noch 5 Firmwareupdates inkludiert. Selbst wenn man also, wie die meisten unserer Kunden, mit den Basis-Features auskommt, ist eine Subscription dennoch de-facto Pflicht.

Alternativen

Neben Sophos existieren natürlich auch andere namhafte Hersteller, die sich als Alternativen eigenen. Vorrangig zu nennen sind dabei:

  • Cisco
  • Fortinet
  • SonicWall

Daneben existieren natürlich noch eine ganze Reihe anderer Lösungen, die aber in der Regel das Budget unserer Kunden sprengen und daher nicht Betracht kommen. Ferner besteht natürlich auch die Möglichkeit Open-Source-Systeme, wie etwa OPNsense, zu nutzen, wobei diese vom Kunden ausgeschlossen wurden.

Für Cisco und Fortinet sprach vor allem, dass wir hier bereits über Erfahrungen verfügen. Preislich bieten beide Anbieter gegenüber Sophos allerdings keinen Vorteil.

Durch einen kroatischen Kollegen wurden wir aufmerksam auf einen hierzulande verhältnismäßig unbekannten Hersteller - MikroTik aus Lettland.

Im Gegensatz zu den anderen genannten Lösungen erzeugt eine Lösung auf Basis der Produkte von MikroTik keine laufenden Kosten, die Geräte werden über viele Jahre mit kostenlosen Updates versorgt und sind darüber hinaus auch ausgesprochen preiswert.

Wir besprachen die Optionen mit unserem Kunden. Dieser wünschrte sich eine möglicht kostenffiziente Lösung und daher boten wir ihm an, eine Migration hin zu MikroTik Hardware durchzuführen - nicht ohne darauf hinzuweisen, dass dies für uns Neuland sein würde.

Vorarbeiten

Jeder Administrator, der einmal eine Sophos XG/S administriert hat, wird den enormen Komfort zu schätzen wissen. Die Weboberfläche ist logisch aufgebaut und die Handhabung schnell erlernt.

Arbeitet man hingegen mit MikroTik Routerboards sieht die Sache anders aus. Das Standardwerkzeug zur Administration ist WinBox, ein Programm das den spröden Charm von Windows 3.1 versprüht, ein klassiches MDI-Interface nutzt. Es gibt Alternativen, etwa WebFig, aber das sieht dann in etwa aus, als würde man WinBox im Browser ausführen. Natürlich bietet RouterOS, das Betriebssystem der MikroTik Routerboards, auch ein leistungsfähiges Terminal-Interface, das auch gut scriptbar ist. Für die Ersteinrichtung haben wir uns allerdings für WinBox entschieden.

Ein genereller Unterschied der beiden Systeme ist, dass unter RouterOS nahezu jeder Aspekt konfiguriert werden kann, häufig bis ins kleinste Detail. Dazu kommt, dass durchgängig keine symbolischen Bezeichner (etwa für Ports) verwendet werden. Dadurch fühlt sich die Konfiguration für Ein- und Umsteiger sehr hart und roh an.

Um eine möglichst geringe Downtime zu erzielen, haben wir uns entschieden, wie folgt vorzugehen:

  • Dokumentation aller bestehenden Firewall-Regeln
  • Dokumentation der gesamten IPsec VPN-Konfiguration
  • Nachbau der Konfiguration in RouterOS
  • Testen des Setups in unserer Labor-Umgebung
  • Vulnerability Scans gegen das neue Setup im Labor
  • Tausch der alten Sophos Hardware gegen das neue Routerboard
  • Testen des gesamten Setups
  • Vulnerability Scans in der Live-Umgebung

Umstellung

Die Dokumentation der Ausgangslage gestaltete sich relativ arbeitsaufwändig, da der Kunde bislang keine Dokumentation hierzu besaß; dieser erhielt er nun im Rahmen des Projekts gratis on-top. Einige nicht benötigte Regeln wurden identifiziert und für die Umstellung verworfen.

Die VPN-Konfiguration hatten wir erst vor einigen Monaten dokumentiert und konnten jetzt darauf zurückgreifen.

So begannen wir nun mit der Konfiguration des Routerboards, wobei wir uns für erste Tests eng an die vorliegende - und wirklich gute - Dokumentation von MikroTik hielten. Das Ergebnis war bereits eine gut arbeitende Firewall, die in dieser Form sicherlich vielen Mittelständlern gut gedient hätte.

Unser Kunde hat jedoch aus regulatorischen Gründen besonders hohe Sicherheitsanforderungen. Im Anschluss befassten wir uns daher genauer mit den Datenfluss-Diagrammen von MikroTik, diese sind übersichtlich und genau. Diese Diagramme sind gerade für Umsteiger extrem hilfreich, da sie auch die Unterschiede zwischen den einzelnen Chains, die sich sehr eng an iptables orientieren, verdeutlichen.

In der Folge bauten wir die alten Regeln nach und richteten die VPN-Verbindungen ein. Dabei stießen wir auf einige Fallstricke, etwa dass IPsec-Traffic nicht durch fast-tracked werden darf, die aber schnell geklärt werden konnten. Interessant hierbei ist, dass es verschiedene Wege gibt, dieses Ziel zu erreichen. Die häufigste Lösung ist die Nutzung von RAW-Regeln, die auf Adress-Bereiche abzielt, allerdings das Connection-Tracking umgeht. Wir haben uns statt dessen dafür entschieden, mangle-Rules und Connection Marking einzusetzen.

RAW-Regeln haben wir ausschließlich als Pre-Checks eingesetzt.

Die Umstellung der VPN-Konfiguration indes war deutlich schwieriger, insbesondere weil MikroTik hier gern von der gängigen Terminologie abweicht und daher ein solides Studium der Dokumentation unerlässlich ist.

Die Vulnerability Scans, die wir zur Kontrolle durchgeführt haben, zeigten ein solides Bild. Nessus und GSA hatten beide nichts am neuen Setup auszusetzen. Tatsächlich gab es sogar einige Warnungen weniger als vorher, da Sophos XGS WebUI noch immer auf TLS 1.0 und TLS 1.1 setzt, was auch nicht ohne weiteres (und vor allem nicht update-sicher) abschaltbar ist.

Zu guter letzt implementierten wir noch einen DNS-basierten AD-Blocker, wofür MikroTik freundlicherweise von Hause aus Optionen mitbringt.

Die eigentliche Umstellung verlief dann tatsächlich ausgesprochen problemlos. Wir hatten ursprünglich eine Downtime von 2 Stunden eingeplant, tatsächlich betrug sie aber lediglich etwa 15 Minuten.

Fazit

Unser Kunde nutzte lediglich die Basis-Features seiner Sophos Firewall, vorrangig die eigentliche Firewall-Funktion (allerdings ohne irgendwelche Next-Gen-Funktionen) und IPsec VPN. Die Migration hat einschließlich der Vorarbeiten etwa 5 Manntage in Anspruch genommen. Die Downtime betrug etwa 15 Minuten.

Die Administration von RouterOS ist komplex und erfordert einige Einarbeitungszeit, die sich aber definitiv lohnt.

Das Routerboard, das ungefähr den gleichen Preis hatte, wie eine 1jährige Subscription bei Sophos, arbeitet problemlos, schnell und zuverlässig. Unser Kunde ist höchst zufrieden.

Der nächste Schritt wird voraussichtlich die Ablösung der Unifi-Access-Points durch MikroTik Hardware sein.

19. Juli 2024

Globaler IT-Ausfall

Ein fehlerhaftes Update und die halbe Welt steht still.

Der heutige Freitag wird überschattet von einem massiven Ausfall von IT-Systemen weltweit.

Hintergrund ist offenbar ein fehlerhaftes Update des CyberSecurity-Dienstleisters CrowdStrike für dessen Hauptprodukt Falcon. Falcon ist ein Softwaresystem, dass Geräte vor Bedrohungen schützen und im besten Fall auch aktiv dagegen vorgehen können soll.

Aufgrund eines Programmierfehlers, der offenbar auch in der Qualitätssicherung nicht bemerkt wurde, stürzten Windows-Systeme, die mit Falcon ausgestattet waren, nach dem automatischen Einspielen des Updates schlicht ab. Was aber noch deutlich schlimmer ist: Falcon ist tief im Betriebssystem verankert - das muss es auch, damit es seiner Aufgabe nachgehen kann. In diesem Fall aber führte das zu einem sogenannten Bootloop, d.h. betroffene Rechner starteten immer und immer wieder neu, ohne jemals betriebsbereit zu werden. Nur ein manueller Eingriff durch die verantwortlichen Administratoren konnte die Rechner wieder zu einem korrekten Systemstart bewegen.

Betroffen von diesem Desaster waren Schätzungen zufolge etwa 8,5 Millionen Rechner weltweit.

Bemerkenswert an diesem Vorfall ist einerseits die große Zahl an betroffenen Computern und andererseits die Frage, wieso ein solch kapitaler Fehler nicht durch die Qualitätssicherung bei CrowdStrike bemerkt werden konnte.

CrowdStrike wird sich sicherlich einige unangenehmen Fragen stellen lassen müssen.

Glücklicherweise waren die meisten Systeme recht schnell wieder einsatzbereit, nachdem CrowdStrike eine Anleitung veröffentlicht hat, um die betroffenen Geräte wiederherzustellen. Die Verzögerungen im weltweiten Flugverkehr werden allerdings sicherlich noch eine Weile andauern.

Einige Kommentatoren hinterfragen bereits, ob der generelle Trend in Richtung Cloud wirklich der richtige Weg ist. Die Frage mag berechtigt sein, allerdings ist der Trend kaum aufzuhalten. Das gesamte Windows-Ökosystem bewegt sich in diese Richtung und das auch nicht erst seit gestern. Ein einzelner Vorfall dieser Art wird daran auch nichts ändern.

Allerdings ist dieser Vorfall sicherlich ein guter Anlass, die eigene IT-Strategie zu prüfen und gegebenenfalls auch kritisch zu hinterfragen - schließlich ist auch Verfügbarkeit üblicherweise ein Schutzziel der Informationssicherheit.