Beim Testen des Warnverhaltens in einer Zugriffsrichtlinie (Internetzugriff) für Cisco Secure Access mit aktiviertem IPS zeigen Benutzer ein unerwartetes Verhalten, bei dem die Warnaktion die IPS-Blockeinstellungen außer Kraft zu setzen scheint. Insbesondere beim Zugriff auf eine URL, die eine IPS-Signatur auslösen soll (SERVER-WEBAPP /etc/passwd file access attempts, GID-SID: 1-1122) wird eine Warnseite angezeigt. Nach der Bestätigung durch den Benutzer wird der Zugriff auf die URL zugelassen, obwohl IPS so konfiguriert ist, dass der Datenverkehr blockiert wird.
Die Konfiguration umfasst:
Aktion: Isolieren
Intrusion Prevention (IPS): Enable
IPS/Baustein
Unterschrift: SERVER-WEBAPP /etc/passwd-Dateizugriffsversuch
GID-SID: 1-1122
Aktivitätssuchprotokolle zeigen in Konflikt stehende Einträge an:
IPS: (IPS: blockieren)
WEB: (WEB: allow - angezeigte Warnseite)
WEB: (WEB: allow - Zugriff nach Warnung)
Produkt: Cisco Secure Internet Access - Vorteile
Technologie: Sicherer Zugriff
Mit Internetzugriff und Warnaktionen konfigurierte Zugriffsrichtlinie
IPS mit Blockierungsaktion für bestimmte Signaturen aktiviert
Dieses Verhalten wurde in Cisco Secure Access als Defekt identifiziert, bei dem die Warnaktion in den Zugriffsrichtlinien Vorrang vor den IPS-Blockeinstellungen hat. Das Problem wirkt sich auf die Interaktion zwischen Warnaktionen für die Zugriffsrichtlinie und der IPS-Sperrfunktion aus.
So überprüfen Sie dieses Verhalten in Ihrer Umgebung:
Schritt 1: Konfigurieren Sie die Zugriffsrichtlinie mit Warnaktion, und aktivieren Sie die IPS-Blockierung:
Legen Sie Aktion auf Isolieren mit Warn-Verhalten fest.
Aktivieren Sie Intrusion Prevention (IPS).
Konfigurieren Sie IPS mit der Aktion "Blockieren".
Anwenden einer bestimmten Signatur (z. B. SERVER-WEBAPP /etc/passwd file access attempts, GID-SID: 1-1122).
Phase 2: Testen Sie die Konfiguration, indem Sie auf eine URL zugreifen, die die IPS-Signatur auslöst:
https://example.com/etc/passwd
Schritt 3: Verhalten beobachten:
Dem Benutzer wird eine Warnseite angezeigt.
Der Benutzer kann fortfahren, nachdem er die Warnung bestätigt hat.
Der Zugriff auf die URL ist trotz IPS-Blockkonfiguration zulässig.
Schritt 4: Aktivitätssuchprotokolle überprüfen:
Überprüfen Sie, ob sowohl der IPS-Block als auch die WEB-Zulassungseinträge vorhanden sind.
Bestätigen Sie die widersprüchlichen Protokolleinträge, die auf den Fehler hinweisen.
Dieses Verhalten wurde als Fehler bestätigt, bei dem die Warnaktion die IPS-Blockeinstellungen in der aktuellen Implementierung per Design überschreibt. Dasselbe Verhalten tritt bei anderen IPS-Signaturen als GID-SID auf: 1-1122 ein, das darauf hinweist, dass es sich bei der Konfiguration von Warnaktionen um ein systemisches Problem handelt, das alle IPS-Signaturen betrifft.
Ein Korrekturplan und ein Zeitplan für diesen Mangel sind noch nicht festgelegt. Unternehmen, die mit diesem Problem konfrontiert sind, sollten ihre Sicherheitsrichtlinien überprüfen und alternative Konfigurationen in Betracht ziehen, wenn eine strikte IPS-Blockierung erforderlich ist.
Die Ursache liegt in einem Fehler in Cisco Secure Access, bei dem die Verarbeitung der Zugriffsrichtlinien-Warnaktion Vorrang vor der IPS-Blockdurchsetzung hat. Dieser Designfehler ermöglicht es Benutzern, die IPS-Sicherheitskontrollen mithilfe des Warnbestätigungsmechanismus zu umgehen und macht die IPS-Blockfunktion praktisch ungültig, wenn Warnaktionen konfiguriert werden.
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
27-Jul-2026
|
Rezertifizierung |
1.0 |
14-Jun-2026
|
Erstveröffentlichung |