ACLs und ACEs auf Sophos Switch sicher konfigurieren

Eine Access Control List (ACL) ist auf dem Sophos Switch zunächst ein benannter Regelcontainer. Die einzelnen Access Control Entries (ACEs) bestimmen anhand von MAC-, IPv4- oder IPv6-Merkmalen, ob übereinstimmender Datenverkehr mit Permit weitergeleitet oder mit Deny verworfen wird. Wirksam wird die Liste erst durch ihre Zuordnung unter Port range & binding > Port binding.

Diese letzte Zuordnung ist der kritische Schritt: Auf einem Port mit gebundener ACL verwirft der Switch sämtlichen Verkehr, der zu keiner Regel dieser ACL passt. Eine unvollständige Liste kann deshalb nicht nur Nutzverkehr, sondern auch den Managementpfad unterbrechen. ACL, ACE und Binding werden daher getrennt vorbereitet, kontrolliert und erst danach stufenweise aktiviert.

⚠️ Lockout-Schutz: Nicht am einzigen Uplink, Administratorport oder Managementpfad beginnen. Einen unabhängigen Managementzugang und einen nicht kritischen Testport bereitstellen und die benötigten Managementflows erlauben. Für eine MAC-plus-IP-Bindung gilt zusätzlich der Abschnitt «MAC- und IP-ACL nur nach einem Kombinationstest gemeinsam binden».

Kurzablauf:

Daten- und Managementpfad planen und als Flows erfassen.
Benötigte Portbereiche, ACLs und ACEs erstellen.
Die ungebundene Policy gegen die Flow-Vorlage kontrollieren.
Zuerst eine ACL-Familie am Testport binden und prüfen; eine geplante MAC-plus-IP-Kombination danach am selben Port testen.
Nur den nachgewiesenen Zustand portweise ausrollen.
Bei einer Abweichung das Binding auf den Snapshot vor der betreffenden Stufe zurücksetzen.

ACL, ACE, Portbereich und Binding unterscheiden

ACL: Benannter Container für Regeln einer Familie: MAC, IPv4 oder IPv6. Eine ACL allein filtert noch keinen Port. Der Name muss aus 4 bis 30 Buchstaben und Zahlen bestehen.
ACE: Einzelne Klassifizierungsregel mit Sequence, Action und Match-Feldern. Sequence bestimmt die Verarbeitungsreihenfolge; 1 ist die erste Regel. Pro MAC- oder IPv4-ACL sind bis zu 128 ACEs, pro IPv6-ACL bis zu 64 ACEs möglich.
Port range: Benannter Bereich von Minimum port bis Maximum port für IPv4- und IPv6-ACEs. In der ACE-Auswahl ist nur der Name sichtbar, nicht der enthaltene Bereich. Der Name muss deshalb den Zweck eindeutig erkennen lassen.
Port binding: Zuordnung der vorbereiteten ACLs zu einem physischen Port.

Ein Binding verwirft nicht passenden Verkehr. An einem Port können nicht gleichzeitig eine IPv4- und eine IPv6-ACL gebunden werden. Eine MAC-ACL lässt sich mit einer IP-ACL kombinieren; wie beide gemeinsam ausgewertet werden, dokumentiert Sophos jedoch nicht.

Die drei ACL-Familien prüfen unterschiedliche Merkmale:

MAC ACL: Quell- und Ziel-MAC samt Masken, VLAN-ID, 802.1p-Wert und EtherType bei Ethernet-II-Paketen.
IPv4 ACL: Quell- und Ziel-IP mit Netzmasken, Protokoll, Quell-/Ziel-Portbereich, DSCP über Service type, ICMP-Typ/-Code und TCP-Flags.
IPv6 ACL: Quell- und Ziel-IP mit Präfixlängen, Protokoll, Quell-/Ziel-Portbereich, DSCP, ICMPv6-Typ/-Code und TCP-Flags.

Eine MAC-ACL ist kein Ersatz für eine IP-Policy: Sie kann beispielsweise eine bestimmte MAC-Adresse oder ein VLAN klassifizieren, aber keinen HTTPS-Dienst anhand eines TCP-Zielports. Eine IP-ACL klassifiziert umgekehrt keine MAC-Adresse. Keine dieser Angaben beweist für sich allein die Identität eines Geräts. Die Familie wird nach dem tatsächlich benötigten Match gewählt, nicht nach dem Namen des Endgeräts.

Voraussetzungen und Flow-Vorlage

In Sophos Fusion den betreffenden Switch öffnen und folgende Seite wählen:

My Products > Switches > Switches > [Switch] > Security

Zugriff, Rolle und Lizenz

Für die zentrale Konfiguration muss der Switch in Sophos Fusion verwaltet werden. Pro zentral verwaltetem Switch ist ein Sophos Switch Support and Services-Abonnement erforderlich; eine zusätzliche, nur für ACLs bestimmte Lizenz nennt Sophos nicht. Für eine rein lokale Verwaltung ist dieses Abonnement nicht erforderlich, der folgende Ablauf und seine UI-Labels beziehen sich jedoch auf Sophos Fusion.

Das angemeldete Konto braucht Schreibzugriff auf die Switch-Konfiguration. Die offizielle ACL-Seite nennt dafür keinen bestimmten Rollennamen und keine einzelne Berechtigung. Deshalb nicht pauschal Super Admin voraussetzen: Vor dem Wartungsfenster mit dem vorgesehenen Konto prüfen, dass in allen benötigten Bereichen Add, Edit, Delete, Save und Update entsprechend der geplanten Änderung verfügbar sind. Ein Konto, das die Tabellen nur lesen kann, genügt nicht.

Vor der Änderung werden der aktuelle Tabellenstand und Configuration source für ACLs, ACEs, Portbereiche und Portbindungen dokumentiert. Ausserdem müssen feststehen:

der exakte Switch und die Ports, an denen die ACL gelten soll;
die Verkehrsrichtung und alle tatsächlich über jeden Port laufenden Quell- und Zielsysteme;
VLANs, Quell- und Ziel-MACs beziehungsweise IPv4-/IPv6-Netze;
benötigte Protokolle, TCP-/UDP-Portbereiche, ICMP- beziehungsweise ICMPv6-Funktionen und gegebenenfalls DSCP oder TCP-Flags;
der aktuelle Managementpfad einschliesslich Administratorquelle, Switch-Managementadresse, VLAN, Uplinks und IP-Familie;
weitere betriebliche Abhängigkeiten auf dem Port, etwa Namensauflösung, Zeit, Adressvergabe, Authentisierung, Monitoring und Sophos-Fusion-Konnektivität;
ein nicht kritischer Testport, geeignete Testsysteme, Wartungsfenster und ein unabhängiger lokaler oder separater Managementzugang;
die bisherigen Werte für MAC ACL, IPv4 ACL und IPv6 ACL jedes später geänderten Ports.

Sophos dokumentiert für gebundene ACLs keine Verarbeitungsrichtung. Deshalb nicht allein aus Quell- und Zielbezeichnungen auf Ingress oder Egress schliessen: Anfrage und Antwort eines repräsentativen Flows vor dem produktiven Rollout am Testport prüfen.

Daraus entsteht eine Flow-Vorlage. Jeder Flow hält alle Planwerte direkt untereinander fest. Die getrennten MAC- und IP-Nachweise dürfen auch dann nicht zusammengezogen werden, wenn nur eine Familie gebunden werden soll.

Flow 1: Management

Priorität und Zweck: 1, Managementzugriff erhalten
Quelle und Ziel: freigegebene Administrationsquelle → Switch-Managementadresse
Familie/Protokoll und Dienst: tatsächlich verwendete IP-Familie und Protokoll; Verwaltungsdienst
Erwartetes Ergebnis: weitergeleitet (Permit)
Nachweis MAC-ACL: passende Permit-ACE oder nicht gebunden
Nachweis IPv4- oder IPv6-ACL: passende Permit-ACE oder nicht gebunden

Flow 2: Betriebsdienste

Priorität und Zweck: 2, benötigten Switch-Betrieb erhalten
Quelle und Ziel: betriebliche Systeme → benötigte Infrastrukturziele
Familie/Protokoll und Dienst: gemäss Ist-Aufnahme; DNS, NTP, DHCP, AAA, Monitoring usw. nur soweit über den Port laufend
Erwartetes Ergebnis: weitergeleitet (Permit)
Nachweis MAC-ACL: passende Permit-ACE oder nicht gebunden
Nachweis IPv4- oder IPv6-ACL: passende Permit-ACE oder nicht gebunden

Flow 3: Fachlich erlaubter Verkehr

Priorität und Zweck: 3, fachlich erlaubten Flow zulassen
Quelle und Ziel: fachlich erlaubte Quelle → fachlich erlaubtes Ziel
Familie/Protokoll und Dienst: MAC, IPv4 oder IPv6; freigegebener Dienst
Erwartetes Ergebnis: weitergeleitet (Permit)
Nachweis MAC-ACL: ACE/Sequence oder nicht gebunden
Nachweis IPv4- oder IPv6-ACL: ACE/Sequence oder nicht gebunden

Flow 4: Unerwünschter Testverkehr

Priorität und Zweck: 4, Sperrwirkung kontrollieren
Quelle und Ziel: definierter unerwünschter Testflow → Testziel
Familie/Protokoll und Dienst: gewählte Familie; gesperrter Dienst
Erwartetes Ergebnis: verworfen
Begründung: passende Deny-ACE oder fehlendes Match
Nachweis MAC-ACL: ACE/fehlendes Match oder nicht gebunden
Nachweis IPv4- oder IPv6-ACL: ACE/fehlendes Match oder nicht gebunden

Die Vorlage ist absichtlich keine pauschale Portliste. Welche Management- und Betriebsflows über den später gebundenen Port laufen, ergibt sich aus der eigenen Topologie. Eine Freigabe für einen einzelnen Web-Port deckt nicht automatisch alle Verbindungen des Switches zu Sophos Fusion oder zu betrieblichen Diensten ab.

MAC- und IP-ACL nur nach einem Kombinationstest gemeinsam binden

Sophos dokumentiert nicht, wie eine gleichzeitig gebundene MAC- und IPv4- oder IPv6-ACL gemeinsam ausgewertet wird. Deshalb keine UND-, ODER-, Reihenfolge- oder Pipeline-Semantik voraussetzen.

Zuerst nur eine Familie am nicht kritischen Testport prüfen. Vor dem Hinzufügen der zweiten Familie muss jeder erlaubte Flow in beiden ACLs durch eine passende Permit-ACE abgedeckt sein. Danach exakt die spätere Kombination am Testport prüfen; Einzeltests nicht auf sie hochrechnen. Ohne vollständige Abdeckung oder erfolgreichen Kombinationstest bleibt nur eine ACL-Familie gebunden.

Dual Stack vorab entscheiden

An einem Port lassen sich nicht gleichzeitig eine IPv4- und eine IPv6-ACL binden. Für einen Dual-Stack-Pfad muss deshalb vor dem Rollout entschieden und am Testport nachgewiesen werden, welche IP-ACL-Familie eingesetzt wird und welche Wirkung das Binding auf den Verkehr der jeweils anderen Familie hat. Die Dokumentation beschreibt dieses Verhalten nicht näher. Diese Einschränkung nicht durch schnelles Umschalten während eines produktiven Tests umgehen.

Bei einer IPv6-Policy gehören erforderliche ICMPv6-Funktionen ausdrücklich in die Flow-Vorlage. Die Oberfläche bietet unter anderem Destination Unreachable, Packet Too Big, Time Exceeded, Parameter Problem, Echo Request, Echo Reply, Router Solicitation, Router Advertisement, Nd Ns und Nd Na. Nur benötigte Typen freigeben, aber Neighbor Discovery und Pfad-MTU-Funktionen nicht unbeabsichtigt durch eine unvollständige Liste unterbrechen.

Sichere Beispiele für das Policy-Design

Die folgenden Werte verwenden Dokumentationsadressen und müssen durch den freigegebenen Plan ersetzt werden. Sie zeigen das Prinzip; sie sind keine universell vollständige Management-ACL.

MAC-Masken eindeutig lesen

Bei MAC-Masken bedeutet f, dass die angegebenen Bits exakt übereinstimmen müssen; 0 steht für beliebige Bits.

MAC a1:b2:c3:d4:e5:66 mit Maske ff:ff:ff:ff:ff:ff trifft nur exakt diese Adresse.
MAC a1:b2:c3:d4:e5:66 mit Maske ff:ff:ff:00:00:00 trifft alle MAC-Adressen, die mit a1:b2:c3 beginnen.

Eine OUI-weite Regel ist wesentlich breiter als eine Hostregel. Sie wird nur verwendet, wenn alle Geräte dieses Herstellerbereichs dieselbe Berechtigung erhalten sollen.

IPv4-Testpolicy ohne sofortigen Lockout

Angenommen, 192.0.2.10 ist eine Testquelle, 198.51.100.20 ein Testziel und nur TCP-Zielport 443 soll im ersten Funktionstest gezielt klassifiziert werden:

Einen Portbereich mit eindeutigem Namen, Minimum port 443 und Maximum port 443 anlegen.
Eine IPv4-ACL mit einem Namen wie IPV4TEST01 erstellen.
Eine ACE mit niedriger Sequence, Action: Permit, der freigegebenen Quell-/Zieladresse samt korrekten Host-Netzmasken, Protocol: TCP und dem angelegten Destination port range erstellen.
Alle weiteren gemäss Flow-Vorlage nötigen Permit-Regeln ergänzen. Die UI-Felder nicht leer oder auf vermeintliche Any-Werte setzen, ohne den gespeicherten Eintrag auf dem eingesetzten Firmwarestand geprüft zu haben.
Vor dem Binding sicherstellen, dass für den Test beabsichtigter Restverkehr entweder durch eine bewusst breite, temporäre Permit-Regel abgedeckt ist oder kontrolliert ausfallen darf.
Erst nach dem Positivtest eine temporäre breite Freigabe in einer separaten Änderung verengen. Nach jeder Verengung erneut Management-, Positiv- und Negativtest ausführen.

Die dokumentierte Wirkung des Bindings – nicht passender Verkehr wird verworfen – macht eine zusätzliche pauschale Deny-Regel am Listenende für diesen Effekt nicht erforderlich. Eine explizite Deny-ACE kann trotzdem sinnvoll sein, wenn ein genau definierter Flow gezielt klassifiziert werden soll. Sie darf aber nicht als Ersatz für eine vollständige Permit-Vorlage dienen. Bei überlappenden ACEs ist Sequence zwar die dokumentierte Verarbeitungsreihenfolge; die Dokumentation erläutert jedoch nicht ausdrücklich die Konfliktauflösung. Solche Regeln daher vermeiden oder ihre Wirkung vor dem produktiven Binding gezielt testen.

Portbereiche anlegen

Folgenden Pfad öffnen:

Security > Port range & binding > Port range

Add wählen.
Unter Name einen Zweck statt einer unklaren Nummer eintragen, beispielsweise einen Namen, der Dienst und Portbereich erkennen lässt.
Minimum port als ersten Port des Bereichs eintragen.
Maximum port als letzten Port eintragen. Für einen einzelnen Port sind beide Werte identisch.
Speichern und in der Tabelle Configuration source prüfen.

Da beim späteren Auswählen in einer ACE nur der Name und nicht der enthaltene Bereich sichtbar ist, werden Name, Minimum und Maximum zusätzlich im Change-Ticket festgehalten. Ein bestehender Portbereich wird nicht allein anhand eines ähnlich klingenden Namens wiederverwendet.

ACLs und ACEs erstellen

Für alle drei Familien gilt derselbe Rahmen:

Die passende Seite Security > MAC ACL & ACE, Security > IPv4 ACL & ACE oder Security > IPv6 ACL & ACE öffnen.
Im ACL-Bereich Add wählen, unter Name einen Namen aus 4 bis 30 Buchstaben und Zahlen eingeben und Save wählen.
Profile name und Configuration source kontrollieren.
Im ACE-Bereich Add wählen, die Felder gemäss Flow-Vorlage setzen und Save wählen.
ACL name, Sequence, Action, Match-Felder und Configuration source im gespeicherten Eintrag kontrollieren.

Bestehende Regeln werden mit Edit geändert oder nach Auswahl mit Delete entfernt. Sequence akzeptiert Werte von 1 bis 2147483647; 1 wird zuerst verarbeitet. Abstände wie 10, 20 und 30 lassen Platz für spätere Einfügungen. Bei Action leitet Permit passenden Verkehr weiter, Deny verwirft ihn.

MAC-Felder

ACL name: Ziel-ACL der Regel.
VLAN ID: 1 bis 4094; für jedes VLAN bleibt das Feld leer.
Source MAC address und Source MAC address mask.
Destination MAC address und Destination MAC address mask.
802.1p value: Priorität von 0 bis 7, wobei 0 die niedrigste ist.
EtherType value: Hexadezimaler Protokollwert; nur zur Filterung von Ethernet-II-formatierten Paketen verwendbar.

Pro MAC-ACL sind höchstens 128 ACEs möglich.

IPv4-Felder

ACL name, Sequence (1 bis 2147483647) und Action (Permit oder Deny);
Service type: DSCP-Wert von 0 bis 63;
Source IP address und Source netmask;
Destination IP address und Destination netmask;
Destination port range und Source port range aus den zuvor definierten Portbereichen;
Protocol: Any, Select from a List oder Select from ID mit einer Protocol ID von 0 bis 255;
in der Protokollliste unter anderem IPv4:ICMP, IPinIP, TCP, EGP, IGP, UDP, HMP, RDP, IPv6:Rout, IPv6:Frag, RSVP, IPv6:ICMP, OSPF, PIM und L2TP;
bei ICMP Any, Select from List oder Select from ID mit einer ID von 0 bis 255, ausserdem ICMP code von 0 bis 255;
TCP Flags für Urg, Ack, Psh, Rst, Syn und Fin jeweils als Set, Unset oder Don’t care.

Eine IPv4-ACL enthält maximal 128 ACEs. Portbereiche nur bei einem dazu passenden Transportprotokoll verwenden und TCP-Flags nur setzen, wenn deren Kombination fachlich beabsichtigt und testbar ist.

IPv6-Felder

ACL name, Sequence (1 bis 2147483647) und Action;
Service type als DSCP-Wert von 0 bis 63;
Source IP address und Source IPv6 prefix length;
Destination IP address und Destination IPv6 prefix length;
Destination port range und Source port range;
Protocol: Any, Select from a List mit TCP, UDP oder IPv6:ICMP, oder Select from ID mit einer Protocol ID von 0 bis 255;
bei ICMP Any, Select from List mit einem angebotenen ICMPv6-Typ oder Select from ID mit einer ID von 0 bis 255 sowie ICMP code von 0 bis 255;
die TCP Flags Urg, Ack, Psh, Rst, Syn und Fin als Set, Unset oder Don’t care.

Pro IPv6-ACL sind maximal 64 ACEs möglich. Präfixlängen und notwendige ICMPv6-/Neighbor-Discovery-Flows vor dem Binding nochmals prüfen.

Policy vor dem Binding prüfen

Eine gespeicherte ACL ist noch nicht automatisch sicher. Vor dem ersten Binding diese statischen Punkte abhaken:

Anzahl, Familie, ACL name, Action und aufsteigende Sequence der ACEs mit dem Plan abgleichen; unerwartet breite oder widersprüchliche Kriterien korrigieren.
MAC-Masken Zeichen für Zeichen, IPv4-Netzmasken und IPv6-Präfixlängen kontrollieren.
Bei Portregeln Name sowie dokumentiertes Minimum port und Maximum port abgleichen.
Für jeden erlaubten Flow den Familiennachweis in der Flow-Vorlage prüfen. Bei nur einer gebundenen Familie genügt deren Nachweis; bei MAC plus IP ist je eine passende Permit-ACE in der MAC-ACL und der IP-ACL erforderlich.
Für jeden Negativtest je vorgesehener Familie die passende Deny-ACE oder das fehlende Match als Grund für den erwarteten Drop dokumentieren.
Configuration source aller beteiligten Objekte prüfen. Für jeden Zielport MAC ACL, IPv4 ACL und IPv6 ACL als Ausgangs-Snapshot erfassen.
Den unabhängigen Managementzugang praktisch testen und bestätigen, dass Test- und Produktivport bei einer geplanten Kombination dieselben ACLs erhalten sollen.

ACL kontrolliert an Ports binden

Pfad:

Security > Port range & binding > Port binding

Die Tabelle zeigt Port, MAC ACL, IPv4 ACL, IPv6 ACL und Configuration source.

Zuerst den nicht kritischen Testport eindeutig anhand Portnummer und Verkabelung identifizieren.
Den Ist-Zustand aller drei ACL-Spalten und Configuration source dokumentieren.
Für die erste Stufe nur eine vorgesehene ACL-Familie auswählen. Die anderen ACL-Spalten auf den dokumentierten sicheren Ausgangswert setzen; bestehende wirksame Bindings nicht ohne eigene Wirkungsprüfung überschreiben.
Kontrollieren, dass nicht gleichzeitig eine IPv4- und eine IPv6-ACL gewählt ist; diese Kombination ist nicht möglich.
Update wählen, die Tabelle neu prüfen und sofort Management-, Positiv-, Negativ- sowie Anfrage-/Antworttests ausführen. Währenddessen den bestehenden Managementzugriff in einer separaten Sitzung beobachten.
Falls keine MAC-plus-IP-Kombination vorgesehen ist, erst nach erfolgreichem Test den nächsten Port einzeln binden und erneut prüfen.
Falls MAC plus IPv4 oder IPv6 vorgesehen ist, vor der zweiten Stufe nochmals bestätigen, dass jeder erlaubte Flow eine passende Permit-ACE in beiden Listen besitzt. Dann am selben Testport die zweite ACL hinzufügen und Update wählen.
Den angezeigten Binding-Zustand kontrollieren und mit der exakten Kombination sämtliche Management-, Positiv-, Negativ-, Betriebs- und Anfrage-/Antworttests wiederholen. Die gemeinsame Auswertungssemantik ist nicht dokumentiert; deshalb ersetzt kein Einzeltest diesen Kombinationstest.
Nur die nachgewiesene Kombination auf weitere Ports übertragen, jeden Port einzeln prüfen und niemals von ähnlich benannten oder nur teilweise identischen ACLs hochrechnen.

Schlägt eine Stufe fehl oder weicht das Ergebnis vom Plan ab, keine weitere ACL oder keinen weiteren Port binden. Über den unabhängigen Zugang am zuletzt geänderten Port sofort alle drei ACL-Spalten auf den unmittelbar davor dokumentierten Zustand zurücksetzen, Update wählen und Management- sowie Betriebsverkehr erneut prüfen. Bei der zweiten Stufe bedeutet das insbesondere, die neu hinzugefügte Familie wieder zu entfernen beziehungsweise ihren vorherigen Wert wiederherzustellen; nicht durch weitere ACE-Experimente an der wirksamen Kombination nachbessern.

In der Binding-Auswahl bedeutet None, dass dem Port keine ACL dieser Auswahl zugewiesen wird. Not set verwendet dagegen die Port-Binding-Einstellungen der lokalen Switch-Oberfläche. Diese Werte sind nicht gleichbedeutend: Für einen kontrollierten Rückbau wird der zuvor dokumentierte Zustand wiederhergestellt, nicht pauschal Not set oder None gewählt.

Einen Uplink erst zuletzt ändern. Laufen Management und viele Client-Netze gemeinsam über diesen Port, muss die Flow-Vorlage alle davon betroffenen erlaubten Verbindungen abdecken. Bleibt diese Abdeckung unklar, wird die ACL dort nicht gebunden.

Wirkung nach dem Binding validieren

Erlaubte Flows

Management über den tatsächlich vorgesehenen Pfad und die tatsächlich verwendete IP-Familie erneut aufbauen; eine bereits offene Sitzung allein ist kein ausreichender Beweis.
Jeden erlaubten Flow der Vorlage von der vorgesehenen Quelle zum vorgesehenen Ziel testen.
Bei einer Dienstregel nicht nur Erreichbarkeit des Hosts, sondern genau den freigegebenen Dienst testen.
Betriebsabhängigkeiten wie Adressvergabe, DNS, Zeit, Authentisierung und Monitoring testen, soweit sie über den gebundenen Port laufen.
Bei IPv6 notwendige Neighbor-Discovery-, Router- und Path-MTU-Funktionen im realen Datenpfad prüfen.
Mindestens einen ausdrücklich nicht geänderten Flow kontrollieren, um Seiteneffekte zu erkennen.
Bei einer MAC-plus-IP-Bindung diese beobachtbaren Ergebnisse mit exakt der späteren Kombination erfassen.

Negativtests

Von einer isolierten Testquelle den ausdrücklich gesperrten Flow erzeugen.
Nachweisen, dass genau dieser Flow das Ziel nicht erreicht, während ein erlaubter Vergleichsflow weiterhin funktioniert.
Nicht allein aus einem Timeout auf die ACL schliessen; Quellhost, Zielhost, VLAN, Routing und Dienststatus separat kontrollieren.
Bei einer Deny-Regel zusätzlich prüfen, dass keine breitere erlaubte Nutzung unbeabsichtigt unterbrochen wurde.

Der Rollout ist erst abgeschlossen, wenn die Konfigurationsanzeige geprüft ist und ein neuer Management-Login, alle erlaubten Testflows sowie mindestens ein definierter Negativtest erfolgreich durchgeführt und dokumentiert sind.

Typische Fehlerbilder

Managementzugriff fällt direkt nach dem Binding aus

Keine weiteren Änderungen über denselben unterbrochenen Pfad versuchen.
Den vorbereiteten unabhängigen Zugang verwenden.
Den Stufen-Rückweg aus dem Binding-Ablauf ausführen: über den unabhängigen Zugang den Snapshot vor der fehlgeschlagenen Stufe wiederherstellen und Update wählen.
Danach prüfen, welcher Management- oder Betriebsflow in den ACEs fehlte oder aufgrund falscher Adresse, Maske, Präfixlänge, VLAN-ID, Portbereich oder Protokoll nicht passte.
Die korrigierte ACL erneut nur am Testport erproben.

Erlaubter Dienst funktioniert nicht

Prüfen, ob die ACL tatsächlich am Port dieses Datenpfads gebunden wurde.
ACL name und Sequence der erwarteten Permit-ACE kontrollieren.
Quell- und Zieladresse nicht vertauschen; IPv4-Netzmaske beziehungsweise IPv6-Präfixlänge prüfen.
Bei TCP oder UDP den ausgewählten Source port range und Destination port range unterscheiden.
Den Portbereich anhand der dokumentierten Min-/Max-Werte prüfen, weil in der ACE-Auswahl nur sein Name sichtbar ist.
Protokoll, ICMP-Typ/-Code und TCP-Flags auf zu enge Kriterien untersuchen.
Bei MAC-ACEs VLAN-ID, EtherType und Wildcard-Maske prüfen.
Beachten, dass jeder nicht passende Verkehr am gebundenen Port verworfen wird.
Sind MAC- und IP-ACL gleichzeitig gebunden, auf den letzten funktionierenden Binding-Zustand zurückkehren und die korrigierte exakte Kombination nur am Testport erneut prüfen.

Unerwünschter Verkehr bleibt möglich

Sicherstellen, dass der Test wirklich den gebundenen Port und die gewählte ACL-Familie durchläuft.
Auf überlappende oder zu breite Permit-ACEs prüfen und ihre Sequence-Werte mit der gespeicherten Verarbeitungsreihenfolge abgleichen.
MAC-Masken kontrollieren: Nullen erweitern den Match-Bereich.
Bei IPv4/IPv6 Protocol: Any, breite Netze und zu grosse Portbereiche prüfen.
Kontrollieren, ob Not set ein lokales Binding übernimmt oder None tatsächlich keine ACL zuweist.
Test mit eindeutigem Quell-/Zielpaar und Dienst wiederholen.

IPv6 fällt nach einer IPv4-Änderung aus oder bleibt unkontrolliert

Da IPv4- und IPv6-ACL nicht gleichzeitig an denselben Port gebunden werden können, zuerst den tatsächlichen Tabellenstand unter Port binding prüfen. Danach das vorab festgelegte Dual-Stack-Design wiederherstellen. Nicht versuchen, beide IP-ACLs gleichzeitig auszuwählen. Bei einer IPv6-ACL ausserdem notwendige ICMPv6- und Neighbor-Discovery-Typen kontrollieren.

ACL lässt sich nicht löschen

Enthält eine ACL noch ACEs, zeigt Sophos Fusion eine Warnung. Entweder die ACEs mit Edit in eine andere passende ACL verschieben oder Fix conflicts wählen, die zu entfernenden Einträge markieren und mit Delete dependants die ACEs zusammen mit der ACL löschen. Vorher sicherstellen, dass die ACL an keinem benötigten Port mehr wirksam sein soll. Ein Dependency-Delete ist kein gewöhnlicher Aufräumschritt, sondern entfernt Regeln.

Central-/Fusion-Anzeige und erwartete Wirkung weichen ab

Configuration source bei ACL, ACE, Portbereich und Binding prüfen.
Not set nicht als «keine ACL» interpretieren; es übernimmt die lokale Port-Binding-Einstellung.
Ziel-Switch und Portnummer mit Verkabelungsplan abgleichen.
Nach Save oder Update die Ansicht neu laden und den gespeicherten Zustand prüfen.
Erst nach Klärung der Konfigurationsquelle erneut testen; wiederholtes Speichern behebt keine falsche Policy.

Rollback

Beim Rollback wird zuerst die Wirkung am Port entfernt; die ACL-Objekte bleiben zunächst bestehen.

Binding zurücksetzen

Über den weiterhin funktionierenden oder unabhängigen Managementzugang Security > Port range & binding > Port binding öffnen.
Den zuletzt geänderten Port anhand der dokumentierten Portnummer auswählen.
MAC ACL, IPv4 ACL und IPv6 ACL exakt auf ihre vorherigen Werte zurücksetzen. War vorher bewusst keine ACL zugewiesen, None verwenden; war die lokale Konfiguration führend, den dokumentierten Wert Not set wiederherstellen. Bei einer fehlgeschlagenen zweiten Stufe wird damit insbesondere die neu hinzugefügte Familie entfernt beziehungsweise auf ihren vorherigen Wert gesetzt.
Update wählen und den Tabellenstand samt Configuration source prüfen.
Management, erlaubten Nutzverkehr und Betriebsdienste erneut testen.
Weitere Ports in umgekehrter Rollout-Reihenfolge zurücksetzen.

Einzelne ACE-Änderung zurücknehmen

War nur eine Regeländerung fehlerhaft und der Managementpfad stabil, die ACE unter der passenden MAC ACE, IPv4 ACE oder IPv6 ACE-Ansicht mit Edit auf alle vorherigen Werte zurücksetzen. Eine neu angelegte ACE kann nach eindeutiger Identifikation ausgewählt und mit Delete entfernt werden. Danach Sequenz, Policywirkung und Positiv-/Negativtests wiederholen.

Bei drohendem Lockout nicht zuerst an ACEs experimentieren: Das Binding wird auf den bekannten Ausgangszustand zurückgesetzt. Erst an der dadurch unwirksamen ACL wird anschliessend korrigiert.

Neu angelegte Objekte entfernen

Sicherstellen, dass die betreffende ACL an keinem Port mehr gebunden ist.
Neu angelegte ACEs auswählen und Delete wählen.
Die nun leere ACL auswählen und Delete wählen.
Neu angelegte, nicht mehr verwendete Portbereiche entfernen.
Bei einer Warnung über abhängige ACEs nicht blind Delete dependants wählen, sondern Abhängigkeiten und gewünschte Ziel-ACL zuerst prüfen.
Tabellenstand und Configuration source mit der Ausgangsdokumentation vergleichen.

Nach dem Rollback werden ein neuer Management-Login, die ursprünglichen erlaubten Datenpfade und der Binding-Zustand aller bearbeiteten Ports geprüft. Ursache, fehlende oder zu breite Freigaben, betroffene Ports, Konfigurationsquelle und Testergebnisse gehören in das Change-Ticket, bevor ein neuer Rollout beginnt.