Cisco Meraki MX67
Aufpasser ohne Allüren
Veröffentlicht in Ausgabe 02/2025 - TESTS
Stateful Packet Inspection ist zwar noch immer ein wichtiges Mittel der IT-Security, zusätzlich sind aber auch erweiterte Technologien wie beispielsweise IDS/IPS, kategoriebasierte Filter, TLS-Inspection, E-Mail-Filter, MDR/XDR sowie Anti-Malware-Systeme erforderlich, um aktuellen Bedrohungen entgegenzuwirken. Auch die Standortvernetzung und Anbindung an zentrale Rechenzentrumsdienste – lokal oder in der Cloud – über SD-WAN mit multiplen Links und unterschiedlichen Eigenschaften stellt inzwischen ein häufig gefordertes Feature für Firewalls dar.
Um alle diese Regelwerke auf multiplen Firewallsystemen an unterschiedlichen Standorten gleich zu halten, ist ein zentrales Management notwendig. Dieses soll die Policies konsistent halten, Konfigurationen an alle Systeme verteilen, aber auch die Echtzeitdaten der Netzwerke und potenzielle Fehler oder Sicherheitsprobleme darstellen. Dafür setzen immer mehr Hersteller auf Clouddienste, so auch die Firewall-Serie Meraxi MX mit cloudbasiertem Management, die in unserem Test durch die Meraki-MX67-Firewall für kleinere Umgebungen vertreten wurde.
Hochwertige Hardware
Auf WAN-Seite bietet die MX67-Firewall einen RJ45-Ethernet-Port mit 1 GBit/s und ein zweiter derartiger Anschluss lässt sich optional aktivieren. Ein integriertes Mobilfunk-Modem findet sich im Modell MX67C und integriertes WLAN ist der MX67W-Firewall vorbehalten. Auf LAN-Seite stehen drei dedizierte 1-GBit/s-RJ45-Ethernet-Ports zur Verfügung. Ein vierter ist nur verfügbar, solange der zweite WAN-Port nicht aktiviert ist.
Stateful Packet Inspection ist zwar noch immer ein wichtiges Mittel der IT-Security, zusätzlich sind aber auch erweiterte Technologien wie beispielsweise IDS/IPS, kategoriebasierte Filter, TLS-Inspection, E-Mail-Filter, MDR/XDR sowie Anti-Malware-Systeme erforderlich, um aktuellen Bedrohungen entgegenzuwirken. Auch die Standortvernetzung und Anbindung an zentrale Rechenzentrumsdienste – lokal oder in der Cloud – über SD-WAN mit multiplen Links und unterschiedlichen Eigenschaften stellt inzwischen ein häufig gefordertes Feature für Firewalls dar.
Um alle diese Regelwerke auf multiplen Firewallsystemen an unterschiedlichen Standorten gleich zu halten, ist ein zentrales Management notwendig. Dieses soll die Policies konsistent halten, Konfigurationen an alle Systeme verteilen, aber auch die Echtzeitdaten der Netzwerke und potenzielle Fehler oder Sicherheitsprobleme darstellen. Dafür setzen immer mehr Hersteller auf Clouddienste, so auch die Firewall-Serie Meraxi MX mit cloudbasiertem Management, die in unserem Test durch die Meraki-MX67-Firewall für kleinere Umgebungen vertreten wurde.
Hochwertige Hardware
Auf WAN-Seite bietet die MX67-Firewall einen RJ45-Ethernet-Port mit 1 GBit/s und ein zweiter derartiger Anschluss lässt sich optional aktivieren. Ein integriertes Mobilfunk-Modem findet sich im Modell MX67C und integriertes WLAN ist der MX67W-Firewall vorbehalten. Auf LAN-Seite stehen drei dedizierte 1-GBit/s-RJ45-Ethernet-Ports zur Verfügung. Ein vierter ist nur verfügbar, solange der zweite WAN-Port nicht aktiviert ist.
Das Gehäuse unseres Testgeräts maß 2,7 x 13 x 23,9 cm bei einem Gewicht von rund 800 Gramm und besaß ein externes 18-Watt-Netzteil. Das Gehäuse wirkte sehr hochwertig. Cisco Meraki verspricht für die Hardware eine lebenslange Garantie mit Austausch am nächsten Arbeitstag – solange eine gültige Lizenz vorliegt.
| Produkt |
Cloudverwaltete Sicherheits-Appliance.
|
|---|---|
| Hersteller |
Cisco Meraki
|
| Preis |
Der Listenpreis für Meraki MX67 beträgt beim Anbieter 841 US-Dollar. Unsere Marktrecherche ergab bei unabhängigen Händlern jedoch teilweise deutlich günstigere Angebote. Die erforderliche Lizenz für ein Jahr "Secure SD-WAN Plus" und den Support ist für 967 US-Dollar zu haben.
|
| Systemanforderungen |
Internetverbindung mit ausreichend Datendurchsatz.
|
| Technische Daten |
Intuitives Webinterface
Die Verwaltung der Meraki-MX-Firewall findet über das webbasierte Portal namens Meraki-Dashboard statt. Es erlaubte uns, auch weitere Netzwerkkomponenten wie einen ebenfalls bereitgestellten Switch oder auch WLAN-Access-Points zu verwalten. Das Portal wirkte auf uns sehr intuitiv und wir konnten es bereits nach kurzer Eingewöhnung gut bedienen.
Zuvor mussten wir uns jedoch einen Test-account für das Meraki-Dashboard anlegen. Um das Gerät hinzuzufügen, hinterlegten wir dessen Seriennummer in den Inventardaten, was das Device für unseren Account aktivierte. Alternativ wäre bei größeren Massenbestellungen auch die Hinterlegung der Bestellnummer möglich.
Um dann unser Testgerät zu verwalten, legten wir im Dashboard ein neues Netzwerk an. Dabei hatten wir die Wahl der darin bereitgestellten Funktionen. Wir entschieden uns für "Kombiniert", um neben der Firewall auch den bereitgestellten Switch verwalten zu können. Falls eine klare Trennung zwischen diesen Funktionen gewünscht ist, ließe sich dies auch einrichten. Parallel dazu wiesen wir dem neuen Netzwerk auch direkt die zuvor hinterlegte Firewall zu, um diese darin zu verwalten. Das gesamte Beanspruchen der Hardware wie auch das Anlegen des Netzwerks gelang ohne Probleme.
Echtes Zero-Touch-Provisioning
Die initiale Verbindung findet im Normalfall mit einem sogenannten Zero-Touch-Provisioning (ZTP) statt. Dies funktioniert jedoch nur, wenn der WAN-Uplink über DHCP verfügt und kein VLAN-Tag in Richtung Provider zu setzen ist. In Deutschland kommt zudem meist PPPoE zur Einwahl zum Einsatz. Zum Hinterlegen der WAN-VLAN-ID und der PPPoE-Zugangsdaten mussten wir uns mit einem Notebook mit einem der LAN-Ports verbinden und die URL "http://setup.meraki.com" aufrufen, was uns zur lokalen Statusseite führte. Dort konnten wir problemlos die angesprochenen Informationen hinterlegen. Als Benutzername diente die Seriennummer, ein Kennwort war nicht vorgesehen. Dies sollte der IT-Verantwortliche natürlich dringend im Nachgang anpassen. An einem Starlink Mini mit DHCP an der WAN-Schnittstelle konnten wir die Firewall auch ohne solche Vorbereitungen die MX über den ZTP-Prozess mit dem Dashboard verbinden.
Nach wenigen Minuten wechselte die LED der MX67 auf durchgehend weiß, was eine erfolgreiche Verbindung zum Meraki-Dashboard signalisierte, und im Nachgang erschien das Gerät auch dort. Über diese TLS-verschlüsselte Managementverbindung fließen anschließend auch Konfigurationsänderungen.
Als Softwarebasis kam im Test die MX-Version 18.211.2 zum Einsatz. Firmwareupdates ließen sich über das Dashboard entweder direkt ausführen oder auch geplant starten. Selbst Massenupdates waren somit problemfrei möglich, was auch eine konsistente Versionierung vereinfacht.
Vielfältige Sicherheitsfunktionen mit kleinen Schwächen
So vielfältig die Gefährdungen für Clients, so umfangreich auch die Firewallfunktionen: Dies begann in unserem Test zunächst bei klassischen eingehenden und ausgehenden Stateful-Inspection-Firewall-Richtlinien. Diese regeln neben dem klassischen Datenverkehr zwischen LAN und WAN auch die Kommunikationsbeziehungen zwischen unterschiedlichen VLANs. Cisco nennt diese Regeln Layer 3, was aber gemäß OSI-Modell nur die halbe Wahrheit darstellt. Im Default erlaubte die MX67 zunächst von innen nach außen jegliche Kommunikation, wobei sie von außen nach innen alles blockte. Ein zonenbasiertes Modell, wie es bei anderen Herstellern inzwischen meist der Fall ist, kennt Meraki jedoch nicht. Die angelegten Regeln zogen bereits kurz nach dem Einrichten und die Cloudanbindung brachte keine merkliche Verzögerung beim Ausrollen von neuen Firewallrichtlinien.
Neben den IPv4- oder IPv6-Quell- und Ziel-IP-Informationen auf Layer 3 ließen sich natürlich auch Layer-4-UDP/TCP-Ports, aber auch Ziel-FQDNs filtern. Ungewöhnlich erschien uns jedoch der Hit-Counter, der bei zutreffenden Regeln nach oben zählt. Er setzt sich bei jedem Seitenaufruf im Meraki-Dashboard zurück. Zudem konnten wir festlegen, ob die MX67 Mitteilungen an einen externen Syslog-Sever sendet. Über eine Spoofing Protection blockte die Firewall ohne zusätzliche Konfiguration gefälschte Quell-IP-Adressen. Neben den klassischen Policies boten sich uns welche für Layer 7. Derartige Verbote überschrieben die Erlaubnisse der Layer-3-Regeln. Letztere behandelte das Gerät statusgebunden jedoch noch vor den statuslosen Layer-7-Regeln.
Wir konnten problemlos den Datenverkehr zwischen unserer Firewall und bestimmten Ländern mittels Geo-Blocking sperren. Dabei waren jedoch keine Ausnahmen von bestimmten IP-Adressblöcken möglich, falls diese beispielsweise falsch zugeordnet sind oder nur ein bestimmter Block in einem Land zulässig ist. Zudem konnten wir auch HTTP-Hostnamen sowie vorbereitete Kategorien von Zielen verbieten.
Dazu zählen beispielsweise Filesharing-Plattformen oder Peer-to-Peer-Kommunikationsbeziehungen einzeln oder als gesamte Kategorie sowie Fernwartungsdienste, um beispielsweise laterale Bewegungen im Netzwerk über Protokolle wie RDP zu verbieten. Dies funktionierte in unseren Tests erstaunlich akkurat. Layer-7-Regeln bieten nur ein "Deny Statement", können also nur gezielt blocken. Hier hätten wir uns noch eine Option für "Allow" gewünscht, um noch gezielter filtern zu können.
Neben den vorbereiteten klassischen Masquerading- beziehungsweise Port-Address-Translation-Regeln, damit multiple Clients über eine WAN-IP-Adresse mit dem WAN kommunizieren können, bot die MX-Firewall auch erweiterte eingehende NAT-Regeln. Darunter klassische Port-Forwardings, um eigene Dienste öffentlich anzubieten und zusätzlich 1-zu-1-NAT-Mappings von einzelnen WAN-IP- zu LAN-IP-Adressen. Mit 1-zu-N- Regeln ließen sich auf einer WAN-IP-Adresse unterschiedliche Ports an verschiedene interne Server weiterleiten. Es gab jedoch keine Möglichkeit für ein ausgehendes NAT.
Eine Kernfunktion für den Firewall-Betrieb stellt das Logging dar. Das Meraki-Gerät bot jedoch nur Live-Logging im Dashboard. Für erweiterte und retrospektive Aufzeichnungen ist ein externer Logging-Server notwendig. Jeder Firewall-Admin kennt Fehlermeldungen von Nutzern, dass zu einer bestimmten Zeit am Vortag etwas nicht funktioniert habe. Solch ein Fall lässt sich mit den integrierten Funktionen nicht prüfen. Dies ist laut Meraki jedoch in Planung. Zudem erkannten wir im Event Log gelegentlich auch gedroppte Events aufgrund zu hoher Last, was zu fehlender Sichtbarkeit führte.
Bedrohungen einfach aussperren
Für noch tiefere Filterungen boten sich uns die Bereiche "Threat Protection" und "Content Filtering" an. Die Advanced Malware Prevention (AMP) dient dem Prüfen von HTTP-Dateidownloads auf der Grundlage von Bedrohungsdaten, die die MX67 aus der AMP-Cloud von Cisco abruft. Als Malware klassifizierte Downloads listete Meraki im Security-Center. Viel zu konfigurieren gab es dabei nicht. Neben einer einfachen Ein/Aus-Auswahl stand noch eine Option offen, die URLs oder Dateien bei False Positives bewusst erlaubt. Bei Dateien brauchte es dafür die SHA256-Checksumme.
Im Threat-Protection-Bereich fanden sich auch die Einstellungen für die Intrusion Detection und Intrusion Protection. Im Untergrund werkelte eine Snort Engine in der aktuellen Version 3. Hierbei versteckt Meraki die Komplexität: Wir konnten zwischen reiner Erkennung (nur IDS) oder dem IPS-Schutz (IDS und IPS) auswählen. Als Parameter gab es drei Aggressivitätsstufen des IPS: "Konnektivität", "Ausbalanciert" und "Sicherheit". Die Stufe Konnektivität blockt nur Snort-Regeln mit CVSS-Score 10, Ausbalanciert (Standardwert) ab 9 aufwärts und Sicherheit entsprechend ab 8 aufwärts. Einfacher kann die Konfiguration nicht sein. Das Ausbalanciert-Level umfasst die Kategorien "Malware" "Command and Control", "Blocklist", "SQL Injection" und Exploit Kits – alle sind per Default aktiviert. Die Stufe "Sicherheit" lieferte zusätzlich noch das Überprüfen verdächtigen Verhaltens anhand von Applikationserkennung. Für den Fall von False Positives konnten wir spezifische Snort-Signaturen in einer Drop-down-Auswahl deaktivieren.
Um Ausnahmen für latenzsensitiven Traffic wie Kollaborationstools oder geschäftskritische Applikationen in AMP und IPS anzulegen, lassen sich entsprechende Kategorien parametrisieren. Dies funktionierte allerdings nicht für einzelne Applikationen, sondern immer nur für Kategorien. Wer also beispielsweise Ausnahmen für MS Teams benötigt, leitet gleichzeitig auch Webex, Zoom und jeglichen SIP- und RTP-Datenverkehr am IDS/IPS und AMP vorbei. Eine andere Variante waren Ausnahmen für einzelne Netze, es standen aber keine Kombinationen zwischen Applikationskategorien und Subnetzen zur Verfügung, wie sie einige Mitbewerber bieten.
Um auf Basis von DNS-Informationen Datenverkehr zu inspizieren und folglich bei Bedarf auch blockieren zu können, kommt das Gerät mit einer Umbrella-Integration daher. Da beide Werkzeuge aus dem Hause Cisco stammen, gelang die Integration über API-Schlüssel erwartbar einfach. Die genauen Richtlinien steuert der Admin dann in Umbrella. Für die Korrelation von sicherheitsrelevanten Informationen und das Anstoßen von Folgemaßnahmen bot sich uns eine API-Integration in die Extended Detection and Response (XDR)-Umgebung aus dem Hause Cisco.
Um gezielt webbasierten Datenverkehr zu reglementieren, nutzten wir den Konfigurationsbereich "Content Filtering". Dabei standen uns Inhaltsblockierungen wie Waffen oder Pornografie und potenziell gefährliche Seiten (bösartige Inhalte, Botnets) zur Verfügung. Dies funktionierte im Test gut und auch die Wartezeit bis zur Anwendung der neuen Richtlinien empfanden wir mit rund einer Minute als angemessen. In einigen Fällen waren jedoch noch Artefakte von Webseiten sichtbar, da die Firewall Teilinhalte von anderen Domänen nicht in die gleiche Kategorie einsortierte. Zur feineren Filterung nutzten wir den URL-Filter. Diese liefert eine Parametrierung bewusst erlaubter als auch verbotener Domänennamen und URLs (Black- und Whitelisting). Hierbei hatten wir jedoch bei einigen URL-Filtern das Problem, dass die MX67 gezieltes Blacklisting nicht korrekt anwendete, was sich jedoch als Browser-Problem erwies.
Uns fehlte in der Standardauslieferung jedoch eine Möglichkeit zur TLS-Entschlüsselung, wie es Mitbewerber bieten. Diese ließe sich gemäß Aussage von Cisco nur in dessen Backend selbst aktivieren, da dieses Feature viele Hardwareressourcen erfordert. Empfohlen ist gemäß Hersteller eher der Rückgriff auf Umbrella oder Secure Connect beziehungsweise Secure Access. Gleichzeitig gab es auch keine Option zum Scannen von E-Mails, obgleich diese noch immer ein großes Einfallstor darstellen.
Nebenbei bemerkt verspricht der Hersteller auf seiner Webseite Machine-Learning-Funktionen. Im Kern kommen diese jedoch bisher nur für das Baselining von Schwellenwerten und der Applikationsüberwachung zum Einsatz.
Routing teilweise nicht wie gewohnt
Eine grundlegende Entscheidung, die der Administrator zunächst treffen muss, ist, wie er die MX-Firewall einsetzen möchte. Hier stehen "Routed Mode" und "Passthrough / VPN Concentrator Mode" zur Verfügung. Beim Routing-Modus dient die Firewall als Layer-3-Gateway in Richtung anderer Subnetze, LAN und WAN. Im "Passthrough / VPN Concentrator Mode" fungiert die Firewall als Layer-2-Bridge oder VPN-Gateway ohne NAT.
Auf LAN-Seite konnten wir in der Routed-Variante entweder im Single-LAN-Modus mit einem IP-Subnetz oder mit multiplen VLANs arbeiten. Beides funktionierte im Test problemlos. Im VLAN-Modus waren wir in der Lage, den physischen Schnittstellen ein VLANs fix als sogenanntes Access-VLAN zuzuweisen oder ein VLAN-Bündel im Trunk-Modus zu übergeben.
IPv4 und IPv6 ließen sich im Dual-Stack-Betrieb einrichten, IPv6-Default-Routen im VPN waren jedoch nicht möglich. Einschränkungen fanden wir zudem im Bereich des dynamischen Routings. Das Border Gateway Protocol (BGP) und Open Shortest Path First (OSPF) konnten wir nur einsetzen, solange VPN auf dem Gerät aktiv war. Zudem ist keine Kombination von OSPF mit multiplen VLANs auf LAN-Seite möglich. OSPF hatte ferner die Einschränkung, dass die Firewall nur aus dem sogenannten Auto-VPN von anderen MX-Appliances gelernte Routen per OSPF bekannt gab. Von der LAN-Seite nahm sie jedoch keine dynamischen Routen an. Das ist jedoch auch in der Dokumentation von Meraki beschrieben. Um symmetrisches Routing zu ermöglich, wären zusätzlich also noch statische Routen in das lokale Netz erforderlich – was einen unvollständigen Eindruck bei uns hinterließ. Hingegen konnten wir erfreulicherweise eBGP auf LAN- und WAN-Seite aktivieren und das statische Routing war flexibel und einfach zu konfigurieren.
Um Lastverteilungs- und Redundanzmechanismen für SD-WAN nutzen zu können, hatten wir die Möglichkeit, den zweiten Port über einen einfachen Klick von LAN auf WAN umzukonfigurieren. Auf dieser WAN-Schnittstelle war dann auch ein VLAN setzbar. Jedoch ließen sich keine multiplen VLANs auf dieser Schnittstelle anlegen. Hingegen gab es eine Parametrisierung für PPPoE auf beiden WAN-Schnittstellen. Mit dem Warm-Spare-Feature konnten wir auch ein Activ/Standby- Paar aus zwei MX-Firewalls bilden. Dafür nutzte Meraki das bekannte First-Hop-Redundancy-Protokoll VRRP.
Problemlose, zeitsparende Standortvernetzung
Um einen geschützten Zugang zum Unternehmens- oder Behördennetz zu erhalten, steht das "Remote Access VPN" bereit. Dafür unterstützt die Firewall sowohl L2TP mit IPSec als auch TLS/DTLS-Tunnel auf Basis des "Cisco Secure Client" (früher AnyConnect-Client). Bei der problemlosen Einrichtung unterstützte uns der automatisch eingerichtete DynDNS-Dienst von Meraki, da wir mit dynamischen öffentlichen IPv4-Adressen arbeiteten. Allerdings ließen sich keine differenzierten VPN-Gruppen mit unterschiedlichen Privilegien-Leveln konfigurieren, um beispielsweise die Berechtigungen des VPN-Zugangs zwischen Finanz- und Personalabteilungen differenzieren zu können. Dazu empfahl Cisco das hauseigene Secure Connect als integriertes SASE, um unterschiedliche Gruppen zu realisieren.
Zur Authentifizierung standen sowohl die integrierte Meraki-Nutzerdatenbank als auch die Anbindung an einen RADIUS-Server sowie ein Active Directory bereit. Für den Cisco Secure Client standen zudem die Anbindung an einen SAML Identity Provider sowie eine zertifikatsbasierte Authentifizierung zur Verfügung. Für diesen Client konnten wir auch Profile zur individuellen Anpassung hochladen. Neben dem Tunneln aller Pakete durch das VPN-Gateway ließen sich auch sogenannte Split-Tunnels einrichten, um gezielt Datenverkehr in den Tunnel zu leiten oder bewusst um ihn herum.
Um Standorte zu vernetzen, bot die Firewall auch Site-to-Site VPNs. Neben klassischen manuell konfigurierbaren IKEv1- und IKEv2-IPSec-VPNs zu Nicht-Meraki-Gegenstellen gibt es die proprietäre AutoVPN-Funktion. Über diese waren wir in der Lage, innerhalb unserer Organisation mit wenigen Klicks eine Hub-and-Spoke-Topologie zu erstellen. Dabei registrieren sich die AutoVPN-Firewalls in der Meraki-Cloud, um ihre Erreichbarkeitsinformationen auszutauschen und einen symmetrischen AES- Schlüssel sowie die zugeordneten Subnetzinformationen zu erhalten.
Im Anschluss bauten die Firewalls auf Basis der bidirektional vorhandenen Erreichbarkeitsinformationen und Schlüssel ein IPSec-VPN auf. Wer einmal ein Site-to-Site-VPN auf anderen Plattformen konfiguriert hat, versteht, dass dies eine immense Erleichterung gegenüber manueller Konfiguration von IKE- und IPSec-Richtlinien darstellt. Neben dem gezielten Tunneling der jeweiligen Subnetze der Firewalls stand uns über einen einfachen Mausklick zudem die Option offen, jeglichen Datenverkehr über eine Default-Route und eine zentrale Firewall zu leiten.
Flexible Lastverteilung mit SD-WAN
Um Datenflüsse intelligenter über das WAN zu steuern, stand neben dem klassischen VPN auch eine SD-WAN-Funktionalität bereit. Dies erlaubt, Traffic dynamisch über mehrere Verbindungen zu verteilen. Im Test betrieben wir einen VDSL-Anschluss auf der ersten WAN-Schnittstelle und eine Starlink-Antenne auf der zweiten. Die Bandbreiten der WAN-Links ließen sich einstellen, sodass die Firewall den ausgehenden Datenverkehr entsprechend steuerte.
Zur Funktionsprüfung der WAN-Links hinterlegten wir eigene Zielserver zur Erreichbarkeitsprüfung und definierten, ob wir eine Lastverteilung oder nur ein Aktiv/Passiv-WAN-Szenario möchten. Dies ließ sich sogar noch dediziert für VPN konfigurieren. Einige Gegenstellen dürften jedoch Probleme mit unterschiedlichen Quell-IP-Adressen für IPSec-Tunnel haben, weshalb es sehr sinnvoll erscheint, die Lastverteilung in diesem Bereich zu deaktivieren.
Danach ging es an die Feinheiten des Traffic-Engineerings. Dies erlaubte uns beispielsweise, Datenverkehr aus unserem VoIP-Subnetz und Kollaborationsanwendungen wie Teams oder Webex gezielt über den VDSL-Link zu leiten, da dieser im Normalfall eine geringere Latenz aufweist. Nur bei schlechter Qualität oder Ausfall sollte dieser Datenverkehr auf unseren Starlink umschwenken. Jedoch sollten Online-Backups dediziert Starlink nutzen und nur bei Ausfall auf VDSL umschwenken, um mit der Übertragung großer Mengen Daten den Echtzeitdatenverkehr nicht zu beeinflussen. Zudem standen sogenannte Performance-Klassen mit Latenz, Jitter und Paketverlust-Schwellenwerten bereit, um den optimalen WAN-Link für die entsprechende Datenverkehrsklasse festzulegen. Nach dem Anlegen solcher Klassen dauerte es jedoch einige Minuten, bis wir sie in den Richtlinien auswählen konnten. Die SD-WAN-Regelwerke empfanden wir insgesamt als sehr leicht und übersichtlich zu konfigurieren.
Direkt im SD-WAN-Bereich standen Werkzeuge für Policing und Shaping des Datenverkehrs zur Verfügung. So beschränkten wir einzelne Clients beispielsweise auf eine maximale Datenrate. Das funktionierte im Test sehr präzise. Zudem ließen sich auch gezielt bestimmte Datenverkehre auf bestimmte maximale Datenraten nach IP-Adressen, Ports, Hostnamen oder Applikationskategorie shapen.
Gute Berichte und Alarmierung
Im Sicherheitsumfeld spielt Sichtbarkeit eine wichtige Rolle. Neben der grafischen Darstellung der Netzwerktopologie sorgte die Clientübersicht mit den jeweilig angewandten Sicherheitsrichtlinien für einen guten Überblick. Dadurch ließ sich leicht prüfen, welcher Client welche Einschränkungen hat. Auch ein allgemeiner Überblick zur Netzwerkverfügbarkeit gibt einen guten ersten Einblick bei eventuellen Problemen. In den Event-Logs fanden wir Link-up/down-Events, IP-Adressänderungen im WAN sowie Content-Filter-Logs. Die Kategorien der Meldungen ließen sich filtern. IDS/IPS-Ereignisse zeigten sich hingegen im Sicherheitscenter, was wir als etwas verwirrend empfanden.
Alarme versendet das System per E-Mail, SMS, Web-Hook oder aus der Meraki-App und der darin integrierten Push-Benachrichtigung. Dies funktionierte im Test ohne Probleme. So sind Alarmierungen beispielsweise für Ausfälle, Qualitätsprobleme im WAN- oder VoIP-Umfeld oder für hohe Auslastungen möglich.
Zudem bot das Meraki-Dashboard ein Packet-Capture-Feature, um Datenverkehr von auszuwählenden Schnittstellen aufzuzeichnen. Wie von tcpdump oder aus Wireshark bekannt, greifen die Aufzeichnungsfilter auf die BPF-Filter-Syntax zurück, um den aufzuzeichnenden Datenverkehr einzuschränken. Die Ausgabe der aufgezeichneten Informationen fand entweder direkt auf der Webseite oder als Download im PCAP-Format statt. Die maximale Aufzeichnungsdauer war jedoch auf eine Stunde begrenzt; wer mehr benötigt, muss also lokal aufzeichnen. Zudem stand der gleiche Link zum Packet Capture an zwei unterschiedlichen Stellen bereit, was etwas verwirrte.
Vordefinierte Rechte und Rollen
Zunächst verwalteten wir die Administratoren der Firewall lokal. Der Login ließ sich auch per Multifaktor-Authentifizierung absichern, was mit TOTP im Test problemlos gelang. Die Privilegien differenzierten sich zunächst zwischen Organisations- und Netzwerkadministratoren. Organisations-Administratoren haben Berechtigungen auf alle Netzwerke, wobei das Dashboard nur zwischen lesender Berechtigung oder Vollberechtigung differenziert. Die Rechte für Netzwerkadmins ließen sich granularer vergeben.
Eigene Privilegien-Level standen im Dashboard nicht zur Verfügung, was wir aber auch nicht als notwendig empfanden. Die vorhandenen Level sind "Monitor-Only", "Read-Only", " Guest Ambassador” und "Full”. Der Monitor-Only-Admin hatte nur Einsicht in den Monitor-Bereich, aber nicht auf die Konfigurationsdaten. Diese standen dem Read-Only-Admin zur Verfügung. Der Guest Ambassador verwaltet Nutzeraccounts für VPN und WLAN und der Vollzugriff via "Full" erklärt sich von selbst. Zusätzlich bot Meraki eine Einschränkung des Zugriffs auf Quell-IP-Adressbereiche sowie die Anbindung eines SAML Identity Providers.
Fazit
Die Meraki MX67 Firewall bot eine sehr übersichtliche und stark vereinfachte zentrale Administration. Dabei ging die Ersteinrichtung sehr schnell vonstatten, doch um die Einfachheit der Administration zu erhalten, hat Meraki auf einige Feinheiten der Parametrisierung verzichtet. Die SD-WAN Leistungsmerkmale überzeugten uns im Test und ließen sich zudem einfach und zügig konfigurieren. In klassisch gerouteten Umgebungen mit OSPF zeigten sich jedoch deutliche Einschränkungen, die IT-Verantwortliche im Design berücksichtigen müssen.
Klassische Firewallfunktionen zur Paketfilterung funktionierten problemfrei. Bei den erweiterten Funktionen wie Geo- und kategoriebasiertem Blocking hätten wir feinere Konfigurationsmöglichkeiten erwartet, um Filter gezielt auf einzelne Subnetze anwenden zu können. Als wünschenswert erachten wir zudem ein retrospektives Firewall-Log mit feineren Filtern. Die einfache Integration von beispielswiese Umbrella für DNS-Filter oder Ciscos XDR überzeugten. Das Fehlen von TLS-Entschlüsselung und E-Mail-Schutz schmälern den guten Eindruck jedoch. Das Preis-Leistungs-Verhältnis ist aus unserer Sicht angemessen. Die Firewall eignet sich für den Einsatz in SOHO-Umgebungen ebenso wie in großen Konzernen mit vielen Standorten.
(jp)
Sicherheitsfeatures |
7 |
Firewallverwaltung |
8 |
SD-WAN |
8 |
Routing-Funktionalität |
5 |
Standortvernetzung über VPN |
7 |
|
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik/
|
|