Best Practices für sichere Web-Appliances
Inhalt
Einleitung
In diesem Dokument werden die Best Practices für die Konfiguration der Cisco Secure Web Appliance (SWA) beschrieben.
Hintergrundinformationen
Dieser Leitfaden soll als Referenz für die Konfiguration anhand von Best Practices dienen und behandelt viele Aspekte einer SWA-Bereitstellung. Sie umfasst die unterstützte Netzwerkumgebung, die Richtlinienkonfiguration, Überwachung und Fehlerbehebung. Die dokumentierten Best Practices sind zwar für alle Administratoren, Architekten und Betreiber wichtig zu verstehen, stellen jedoch nur Richtlinien dar und müssen entsprechend behandelt werden. Jedes Netzwerk hat seine eigenen spezifischen Anforderungen und Herausforderungen.
Als Sicherheitsgerät kommuniziert der SWA auf verschiedene Weise mit dem Netzwerk. Sie ist Quelle und Ziel von Web-Datenverkehr. Es fungiert gleichzeitig als Webserver und Web-Client. Sie verwendet mindestens IP-Adressen-Spoofing auf Serverseite und Man-in-the-Middle-Techniken, um HTTPS-Transaktionen zu überprüfen. Die Client-IP-Adressen können gefälscht werden, was die Bereitstellung noch komplexer macht und zusätzliche Anforderungen an die Netzwerkkonfigurationen stellt. In diesem Leitfaden werden die häufigsten Probleme im Zusammenhang mit der Konfiguration von Netzwerkgeräten behandelt.
Die Konfiguration der SWA-Richtlinien wirkt sich nicht nur auf die Effektivität der Absicherung und Durchsetzung der Richtlinien aus, sondern auch auf die Leistung der Appliance. In diesem Leitfaden wird erläutert, wie sich die Komplexität einer Konfiguration auf die Systemressourcen auswirkt. Sie definiert Komplexität in diesem Kontext und beschreibt, wie sie im Richtlinienentwurf minimiert werden kann. Darüber hinaus werden spezifische Funktionen und ihre Konfiguration genannt, um die Sicherheit, Skalierbarkeit und Effizienz zu erhöhen.
Im Abschnitt Überwachung und Warnmeldungen dieses Dokuments werden die effektivsten Methoden zur Überwachung der Appliance, Performance und Verfügbarkeit sowie der Nutzung der Systemressourcen erläutert. Darüber hinaus enthält es Informationen zur grundlegenden Fehlerbehebung.
Netzwerkumgebung
ICMP
Path MTU Discovery (MTU-Pfaderkennung), wie in RFC 1191 definiert, bestimmt der Mechanismus die maximale Größe eines Pakets entlang beliebiger Pfade. Mit IPv4 kann ein Gerät die Maximum Transmission Unit (MTU) eines Pakets auf einem Pfad bestimmen, indem es das Don’t Fragment (DF)-Bit im IP-Header des Pakets festlegt. Wenn ein Gerät das Paket an einem Link entlang des Pfads nicht ohne Fragment weiterleiten kann, wird eine ICMP-Nachricht (Internet Control Message Protocol) Fragmentation Needed (Typ 3, Code 4) an die Quelle zurückgesendet. Der Client sendet dann ein kleineres Paket erneut. Dieser Vorgang wird fortgesetzt, bis die MTU für den vollständigen Pfad erkannt wird. IPv6 unterstützt keine Fragmentierung und verwendet eine ICMPv6-Nachricht vom Typ "Packet Too Big" (Zu große Pakete, Typ 2), um anzuzeigen, dass ein Paket nicht über eine bestimmte Verbindung passt.
Da der Prozess der Paketfragmentierung die Leistung eines TCP-Datenflusses erheblich beeinträchtigen kann, verwendet die SWA die MTU-Pfaderkennung. Die genannten ICMP-Meldungen müssen in den entsprechenden Netzwerkgeräten aktiviert werden, damit die SWA die MTU für ihren Pfad durch das Netzwerk bestimmen kann. Dieses Verhalten kann im SWA deaktiviert werden, indem der Befehl pathmtudiscovery in der CLI ausgeführt wird. Auf diese Weise sinkt die Standard-MTU-Größe auf 576 Byte (gemäß RFC 879), was sich erheblich auf die Leistung auswirkt. Der Administrator muss einen zusätzlichen Schritt unternehmen, um die MTU im SWA manuell über den Befehl etherconfig CLI zu konfigurieren.
Im Fall des Web Cache Communication Protocol (WCCP) wird der Web-Datenverkehr von einem anderen Netzwerkgerät entlang des Client-Pfads zum Internet an die SWA umgeleitet. Bei anderen Protokollen wie ICMP werden diese nicht an die SWA umgeleitet. Es besteht die Möglichkeit, dass die SWA von einem Router im Netzwerk eine ICMP-Meldung "Fragmentation Needed" (Fragmentierung erforderlich) auslösen. Die Nachricht wird jedoch nicht an die SWA übermittelt. Wenn dies im Netzwerk möglich ist, muss die MTU-Pfaderkennung deaktiviert werden. Wie bereits erwähnt, ist bei dieser Konfiguration der zusätzliche Schritt des manuellen Einstellens der MTU auf dem SWA durch Ausführen des Befehls etherconfig in der CLI erforderlich.
Firewalls
In einer Standardkonfiguration macht der SWA beim Proxying einer Verbindung keinen Spoofing-Vorgang für die Client-IP-Adresse durch. Dies bedeutet, dass der gesamte ausgehende Internetdatenverkehr von der SWA-IP-Adresse stammt. Sie müssen sicherstellen, dass die Network Address Translation (NAT)-Geräte über einen ausreichenden Pool an externen Adressen und Ports verfügen, um dies zu ermöglichen. Es empfiehlt sich, hierfür eine bestimmte Adresse zu verwenden.
Einige Firewalls verwenden DoS-Schutzmechanismen (Denial-of-Service) oder andere Sicherheitsfunktionen, die ausgelöst werden, wenn eine große Anzahl gleichzeitiger Verbindungen von einer einzigen Client-IP-Adresse ausgeht. Wenn Client-IP-Spoofing nicht aktiviert ist, muss die SWA-IP-Adresse von diesen Schutzmaßnahmen ausgeschlossen werden.
Unicast Reverse Path Forwarding
Die SWA spiegelt die Server-IP-Adresse bei der Kommunikation mit einem Client wider und kann optional so konfiguriert werden, dass die Client-IP-Adresse bei der Kommunikation mit einem Upstream-Server manipuliert wird. Schutzfunktionen wie Unicast Reverse Path Forwarding (uRPF) können auf Switches aktiviert werden, um sicherzustellen, dass ein eingehendes Paket mit dem erwarteten Eingangsport übereinstimmt. Bei diesen Schutzmaßnahmen wird die Quellschnittstelle eines Pakets anhand der Routing-Tabelle überprüft, um sicherzustellen, dass das Paket am erwarteten Port angekommen ist. Die SWA müssen gegebenenfalls von diesen Schutzmaßnahmen ausgenommen werden.
IP-Spoofing mit WCCP
Wenn die IP-Spoofing-Funktion im SWA aktiviert ist, verwenden ausgehende Anfragen die Quelladresse der ursprünglichen Client-Anfrage. Dies erfordert eine zusätzliche Konfiguration der zugehörigen Netzwerkinfrastruktur, um sicherzustellen, dass die Rückgabepakete an die ausgehende SWA-Schnittstelle und nicht an den Client, von dem die Anforderung stammt, weitergeleitet werden.
Wenn WCCP auf einem Netzwerkgerät (Router, Switch oder Firewall) implementiert wird, wird eine Dienst-ID definiert, die den Datenverkehr anhand einer Zugriffskontrollliste (ACL) vergleicht. Die Service-ID wird dann auf eine Schnittstelle angewendet und zur Zuordnung des Datenverkehrs für die Umleitung verwendet. Wenn IP-Spoofing aktiviert ist, muss eine zweite Dienst-ID erstellt werden, um sicherzustellen, dass auch der zurückkehrende Datenverkehr an die SWA umgeleitet wird.
SWA-Netzwerkkonfiguration
Schnittstellen
Das SWA verfügt über fünf Netzwerkschnittstellen: M1, P1, P2, T1 und T2. Diese müssen nach Möglichkeit für ihren jeweiligen Zweck eingesetzt werden. Es ist von Vorteil, jeden Port aus seinen eigenen Gründen zu verwenden. Die M1-Schnittstelle muss mit einem dedizierten Managementnetzwerk verbunden sein, und Split-Routing muss aktiviert sein, um die Belastung durch administrative Services zu begrenzen. Der P1 kann auf den Datenverkehr von Clientanforderungen beschränkt werden, während P2 keine expliziten Proxyanforderungen akzeptieren darf. Dadurch wird der Datenverkehr auf den einzelnen Schnittstellen verringert und das Netzwerkdesign besser segmentiert.
Die T1- und T2-Ports sind für die L4TM-Funktion (Layer 4 Traffic Monitor) verfügbar. Dieser überwacht einen gespiegelten Layer-2-Port und blockiert den Datenverkehr auf Basis einer blockierten Liste bekannter schädlicher IP-Adressen und Domänennamen. Hierzu werden die Quell- und Ziel-IP-Adressen des Datenverkehrs überprüft und ein TCP-Reset-Paket bzw. eine Meldung "Port Unreachable" (Port nicht erreichbar) gesendet, wenn die gesperrte Liste übereinstimmt. Datenverkehr, der mit einem beliebigen Protokoll gesendet wird, kann mit dieser Funktion blockiert werden.
Auch wenn die L4TM-Funktion nicht aktiviert ist, kann die transparente Umgehung verbessert werden, wenn die T1- und T2-Ports an einen gespiegelten Port angeschlossen werden. Im Fall von WCCP kennt der SWA nur die Quell- und Ziel-IP-Adresse eines eingehenden Pakets und muss auf der Grundlage dieser Informationen entscheiden, ob er einen Proxy für das Paket bereitstellt oder es umgeht. Der SWA löst alle Einträge in der Umgehungseinstellungsliste alle 30 Minuten auf, unabhängig von den Datensätzen Time to Live (TTL). Wenn die L4TM-Funktion jedoch aktiviert ist, kann der SWA Snooped-DNS-Abfragen verwenden, um diese Datensätze häufiger zu aktualisieren. Dadurch wird das Risiko eines Fehlalarms in einem Szenario reduziert, in dem der Client eine andere Adresse als den SWA aufgelöst hat.
Management-Netzwerkrouting
Wenn das dedizierte Managementnetzwerk nicht über einen Internetzugang verfügt, kann für jeden Dienst die Verwendung der Datenweiterleitungstabelle konfiguriert werden. Diese kann an die Netzwerktopologie angepasst werden. Im Allgemeinen wird jedoch empfohlen, das Managementnetzwerk für alle Systemdienste und das Datennetzwerk für den Client-Datenverkehr zu verwenden. Ab AsyncOS Version 11.0 kann das Routing für folgende Dienste festgelegt werden:
- DNS
- Active Directory
- Externe URL-Feeds
- Updates und Upgrades
- Dateireputation und -analyse mit Advanced Malware Protection (AMP)
Für eine zusätzliche Ausgangsfilterung des Verwaltungsdatenverkehrs können statische Adressen für die Verwendung in den folgenden Services konfiguriert werden:
Externe URL-Feeds:
1. Benutzerdefiniert; hängt davon ab, wo sie gehostet werden.
2. Reputation und Analyse von AMP-Dateien.
3. cloud-sa.amp.cisco.com (Nordamerika)
4. cloud-sa.eu.amp.cisco.com (Europa)
5. cloud-sa.apjc.amp.cisco.com (Asien-Pazifik-Raum)
Update und Upgrades:
1. downloads-static.ironport.com
2. updates-static.ironport.com
TALOS-Telemetrie
Die Cisco Talos Group ist bekannt für die Identifizierung neuer Bedrohungen. Alle an Talos übermittelten Daten werden anonymisiert und in US-amerikanischen Rechenzentren gespeichert. Die Teilnahme an SensorBase verbessert die Kategorisierung und Identifizierung von webbasierten Bedrohungen und führt zu einem besseren Schutz vor den SWA und anderen Cisco Sicherheitslösungen.
DNS
Nach den Best Practices für die Sicherheit des Domain Name Servers (DNS) muss jedes Netzwerk zwei DNS-Resolver hosten: eine für autoritative Datensätze innerhalb einer lokalen Domäne und eine für die rekursive Auflösung von Internet-Domänen. Um dies zu ermöglichen, lassen die SWAs DNS-Server für bestimmte Domänen konfigurieren. Wenn nur ein DNS-Server für lokale und rekursive Abfragen verfügbar ist, sollten Sie die zusätzliche Last berücksichtigen, die er bei Verwendung für alle SWA-Abfragen hinzufügt. Die bessere Option besteht darin, den internen Resolver für lokale Domänen und den Root-Internet-Resolver für externe Domänen zu verwenden. Dies hängt vom Risikoprofil und der Toleranz des Administrators ab.
Standardmäßig speichern die SWA einen DNS-Eintrag mindestens 30 Minuten im Cache, unabhängig vom TTL des Eintrags. Moderne Websites, die Content Delivery Networks (CDNs) intensiv nutzen, verfügen über niedrige TTL-Werte, da sich ihre IP-Adressen häufig ändern. Dies kann dazu führen, dass ein Client eine IP-Adresse für einen bestimmten Server zwischenspeichert und der SWA eine andere Adresse für denselben Server zwischenspeichert. Um dem entgegenzuwirken, kann die Standard-TTL für SWA von den folgenden CLI-Befehlen auf fünf Minuten herabgesetzt werden:
SWA_CLI> dnsconfig
...
Choose the operation you want to perform:
- NEW - Add a new server.
- EDIT - Edit a server.
- DELETE - Remove a server.
- SETUP - Configure general settings.
- SEARCH - Configure DNS domain search list.
[]> SETUP
...
Enter the minimum TTL in seconds for DNS cache.
...
Sekundäre DNS-Server müssen konfiguriert werden, wenn der primäre Server nicht verfügbar ist. Wenn alle Server mit derselben Priorität konfiguriert sind, wird die Server-IP nach dem Zufallsprinzip ausgewählt. Je nach Anzahl der konfigurierten Server kann die Zeitüberschreitung für einen bestimmten Server variieren. Diese Tabelle gibt den Timeout für eine Abfrage von bis zu sechs DNS-Servern an:
| Anzahl der DNS-Server | Abfragetimeout (in der Sequenz) |
| 1 | 60 |
| 2 | 5, 45 |
| 3 | 5, 10, 45 |
| 4 | 1, 3, 11, 45 |
| 5 | 1, 3, 11, 45, 1 |
| 6 | 1, 3, 11, 45, 1, 1 |
Erweiterte DNS-Optionen sind nur über die CLI verfügbar. Diese Optionen sind in CLI verfügbar, indem der Befehl advanced proxyconfig > DNS ausgeführt wird.
Wählen Sie eine der folgenden Optionen aus:
- 0 - DNS-Antworten immer in der richtigen Reihenfolge verwenden
- 1 - Verwenden Sie die vom Client angegebene Adresse und dann DNS.
- 2 - Eingeschränkte DNS-Nutzung
- 3 - Sehr begrenzte DNS-Nutzung
- Bei den Optionen 1 und 2 wird DNS verwendet, wenn die Webreputation aktiviert ist.
- Bei den Optionen 2 und 3 wird DNS für explizite Proxyanforderungen verwendet. Wenn kein Upstreamproxy vorhanden ist oder der konfigurierte Upstreamproxy fehlschlägt.
- Bei allen Optionen wird DNS verwendet, wenn Ziel-IP-Adressen in der Richtlinienmitgliedschaft verwendet werden.
Diese Optionen steuern, wie der SWA bei der Auswertung einer Client-Anforderung die IP-Adresse festlegt, mit der eine Verbindung hergestellt werden soll. Wenn eine Anforderung empfangen wird, erhält der SWA eine Ziel-IP-Adresse und einen Hostnamen. Der SWA muss entscheiden, ob er der ursprünglichen Ziel-IP-Adresse für die TCP-Verbindung vertrauen oder ob er seine eigene DNS-Auflösung durchführen und die aufgelöste Adresse verwenden möchte. Der Standardwert ist "0 = DNS-Antworten immer in der richtigen Reihenfolge verwenden". Dies bedeutet, dass der SWA dem Client nicht vertraut, um die IP-Adresse anzugeben.
- Option 1 - Der SWA versucht die vom Client bereitgestellte IP-Adresse für die Verbindung, geht jedoch bei einem Fehler auf die aufgelöste Adresse zurück. Die aufgelöste Adresse wird für die Richtlinienbewertung verwendet (Webkategorie, Webreputation usw.).
- Option 2 - Der SWA verwendet nur die vom Client bereitgestellte Adresse für die Verbindung und greift nicht zurück. Die aufgelöste Adresse wird für die Richtlinienbewertung (Webkategorie, Webreputation usw.) verwendet.
- Option 3 - Der SWA verwendet nur die vom Client bereitgestellte Adresse für die Verbindung und greift nicht zurück. Die vom Client bereitgestellte IP-Adresse wird für die Richtlinienbewertung verwendet (Webkategorie, Webreputation usw.).
Die gewählte Option hängt davon ab, wie viel Vertrauen der Administrator dem Client anvertrauen muss, wenn er die aufgelöste Adresse für einen bestimmten Hostnamen ermittelt. Wenn es sich bei dem Client um einen Downstream-Proxy handelt, wählen Sie Option 3 aus, um die zusätzliche Latenz unnötiger DNS-Abfragen zu vermeiden.
Lastenausgleich
WCCP ermöglicht ein transparentes Load Balancing des Datenverkehrs, wenn bis zu acht Appliances verwendet werden. Sie ermöglicht die Verteilung von Datenverkehrsflüssen auf der Grundlage von Hash oder Maske. Sie kann gewichtet werden, wenn im Netzwerk eine Kombination von Appliance-Modellen vorhanden ist, und Geräte können ohne Ausfallzeiten zum Service-Pool hinzugefügt bzw. aus diesem entfernt werden. Bei Verwendung von mindestens 8 SWAs wird ein dedizierter Load Balancer empfohlen.
Die Best Practices für die WCCP-Konfiguration unterscheiden sich je nach verwendeter Plattform. Die Best Practices für Cisco Catalyst® Switches sind im Cisco Catalyst Instant Access Solution-Whitepaper dokumentiert.
Bei Verwendung von WCCP mit einer Cisco Adaptive Security Appliance (ASA) gelten Einschränkungen. Client-IP-Spoofing wird nicht unterstützt. Hinzu kommt, dass sich die Clients und SWA hinter derselben Schnittstelle befinden müssen. Daher ist es flexibler, einen Layer-4-Switch oder -Router zur Umleitung des Datenverkehrs zu verwenden. Die WCCP-Konfiguration auf der ASA-Plattform wird unter WCCP auf ASA beschrieben: Konzepte, Einschränkungen und Konfiguration
Bei expliziten Bereitstellungen stellt eine Proxy Auto-Configuration (PAC)-Datei die am häufigsten bereitgestellte Methode dar. Sie hat jedoch Nachteile und Sicherheitsauswirkungen, die über den Umfang dieses Dokuments hinausgehen. Wenn eine PAC-Datei bereitgestellt wird, wird empfohlen, den Standort mithilfe von Gruppenrichtlinienobjekten (Group Policy Objects, GPOs) zu konfigurieren, anstatt sich auf das Webproxy Auto-Discover Protocol (WPAD) zu verlassen, das ein häufiges Ziel für Angreifer ist und bei falscher Konfiguration leicht ausgenutzt werden kann. Der SWA kann mehrere PAC-Dateien hosten und deren Ablauf im Browser-Cache steuern.
Eine PAC-Datei kann direkt vom SWA über eine konfigurierbare TCP-Portnummer angefordert werden (standardmäßig 9001). Wenn kein Port angegeben ist, kann die Anforderung an den Proxy-Prozess selbst gesendet werden, als handele es sich um eine ausgehende Webanforderung. In diesem Fall ist es möglich, eine bestimmte PAC-Datei basierend auf dem HTTP-Host-Header in der Anfrage bereitzustellen.
Kerberos muss bei Verwendung in einer HA-Umgebung (High Availability) anders konfiguriert werden. Der SWA bietet Unterstützung für Keytab-Dateien, sodass mehrere Hostnamen mit einem Service Principle Name (SPN) verknüpft werden können. Weitere Informationen finden Sie unter Erstellen eines Dienstkontos in Windows Active Directory für die Kerberos-Authentifizierung in Hochverfügbarkeitsbereitstellungen .
Aktive Authentifizierung
Kerberos ist ein sichereres und weit verbreitetes Authentifizierungsprotokoll als der NT LAN Manager Security Support Provider (NTLMSSP). Das Apple OS X-Betriebssystem unterstützt NTLMSSP nicht. Es kann jedoch Kerberos für die Authentifizierung verwenden, wenn eine Domäne hinzugefügt wird. Die Standardauthentifizierung darf nicht verwendet werden, da sie Anmeldeinformationen unverschlüsselt im HTTP-Header sendet und leicht von einem Angreifer im Netzwerk ausgespäht werden kann. Wenn die Standardauthentifizierung verwendet werden muss, muss die Verschlüsselung der Anmeldeinformationen aktiviert werden, um sicherzustellen, dass die Anmeldeinformationen über einen verschlüsselten Tunnel gesendet werden.
Der Konfiguration muss mehr als ein Domain Controller hinzugefügt werden, um die Verfügbarkeit sicherzustellen. Ein Load Balancing dieses Datenverkehrs ist jedoch nicht erforderlich. Der SWA sendet ein TCP-SYN-Paket an alle konfigurierten Domänencontroller, und der erste, der antwortet, wird für die Authentifizierung verwendet.
Der Umleitungshostname, der auf der Seite mit den Authentifizierungseinstellungen konfiguriert wird, bestimmt, wohin ein transparenter Client gesendet wird, um die Authentifizierung abzuschließen. Damit ein Windows-Client die integrierte Authentifizierung abschließen und Single Sign-On (SSO) durchführen kann, muss sich der Umleitungs-Hostname in der Zone "Trusted Sites" (Vertrauenswürdige Sites) in der Systemsteuerung für Internetoptionen befinden. Für das Kerberos-Protokoll muss der vollqualifizierte Domänenname (Fully Qualified Domain Name, FQDN) verwendet werden, um eine Ressource anzugeben. Dies bedeutet, dass der Kurzname (oder der Name "NETBIOS") nicht verwendet werden kann, wenn Kerberos der beabsichtigte Authentifizierungsmechanismus ist. Der FQDN muss den vertrauenswürdigen Sites manuell hinzugefügt werden (z. B. über die Gruppenrichtlinie). Zusätzlich muss die automatische Anmeldung mit Benutzername und Passwort im Internet-Optionen-Bedienfeld eingestellt werden.
In Firefox sind zusätzliche Einstellungen erforderlich, damit der Browser die Authentifizierung mit Netzwerkproxys abschließen kann. Diese Einstellungen können auf der Seite about:config konfiguriert werden. Damit Kerberos erfolgreich abgeschlossen werden kann, muss der Umleitungshostname der Option network.negotiation-auth.trusted-uris hinzugefügt werden. Für NTLMSSP muss sie der Option network.automatic-ntlm-auth.trusted-uris hinzugefügt werden.
Authentifizierungs-Surrogate werden verwendet, um sich einen authentifizierten Benutzer für einen festgelegten Zeitraum nach Abschluss der Authentifizierung zu merken. Es müssen, wann immer möglich, IP-Surrogate verwendet werden, um die Anzahl der aktiven Authentifizierungsereignisse zu begrenzen. Die aktive Authentifizierung eines Clients ist eine ressourcenintensive Aufgabe, insbesondere bei Verwendung von Kerberos. Das Surrogat-Timeout beträgt standardmäßig 3.600 Sekunden (eine Stunde) und kann gesenkt werden, der niedrigste empfohlene Wert beträgt jedoch 900 Sekunden (15 Minuten).
Dieses Bild zeigt, wie "redirect.WSA.lab" als Hostname für die Umleitung verwendet wird:
Passive Authentifizierung
Die SWA können andere Cisco Sicherheitsplattformen nutzen, um Proxy-Benutzer passiv zu identifizieren. Die passive Benutzeridentifizierung macht Authentifizierungsaufforderungen und direkte Active Directory-Kommunikation überflüssig. Dies reduziert die Latenz und die Nutzung von Appliance-Ressourcen. Die derzeit verfügbaren Mechanismen für die passive Authentifizierung werden über den Context Directory Agent (CDA), die Identity Services Engine (ISE) und den passiven Identity Connector (ISE-PIC) des Identity Services Connectors bereitgestellt.
ISE ist ein funktionsstarkes Produkt, mit dem Administratoren ihre Authentifizierungsservices zentralisieren und eine umfassende Netzwerkzugriffskontrolle nutzen können. Wenn die ISE von einem Benutzerauthentifizierungsereignis erfährt (entweder über die Point1x-Authentifizierung oder die Web-Authentifizierungsumleitung), füllt sie eine Sitzungsdatenbank mit Informationen über den Benutzer und das Gerät auf, der bzw. das an der Authentifizierung beteiligt ist. Der SWA stellt über das Platform Exchange Grid (pxGrid) eine Verbindung zur ISE her und bezieht den Benutzernamen, die IP-Adresse und das Security Group Tag (SGT), das mit einer Proxyverbindung verknüpft ist. Seit AsyncOS-Version 11.7 kann der SWA auch den External Restful Service (ERS) auf der ISE abfragen, um Gruppeninformationen abzurufen.
Die empfohlenen Versionen sind ISE 3.1 und SWA 14.0.2-X und höher. Weitere Informationen zur ISE-Kompatibilitätsmatrix für SWA finden Sie unter ISE-Kompatibilitätsmatrix für sichere Web-Appliances. Weitere Informationen zu den Schritten der vollständigen Integration finden Sie im Benutzerhandbuch der Web Security Appliance.
Cisco kündigt das Ende des Lebenszyklus der Cisco Context Directory Agent (CDA)-Software an (siehe Cisco Context Directory Agent (CDA).
Ab CDA Patch 6 ist dies mit Microsoft Server 2016 kompatibel. Administratoren werden jedoch aktiv aufgefordert, ihre CDA-Bereitstellungen auf ISE-PIC zu migrieren. Beide Lösungen verwenden WMI zum Abonnieren des Windows-Sicherheitsereignisprotokolls, um Benutzer-zu-IP-Zuordnungen (Sitzungen) zu generieren. Im Fall von CDA werden die SWA-Abfragen mit RADIUS zugeordnet.
Im Fall von ISE-PIC werden in der vollständigen ISE-Bereitstellung dieselben pxGrid- und ERS-Verbindungen verwendet. Die ISE-PIC-Funktion ist in einer vollständigen ISE-Installation und in einer eigenständigen virtuellen Appliance verfügbar.
Servicekonfiguration
Webproxy
Caching muss in der Webproxy-Konfiguration aktiviert werden, um Bandbreite zu sparen und die Leistung zu steigern. Dies wird umso wichtiger, als der Anteil des HTTPS-Datenverkehrs zunimmt, da HTTPS-Transaktionen standardmäßig nicht im SWA zwischengespeichert werden. Wenn der Proxy nur für explizite Clients bereitgestellt wird, muss der Weiterleitungsmodus angegeben werden, um Datenverkehr abzulehnen, der nicht speziell für den Proxydienst bestimmt ist. Auf diese Weise wird die Angriffsfläche der Appliance reduziert, und es werden Best Practices angewendet (deaktivieren Sie die Appliance, wenn sie nicht benötigt wird).
Bereichsanforderungs-Header werden in HTTP-Anforderungen verwendet, um den Bytebereich einer Datei für den Download anzugeben. Es wird häufig von Betriebssystemen und Daemons für Anwendungsaktualisierungen verwendet, um kleine Teile einer Datei gleichzeitig zu übertragen. Standardmäßig entfernt der SWA diese Header, damit er die gesamte Datei für Antivirus-Scanning, Dateireputation und -analyse und Application Visibility Control (AVC) abrufen kann. Wenn die globale Weiterleitung von Bereichsanforderungs-Headern in den Proxyeinstellungen aktiviert ist, können Administratoren individuelle Zugriffsrichtlinien erstellen, die diese Header weiterleiten oder entfernen. Weitere Informationen zu dieser Konfiguration finden Sie im Abschnitt "Access Policies" (Zugriffsrichtlinien).
HTTPS-Proxy
Empfohlene Sicherheitsverfahren legen nahe, dass private Schlüssel auf der Appliance generiert und niemals woanders hin transportiert werden müssen. Der HTTPS-Proxy-Assistent ermöglicht die Erstellung des Schlüsselpaars und des Zertifikats, das für die Entschlüsselung von TLS-Verbindungen (Transport Layer Security) verwendet wird. Die Zertifikatsanforderung (Certificate Signing Request, CSR) kann von einer internen Zertifizierungsstelle (Certificate Authority, CA) heruntergeladen und unterzeichnet werden. In einer Active Directory (AD)-Umgebung ist dies die beste Methode, da eine AD-integrierte Zertifizierungsstelle automatisch von allen Mitgliedern der Domäne als vertrauenswürdig angesehen wird und keine zusätzlichen Schritte zum Bereitstellen des Zertifikats erforderlich sind.
Eine Sicherheitsfunktion des HTTPS-Proxys ist die Validierung von Serverzertifikaten. Best Practices legen nahe, dass ungültige Zertifikate erfordern, dass die Verbindung getrennt wird. Wenn Sie Entschlüsseln für EUN aktivieren, kann der SWA eine Blockseite mit der Begründung für den Block anzeigen. Wenn diese Option nicht aktiviert ist, führen blockierte HTTPS-Sites zu einem Browserfehler. Dies führt zu einer Erhöhung der Helpdesk-Tickets und der Annahme seitens der Benutzer, dass etwas nicht funktioniert, sondern dass die Verbindung durch die SWA blockiert wurde. Alle ungültigen Zertifikatoptionen müssen mindestens auf Entschlüsseln festgelegt sein. Wenn Sie eine dieser Optionen als Überwachen festlegen, kann das System keine nützlichen Fehlermeldungen protokollieren, wenn Zertifikatprobleme das Laden einer Site verhindern.
Wie beim Online Certificate Services Protocol (OCSP) müssen Prüfungen aktiviert bleiben, und Monitor darf für keine der Optionen verwendet werden. Zurückgezogene Zertifikate müssen gelöscht werden, und alle anderen Zertifikate müssen mindestens auf Entschlüsseln festgelegt sein, damit relevante Fehlermeldungen protokolliert werden können. Authority Information Access Chasing (AIA-Verfolgung): Hier kann ein Client den Unterzeichner des Zertifikats und eine URL ermitteln, unter der zusätzliche Zertifikate abgerufen werden können.
Wenn z. B. eine Zertifikatskette, die von einem Server empfangen wird, unvollständig ist (wenn ein Zwischen- oder Stammzertifikat fehlt), kann der SWA das AIA-Feld überprüfen und es verwenden, um die fehlenden Zertifikate abzurufen und die Authentizität zu überprüfen. Diese Einstellung ist in CLI nur über die folgenden Befehle verfügbar:
SWA_CLI> advancedproxyconfig
Choose a parameter group:
- AUTHENTICATION - Authentication related parameters
- CACHING - Proxy Caching related parameters
- DNS - DNS related parameters
- EUN - EUN related parameters
- NATIVEFTP - Native FTP related parameters
- FTPOVERHTTP - FTP Over HTTP related parameters
- HTTPS - HTTPS related parameters
- SCANNING - Scanning related parameters
- PROXYCONN - Proxy connection header related parameters
- CUSTOMHEADERS - Manage custom request headers for specific domains
- MISCELLANEOUS - Miscellaneous proxy related parameters
- SOCKS - SOCKS Proxy parameters
- CONTENT-ENCODING - Block content-encoding types
- SCANNERS - Scanner related parameters
[]> HTTPS
...
Do you want to enable automatic discovery and download of missing Intermediate Certificates?
[Y]>
...
Anmerkung: Diese Einstellung ist standardmäßig aktiviert und darf nicht deaktiviert werden. Viele moderne Server verlassen sich auf diesen Mechanismus, um eine vollständige Vertrauenskette für Clients bereitzustellen.
Layer-4-Datenverkehrsüberwachung (L4TM)
Mit L4TM kann die Reichweite des SWA auf schädlichen Datenverkehr erweitert werden, der nicht über den Proxy geleitet wird. Außerdem kann der Datenverkehr auf allen TCP- und UDP-Ports einbezogen werden. Die T1- und T2-Ports sind für den Anschluss an eine Netzwerkverbindung oder eine Switch-Monitor-Sitzung vorgesehen. Auf diese Weise kann SWA den gesamten Datenverkehr von Clients passiv überwachen. Wenn Datenverkehr für eine schädliche IP-Adresse erkannt wird, kann der SWA TCP-Sitzungen beenden, indem er eine RST sendet, während er die Server-IP-Adresse manipuliert. Für UDP-Datenverkehr kann eine Nachricht "Port Unreachable" (Port nicht erreichbar) gesendet werden. Bei der Konfiguration der Überwachungssitzung ist es am besten, Datenverkehr, der für die Verwaltungsschnittstelle des SWA bestimmt ist, auszuschließen, um zu verhindern, dass die Funktion den Zugriff auf das Gerät potenziell beeinträchtigt.
Zusätzlich zur Überwachung auf schädlichen Datenverkehr durchsucht L4TM auch DNS-Abfragen, um die Liste der Umgehungseinstellungen zu aktualisieren. Diese Liste wird in WCCP-Bereitstellungen verwendet, um bestimmte Anforderungen für das direkte Routing zum Webserver an den WCCP-Router zurückzugeben. Pakete, die mit der Liste der Umgehungseinstellungen übereinstimmen, werden vom Proxy nicht verarbeitet. Die Liste kann IP-Adressen oder Servernamen enthalten. Der SWA löst alle 30 Minuten alle Einträge in der Umgehungseinstellungsliste auf, unabhängig von der TTL des Datensatzes. Wenn die L4TM-Funktion jedoch aktiviert ist, kann der SWA Snooped-DNS-Abfragen verwenden, um diese Datensätze häufiger zu aktualisieren. Dadurch wird das Risiko eines Fehlalarms in einem Szenario reduziert, in dem der Client eine andere Adresse als den SWA aufgelöst hat.
Richtlinienkonfiguration
Eine korrekte Richtlinienkonfiguration ist für die Leistung und Skalierbarkeit der SWA von zentraler Bedeutung. Effektive Richtlinien schützen die Kunden und setzen die Unternehmensanforderungen durch. Die Richtlinienkonfiguration wirkt sich jedoch auch auf die Ressourcennutzung, die Integrität der Appliances und die Leistung aus. Komplexe oder schlecht konzipierte Richtlinien verursachen Instabilität und verlangsamen die Reaktionsfähigkeit.
Komplexität
Verschiedene politische Elemente werden bei der Erstellung von SWA-Policen verwendet. Die aus der Konfiguration generierte XML-Datei wird zum Erstellen einer Reihe von Back-End-Konfigurationsdateien und Zugriffsregeln verwendet. Je komplexer die Konfiguration, desto mehr Zeit muss der Proxy-Prozess mit der Bewertung verschiedener Regelsätze für jede Transaktion verbringen. Beim Benchmarking und der Bedarfsbestimmung der SWA werden grundlegende Richtlinienelemente erstellt, die drei Komplexitätsstufen der Konfiguration repräsentieren. Eine Konfiguration mit geringer Komplexität umfasst 10 Identitätsprofile, Entschlüsselungsrichtlinien, Zugriffsrichtlinien und benutzerdefinierte Kategorien (die 10 Regex-Einträge, 50 Server-IPs und 420 Hostnamen enthalten). Eine Verdoppelung oder Verdreifachung dieser Werte führt zu Konfigurationen mit mittlerer oder hoher Komplexität.
Wenn eine Konfiguration zu komplex wird, gehören zu den ersten Symptomen in der Regel eine langsame Reaktion in der Webschnittstelle und der CLI. Zunächst kann es keine nennenswerten Auswirkungen auf die Benutzer geben. Je komplexer die Konfiguration ist, desto mehr Zeit muss der Proxy-Prozess im Benutzermodus verbringen. Aus diesem Grund kann die Überprüfung des prozentualen Zeitaufwands in diesem Modus nützlich sein, um eine übermäßig komplexe Konfiguration als Ursache für eine langsame SWA zu diagnostizieren.
Die CPU-Zeit in Sekunden wird im track_stats-Protokoll alle 5 Minuten protokolliert. Dies bedeutet, dass der Benutzerzeitprozentsatz als (Benutzerzeit + Systemzeit)/300 berechnet werden kann. Wenn die Benutzerzeit auf 270 heranrückt, verbraucht der Prozess zu viele CPU-Zyklen im Benutzermodus, und dies ist in der Regel darauf zurückzuführen, dass die Konfiguration zu komplex ist, um effizient analysiert zu werden.
Anmerkung: Der SWA verfügt über die maximale Begrenzung von 60.000 gleichzeitigen Client-Verbindungen und 60.000 gleichzeitigen Server-Verbindungen.
Identifikationsprofile
Die Identifizierungsprofile (ID) sind die ersten Richtlinienelemente, die beim Empfang einer neuen Anforderung ausgewertet werden. Alle im ersten Abschnitt des ID-Profils konfigurierten Informationen werden mit einem logischen AND ausgewertet. Das bedeutet, dass alle Kriterien übereinstimmen müssen, damit die Anfrage dem Profil entspricht. Bei der Erstellung einer Richtlinie muss diese so konkret wie unbedingt erforderlich sein. Profile mit einzelnen Host-Adressen werden nur selten benötigt und können zu umfangreichen Konfigurationen führen. Die Nutzung der User-Agent-Zeichenfolge in den HTTP-Headern, der benutzerdefinierten Kategorieliste oder dem Subnetz ist im Allgemeinen eine bessere Strategie, um den Umfang eines Profils einzuschränken.
Im Allgemeinen werden Richtlinien, die eine Authentifizierung erfordern, am unteren Rand konfiguriert, Ausnahmen am oberen Rand. Bei der Bestellung von Richtlinien, die keine Authentifizierung erfordern, müssen die am häufigsten verwendeten Richtlinien so nah wie möglich am Anfang sein. Verlassen Sie sich nicht auf eine fehlgeschlagene Authentifizierung, um den Zugriff einzuschränken. Wenn sich ein bekannter Client im Netzwerk nicht bei einem Proxy authentifizieren kann, muss er von der Authentifizierung ausgenommen und in den Zugriffsrichtlinien gesperrt werden. Clients, die sich nicht wiederholt authentifizieren können, senden nicht authentifizierte Anfragen an die SWA, die Ressourcen verbrauchen und eine übermäßige CPU- und Speichernutzung verursachen können.
Administratoren werden häufig fälschlicherweise davon ausgegangen, dass ein eindeutiges ID-Profil und die entsprechende Entschlüsselungs- und Zugriffsrichtlinie vorhanden sein müssen. Dies ist eine ineffiziente Strategie für die Richtlinienkonfiguration. Richtlinien müssen nach Möglichkeit "zusammengefasst" werden, damit ein einzelnes ID-Profil mit mehreren Entschlüsselungs- und Zugriffsrichtlinien verknüpft werden kann. So wird sichergestellt, dass alle Kriterien in einer Richtlinie einander entsprechen müssen (sowohl der Datenverkehr als auch die Richtlinie). Im Allgemeinen ermöglichen die Authentifizierungsrichtlinie und die daraus resultierenden Richtlinien insgesamt weniger Richtlinien.
Entschlüsselungsrichtlinien
Wie beim ID-Profil werden die in der Entschlüsselungsrichtlinie festgelegten Kriterien als logisches UND ausgewertet, mit einer wichtigen Ausnahme, wenn Informationen von der ISE verwendet werden. Auf diese Weise erfolgt die Richtlinienanpassung, je nachdem, welche Elemente konfiguriert sind (AD-Gruppe, Benutzer oder SGT):
- AD-Gruppen und -Benutzer - keine Änderung des vorherigen Verhaltens; Die Richtlinie wird zugeordnet, wenn der Benutzer Mitglied einer Gruppe ist ODER wenn der Benutzer in der Richtlinie angegeben ist.
- SGT und AD-Gruppen und -Benutzer - Die Richtlinie wird zugeordnet, wenn der Benutzer mit dem SGT verknüpft ist UND Mitglied der AD-Gruppe ist ODER wenn der Benutzer in der Richtlinie angegeben ist.
- SGT und Benutzer - Die Richtlinie wird zugeordnet, wenn der Benutzer dem SGT zugeordnet ist oder der Benutzer in der Richtlinie angegeben ist.
Von den SWA-Services ist die Auswertung des HTTPS-Verkehrs aus Performance-Sicht am wichtigsten. Der Anteil des entschlüsselten Datenverkehrs hat direkte Auswirkungen auf die Größe der Appliance. Ein Administrator kann sich darauf verlassen, dass mindestens 75 % des Webdatenverkehrs über HTTPS erfolgen wird.
Nach der Erstinstallation muss der Prozentsatz des entschlüsselten Datenverkehrs bestimmt werden, um sicherzustellen, dass die Erwartungen für ein zukünftiges Wachstum richtig definiert sind. Nach der Bereitstellung muss diese Nummer einmal pro Quartal überprüft werden. Der Anteil des entschlüsselten HTTPS-Verkehrs durch die SWA lässt sich mit einer Kopie der access_logs auch ohne zusätzliche Protokollverwaltungssoftware leicht ermitteln. Mit einfachen Bash- oder PowerShell-Befehlen kann diese Zahl abgerufen werden. Nachfolgend finden Sie einige Beispielbefehle für jede Umgebung:
1. Linux-Befehl:
cat aclog.current | grep -Ev "\/407|\/401" | awk 'BEGIN { total=0; decrypt=0; ssl=0;} {total++; if($0 ~ "TCP_CONNECT .*\:443| CONNECT tunnel") ssl++; if($0 ~ "DECRYPT") decrypt++; } END {if(total==0 && ssl==0) exit; print "Total: " total; print "SSL: " ssl; print "Decrypt: " decrypt; print "Percentage (DECRYPT/SSL)..: " (decrypt/ssl)*100.0 "%"; print "Percentage (DECRYPT/TOTAL)..: " (decrypt/total)*100.0 "%";}'2. PowerShell-Befehl:
$lines = Get-Content -Path "aclog.current" | Where-Object { $_ -notmatch "/407|/401" }; $total = 0; $decrypt = 0; $ssl = 0; $lines | ForEach-Object { $total++; if ($_ -match "TCP_CONNECT .*:443| CONNECT tunnel") { $ssl++ }; if ($_ -match "DECRYPT") { $decrypt++ } }; if ($total -ne 0 -or $ssl -ne 0) { Write-Output "Total: $total"; Write-Output "SSL: $ssl"; Write-Output "Decrypt: $decrypt"; if ($ssl -ne 0) { $percentageDecryptSSL = ($decrypt / $ssl) * 100.0; Write-Output "Percentage (DECRYPT/SSL)..: $percentageDecryptSSL%" }; if ($total -ne 0) { $percentageDecryptTotal = ($decrypt / $total) * 100.0; Write-Output "Percentage (DECRYPT/TOTAL)..: $percentageDecryptTotal%" } }Beim Entwerfen von Entschlüsselungsrichtlinien ist es wichtig zu verstehen, wie die verschiedenen in der Richtlinie aufgeführten Aktionen dazu führen, dass die Appliance HTTPS-Verbindungen auswertet. Die Passthrough-Aktion wird verwendet, wenn der Client und der Server jedes Ende ihrer TLS-Sitzung beenden dürfen müssen, ohne dass der SWA jedes Paket entschlüsselt. Selbst wenn ein Standort auf "Passthrough" gesetzt ist, muss der SWA einen TLS-Handshake mit dem Server durchführen. Der SWA muss eine Verbindung aufgrund der Zertifikatsgültigkeit blockieren und eine TLS-Verbindung mit dem Server initiieren, um das Zertifikat zu erhalten. Wenn das Zertifikat gültig ist, schließt der SWA die Verbindung und ermöglicht dem Client, die Sitzung direkt mit dem Server einzurichten.
Der einzige Fall, in dem SWA keinen TLS-Handshake ausführt, ist der Fall, wenn der Servername oder die IP-Adresse in einer benutzerdefinierten Kategorie vorhanden ist. Diese Eigenschaft ist auf "passthrough" gesetzt, und der Servername ist entweder in einer HTTP-VERBINDUNG oder in einem TLS-Client-Hello verfügbar. In einem expliziten Szenario gibt der Client dem Proxy den Hostnamen des Servers vor der TLS-Sitzungsinitiierung (im Host-Header) an, sodass dieses Feld mit der benutzerdefinierten Kategorie abgeglichen wird.
In einer transparenten Bereitstellung überprüft SWA das Feld "Server Name Indication (SNI)" (Servernamen-Angabe) in der Meldung "TLS Client Hello" (TLS-Client hallo) und wertet es anhand der benutzerdefinierten Kategorie aus. Wenn der Host-Header oder SNI nicht vorhanden ist, muss SWA den Handshake mit dem Server fortsetzen, um die Felder Subject Alternative Name (SAN) und Common Name (CN) im Zertifikat (in dieser Reihenfolge) zu überprüfen.
Um die Anzahl der TLS-Handshakes zu reduzieren, legen Sie die vertrauenswürdigen Server in benutzerdefinierten Kategorielisten auf Passthrough fest. Im Gegensatz zu Webkategorien oder Reputationsbewertungen (bei denen die SWA einen TLS-Handshake durchführen muss) wird dadurch der vollständige Handshake umgangen, aber die Überprüfung der Zertifikatsgültigkeit wird verhindert.
Angesichts der Geschwindigkeit, mit der neue Websites im Web erscheinen, ist es wahrscheinlich, dass eine Reihe von Websites von den von SWA verwendeten Datenbanken zu Web-Reputation und Kategorisierung nicht kategorisiert werden. Dies deutet nicht darauf hin, dass die Website eher schädlich ist, und alle diese Websites werden immer noch AV-Scanning, AMP-Dateireputation und -analysen sowie Objektblockierungen unterzogen. Aus diesen Gründen wird nicht empfohlen, nicht kategorisierte Websites zu löschen (in den meisten Fällen). Es ist am besten, diese so einzustellen, dass sie von den AV-Engines entschlüsselt und gescannt und von AVC, AMP, Zugriffsrichtlinien usw. ausgewertet werden. Weitere Informationen zu nicht kategorisierten Sites finden Sie im Abschnitt Zugriffsrichtlinien.
Zugriffsrichtlinien
Wie das ID-Profil werden auch die in der Entschlüsselungsrichtlinie festgelegten Kriterien als logisches UND ausgewertet. Eine wichtige Ausnahme bildet hierbei die Verwendung von Informationen der ISE. Das Verhalten für die Richtlinienzuordnung wird als Nächstes anhand der konfigurierten Elemente (AD-Gruppe, Benutzer oder SGT) erläutert:
- AD-Gruppen und -Benutzer - Keine Änderung des vorherigen Verhaltens, da die Richtlinie zugeordnet wird, wenn der Benutzer Mitglied einer Gruppe ist ODER der Benutzer in der Richtlinie angegeben ist.
- SGT und AD-Gruppen und -Benutzer - Die Richtlinie wird zugeordnet, wenn der Benutzer mit dem SGT verknüpft ist UND Mitglied der AD-Gruppe ist ODER wenn der Benutzer in der Richtlinie angegeben ist.
- SGT und Benutzer - Die Richtlinie wird zugeordnet, wenn der Benutzer mit dem SGT verknüpft ist ODER wenn der Benutzer in der Richtlinie angegeben ist.
Der HTTP-Datenverkehr wird unmittelbar nach der Authentifizierung anhand der Zugriffsrichtlinien ausgewertet. Der HTTPS-Datenverkehr wird nach der Authentifizierung ausgewertet, und es wird geprüft, ob die Entschlüsselungsaktion gemäß der entsprechenden Entschlüsselungsrichtlinie angewendet wird. Für entschlüsselte Anforderungen gibt es zwei access_log -Einträge. Der erste Protokolleintrag zeigt die Aktion an, die auf die anfängliche TLS-Verbindung angewendet wurde (Entschlüsselung), und ein zweiter Protokolleintrag zeigt die Aktion, die von der Zugriffsrichtlinie auf die entschlüsselte HTTP-Anforderung angewendet wurde.
Wie im Webproxy-Abschnitt erläutert, werden Bereichsanforderungs-Header verwendet, um einen bestimmten Bytebereich einer Datei anzufordern. Sie werden häufig von Aktualisierungsdiensten für Betriebssysteme und Anwendungen verwendet. Die SWA entfernen diese Header standardmäßig von ausgehenden Anfragen, da es ohne die gesamte Datei nicht möglich ist, Malware-Scans durchzuführen oder AVC-Funktionen zu nutzen. Wenn viele Hosts im Netzwerk häufig kleine Bytebereiche anfordern, um Updates abzurufen, kann dies dazu führen, dass SWA die gesamte Datei mehrere Male gleichzeitig herunterlädt. Dadurch kann die verfügbare Internetbandbreite schnell erschöpft und es zu Serviceausfällen kommen. Die häufigsten Ursachen für dieses Fehlerszenario sind Microsoft Windows-Updates und Adobe-Software-Update-Daemons.
Die beste Lösung zur Vermeidung dieses Problems besteht darin, den Datenverkehr im SWA vollständig zu steuern. Dies ist in transparent bereitgestellten Umgebungen nicht immer umsetzbar. In diesen Fällen besteht die nächstbeste Option darin, dedizierte Zugriffsrichtlinien für den Datenverkehr zu erstellen und die Weiterleitung von Bereichsanforderungs-Headern für diese Richtlinien zu aktivieren. Sie sollten bedenken, dass AV-Scanning und AVC für diese Anforderungen nicht möglich sind, und die Richtlinien müssen so konzipiert sein, dass sie nur den beabsichtigten Datenverkehr betreffen. Die beste Methode, dies zu erreichen, besteht darin, die Benutzer-Agent-Zeichenfolge im Anforderungsheader abzugleichen. Die Benutzer-Agent-Zeichenfolge für allgemeine Update-Daemons kann online gefunden werden, oder die Anforderungen können von einem Administrator erfasst und geprüft werden. Die meisten Update-Services, einschließlich Microsoft Windows- und Adobe-Software-Updates, verwenden kein HTTPS.
Wie im Abschnitt "Entschlüsselungsrichtlinien" beschrieben, wird nicht empfohlen, nicht kategorisierte Websites in den Entschlüsselungsrichtlinien zu löschen. Aus den gleichen Gründen wird nicht empfohlen, sie in den Zugriffsrichtlinien zu blockieren. Die Dynamic Content Analysis (DCA)-Engine kann den Inhalt einer bestimmten Site zusammen mit anderen heuristischen Daten für kategorisierte Sites verwenden, die durch URL-Datenbanksuchvorgänge als nicht kategorisiert gekennzeichnet würden. Durch die Aktivierung dieser Funktion wird die Anzahl nicht kategorisierter Urteile im SWA reduziert.
Mit den Einstellungen für das Objektscannen einer Zugriffsrichtlinie können verschiedene Archivdateitypen geprüft werden. Wenn das Netzwerk im Rahmen von Anwendungs-Updates regelmäßig Archivdateien herunterlädt, kann die CPU-Auslastung durch die Aktivierung von Archivdateiinspektionen erheblich gesteigert werden. Dieser Datenverkehr muss zuvor ausgenommen und identifiziert werden, wenn alle archivierten Dateien überprüft werden sollen. Der erste Ort, an dem mögliche Methoden zur Identifizierung von Datenverkehr untersucht werden sollten, ist die Zeichenfolge "user-agent", da diese dazu beitragen kann, IP-Zulassungslisten zu vermeiden, deren Verwaltung zu mühsam werden kann.
Benutzerdefinierte und externe URL-Kategorien
Die benutzerdefinierten Kategorielisten werden verwendet, um einen Server nach IP-Adresse oder Hostnamen zu identifizieren. Es ist möglich, reguläre Ausdrücke (regex) zu verwenden, um Muster anzugeben, bei denen Servernamen übereinstimmen. Es ist ressourcenintensiver, ein reguläres Muster für die Übereinstimmung mit einem Servernamen zu verwenden als eine Übereinstimmung mit einer Teilzeichenfolge. Dieser darf nur bei Bedarf verwendet werden. Ein "". kann am Anfang eines Domänennamens hinzugefügt werden, um einer Unterdomäne ohne Verwendung von regex zu entsprechen.
Beispielsweise entspricht ".cisco.com" auch "www.cisco.com". Wie im Abschnitt Komplexität erläutert, wird niedrige Komplexität als 10 benutzerdefinierte Kategorielisten definiert, mittlere Komplexität als 20 und hohe Komplexität als 30. Es wird empfohlen, diese Zahl unter 20 zu halten, insbesondere wenn die Listen reguläre Muster verwenden oder eine große Anzahl von Einträgen enthalten. Weitere Informationen zur Anzahl der Einträge für jeden Typ finden Sie im Abschnitt "Zugriffsrichtlinien".
Externe URL-Feeds sind flexibler als statische benutzerdefinierte Kategorielisten, und ihre Nutzung kann sich direkt auf die Sicherheit auswirken, da sie die manuelle Verwaltung durch einen Administrator überflüssig machen. Diese Funktion kann zum Abrufen von Listen verwendet werden, die nicht von einem SWA-Administrator verwaltet oder gesteuert werden. Die Möglichkeit zum Hinzufügen einzelner Ausnahmen zu heruntergeladenen Adressen wurde in AsyncOS Version 11.8 eingeführt.
Die Office365-API ist nützlich, um bei Richtlinienentscheidungen zu diesem häufig bereitgestellten Dienst zu helfen, und kann für einzelne Anwendungen (PowerPoint, Skype, Word usw.) verwendet werden. Microsoft empfiehlt zur Leistungsoptimierung, Proxys für den gesamten Office365-Datenverkehr zu umgehen. In der Microsoft-Dokumentation heißt es:
Vorsicht: "Während SSL Break and Inspect die größte Latenz verursacht, können andere Services wie Proxy-Authentifizierung und Reputationsprüfung zu Leistungseinbußen und einem schlechten Anwendererlebnis führen. Darüber hinaus benötigen diese Perimeter-Netzwerkgeräte genügend Kapazität, um alle Netzwerkverbindungsanforderungen zu verarbeiten. Wir empfehlen, Ihre Proxy- oder Inspektionsgeräte für direkte Office 365-Netzwerkanforderungen zu umgehen." Weitere Informationen erhalten Sie unter: Management von Microsoft 365-Endgeräten.
Ab AsyncOS Version 11.8 können Sie die dynamische Kategorieliste verwenden, die von der Office365-API abgerufen wurde, um die Umgehungseinstellungsliste aufzufüllen. Die Liste wird verwendet, um umgeleiteten Datenverkehr für das direkte Routing zurück an das WCCP-Gerät zu senden. In einer transparenten Proxyumgebung kann diese Anleitung jedoch schwer zu verwenden sein.
Durch das Umgehen des gesamten Office365-Datenverkehrs wird ein toter Winkel für Administratoren geschaffen, die grundlegende Sicherheitskontrollen und Berichterstellung für den Datenverkehr benötigen. Wenn der Office365-Datenverkehr nicht von der SWA umgangen wird, ist es wichtig, die spezifischen technischen Herausforderungen zu kennen, die auftreten können. Dazu gehört die Anzahl der Verbindungen, die von den Anwendungen benötigt werden. Die Größe muss entsprechend angepasst werden, um die zusätzlichen TCP-Verbindungen zu ermöglichen, die von Office365-Anwendungen benötigt werden. Dadurch kann die Gesamtzahl der Verbindungen zwischen 10 % und 15 % der persistenten TCP-Sitzungen pro Benutzer erhöht werden.
Die vom HTTPS-Proxy ausgeführten Entschlüsselungs- und Wiederverschlüsselungsaktionen führen zu einer geringen Latenz der Verbindungen. Office 365-Anwendungen sind möglicherweise anfällig für Latenz. Wenn sich dies durch andere Faktoren wie langsame WAN-Verbindungen und unterschiedliche geografische Standorte noch verschärft, kann dies zu einer Beeinträchtigung der Benutzerfreundlichkeit führen.
Einige Office365-Anwendungen verwenden proprietäre TLS-Parameter, die verhindern, dass der HTTPS-Proxy einen Handshake mit dem Anwendungsserver abschließt. Dies ist erforderlich, um das Zertifikat zu validieren oder den Hostnamen abzurufen. In Kombination mit einer Anwendung wie Skype for Business wird dadurch kein Feld für die Server-Namensangabe (SNI) in der TLS-Client-Hello-Nachricht gesendet. Sie müssen diesen Datenverkehr vollständig umgehen. Mit AsyncOS v11.8 wurde die Möglichkeit eingeführt, Datenverkehr nur basierend auf der Ziel-IP-Adresse zu umgehen, ohne dass in diesem Szenario Zertifikatprüfungen durchgeführt werden müssen.
Monitore und Warnmeldungen
CLI-Monitore
Die SWA-CLI stellt Befehle für die Echtzeitüberwachung wichtiger Prozesse bereit. Einige nützliche Befehle zeigen Statistiken zum Proxy-Prozess an. Die Ausführung des Befehls status detail ist eine gute Quelle für eine Zusammenfassung der Ressourcennutzung und Leistungsmetriken, einschließlich Betriebszeit, genutzte Bandbreite, Reaktionslatenz, Anzahl der Verbindungen usw.
Dies ist eine Beispielausgabe:
SWA_CLI> status detail
Status as of: Fri Nov 11 14:06:52 2022 +03
Up since: Fri Apr 08 10:15:00 2022 +03 (217d 3h 51m 52s)
System Resource Utilization:
CPU 3.3%
RAM 6.2%
Reporting/Logging Disk 45.6%
Transactions per Second:
Average in last minute 55
Maximum in last hour 201
Average in last hour 65
Maximum since proxy restart 1031
Average since proxy restart 51
Bandwidth (Mbps):
Average in last minute 4.676
Maximum in last hour 327.258
Average in last hour 10.845
Maximum since proxy restart 1581.297
Average since proxy restart 11.167
Response Time (ms):
Average in last minute 635
Maximum in last hour 376209
Average in last hour 605
Maximum since proxy restart 2602943
Average since proxy restart 701
Cache Hit Rate:
Average in last minute 0
Maximum in last hour 2
Average in last hour 0
Maximum since proxy restart 15
Average since proxy restart 0
Connections:
Idle client connections 186
Idle server connections 184
Total client connections 3499
Total server connections 3632
SSLJobs:
In queue Avg in last minute 4
Average in last minute 45214
SSLInfo Average in last min 94
Network Events:
Average in last minute 0.0
Maximum in last minute 35
Network events in last min 124502Wenn Sie den Befehl rate ausführen, werden Echtzeitinformationen über den Prozentsatz der vom Proxyprozess verwendeten CPU, die Anzahl der Anforderungen pro Sekunde (RPS) und Cache-Statistiken angezeigt. Mit diesem Befehl werden neue Ausgaben abgefragt und angezeigt, bis sie unterbrochen werden. Dies ist eine Beispielausgabe:
SWA_CLI> rate
Press Ctrl-C to stop.
%proxy reqs client server %bw disk disk
CPU /sec hits blocks misses kb/sec kb/sec saved wrs rds
5.00 51 1 147 370 2283 2268 0.6 48 37
4.00 36 0 128 237 21695 21687 0.0 47 38
4.00 48 2 179 307 8168 8154 0.2 65 33
5.00 53 0 161 372 2894 2880 0.5 48 32
6.00 52 0 198 328 15110 15100 0.1 63 33
6.00 77 0 415 363 4695 4684 0.2 48 34
7.00 85 1 417 433 5270 5251 0.4 49 35
7.00 67 1 443 228 2242 2232 0.5 85 44Wenn Sie den Befehl tcpservices ausführen, werden Informationen zu ausgewählten Prozess-Listening-Ports angezeigt. Außerdem wird eine Erläuterung der einzelnen Prozesse, der Adresse und der Port-Kombination angezeigt:
SWA_CLI> tcpservices
System Processes (Note: All processes may not always be present)
ftpd.main - The FTP daemon
ginetd - The INET daemon
interface - The interface controller for inter-process communication
ipfw - The IP firewall
slapd - The Standalone LDAP daemon
sntpd - The SNTP daemon
sshd - The SSH daemon
syslogd - The system logging daemon
winbindd - The Samba Name Service Switch daemon
Feature Processes
coeuslogd - Main WSA controller
gui - GUI process
hermes - Mail server for sending alerts, etc.
java - Processes for storing and querying Web Tracking data
musd - AnyConnect Secure Mobility server
pacd - PAC file hosting daemon
prox - WSA proxy
trafmon - L4 Traffic Monitor
uds - User Discovery System (Transparent Auth)
wccpd - WCCP daemon
COMMAND USER TYPE NODE NAME
connector root IPv4 TCP 127.0.0.1:8823
java root IPv6 TCP [::127.0.0.1]:18081
hybridd root IPv4 TCP 127.0.0.1:8833
gui root IPv4 TCP 172.16.40.80:8443
ginetd root IPv4 TCP 172.16.40.80:ssh
nginx root IPv6 TCP *:4431
nginx root IPv4 TCP 127.0.0.1:8843
nginx nobody IPv6 TCP *:4431
nginx nobody IPv4 TCP 127.0.0.1:8843
nginx nobody IPv6 TCP *:4431
nginx nobody IPv4 TCP 127.0.0.1:8843
api_serve root IPv4 TCP 172.16.40.80:6080
api_serve root IPv4 TCP 127.0.0.1:60001
api_serve root IPv4 TCP 172.16.40.80:6443
chimera root IPv4 TCP 127.0.0.1:6380
nectar root IPv4 TCP 127.0.0.1:6382
redis-ser root IPv4 TCP 127.0.0.1:6383
redis-ser root IPv4 TCP 127.0.0.1:6379
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:25255
prox root IPv4 TCP 127.0.0.1:socks
prox root IPv6 TCP [::1]:socks
prox root IPv4 TCP 172.16.11.69:socks
prox root IPv4 TCP 172.16.11.68:socks
prox root IPv4 TCP 172.16.11.252:socks
prox root IPv4 TCP 127.0.0.1:ftp-proxy
prox root IPv6 TCP [::1]:ftp-proxy
prox root IPv4 TCP 172.16.11.69:ftp-proxy
prox root IPv4 TCP 172.16.11.68:ftp-proxy
prox root IPv4 TCP 172.16.11.252:ftp-proxy
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.16.11.69:https
prox root IPv4 TCP 172.16.11.68:https
prox root IPv4 TCP 172.16.11.252:https
prox root IPv4 TCP 127.0.0.1:25256
prox root IPv4 TCP 127.0.0.1:http
prox root IPv6 TCP [::1]:http
prox root IPv4 TCP 172.16.11.69:http
prox root IPv4 TCP 172.16.11.68:http
prox root IPv4 TCP 172.16.11.252:http
prox root IPv4 TCP 127.0.0.1:3128
prox root IPv6 TCP [::1]:3128
prox root IPv4 TCP 172.16.11.69:3128
prox root IPv4 TCP 172.16.11.68:3128
prox root IPv4 TCP 172.16.11.252:3128
prox root IPv4 TCP 127.0.0.1:https
prox root IPv6 TCP [::1]:https
prox root IPv4 TCP 172.21.11.69:https
prox root IPv4 TCP 172.21.11.68:https
prox root IPv4 TCP 172.21.11.252:https
prox root IPv4 TCP 127.0.0.1:25257
smart_age root IPv6 TCP [::127.0.0.1]:65501
smart_age root IPv6 TCP [::127.0.0.1]:28073
interface root IPv4 TCP 127.0.0.1:domain
stunnel root IPv4 TCP 127.0.0.1:32137Protokollieren
Der Web-Datenverkehr ist äußerst dynamisch und vielfältig. Nachdem die Proxy-Bereitstellung abgeschlossen ist, müssen Menge und Zusammensetzung des Datenverkehrs, der durch die Appliance geleitet wird, regelmäßig überprüft werden. Sie müssen den Anteil des entschlüsselten Datenverkehrs regelmäßig (einmal pro Quartal) überprüfen, um sicherzustellen, dass die Größe den Erwartungen und Spezifikationen der Erstinstallation entspricht. Dies kann mit einem Protokollverwaltungsprodukt wie Advanced Web Security Reporting (AWSR) oder mit Bash- oder PowerShell-Befehlen mit Zugriffsprotokollen erfolgen. Die Anzahl der RPS muss regelmäßig überprüft werden, um sicherzustellen, dass die Appliance genügend Overhead hat, um Datenverkehrsspitzen und ein mögliches Failover in einer hochverfügbaren Konfiguration mit Lastausgleich zu berücksichtigen.
Das track_stats-Protokoll wird alle fünf Minuten angehängt und enthält mehrere Abschnitte der Ausgabe, die direkt mit dem Proxy-Prozess und seinen Objekten im Speicher in Zusammenhang stehen. Bei der Leistungsüberwachung umfassen die durchschnittlichen Latenzanforderungsprozesse die DNS-Suchzeit, die AV-Engine-Suchzeit und viele weitere nützliche Felder. Dieses Protokoll kann nicht über die GUI oder die CLI konfiguriert werden und ist nur über Secure Copy Protocol (SCP) oder File Transfer Protocol (FTP) zugänglich. Dies ist ein wichtiges Protokoll für die Fehlerbehebung, da es regelmäßig abgefragt werden muss.
Eine einzelne SHD-Protokollzeile wird alle 60 Sekunden geschrieben und enthält Felder, die für die Leistungsüberwachung wichtig sind, einschließlich Latenz, RPS, der gesamten clientseitigen und serverseitigen Verbindungen. Dies ist ein Beispiel für eine SHD-Protokollzeile:
Fri Nov 11 14:16:42 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 62 Band 11383 Latency 619 CacheHit 0 CliConn 3817 SrvConn 3804 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:17:42 2022 Info: Status: CPULd 2.6 DskUtil 45.7 RAMUtil 6.7 Reqs 55 Band 10532 Latency 774 CacheHit 0 CliConn 3546 SrvConn 3539 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:18:43 2022 Info: Status: CPULd 1.9 DskUtil 45.7 RAMUtil 6.6 Reqs 48 Band 7285 Latency 579 CacheHit 0 CliConn 3418 SrvConn 3410 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:19:43 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.6 Reqs 52 Band 34294 Latency 791 CacheHit 0 CliConn 3605 SrvConn 3586 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:20:43 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 55 Band 8696 Latency 691 CacheHit 0 CliConn 3455 SrvConn 3432 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:21:43 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.7 Reqs 49 Band 7064 Latency 1403 CacheHit 0 CliConn 3339 SrvConn 3330 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:22:43 2022 Info: Status: CPULd 1.9 DskUtil 45.7 RAMUtil 6.8 Reqs 41 Band 5444 Latency 788 CacheHit 0 CliConn 3227 SrvConn 3212 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:23:43 2022 Info: Status: CPULd 2.2 DskUtil 45.7 RAMUtil 6.8 Reqs 48 Band 6793 Latency 820 CacheHit 0 CliConn 3280 SrvConn 3265 MemBuf 1 SwpPgOut 250467 ProxLd 3 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:24:44 2022 Info: Status: CPULd 2.3 DskUtil 45.7 RAMUtil 6.7 Reqs 44 Band 8735 Latency 673 CacheHit 0 CliConn 3405 SrvConn 3389 MemBuf 1 SwpPgOut 250467 ProxLd 5 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0
Fri Nov 11 14:25:44 2022 Info: Status: CPULd 2.4 DskUtil 45.7 RAMUtil 6.7 Reqs 53 Band 8338 Latency 731 CacheHit 0 CliConn 3637 SrvConn 3622 MemBuf 1 SwpPgOut 250467 ProxLd 4 Wbrs_WucLd 0.0 LogLd 0.0 RptLd 0.0 WebrootLd 0.0 SophosLd 0.0 McafeeLd 0.0 WTTLd 0.0 AMPLd 0.0Den access_logs können weitere benutzerdefinierte Felder hinzugefügt werden, die Latenzinformationen für einzelne Anforderungen angeben. Zu diesen Feldern gehören Serverantwort, DNS-Auflösung und AV-Scanner-Latenz. Die Felder müssen dem Protokoll hinzugefügt werden, um nützliche Informationen für die Fehlerbehebung zu erhalten. Dies ist die empfohlene benutzerdefinierte Feldzeichenfolge:
[ Request Details: ID = %I, User Agent = %u, AD Group Memberships = ( %m ) %g ] [ Tx Wait Times (in ms): 1st byte to server = %:<1, Request Header = %:, Response Header = %:h>, Client Body = %:b> ] [ Rx Wait Times (in ms): 1st request byte = %:1<, Request Header = %:h<, Client Body = %:b<, 1st response byte = %:>1, Response header = %:>h, Server response = %:>b, Disk Cache = %:>c; Auth response = %:a; DNS response = %:d, WBRS response = %:r, AVC response = %:A>, AVC total = %:A<, DCA response = %:C>, DCA total = %:C<, McAfee response = %:m>, McAfee total = %:m<, Sophos response = %:p>, Sophos total = %:p<, Webroot response = %:w>, Webroot total = %:w<, Anti-Spyware response = %:s, AMP response = %:e>, AMP total = %:e<; Latency = %x; %L ][Client Port = %F, Server IP = %k, Server Port = %p] Aus diesen Werten abgeleitete Leistungsinformationen werden in der folgenden Tabelle aufgelistet:
| Benutzerdefiniertes Feld | Beschreibung |
| %:<a | Die Wartezeit, bis die Antwort vom Webproxy-Authentifizierungsprozess empfangen wird, nachdem der Webproxy die Anforderung gesendet hat. |
| %:<b | Wartezeit, bis nach dem Header ein Anforderungstext auf den Server geschrieben wird. |
| %:<d | Die Wartezeit, bis die Antwort vom DNS-Prozess des Webproxys empfangen wird, nachdem der Webproxy die Anforderung gesendet hat. |
| %:<h | Wartezeit, bis nach dem ersten Byte ein Anforderungsheader auf den Server geschrieben wird. |
| %:<r | Die Wartezeit, bis die Webreputationsfilter eine Antwort erhalten, nachdem der Webproxy die Anforderung gesendet hat. |
| %:<s | Warten Sie, bis das Urteil des Anti-Spyware-Prozesses für den Webproxy eingegangen ist, nachdem der Webproxy die Anforderung gesendet hat. |
| %:> | Wartezeit auf das erste Antwortbyte vom Server. |
| %:>a | Wartezeit bis zum Empfang der Antwort vom Webproxy-Authentifizierungsprozess. Enthält die Zeit, die der Webproxy benötigt, um die Anforderung zu senden. |
| %:>b | Wartezeit auf den vollständigen Antworttext, nachdem der Header empfangen wurde. |
| %:>c | Die Zeit, die der Webproxy benötigt, um eine Antwort aus dem Festplatten-Cache zu lesen. |
| %:>d | Wartezeit, bis die Antwort vom Webproxy-DNS-Prozess empfangen wird. Enthält die Zeit, die der Webproxy benötigt, um die Anforderung zu senden. |
| %:>h | Wartezeit für den Server-Header nach dem ersten Antwortbyte. |
| %:>r | Wartezeit, bis das Urteil der Web-Reputationsfilter vorliegt. Enthält die Zeit, die der Webproxy benötigt, um die Anforderung zu senden. |
| %:>s | Wartezeit, bis das Urteil vom Anti-Spyware-Prozess des Webproxys eingeht. Enthält die Zeit, die der Webproxy benötigt, um die Anforderung zu senden. |
| %:1< | Wartezeit für das erste Anforderungsbyte einer neuen Clientverbindung. |
| %:1> | Wartezeit für das erste auf einen Client geschriebene Byte. |
| %:b< | Wartezeit auf vollständigen Client-Text. |
| %:b> | Wartezeit auf den gesamten Textkörper, der auf einen Client geschrieben wurde. |
| %:e> | Wartezeit bis zum Empfang der Antwort vom AMP-Scanmodul, nachdem der Webproxy die Anforderung gesendet hat. |
| %:e< |
Wartezeit bis zum Empfang des Urteils von der AMP-Scan-Engine. Enthält die Zeit, die der Webproxy benötigt, um die Anforderung zu senden. |
| %:h< | Wartezeit für den gesamten Client-Header nach dem ersten Byte. |
| %:h> | Wartezeit auf den vollständigen Header, der auf einen Client geschrieben wurde. |
| %:m< | Wartezeit, bis das Urteil vom McAfee-Scanmodul eingeht. Enthält die Zeit, die der Webproxy benötigt, um die Anforderung zu senden. |
| %:m> | Wartezeit, bis die Antwort vom McAfee-Scanmodul empfangen wird. Nachdem der Webproxy die Anforderung gesendet hat. |
| %F | Client-Quellport. |
| %p | Webserver-Port. |
| %k | IP-Adresse der Datenquelle (Webserver-IP-Adresse). |
| %:w< | Wartezeit, bis das Urteil der Webroot-Scan-Engine vorliegt. Enthält die Zeit, die der Webproxy benötigt, um die Anforderung zu senden. |
| %:w> | Wartezeit, bis die Antwort vom Webroot-Scanmodul empfangen wird. Nachdem der Webproxy die Anforderung gesendet hat. |
Das SWA-Lizenzmodell ermöglicht die Wiederverwendung von Lizenzen für physische Appliances für virtuelle Appliances. Sie können diese nutzen und Test-SWAv-Appliances für den Einsatz in einer Laborumgebung bereitstellen. Neue Funktionen und Konfigurationen können per Pilotprojekt implementiert werden, um Stabilität und Zuverlässigkeit zu gewährleisten, ohne dass Lizenzbedingungen verletzt werden.
Advanced Web Security Reporting (AWSR)
AWSR muss genutzt werden, um Berichtsdaten von SWA sicherzustellen, insbesondere in Umgebungen, in denen viele SWAs bereitgestellt werden. Diese Lösung ist skalierbarer als die Verwendung einer zentralisierten Berichterstellung auf einer Security Management Appliance (SMA) und bietet benutzerdefinierte Berichterstellungsattribute, die die Tiefe und Anpassung Ihrer Daten erhöhen. Die Berichte können gruppiert und an die Anforderungen jedes Unternehmens angepasst werden. Die Cisco Advanced Services Group muss bei der Bedarfsbestimmung für AWSR berücksichtigt werden.
E-Mail-Benachrichtigung
Das integrierte E-Mail-Warnsystem der SWA lässt sich am besten als Basiswarnsystem einsetzen. Sie muss entsprechend den Anforderungen des Administrators angepasst werden, da es bei Aktivierung aller Informationsereignisse zu Geräuschen kommen kann. Es ist wichtig, die Warnungen einzuschränken und aktiv zu überwachen, als alles zu warnen und als Spam zu ignorieren.
| Warnmeldungseinstellungen | Konfiguration |
| Von Adresse, die beim Senden von Warnungen verwendet wird | Automatisch generiert |
| Anfängliche Wartezeit in Sekunden bis zum Senden einer doppelten Warnung | 300 Sekunden |
| Maximale Dauer in Sekunden, die gewartet wird, bevor ein Alert-Doppel gesendet wird | 3600 Sekunden |
Verfügbarkeitsüberwachung
Es gibt zwei Methoden zur Überwachung der Verfügbarkeit eines Webproxys.
- Die erste ist die Layer-3-Überwachung (L3), bei der getestet wird, ob die IP-Adresse der Appliance im Netzwerk erreichbar ist. Der einfachste Weg, dies zu testen, besteht darin, eine ICMP-Echo-(Ping-)Anfrage in regelmäßigen Abständen an die Adresse zu senden und nach einem Antwortpaket zu suchen. Die Attribute der Antwort, z. B. TTL, und die Latenz können analysiert werden, um den Zustand der Netzwerkschicht zu bestimmen.
- Es ist möglich, dass ein Gerät auf Pings reagiert, die Proxy-Prozesse jedoch nicht oder nur zeitweilig. Sollte dies der Fall sein, empfiehlt es sich, einen Layer-7-Monitor (L7) hinzuzufügen, der eine explizite Proxyanforderung an die Appliance sendet und einen 200 OK-HTTP-Antwortcode erwartet. Dabei werden die Erreichbarkeit der Netzwerkschnittstelle, die Reaktionsfähigkeit der Proxydienste und die Funktionsfähigkeit der Upstream-Dienste bei Anforderung einer externen Ressource getestet. Diese Art der Überwachung erfolgt in der Regel in Form einer expliziten HTTP-HEAD-Anforderung, die den Proxy auffordert, eine Verbindung mit einer Ressource herzustellen. Die HEAD-Methode fordert die zurückzugebenden Header an, und der Client muss eine GET-Anforderung senden. Dies gilt nur für die Antwort-Header ohne Daten.
- Wenn Sie ein L7-Überwachungstool oder -skript verwenden, stellen Sie sicher, dass der Datenverkehr nicht authentifiziert wird. Andernfalls kann es zu Authentifizierungsfehlern und zur Auslastung von Ressourcen kommen. Wenn Sie im Überwachungstool eine benutzerdefinierte Benutzer-Agent-Zeichenfolge verwenden, muss diese zum Identifizieren von Datenverkehr verwendet werden. Während der Datenverkehr von der Authentifizierung ausgenommen ist, kann er dennoch durch die Zugriffsrichtlinien auf unnötigen Internetzugriff beschränkt werden.
Wenn Sie eine oder mehrere dieser Methoden verwenden, muss ein Administrator eine Baseline akzeptabler Metriken für die Proxyantwort erstellen und diese zum Erstellen von Warnmeldungsschwellenwerten verwenden.
SNMP-Überwachung
Das Simple Network Management Protocol (SNMP) ist die wichtigste Methode zur Überwachung des Systemzustands der Appliance. Er kann verwendet werden, um Warnungen von der Appliance zu empfangen (Traps) oder um verschiedene Objektkennungen (OIDs) abzufragen, um Informationen zu sammeln. Es gibt viele OIDs für die SWA, die die Nutzung von Hardware und Ressourcen für einzelne Prozesse und statistische Informationen detailliert beschreiben.
Es gibt eine Reihe spezifischer Machine Information Base (MIB), die aus Hardware- und leistungsbezogenen Gründen überwacht werden müssen. Weitere Informationen finden Sie in der vollständigen Liste der MIBs.
Die folgende Liste enthält die empfohlenen MIBs für die Überwachung:
| Hardware-OID | Name |
| 1.3.6.1.4.1.15497.1.1.1.18.1.3 | RAID-ID |
| 1.3.6.1.4.1.15497.1.1.1.18.1.2 | RAID-Status |
| 1.3.6.1.4.1.15497.1.1.1.18.1.4 | raidLetzterFehler |
| 1.3.6.1.4.1.15497.1.1.1.10 | Lüftertabelle |
| 1.3.6.1.4.1.15497.1.1.1.9.1.2 | Grad Celsius |
Diese OIDs werden direkt der Ausgabe des CLI-Befehls status detail zugeordnet:
| OID | Name | Statusdetailfeld |
| Systemressourcen | ||
| 1.3.6.1.4.1.15497.1.1.1.2.0 | proCentCPU-Auslastung | CPU |
| 1.3.6.1.4.1.15497.1.1.1.1.0 | perCentSpeicherauslastung | RAM |
| Transaktionen pro Sekunde | ||
| 1.3.6.1.4.1.15497.1.2.3.7.1.1.0 | CacheDurchsatzJetzt | Durchschnittliche Transaktionen pro Sekunde in letzter Minute. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.2.0 | CacheDurchsatz1StdPeak | Maximale Anzahl von Transaktionen pro Sekunde in der letzten Stunde. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.3.0 | CacheDurchsatz1StdMittel | Durchschnittliche Transaktionen pro Sekunde in der letzten Stunde. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.8.0 | CacheDurchsatzLifePeak | Maximale Anzahl von Transaktionen pro Sekunde seit dem Neustart des Proxys. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.9.0 | CacheDurchsatzLebensmittel | Durchschnittliche Transaktionen pro Sekunde seit dem Neustart des Proxys. |
| Bandbreite | ||
| 1.3.6.1.4.1.15497.1.2.3.7.4.1.0 | cacheBreiteGesamtJetzt | Durchschnittliche Bandbreite in letzter Minute. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.2.0 | CacheBwidthTotal1StdPeak | Maximale Bandbreite in der letzten Stunde. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.3.0 | CacheBreiteInsgesamt1StdMittel | Durchschnittliche Bandbreite in der letzten Stunde. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.8.0 | CacheBwidthTotalLifePeak | Maximale Bandbreite seit dem Neustart des Proxys. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.9.0 | ZwischenspeicherGesamtlebensdauerMittel | Durchschnittliche Bandbreite seit dem Neustart des Proxys. |
| Reaktionszeit | ||
| 1.3.6.1.4.1.15497.1.2.3.7.9.1.0 | cacheTrefferJetzt | Durchschnittliche Cache-Trefferrate in letzter Minute. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.2.0 | CacheTreffer1StdPeak | Maximale Cache-Trefferrate in der letzten Stunde. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.3.0 | CacheHits1StdMean | Durchschnittliche Cache-Trefferrate in der letzten Stunde. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.8.0 | ZwischenspeicherTrefferLebensspitze | Die maximale Cache-Trefferrate seit dem Neustart des Proxys. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.9.0 | ZwischenspeicherTrefferLebensmittel | Durchschnittliche Cache-Trefferrate seit Proxy-Neustart. |
| Cache-Trefferrate | ||
| 1.3.6.1.4.1.15497.1.2.3.7.5.1.0 | cacheTrefferJetzt | Durchschnittliche Cache-Trefferrate in letzter Minute. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.2.0 | CacheTreffer1StdPeak | Maximale Cache-Trefferrate in der letzten Stunde. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.3.0 | CacheHits1StdMean | Durchschnittliche Cache-Trefferrate in der letzten Stunde. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.8.0 | ZwischenspeicherTrefferLebensspitze | Die maximale Cache-Trefferrate seit dem Neustart des Proxys. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.9.0 | ZwischenspeicherTrefferLebensmittel | Durchschnittliche Cache-Trefferrate seit Proxy-Neustart. |
| Verbindungen | ||
| 1.3.6.1.4.1.15497.1.2.3.2.7.0 | cacheClientIdleConns | Inaktive Clientverbindungen. |
| 1.3.6.1.4.1.15497.1.2.3.3.7.0 | cacheServerIdleVerbindungen | Inaktive Serververbindungen |
| 1.3.6.1.4.1.15497.1.2.3.2.8.0 | CacheClientGesamtVerbindungen | Clientverbindungen gesamt |
| 1.3.6.1.4.1.15497.1.2.3.3.8.0 | CacheServerInsgesamtVerbindungen | Serververbindungen gesamt |
Nützliche Links
- Firewall für sichere Web-Appliance konfigurieren
- Sicherer Zugriff auf Web-Appliances
- Installieren der sicheren Web-Appliance auf VMware ESX
- Installieren der sicheren Web-Appliance auf Microsoft Hyper-V
- Migration der Konfiguration zwischen zwei SWAs
- Sichere Web-Appliance auf vorherige Version zurücksetzen
- Konfigurieren der Sicherung auf einer sicheren Web-Appliance
- Konfigurieren der Active Directory-Authentifizierung in SWA
- Konfigurieren der Kerberos Single-Sign-On-Authentifizierung in SWA
- Umgehen der Authentifizierung in einer sicheren Web-Appliance
- Download ausführbarer Dateien in SWA blockieren
- Konfiguration der Microsoft O365 Tenant-Einschränkung in SWA
- Umgehen des Datenverkehrs von Microsoft Updates in einer sicheren Web-Appliance
- Aktivierung bestimmter YouTube-Kanäle/Videos und Blockierung sonstiger YouTube-Inhalte in SWA
- Benutzerdefinierte URL-Kategorien in sicherer Web-Appliance konfigurieren
- Upstreamproxy in sicherer Webappliance konfigurieren
- SNMP in SWA konfigurieren und Fehlerbehebung dafür durchführen
- Fehlerbehebung beim DNS-Dienst der sicheren Webappliance
- Konfigurieren der Paketerfassung auf der Content Security Appliance
- Zugreifen auf Protokolle der sicheren Web-Appliance
- Konfigurieren von Leistungsparametern in Zugriffsprotokollen
- Fehlerbehebung bei der Leistung sicherer Web-Appliances mit SHD-Protokollen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
5.0 |
16-Jul-2026
|
Aktualisierte Rechtschreibung, Grammatik, Satzstruktur, Einführung, eingefügte Zeilen für separate Abschnitte/Lesbarkeit, korrigierte CCW-Warnungen und korrigierte URLs. |
4.0 |
25-Sep-2024
|
Erstveröffentlichung |
1.0 |
10-Apr-2023
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)