Best practices voor veilige webtoepassingen gebruiken
Inhoud
Inleiding
Dit document beschrijft de best practices voor het configureren van de Cisco Secure Web Appliance (SWA).
Achtergrondinformatie
Deze gids is bedoeld als referentie voor de configuratie van best practices en behandelt veel aspecten van een SWA-implementatie. Het omvat de ondersteunde netwerkomgeving, beleidsconfiguratie, bewaking en probleemoplossing. Hoewel de gedocumenteerde best practices belangrijk zijn voor alle beheerders, architecten en operators om te begrijpen, zijn ze slechts richtlijnen en moeten ze als zodanig worden behandeld. Elk netwerk heeft zijn eigen specifieke eisen en uitdagingen.
Als beveiligingsapparaat werkt de SWA op verschillende unieke manieren met het netwerk samen. Het is zowel een bron als een bestemming van webverkeer. Het werkt op hetzelfde moment als een webserver en een webclient. Het maakt minimaal gebruik van server-side IP-adresspoofing en man-in-the-middle-technieken om HTTPS-transacties te inspecteren. Het kan IP-adressen van clients vervalsen, waardoor de implementatie nog complexer wordt en extra eisen worden gesteld aan ondersteunende netwerkconfiguraties. Deze handleiding behandelt de meest voorkomende problemen met betrekking tot netwerkapparaatconfiguraties.
De configuratie van het SWA-beleid heeft niet alleen gevolgen voor de veiligheid, efficiëntie en handhaving, maar ook voor de prestaties van het apparaat. In deze handleiding wordt beschreven hoe de complexiteit van een configuratie van invloed is op systeembronnen. Het definieert complexiteit in deze context en beschrijft hoe deze kan worden geminimaliseerd in het beleidsontwerp. Daarnaast wordt er verwezen naar specifieke functies en hoe deze moeten worden geconfigureerd om de beveiliging, schaalbaarheid en werkzaamheid te vergroten.
In het gedeelte Monitoring and Alerting van dit document worden de meest effectieve manieren beschreven om het gebruik van het apparaat, de prestaties en beschikbaarheid en de systeembronnen te controleren. Het biedt ook informatie voor elementaire probleemoplossing.
netwerkomgeving
ICMP
Path MTU Discovery, zoals gedefinieerd in RFC 1191, het mechanisme bepaalt de maximale grootte van een pakket langs willekeurige paden. Met IPv4 kan een apparaat de maximale transmissie-eenheid (MTU) van elk pakket langs een pad bepalen door de niet-fragmentatiebit (DF) in de IP-header van het pakket in te stellen. Als een apparaat het pakket niet zonder een fragment kan doorsturen, wordt een ICMP-bericht (Internet Control Message Protocol) Fragmentation Needed (Type 3, Code 4) naar de bron verzonden. De klant stuurt dan een kleiner pakket opnieuw. Dit gaat door totdat de MTU voor het volledige pad is ontdekt. IPv6 ondersteunt geen fragmentatie en gebruikt een Packet Too Big (Type 2) ICMPv6-bericht om aan te geven dat een pakket niet via een bepaalde link kan worden geplaatst.
Omdat het proces van fragmentatie van pakketten ernstige gevolgen kan hebben voor de prestaties van een TCP-stroom, maakt de SWA gebruik van Path MTU Discovery. De genoemde ICMP-berichten moeten worden ingeschakeld in relevante netwerkapparaten, zodat de SWA de MTU voor zijn pad door het netwerk kan bepalen. Dit gedrag kan worden uitgeschakeld in de SWA door de pathmtudiscovery-opdracht in CLI uit te voeren. Het uitschakelen van de Path MTU Discovery zorgt ervoor dat de standaard MTU daalt tot 576 bytes zoals gedefinieerd in RFC 879, wat een ernstige invloed heeft op de prestaties. De beheerder moet een extra stap zetten om de MTU handmatig te configureren in de SWA vanaf de opdracht etherconfig CLI.
In het geval van het Web Cache Communication Protocol (WCCP) wordt het webverkeer vanaf een ander netwerkapparaat via het clientpad naar het internet naar de SWA geleid. Bij andere protocollen, zoals ICMP, worden deze niet doorgestuurd naar de SWA. Er is een mogelijkheid dat de SWA een ICMP Fragmentation Needed-bericht van een router op het netwerk kan activeren. De boodschap wordt echter niet overgebracht aan de SWA. Als dit mogelijk is in het netwerk, moet Path MTU Discovery worden uitgeschakeld. Zoals gezegd is met deze configuratie de extra stap vereist om de MTU handmatig in te stellen op de SWA door de etherconfig-opdracht in CLI uit te voeren.
Firewalls
In een standaardconfiguratie spooft de SWA het IP-adres van de client niet wanneer een verbinding wordt geproxyd. Dit betekent dat al het uitgaande webverkeer afkomstig is van het SWA IP-adres. U moet ervoor zorgen dat de NAT-apparaten (Network Address Translation) een voldoende grote pool van externe adressen en poorten hebben om dit mogelijk te maken. Het is een goed idee om een specifiek adres voor dit doel te wijden.
Sommige firewalls maken gebruik van DoS-beveiligingen (Denial-of-Service) of andere beveiligingsfuncties die worden geactiveerd wanneer grote aantallen gelijktijdige verbindingen afkomstig zijn van één IP-adres van de client. Wanneer IP-spoofing van de client niet is ingeschakeld, moet het SWA-IP-adres van deze beveiligingen worden uitgesloten.
Unicast omgekeerde pad doorsturen
De SWA spooft het IP-adres van de server wanneer deze communiceert met een client en kan optioneel worden geconfigureerd om het IP-adres van de client te spoofen wanneer deze communiceert met een upstream-server. Beschermingen zoals Unicast Reverse Path Forwarding (uRPF) kunnen op switches worden ingeschakeld om ervoor te zorgen dat een binnenkomend pakket overeenkomt met de verwachte ingangspoort. Deze beveiligingen controleren de broninterface van een pakket tegen de routeringstabel om ervoor te zorgen dat het op de verwachte poort aankomt. De SWA moet waar nodig van deze bescherming worden vrijgesteld.
IP-spoofing met WCCP
Wanneer de IP-spoofingfunctie is ingeschakeld in de SWA, verlaten uitgaande verzoeken het toestel en gebruiken ze het bronadres van het oorspronkelijke clientverzoek. Dit vereist extra configuratie van de gerelateerde netwerkinfrastructuur om ervoor te zorgen dat de retourpakketten worden gerouteerd naar de uitgaande SWA-interface, in plaats van de client die het verzoek heeft gedaan.
Wanneer WCCP wordt geïmplementeerd op een netwerkapparaat (router, switch of firewall), wordt een service-ID gedefinieerd die overeenkomt met verkeer op basis van een Access Control List (ACL). De service-ID wordt vervolgens toegepast op een interface en gebruikt om verkeer voor omleiding te matchen. Als IP-spoofing is ingeschakeld, moet een tweede service-ID worden gemaakt om ervoor te zorgen dat het retourverkeer ook naar de SWA wordt omgeleid.
SWA-netwerkconfiguratie
Interfaces
De SWA heeft vijf bruikbare netwerkinterfaces: M1, P1, P2, T1 en T2. Elk van deze moet worden gebruikt voor hun specifieke doel waar mogelijk. Het is nuttig om elke haven om zijn eigen redenen te gebruiken. De M1-interface moet worden aangesloten op een speciaal beheernetwerk en gesplitste routering moet worden ingeschakeld om de blootstelling van administratieve diensten te beperken. De P1 kan worden beperkt tot clientaanvraagverkeer, P2 mag geen expliciete proxyverzoeken accepteren. Dit vermindert de hoeveelheid verkeer op elke interface en maakt een betere segmentatie in het netwerkontwerp mogelijk.
De T1- en T2-poorten zijn beschikbaar voor de Layer 4 Traffic Monitor (L4TM)-functie. Dit controleert een gespiegelde laag 2-poort en blokkeert verkeer op basis van een geblokkeerde lijst met bekende schadelijke IP-adressen en domeinnamen. Het doet dit door te kijken naar de bron en bestemming IP-adressen van het verkeer en stuurt een TCP reset pakket, of Port Unreach bericht als de geblokkeerde lijst overeenkomt. Verkeer dat met een protocol wordt verzonden, kan met deze functie worden geblokkeerd.
Zelfs als de L4TM-functie niet is ingeschakeld, kan de transparante bypass worden verbeterd wanneer de T1- en T2-poorten zijn aangesloten op een gespiegelde poort. In het geval van WCCP kent de SWA alleen het bron- en bestemmings-IP-adres van een binnenkomend pakket en moet hij een beslissing nemen om het te proxy of te omzeilen op basis van die informatie. De SWA lost elke 30 minuten alle items op in de lijst met bypass-instellingen, ongeacht de records Time to Live (TTL). Als de L4TM-functie echter is ingeschakeld, kan de SWA gebruikmaken van gesnoopte DNS-query's om deze records vaker bij te werken. Dit vermindert het risico op een fout-negatief in een scenario waarin de klant een ander adres heeft opgelost dan de SWA.
netwerkroutering voor beheer
Als het gereserveerde beheernetwerk geen internettoegang heeft, kan elke service worden geconfigureerd om de datarouteringstabel te gebruiken. Dit kan worden aangepast aan de netwerktopologie, maar in het algemeen wordt aanbevolen om het beheernetwerk voor alle systeemservices en het gegevensnetwerk voor clientverkeer te gebruiken. Vanaf AsyncOS versie 11.0 zijn de services waarvoor routering kan worden ingesteld:
- DNS
- Active Directory
- Externe URL-feeds
- Updates en upgrades
- Advanced Malware Protection (AMP) Bestandsreputatie en -analyse
Voor extra uitgangs-filtering van beheerverkeer kunnen statische adressen worden geconfigureerd voor gebruik in deze services:
Externe URL-feeds:
1. Custom; afhankelijk van waar ze worden gehost.
2. AMP-bestandsreputatie en -analyse.
3. cloud-sa.amp.cisco.com (Noord-Amerika).
4. cloud-sa.eu.amp.cisco.com (Europa).
5. cloud-sa.apjc.amp.cisco.com (Azië/Stille Oceaan).
Updates en upgrades:
1. downloads-static.ironport.com
2. updates-static.ironport.com
TALOS-telemetrie
De Cisco Talos Group staat bekend om het identificeren van nieuwe en opkomende bedreigingen. Alle gegevens die naar Talos worden verzonden, worden geanonimiseerd en opgeslagen in Amerikaanse datacenters. Deelname aan SensorBase verbetert de categorisatie en identificatie van webbedreigingen en leidt tot een betere bescherming tegen de SWA en andere beveiligingsoplossingen van Cisco.
DNS
De best practices voor de beveiliging van Domain Name Server (DNS) suggereren dat elk netwerk twee DNS-resolvers moet hosten: één voor gezaghebbende records van binnen een lokaal domein en één voor recursieve resolutie van internetdomeinen. De SWA maakt het mogelijk om DNS-servers te configureren voor specifieke domeinen. Als er slechts één DNS-server beschikbaar is voor zowel lokale als recursieve query's, moet u rekening houden met de extra belasting die wordt toegevoegd wanneer deze wordt gebruikt voor alle SWA-query's. De betere optie is om de interne resolver te gebruiken voor lokale domeinen en de root internet resolvers voor externe domeinen. Dit is afhankelijk van het risicoprofiel en de tolerantie van de beheerder.
Standaard cacht de SWA een DNS-record gedurende minimaal 30 minuten, ongeacht de TTL van het record. Moderne websites die veel gebruik maken van Content Delivery Networks (CDN's) hebben lage TTL-records omdat hun IP-adressen vaak veranderen. Dit kan ertoe leiden dat een client één IP-adres voor een bepaalde server in de cache plaatst en dat de SWA een ander adres voor dezelfde server in de cache plaatst. Om dit tegen te gaan, kan de standaard SWA TTL worden verlaagd tot vijf minuten van deze CLI-opdrachten:
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.
...
Secundaire DNS-servers moeten worden geconfigureerd als de primaire server niet beschikbaar is. Als alle servers met dezelfde prioriteit zijn geconfigureerd, wordt het IP-adres van de server willekeurig gekozen. Afhankelijk van het aantal geconfigureerde servers kan de time-out voor een bepaalde server variëren. Deze tabel is de time-out voor een query voor maximaal zes DNS-servers:
| Aantal DNS-servers | Query Time-out (in volgorde) |
| 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 |
Er zijn geavanceerde DNS-opties alleen beschikbaar via de CLI. Deze opties zijn beschikbaar in CLI door de geavanceerde proxyconfig > DNS-opdracht uit te voeren.
Selecteer een van de volgende opties:
- 0 - Gebruik altijd DNS-antwoorden in volgorde.
- 1 - Gebruik het door de klant opgegeven adres en vervolgens DNS.
- 2 - Beperkt DNS-gebruik
- 3 - Zeer beperkt DNS-gebruik
- Voor opties 1 en 2 wordt DNS gebruikt als Webreputatie is ingeschakeld.
- Voor opties 2 en 3 wordt DNS gebruikt voor expliciete proxyverzoeken. Als er geen upstream-proxy is, of als de geconfigureerde upstream-proxy uitvalt.
- Voor alle opties wordt DNS gebruikt wanneer bestemmings-IP-adressen worden gebruikt in het beleidslidmaatschap.
Deze opties bepalen hoe de SWA beslist over het IP-adres waarmee verbinding moet worden gemaakt bij het evalueren van een clientverzoek. Wanneer een verzoek wordt ontvangen, ziet de SWA een IP-adres van de bestemming en een hostnaam. De SWA moet beslissen of het oorspronkelijke IP-adres van de bestemming voor de TCP-verbinding moet worden vertrouwd, of dat de SWA zijn eigen DNS-resolutie moet voltooien en het opgeloste adres moet gebruiken. De standaard is 0 = Gebruik altijd de DNS-antwoorden in volgorde, wat betekent dat de SWA de client niet vertrouwt om het IP-adres op te geven.
- Optie 1 - De SWA probeert het door de client geleverde IP-adres voor de verbinding, maar valt terug naar het opgeloste adres als het faalt. Het opgeloste adres wordt gebruikt voor beleidsevaluatie (webcategorie, webreputatie enzovoort).
- Optie 2: De SWA gebruikt alleen het door de klant opgegeven adres voor de verbinding en valt niet terug. Het opgeloste adres wordt gebruikt voor beleidsevaluatie (webcategorie, webreputatie, enzovoort).
- Optie 3: De SWA gebruikt alleen het door de klant opgegeven adres voor de verbinding en valt niet terug. Het door de klant verstrekte IP-adres wordt gebruikt voor beleidsevaluatie (webcategorie, webreputatie, enzovoort).
De gekozen optie is afhankelijk van hoeveel vertrouwen de beheerder in de client moet stellen bij het bepalen van het opgeloste adres voor een bepaalde hostnaam. Als de client een downstream-proxy is, kiest u optie 3 om de extra latentie van onnodige DNS-opzoekingen te voorkomen.
taakverdeling
WCCP zorgt voor transparante verkeerslastverdeling wanneer maximaal acht apparaten worden gebruikt. Het maakt het mogelijk om verkeersstromen te balanceren op basis van hash of masker, het kan worden gewogen als er een mix van toestelmodellen in het netwerk is en apparaten kunnen zonder downtime worden toegevoegd / verwijderd uit de servicepool. Een speciale load balancer wordt aanbevolen bij gebruik van 8 SWA's of meer.
De best practices voor WCCP-configuratie variëren afhankelijk van het gebruikte platform. Voor Cisco Catalyst®-switches worden best practices gedocumenteerd in het Cisco Catalyst Instant Access Solution-whitepaper.
WCCP heeft beperkingen bij gebruik met een Cisco Adaptive Security Appliance (ASA). Namelijk, client IP spoofing wordt niet ondersteund. Daarnaast moeten de clients en SWA achter dezelfde interface zitten. Hiervoor is het flexibeler om een layer 4-switch of router te gebruiken om verkeer om te leiden. WCCP-configuratie op het ASA-platform wordt beschreven in WCCP op ASA: Concepts, Limitations en Configuration.
Voor expliciete implementaties is een PAC-bestand (Proxy Auto-Configuration) de meest gebruikte methode, maar het heeft nadelen en veiligheidsimplicaties die buiten het bereik van dit document vallen. Als een PAC-bestand wordt geïmplementeerd, wordt voorgesteld om Group Policy Objects (GPO's) te gebruiken om de locatie te configureren in plaats van te vertrouwen op het Web Proxy Auto-Discover Protocol (WPAD), dat een gemeenschappelijk doelwit is voor aanvallers en gemakkelijk kan worden geëxploiteerd als het verkeerd is geconfigureerd. De SWA kan meerdere PAC-bestanden hosten en de vervaldatum ervan in de cache van de browser regelen.
Een PAC-bestand kan rechtstreeks worden aangevraagd bij de SWA vanaf een configureerbaar TCP-poortnummer (standaard 9001). Als een poort niet is opgegeven, kan het verzoek naar het proxyproces zelf worden verzonden alsof het een uitgaand webverzoek is. In dit geval is het mogelijk om een specifiek PAC-bestand te serveren op basis van de HTTP-hostheader die aanwezig is in het verzoek.
Kerberos moet anders worden geconfigureerd wanneer het wordt gebruikt in een omgeving met hoge beschikbaarheid (HA). De SWA biedt ondersteuning voor keytab-bestanden, waardoor meerdere hostnamen kunnen worden gekoppeld aan een Service Principle Name (SPN). Zie Een serviceaccount maken in Windows Active Directory voor Kerberos-verificatie bij implementaties met hoge beschikbaarheid voor meer informatie.
Actieve verificatie
Kerberos is een veiliger en breder ondersteund verificatieprotocol dan NT LAN Manager Security Support Provider (NTLMSSP). Het Apple OS X-besturingssysteem ondersteunt NTLMSSP niet, maar kan Kerberos gebruiken om te verifiëren of een domein is aangesloten. Basisauthenticatie mag niet worden gebruikt, omdat het ongecodeerde referenties verzendt in de HTTP-header en gemakkelijk kan worden gesnuffeld door een aanvaller op het netwerk. Als de basisverificatie moet worden gebruikt, moet de codering van de referenties worden ingeschakeld om ervoor te zorgen dat de referenties via een gecodeerde tunnel worden verzonden.
Er moet meer dan één domeincontroller aan de configuratie worden toegevoegd om beschikbaarheid te garanderen, maar er is geen inherente taakverdeling van dit verkeer. De SWA stuurt een TCP SYN-pakket naar alle geconfigureerde domeincontrollers en de eerste die reageert, wordt gebruikt voor verificatie.
De hostnaam voor omleiding die is geconfigureerd op de pagina met verificatie-instellingen bepaalt waar een transparante client wordt verzonden om de verificatie te voltooien. Als een Windows-client geïntegreerde verificatie wil voltooien en Single Sign-On (SSO) wil bereiken, moet de hostnaam voor omleiding zich in de zone Trusted Sites in het configuratiescherm voor internetopties bevinden. Het Kerberos-protocol vereist dat de Fully Qualified Domain Name (FQDN) wordt gebruikt om een bron op te geven, wat betekent dat de "shortname" (of "NETBIOS"-naam) niet kan worden gebruikt als Kerberos het beoogde verificatiemechanisme is. Het FQDN moet handmatig worden toegevoegd aan de vertrouwde sites (bijvoorbeeld via het groepsbeleid). Bovendien moet de automatische aanmelding met de gebruikersnaam en het wachtwoord worden ingesteld in het configuratiescherm voor internetopties.
In Firefox zijn extra instellingen vereist voor de browser om de verificatie met netwerkproxy's te voltooien. Deze instellingen kunnen worden geconfigureerd op de pagina about: config. Om Kerberos met succes te voltooien, moet de hostnaam voor de redirect worden toegevoegd aan de optie network.negotiate-auth.trusted-uris. Voor NTLMSSP moet het worden toegevoegd aan de optie network.automatic-ntlm-auth.trusted-uris.
Authenticatie surrogaten worden gebruikt om een geverifieerde gebruiker te onthouden voor een bepaalde duur nadat de verificatie is voltooid. IP-surrogaten moeten zoveel mogelijk worden gebruikt om het aantal actieve authenticatiegebeurtenissen dat zich voordoet te beperken. Het actief verifiëren van een client is een resource-intensieve taak, vooral wanneer Kerberos wordt gebruikt. De surrogaattime-out is standaard 3600 seconden (één uur) en kan worden verlaagd, maar de laagste aanbevolen waarde is 900 seconden (15 minuten).
Deze afbeelding laat zien hoe "redirect.WSA.lab" wordt gebruikt als de redirect hostnaam:
passieve authenticatie
De SWA kan andere Cisco-beveiligingsplatforms gebruiken om proxygebruikers passief te identificeren. Passieve gebruikersidentificatie elimineert authenticatieverzoeken en directe Active Directory-communicatie. Dit vermindert de latentie en het gebruik van hulpmiddelen. De huidige beschikbare mechanismen voor passieve authenticatie zijn via de Context Directory Agent (CDA), de Identity Services Engine (ISE) en de Identity Services Connector Passive Identity Connector (ISE-PIC).
ISE is een product met veel functies waarmee beheerders hun verificatieservices kunnen centraliseren en een uitgebreide reeks netwerktoegangscontroles kunnen gebruiken. Wanneer ISE meer te weten komt over een gebruikersverificatiegebeurtenis (via Dot1x-verificatie of webverificatieomleiding), wordt een sessiedatabase gevuld met informatie over de gebruiker en het apparaat die bij de verificatie betrokken zijn. De SWA maakt verbinding met ISE via het Platform Exchange Grid (pxGrid) en verkrijgt de gebruikersnaam, het IP-adres en de Security Group Tag (SGT) die zijn gekoppeld aan een proxyverbinding. Sinds AsyncOS versie 11.7 kan de SWA ook de External Restful Service (ERS) op ISE bevragen om groepsinformatie te verkrijgen.
De voorgestelde versies zijn ISE 3.1 en SWA 14.0.2-X en hoger. Zie ISE Compatibility Matrix for Secure Web Appliance voor meer informatie over de ISE Compatibility Matrix voor SWA. Raadpleeg de Handleiding voor eindgebruikers van het Web Security Appliance voor meer informatie over volledige integratiestappen.
Cisco kondigt end-of-life aan voor Cisco Context Directory Agent (CDA)-software, zie Cisco Context Directory Agent (CDA).
Vanaf CDA Patch 6 is dit compatibel met Microsoft Server 2016. Beheerders worden echter actief aangemoedigd om hun CDA-implementaties naar ISE-PIC te migreren. Beide oplossingen gebruiken WMI om een abonnement te nemen op het Windows Security Event Log om gebruikers-naar-IP-mappings te genereren (bekend als sessies). In het geval van CDA zoekt de SWA de kaart met RADIUS.
In het geval van ISE-PIC worden dezelfde pxGrid- en ERS-verbindingen gebruikt bij de volledige ISE-implementatie. ISE-PIC-functionaliteit is beschikbaar in een volledige ISE-installatie en in een zelfstandig virtueel apparaat.
Serviceconfiguratie
webproxy
Caching moet worden ingeschakeld in de webproxyconfiguratie om bandbreedte te besparen en de prestaties te verbeteren. Dit wordt steeds minder belangrijk omdat het percentage HTTPS-verkeer toeneemt omdat de SWA standaard geen HTTPS-transacties cache. Als de proxy alleen wordt geïmplementeerd om expliciete clients te bedienen, moet de doorstuurmodus worden opgegeven om verkeer te weigeren dat niet specifiek voor de proxyservice is bestemd. Op die manier wordt het aanvalsoppervlak van het apparaat verkleind en zijn er best practices (schakel de functie uit als deze niet vereist is).
Bereik verzoek headers worden gebruikt in HTTP-verzoeken om het byte bereik van een bestand voor download op te geven. Het wordt vaak gebruikt door besturingssystemen en applicatie-update daemons om kleine delen van een bestand tegelijk over te dragen. Standaard verwijdert de SWA deze headers zodat het het volledige bestand kan verkrijgen voor het scannen van antivirus (AV), bestandsreputatie en -analyse en Application Visibility Control (AVC). Door het doorsturen van range request headers wereldwijd in de proxy-instellingen in te schakelen, kunnen beheerders afzonderlijke toegangsbeleidsregels maken die deze headers doorsturen of strippen. Meer informatie over deze configuratie wordt uitgelegd in het gedeelte Toegangsbeleid.
HTTPS-proxy
Volgens best practices op het gebied van beveiliging moeten privésleutels worden gegenereerd op het apparaat waar ze worden gebruikt en mogen ze nooit elders worden vervoerd. Met de HTTPS-proxywizard kunt u het sleutelpaar en het certificaat maken dat wordt gebruikt voor het decoderen van TLS-verbindingen (Transport Layer Security). Het Certificate Signing Request (CSR) kan worden gedownload en ondertekend door een interne Certificate Authority (CA). In een Active Directory (AD)-omgeving is dit de beste methode omdat een AD-geïntegreerde CA automatisch wordt vertrouwd door alle leden van het domein en er geen extra stappen nodig zijn om het certificaat te implementeren.
Een van de beveiligingsfuncties van de HTTPS-proxy is het valideren van servercertificaten. Best practices suggereren dat ongeldige certificaten vereisen dat de verbinding wordt verbroken. Als u Decrypt voor EUN inschakelt, kan de SWA een blokpagina presenteren waarin de reden voor het blok wordt uitgelegd. Als dit niet is ingeschakeld, resulteren alle HTTPS-sites die worden geblokkeerd, in een browserfout. Dit leidt tot meer helpdesktickets en een aanname van de gebruikers dat er iets kapot is, in plaats van dat SWA de verbinding heeft geblokkeerd. Alle ongeldige certificaatopties moeten zijn ingesteld op ten minste Decrypt. Als u een van deze opties als monitor laat instellen, kan het systeem geen nuttige foutberichten loggen als certificaatproblemen verhinderen dat een site wordt geladen.
Net als het Online Certificate Services Protocol (OCSP) moeten controles ingeschakeld blijven en mag Monitor voor geen enkele optie worden gebruikt. Ingetrokken certificaten moeten worden verwijderd en alle andere moeten ten minste zijn ingesteld op Decrypt om het loggen van relevante foutberichten mogelijk te maken. Authority Information Access Chasing (AIA-achtervolging) is waar een client de ondertekenaar van het certificaat en een URL kan verzamelen waar extra certificaten kunnen worden opgehaald.
Als een certificaatketen die van een server is ontvangen bijvoorbeeld onvolledig is (als deze een tussenliggend of basiscertificaat mist), kan de SWA het AIA-veld controleren en gebruiken om de ontbrekende certificaten op te halen en de authenticiteit te verifiëren. Deze instelling is alleen beschikbaar in CLI via de volgende opdrachten:
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]>
...
Opmerking: deze instelling is standaard ingeschakeld en mag niet worden uitgeschakeld. Veel moderne servers vertrouwen op dit mechanisme om klanten een volledige vertrouwensketen te bieden.
Layer 4-verkeersmonitor (L4TM)
De L4TM is een zeer effectieve manier om het bereik van de SWA uit te breiden met kwaadaardig verkeer dat de proxy niet doorkruist en om verkeer op alle TCP- en UDP-poorten op te nemen. De T1- en T2-poorten zijn bedoeld om te worden aangesloten op een netwerktap of een monitorsessie voor switch. Hierdoor kan SWA passief al het verkeer van klanten monitoren. Als er verkeer wordt weergegeven dat bestemd is voor een kwaadaardig IP-adres, kan de SWA TCP-sessies beëindigen door een RST te verzenden terwijl het IP-adres van de server wordt vervalst. Voor UDP-verkeer kan het een bericht verzenden dat niet bereikbaar is voor de poort. Wanneer u de monitorsessie configureert, kunt u het beste verkeer uitsluiten dat bestemd is voor de beheerinterface van de SWA om te voorkomen dat de functie de toegang tot het apparaat verstoort.
Naast het monitoren van kwaadaardig verkeer, snoopt de L4TM ook DNS-query's om de bypass-instellingenlijst bij te werken. Deze lijst wordt gebruikt in WCCP-implementaties om bepaalde verzoeken terug te sturen naar de WCCP-router voor directe routering naar de webserver. Pakketten die overeenkomen met de bypass-instellingenlijst worden niet verwerkt door de proxy. De lijst kan IP-adressen of servernamen bevatten. De SWA lost elke 30 minuten alle items op in de lijst met bypass-instellingen, ongeacht de TTL van het record. Als de L4TM-functie echter is ingeschakeld, kan de SWA gebruikmaken van gesnoopte DNS-query's om deze records vaker bij te werken. Dit vermindert het risico op een fout-negatief in een scenario waarin de klant een ander adres heeft opgelost dan de SWA.
Beleidsconfiguratie
Een correcte beleidsconfiguratie is van cruciaal belang voor de prestaties en schaalbaarheid van de SWA. Effectief beleid beschermt klanten en dwingt bedrijfsvereisten af. De beleidsconfiguratie heeft echter ook invloed op het gebruik van bronnen, de gezondheid van het apparaat en de prestaties. Complexe of slecht ontworpen beleidsmaatregelen veroorzaken instabiliteit en trage reactiesnelheid
ingewikkeldheid
Verschillende beleidselementen worden gebruikt bij de opbouw van SWA-beleid. Het XML-bestand dat uit de configuratie wordt gegenereerd, wordt gebruikt om een aantal back-endconfiguratiebestanden en toegangsregels te maken. Hoe complexer de configuratie, hoe meer tijd het proxyproces moet besteden aan het evalueren van verschillende regelsets voor elke transactie. Bij het benchmarken en dimensioneren van de SWA wordt een basisreeks beleidselementen gecreëerd die drie lagen van configuratiecomplexiteit vertegenwoordigen. Een configuratie met lage complexiteit omvat 10 identiteitsprofielen, decoderingsbeleid, toegangsbeleid en aangepaste categorieën (met 10 regex-items, 50 server-IP's en 420 hostnamen). Het verdubbelen of verdrievoudigen van deze waarden resulteert in een configuratie met een gemiddelde of hoge complexiteit.
Wanneer een configuratie te complex wordt, zijn de eerste symptomen meestal een langzame reactie in de webinterface en CLI. Er kan in eerste instantie geen significante impact zijn voor gebruikers. Maar hoe complexer de configuratie is, hoe meer tijd het proxyproces in de gebruikersmodus moet doorbrengen. Daarom kan het controleren van het percentage tijd dat in deze modus wordt doorgebracht, nuttig zijn om een te complexe configuratie te diagnosticeren als de oorzaak van een trage SWA.
De CPU-tijd, in seconden, wordt elke 5 minuten vastgelegd in het track_stats-log. Dit betekent dat het gebruikerstijdpercentage kan worden berekend als (gebruikerstijd + systeemtijd)/300. Naarmate de gebruikerstijd 270 nadert, besteedt het proces te veel CPU-cycli in de gebruikersmodus, en dit is meestal te wijten aan het feit dat de configuratie te complex is om efficiënt te worden geparseerd.
Opmerking: de SWA heeft de maximale beperking van 60.000 gelijktijdige clientverbindingen en 60.000 gelijktijdige serververbindingen.
Identificatieprofielen
De Identificatie (ID) profielen zijn de eerste beleidselementen die worden geëvalueerd wanneer een nieuw verzoek wordt ontvangen. Alle informatie die in het eerste deel van het ID-profiel is geconfigureerd, wordt geëvalueerd met een logische EN. Dit betekent dat alle criteria moeten overeenkomen voor het verzoek om het profiel te matchen. Bij het opstellen van een beleid moet het zo specifiek zijn als absoluut noodzakelijk is. Profielen met individuele hostadressen zijn zelden vereist en kunnen leiden tot te grote configuraties. Gebruikmaken van de user-agent string in de HTTP headers, aangepaste categorielijst of subnet is over het algemeen een betere strategie om het bereik van een profiel te beperken.
Over het algemeen worden beleidsregels waarvoor verificatie vereist is, onderaan geconfigureerd en worden uitzonderingen bovenaan toegevoegd. Bij het bestellen van beleid dat geen authenticatie vereist, moet het meest gebruikte beleid het dichtst bij de top mogelijk zijn. Vertrouw niet op mislukte verificatie om de toegang te beperken. Als een bekende client in het netwerk niet kan verifiëren bij een proxy, moet deze zijn vrijgesteld van verificatie en worden geblokkeerd in het toegangsbeleid. Klanten die niet herhaaldelijk kunnen verifiëren, sturen niet-geverifieerde verzoeken naar de SWA, die bronnen gebruiken en overmatig CPU- en geheugengebruik kunnen veroorzaken.
Een veel voorkomende misvatting voor beheerders is dat er een uniek ID-profiel en het bijbehorende decryptie- en toegangsbeleid moet zijn. Dit is een inefficiënte strategie voor beleidsconfiguratie. Indien mogelijk moet het beleid worden "samengevouwen", zodat een enkel ID-profiel kan worden gekoppeld aan meerdere decoderings- en toegangsbeleid. Dit zorgt ervoor dat alle criteria in een bepaald beleid op elkaar moeten aansluiten (zowel het verkeer als het beleid). Over het algemeen zorgen het authenticatiebeleid en het daaruit voortvloeiende beleid voor minder beleid als geheel.
Decryptiebeleid
Net als bij het ID-profiel worden de criteria in het decoderingsbeleid beoordeeld als een logische EN, met één belangrijke uitzondering wanneer informatie uit het ISE wordt gebruikt. Dit is hoe beleidsmatching werkt, afhankelijk van welke elementen zijn geconfigureerd (AD-groep, gebruiker of SGT):
- AD-groepen en -gebruikers - Geen wijziging in eerder gedrag; het beleid wordt gematcht als de gebruiker lid is van een groep, OF de gebruiker is opgegeven in het beleid.
- SGT- en AD-groepen en -gebruikers - Het beleid wordt afgestemd als de gebruiker is gekoppeld aan de SGT EN lid is van de AD-groep, OF als de gebruiker is opgegeven in het beleid.
- SGT en gebruikers - Het beleid wordt gekoppeld als de gebruiker is gekoppeld aan de SGT of de gebruiker is gespecificeerd in het beleid.
Van de door de SWA uitgevoerde diensten is de evaluatie van het HTTPS-verkeer vanuit prestatieoogpunt het belangrijkst. Het percentage ontsleuteld verkeer heeft een directe invloed op de grootte van het apparaat. Een beheerder kan erop rekenen dat minstens 75% van het webverkeer HTTPS is.
Na de eerste installatie moet het percentage ontsleuteld verkeer worden bepaald om ervoor te zorgen dat de verwachtingen voor toekomstige groei nauwkeurig worden vastgesteld. Na de implementatie moet dit nummer eenmaal per kwartaal worden gecontroleerd. Het vinden van het percentage ontsleuteld HTTPS-verkeer door de SWA is eenvoudig met een kopie van de access_logs, zelfs zonder extra logbeheersoftware. Het uitvoeren van eenvoudige Bash- of PowerShell-opdrachten kan worden gebruikt om dit nummer te verkrijgen. Dit zijn enkele voorbeeldcommando's voor elke omgeving:
1. Linux-opdracht:
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-opdracht:
$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%" } }Bij het ontwerpen van decoderingsbeleid is het belangrijk om te begrijpen hoe de verschillende acties die in het beleid worden vermeld ervoor zorgen dat het apparaat HTTPS-verbindingen evalueert. De doorvoeractie wordt gebruikt wanneer de client en de server elk einde van hun TLS-sessie moeten kunnen beëindigen zonder dat de SWA elk pakket decodeert. Zelfs als een site is ingesteld op passthrough, moet de SWA nog steeds verplicht zijn om één TLS-handshake met de server te voltooien. De SWA moet ervoor kiezen om een verbinding te blokkeren op basis van de geldigheid van het certificaat en moet een TLS-verbinding met de server initiëren om het certificaat te verkrijgen. Als het certificaat geldig is, sluit de SWA de verbinding en kan de client de sessie rechtstreeks met de server blijven instellen.
Het enige geval waarin SWA geen TLS-handdruk uitvoert, is wanneer de servernaam of het IP-adres in een aangepaste categorie aanwezig is. Dit is ingesteld op doorvoer en de servernaam is beschikbaar in een HTTP CONNECT- of een TLS Hello-client. In een expliciet scenario geeft de client de hostnaam van de server aan de proxy voordat de TLS-sessie wordt gestart (in de hostheader), dus dit veld wordt vergeleken met de aangepaste categorie.
In een transparante implementatie controleert SWA het veld Server Name Indication (SNI) in het TLS Client Hello-bericht en evalueert het ten opzichte van de aangepaste categorie. Als de hostheader of SNI niet aanwezig is, moet SWA de handdruk met de server voortzetten om de velden Alternatieve naam (SAN) en Algemene naam (CN) op het certificaat te controleren (in deze volgorde).
Om het aantal TLS-handdrukken te verminderen, stelt u vertrouwde servers in op doorvoer uit aangepaste categorielijsten. In tegenstelling tot webcategorieën of reputatiescores (waarvoor SWA nog steeds een TLS-handdruk moet voltooien), wordt de volledige handdruk omzeild, maar worden certificaatvaliditeitscontroles voorkomen.
Gezien de snelheid waarmee nieuwe sites op het web verschijnen, is het waarschijnlijk dat een aantal sites niet worden gecategoriseerd door de webreputatie en categorisatiedatabases die door SWA worden gebruikt. Dit geeft niet aan dat de site waarschijnlijk kwaadaardiger is en dat al deze sites nog steeds worden onderworpen aan AV-scanning, AMP-bestandsreputatie en -analyse en elk object blokkeren. Om deze redenen wordt het niet aanbevolen om niet-gecategoriseerde sites te laten vallen (in de meeste omstandigheden). Het is het beste om deze in te stellen om te worden gedecodeerd en gescand door de AV-motoren en te worden geëvalueerd door AVC, AMP, toegangsbeleid, enzovoort. Er is meer informatie over niet-gecategoriseerde sites in de sectie Toegangsbeleid.
Toegangsbeleid
Net als het ID-profiel worden de criteria in het decoderingsbeleid ook beoordeeld als een logische EN met één belangrijke uitzondering wanneer informatie uit het ISE wordt gebruikt. Het beleid-matching gedrag wordt hierna uitgelegd, op basis van welke elementen zijn geconfigureerd (AD groep, gebruiker of SGT):
- AD-groepen en -gebruikers - Geen wijziging in eerder gedrag omdat het beleid is gekoppeld als de gebruiker lid is van een groep, OF de gebruiker is opgegeven in het beleid.
- SGT- en AD-groepen en -gebruikers - Het beleid wordt afgestemd als de gebruiker is gekoppeld aan de SGT EN lid is van de AD-groep, OF als de gebruiker is opgegeven in het beleid.
- SGT en gebruikers - Het beleid wordt gekoppeld als de gebruiker is gekoppeld aan de SGT OF de gebruiker is gespecificeerd in het beleid.
Het HTTP-verkeer wordt direct na de authenticatie beoordeeld aan de hand van het toegangsbeleid. HTTPS-verkeer wordt geëvalueerd nadat het is geverifieerd en als de decoderingsactie wordt toegepast volgens het bijpassende decoderingsbeleid. Voor ontsleutelde aanvragen zijn er twee access_log-vermeldingen. Het eerste log-item toont de actie die is toegepast op de eerste TLS-verbinding (decoderen) en een tweede log-item toont de actie die is toegepast door het toegangsbeleid op het gedecodeerde HTTP-verzoek.
Zoals uitgelegd in de sectie Web Proxy, worden de headers van de bereikaanvraag gebruikt om een specifiek bytebereik van een bestand aan te vragen en worden deze vaak gebruikt door de updateservices voor besturingssystemen en toepassingen. De SWA verwijdert deze headers standaard van uitgaande verzoeken, omdat het zonder het volledige bestand onmogelijk is om malwarescanning uit te voeren of AVC-functies te gebruiken. Als veel hosts op het netwerk vaak kleine bytebereiken vragen om updates op te halen, kan dit SWA activeren om het hele bestand meerdere keren tegelijk te downloaden. Hierdoor kan de beschikbare internetbandbreedte snel worden uitgeput en kunnen serviceonderbrekingen optreden. De meest voorkomende oorzaken van dit faalscenario zijn Microsoft Windows-updates en Adobe Software Update Daemons.
Om dit te verzachten, is de beste oplossing om het verkeer rond de SWA helemaal te sturen. Dit is niet altijd haalbaar voor transparant geïmplementeerde omgevingen, en in deze gevallen is de volgende beste optie om een specifiek toegangsbeleid voor het verkeer te maken en het doorsturen van kopteksten voor bereikaanvragen voor dat beleid mogelijk te maken. U moet rekening houden met het feit dat AV-scanning en AVC niet mogelijk is voor deze verzoeken en het beleid moet zijn ontworpen om alleen het beoogde verkeer te targeten. De beste manier om dit te bereiken is door de user-agent string te matchen die in de request header wordt gevonden. De user-agent string voor de gebruikelijke update daemons kan online worden gevonden, of de verzoeken kunnen worden vastgelegd door een beheerder en onderzocht. De meeste updateservices, waaronder Microsoft Windows- en Adobe-software-updates, maken geen gebruik van HTTPS.
Zoals beschreven in het gedeelte Decryptiebeleid, wordt het niet aanbevolen om niet-gecategoriseerde sites in het decryptiebeleid te laten vallen. Om dezelfde redenen wordt het niet aanbevolen om ze te blokkeren in het toegangsbeleid. De Dynamic Content Analysis (DCA) -engine kan de inhoud van een bepaalde site gebruiken, samen met andere heuristische gegevens om sites te categoriseren die niet-gecategoriseerd zijn door URL-databaseopzoekingen. Als u deze functie inschakelt, wordt het aantal niet-gecategoriseerde vonnissen in de SWA verminderd.
Met de instellingen voor het scannen van objecten van een toegangsbeleid kunnen verschillende typen archiefbestanden worden geïnspecteerd. Als het netwerk regelmatig archiefbestanden downloadt als onderdeel van updates van toepassingen, kan het inschakelen van archiefbestandsinspecties het CPU-gebruik aanzienlijk verhogen. Dit verkeer moet van tevoren worden vrijgesteld en geïdentificeerd als het de bedoeling is om alle gearchiveerde bestanden te inspecteren. De eerste plaats om mogelijke methoden te onderzoeken om verkeer te identificeren, is de user-agent-string, omdat dit kan helpen voorkomen dat IP-toegestane lijsten die omslachtig kunnen worden om te onderhouden.
Aangepaste en externe URL-rubrieken
De aangepaste categorielijsten worden gebruikt om een server te identificeren op IP-adres of hostnaam. Het is mogelijk om reguliere expressies (regex) te gebruiken om patronen op te geven waar servernamen overeenkomen. Het is meer resource-intensief om regex patroon te gebruiken om een servernaam te matchen dan om een substring match te gebruiken. Dit mag alleen worden gebruikt wanneer dat nodig is. Een "." kan worden toegevoegd aan het begin van een domeinnaam om een subdomein te matchen zonder regex te gebruiken.
cisco.com komt bijvoorbeeld ook overeen met www.cisco.com. Zoals uitgelegd in het gedeelte Complexiteit, wordt lage complexiteit gedefinieerd als 10 aangepaste categorielijsten, gemiddelde complexiteit als 20 en hoge complexiteit als 30. Het wordt aanbevolen om dit aantal onder de 20 te houden, vooral als de lijsten regex-patronen gebruiken of een groot aantal vermeldingen bevatten. Raadpleeg het gedeelte Toegangsbeleid voor meer informatie over het aantal vermeldingen voor elk type.
Externe URL-feeds zijn flexibeler dan statische aangepaste categorielijsten, en het gebruik ervan kan een directe impact hebben op de beveiliging, omdat ze de noodzaak voor een beheerder om ze handmatig te onderhouden, wegnemen. Deze functie kan worden gebruikt om lijsten op te halen die niet worden onderhouden of beheerd door een SWA-beheerder, de mogelijkheid om individuele uitzonderingen toe te voegen aan gedownloade adressen werd geïntroduceerd in AsyncOS versie 11.8.
De Office365 API is handig om te helpen bij beleidsbeslissingen over deze veelgebruikte service en kan worden gebruikt voor individuele toepassingen (PowerPoint, Skype, Word, enzovoort). Microsoft raadt aan om proxies voor al het Office365-verkeer te omzeilen om de prestaties te optimaliseren. Microsoft-documentatie vermeldt:
Waarschuwing: terwijl SSL Break en Inspect de grootste latentie creëert, kunnen andere services zoals proxy-verificatie en reputatieonderzoek slechte prestaties en een slechte gebruikerservaring veroorzaken. Bovendien hebben deze netwerkapparaten van de perimeter voldoende capaciteit nodig om alle aanvragen voor netwerkverbindingen te verwerken. Het wordt aanbevolen om uw proxy- of inspectieapparaten te omzeilen voor directe Office 365-netwerkverzoeken. Ga voor meer informatie naar: Microsoft 365-eindpunten beheren.
Beginnend in AsyncOS versie 11.8, kunt u de dynamische categorielijst opgehaald uit de Office365 API gebruiken om de bypass-instellingenlijst te vullen. De lijst wordt gebruikt om omgeleid verkeer terug te sturen naar het WCCP-apparaat voor directe routering, maar het kan moeilijk zijn om deze richtlijnen in een transparante proxyomgeving te gebruiken.
Het omzeilen van alle Office365-verkeer creëert een blinde vlek voor beheerders die een aantal basisbeveiligingscontroles en rapportage voor verkeer vereisen. Als Office 365-verkeer niet wordt omzeild door SWA, is het belangrijk om de specifieke technische uitdagingen te begrijpen die zich kunnen voordoen. Een daarvan is het aantal verbindingen dat de toepassingen vereisen. De grootte moet op de juiste manier worden aangepast aan de extra TCP-verbindingen die vereist zijn voor Office 365-toepassingen. Hierdoor kan het totale aantal verbindingen per gebruiker toenemen tussen 10% en 15% van de permanente TCP-sessies.
De decodeer- en hercoderingsacties die door de HTTPS-proxy worden uitgevoerd, introduceren een kleine hoeveelheid latentie in de verbindingen. Office365-toepassingen kunnen gevoelig zijn voor latentie, en voor andere factoren zoals trage WAN-verbindingen en ongelijksoortige geografische locatiesamenstelling kan deze gebruikerservaring lijden.
Sommige Office365-toepassingen maken gebruik van eigen TLS-parameters die voorkomen dat de HTTPS-proxy een handdruk met de toepassingsserver voltooit. Dit is vereist om het certificaat te valideren of de hostnaam op te halen. In combinatie met een toepassing zoals Skype voor Bedrijven verzendt dit geen veld Server Name Indication (SNI) in het TLS Client Hello-bericht, u moet dit verkeer volledig omzeilen. AsyncOS v11.8 introduceerde de mogelijkheid om verkeer te omzeilen op basis van alleen het IP-adres van de bestemming, zonder certificaatcontroles om dit scenario aan te pakken.
Monitoren en waarschuwingen
CLI-monitoren
De SWA CLI biedt opdrachten voor real-time monitoring van belangrijke processen. Sommige nuttige opdrachten tonen statistieken met betrekking tot het prox-proces. Het uitvoeren van de opdracht Statusdetails is een goede bron voor een overzicht van het gebruik van bronnen en prestatiemetingen, waaronder uptime, gebruikte bandbreedte, responslatentie, aantal verbindingen en meer.
Dit is een voorbeeld van output:
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 124502Met de opdracht Rate wordt realtime informatie weergegeven over het percentage CPU dat wordt gebruikt voor het prox-proces, het aantal verzoeken per seconde (RPS) en cachestatistieken. Deze opdracht blijft nieuwe uitgangen pollen en weergeven totdat deze worden onderbroken. Dit is een voorbeeld van output:
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 44Wanneer u de opdracht tcpservices uitvoert, wordt informatie weergegeven over geselecteerde poorten voor procesluisteren. Een uitleg van elk proces, het adres en de poortcombinatie wordt ook weergegeven:
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:32137Logboekregistratie
Het webverkeer is zeer dynamisch en gevarieerd. Nadat een proxy-implementatie is voltooid, is het belangrijk om regelmatig de hoeveelheid en samenstelling van het verkeer dat door het apparaat wordt geleid opnieuw te beoordelen. U moet het percentage ontsleuteld verkeer regelmatig controleren (eenmaal per kwartaal) om ervoor te zorgen dat de grootte overeenkomt met de verwachtingen en specificaties van de eerste installatie. Dit kan worden gedaan met een logmanagementproduct zoals Advanced Web Security Reporting (AWSR) of met Bash- of PowerShell-opdrachten met toegangslogs. Het aantal RPS moet regelmatig opnieuw worden beoordeeld om ervoor te zorgen dat het apparaat voldoende overhead heeft om pieken in het verkeer en mogelijke failover in een configuratie met hoge beschikbaarheid en lastverdeling te kunnen verwerken.
Het track_stats-log wordt elke vijf minuten toegevoegd en bevat verschillende secties van uitvoer die rechtstreeks verband houden met het prox-proces en de objecten in het geheugen. Bij prestatiebewaking omvatten de gemiddelde latentieaanvraagprocessen DNS-opzoektijd, AV-motorscantijd en nog veel meer nuttige velden. Dit log kan niet worden geconfigureerd vanuit de gebruikersinterface of de CLI en is alleen toegankelijk via Secure Copy Protocol (SCP) of File Transfer Protocol (FTP). Dit is een belangrijk logboek dat u moet hebben bij het oplossen van problemen, omdat het vaak moet worden gepolst.
Een afzonderlijke SHD-logregel wordt elke 60 seconden geschreven en bevat velden die belangrijk zijn voor prestatiemonitoring, waaronder latentie, RPS, totale client-side en server-side verbindingen. Dit is een voorbeeld van een SHD-logregel:
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.0Aanvullende aangepaste velden kunnen worden toegevoegd aan de access_logs die latentie-informatie voor individuele verzoeken aangeven. Deze velden omvatten serverrespons, DNS-resolutie en AV-scannerlatentie. De velden moeten aan het logboek worden toegevoegd om waardevolle informatie te verzamelen voor het oplossen van problemen. Dit is de aanbevolen aangepaste veldtekenreeks om te gebruiken:
[ Request Details: ID = %I, User Agent = %u, AD Group Memberships = ( %m ) %g ] [ Tx Wait Times (in ms): 1st byte to server = %:<1, Request Header = %:<h, Request to Server = %:<b, 1st byte to client = %:1>, 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, Auth total = %:>a; DNS response = %:<d, DNS total = %:>d, WBRS response = %:<r, WBRS total = %:>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, Anti-Spyware total = %:>s, AMP response = %:e>, AMP total = %:e<; Latency = %x; %L ][Client Port = %F, Server IP = %k, Server Port = %p]Prestatiegegevens die zijn afgeleid van deze waarden worden weergegeven in de tabel:
| Aangepast veld | Beschrijving |
| %:<a | Wacht tot u het antwoord van het webproxy-verificatieproces ontvangt nadat de webproxy het verzoek heeft verzonden. |
| %:<b | Wacht met het schrijven van een verzoek naar de server na de koptekst. |
| %:<d | Wacht tot u het antwoord van het DNS-proces voor webproxy ontvangt nadat de webproxy het verzoek heeft verzonden. |
| %:<h | Wacht met het schrijven van een request header naar de server na de eerste byte. |
| %:<r | Wacht tot het antwoord van de webreputatiefilters is ontvangen nadat de webproxy het verzoek heeft verzonden. |
| %:<s | Wacht tot u het vonnis van de web proxy anti-spyware proces ontvangt nadat de web proxy het verzoek verzendt. |
| %:> | Wacht op de eerste antwoordbyte van de server. |
| %:>a | Wacht even om het antwoord van het webproxy-verificatieproces te ontvangen. Bevat de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:>b | Wacht tot het volledige antwoordgedeelte is ontvangen nadat de koptekst is ontvangen. |
| %:>c | De webproxy heeft tijd nodig om een antwoord uit de schijfcache te lezen. |
| %:>d | Wacht even om het antwoord van het DNS-proces van de webproxy te ontvangen. Bevat de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:>h | Wacht op de serverheader na de eerste antwoordbyte. |
| %:>r | Wacht even om het vonnis van de webreputatiefilters te ontvangen. Bevat de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:>s | Wacht even om het vonnis te ontvangen van het antispywareproces van de webproxy. Bevat de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:1< | Wacht tot de eerste byte voor het aanvragen van een nieuwe clientverbinding. |
| %: 1> | Wacht tot de eerste byte naar een client is geschreven. |
| %: b< | Wacht even voor een compleet cliëntenlichaam. |
| %: b> | Wacht tot het volledige lichaam naar een klant is geschreven. |
| %: e> | Wacht totdat de reactie van de AMP-scanengine is ontvangen nadat de webproxy het verzoek heeft verzonden. |
| %: e< |
Wacht even om het vonnis van de AMP-scanengine te ontvangen. Bevat de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:h< | Wacht tot de volledige client header na de eerste byte. |
| %:h> | Wacht tot de volledige header naar een client is geschreven. |
| %: m< | Wacht even om het vonnis van de McAfee-scanmachine te ontvangen. Bevat de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %: m> | Wacht even om de reactie van de McAfee-scanengine te ontvangen. Nadat de webproxy het verzoek heeft verzonden. |
| %F | Bronpoort van client. |
| %p | Webserverpoort. |
| %k | IP-adres van gegevensbron (IP-adres van webserver). |
| %: w< | Wacht even om het vonnis van de webroot-scanengine te ontvangen. Bevat de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %: w> | Wacht even om de reactie van de webroot scanning engine te ontvangen. Nadat de webproxy het verzoek heeft verzonden. |
Het SWA-licentiemodel maakt hergebruik van licenties voor fysieke apparaten voor virtuele apparaten mogelijk. U kunt hiervan profiteren en SWAv-apparaten testen voor gebruik in een laboratoriumomgeving. Nieuwe functies en configuraties kunnen worden getest om stabiliteit en betrouwbaarheid te garanderen zonder de licentievoorwaarden te schenden.
Advanced Web Security Reporting (AWSR)
AWSR moet worden gebruikt om de rapportage van gegevens van SWA te waarborgen, vooral in omgevingen waar veel SWA's worden geïmplementeerd. Deze oplossing is schaalbaarder dan het gebruik van gecentraliseerde rapportage op een Security Management Appliance (SMA) en biedt aangepaste rapportagekenmerken die diepte en aanpassing aan uw gegevens toevoegen. Rapporten kunnen worden gegroepeerd en aangepast aan de behoeften van elke organisatie. Cisco Advanced Services Group moet worden ingezet bij het bepalen van de grootte van AWSR.
E-mailalarmering
Het ingebouwde e-mailwaarschuwingssysteem op SWA kan het beste worden gebruikt als een basislijnwaarschuwingssysteem. Het moet op de juiste manier worden aangepast aan de behoeften van de beheerder, omdat het lawaaierig kan zijn als alle informatieve gebeurtenissen zijn ingeschakeld. Het is belangrijk om de waarschuwingen te beperken en deze actief te monitoren dan is het om alles te waarschuwen en te negeren als spam.
| Waarschuwingsinstellingen | Configuratie |
| Van adres tot gebruik bij het verzenden van waarschuwingen. | Automatisch gegenereerd |
| Het eerste aantal seconden dat moet worden gewacht voordat een dubbele waarschuwing wordt verzonden. | 300 seconden |
| Maximaal aantal seconden dat moet worden gewacht voordat een dubbele waarschuwing wordt verzonden. | 3600 seconden |
Beschikbaarheidsbewaking
Er zijn twee methoden die kunnen worden gebruikt om de beschikbaarheid van een webproxy te controleren.
- De eerste is Layer 3 (L3) monitoring, die test of het IP-adres van het toestel bereikbaar is op het netwerk. De eenvoudigste manier om dit te testen is om een ICMP Echo (ping) verzoek te sturen naar het adres met regelmatige tussenpozen en te controleren op een antwoordpakket. De attributen van het antwoord, zoals TTL en latency, kunnen worden ontleed om de status van de netwerklaag te bepalen.
- Het is mogelijk dat een apparaat reageert op pings, maar de proxyprocessen zijn niet responsief of intermitterend. Als dit gebeurt, is het raadzaam om een Layer 7 (L7) -monitor toe te voegen, die een expliciet proxyverzoek naar het toestel stuurt en een 200 OK HTTP-responscode verwacht. Dit test de bereikbaarheid van de netwerkinterface, het reactievermogen van de proxyservices en de levensvatbaarheid van upstreamservices als een externe bron wordt gevraagd. Dit type monitoring neemt meestal de vorm aan van een expliciet HTTP HEAD-verzoek dat de proxy vraagt om verbinding te maken met een bron. De HEAD-methode vraagt om de headers terug te sturen en de klant moet een GET-verzoek sturen. Dit omvat alleen de antwoordheaders zonder gegevens.
- Als u een L7-monitoringtool of -script gebruikt, moet u ervoor zorgen dat het verkeer is vrijgesteld van verificatie. Anders resulteert dit in verificatiefouten en het gebruik van bronnen. Wanneer u een aangepaste user-agent string gebruikt in de monitoring tool, moet deze gebruikt worden om het verkeer te identificeren. Hoewel het verkeer is vrijgesteld van authenticatie, kan het nog steeds worden beperkt van onnodige internettoegang via het toegangsbeleid.
Wanneer u een of meer van deze methoden gebruikt, moet een beheerder een basislijn van acceptabele metrieken rond de proxyrespons vaststellen en deze gebruiken om alarmdrempels op te bouwen.
SNMP-bewaking
Het Simple Network Management Protocol (SNMP) is de belangrijkste methode voor het bewaken van de gezondheid van het apparaat. Het kan worden gebruikt om waarschuwingen van het apparaat (traps) te ontvangen of om verschillende Object Identifiers (OID's) te pollen om informatie te verzamelen. Er zijn veel OID's beschikbaar op de SWA die hardware-tot-brongebruik specificeren voor individuele proces- en statistische informatie.
Er zijn een aantal specifieke Machine Information Base (MIB) die om hardware- en prestatiegerelateerde redenen moeten worden gemonitord. Zie de volledige lijst van MIBs.
Dit is een lijst van de aanbevolen MIB's om te controleren:
| Hardware-OID | Naam |
| 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 | raidLastError |
| 1.3.6.1.4.1.15497.1.1.1.10 | waaiertafel |
| 1.3.6.1.4.1.15497.1.1.1.9.1.2 | graden Celsius |
Deze OID's worden rechtstreeks toegewezen aan de uitvoer van de opdracht statusdetails CLI:
| OID | Naam | veld Statusdetails |
| Systeembronnen | ||
| 1.3.6.1.4.1.15497.1.1.1.2.0 | procentuele CPU-benutting | CPU |
| 1.3.6.1.4.1.15497.1.1.1.1.0 | procentGeheugengebruik | RAM |
| Transacties per seconde | ||
| 1.3.6.1.4.1.15497.1.2.3.7.1.1.0 | cacheThruputNow | Gemiddelde transacties per seconde op het laatste moment. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.2.0 | cacheThruput1hrPeak | Maximale transacties per seconde in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.3.0 | cacheThruput1hrMean | Gemiddelde transacties per seconde in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.8.0 | cacheThruputLifePeak | Maximale transacties per seconde sinds proxy-herstart. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.9.0 | cacheThruputLifeMean | Gemiddelde transacties per seconde sinds proxy-herstart. |
| bandbreedte | ||
| 1.3.6.1.4.1.15497.1.2.3.7.4.1.0 | cacheBwidthTotalNow | Gemiddelde bandbreedte op het laatste moment. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.2.0 | cacheBwidthTotal1hrPeak | Maximale bandbreedte in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.3.0 | cachebreedteTotaal1uurGemiddelde | Gemiddelde bandbreedte in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.8.0 | cachebreedteTotalLifePeak | Maximale bandbreedte sinds proxy-herstart. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.9.0 | cacheBwidthTotalLifeMean | Gemiddelde bandbreedte sinds proxy-herstart. |
| reactietijd | ||
| 1.3.6.1.4.1.15497.1.2.3.7.9.1.0 | cacheNu raken | Gemiddelde cache hit rate op het laatste moment. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.2.0 | cacheHits1hrPeak | Maximale cache hit rate in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.3.0 | cacheHits1hrMean | Gemiddelde cache hit rate in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.8.0 | cacheHitsLifePeak | Maximale cache hit rate sinds proxy herstart. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.9.0 | cacheHitsLifeMean | Gemiddelde cache hit rate sinds proxy herstart. |
| Cache hit rate | ||
| 1.3.6.1.4.1.15497.1.2.3.7.5.1.0 | cacheNu raken | Gemiddelde cache hit rate op het laatste moment. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.2.0 | cacheHits1hrPeak | Maximale cache hit rate in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.3.0 | cacheHits1hrMean | Gemiddelde cache hit rate in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.8.0 | cacheHitsLifePeak | Maximale cache hit rate sinds proxy herstart. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.9.0 | cacheHitsLifeMean | Gemiddelde cache hit rate sinds proxy herstart. |
| Verbindingen | ||
| 1.3.6.1.4.1.15497.1.2.3.2.7.0 | cacheClientIdleConns | Ongebruikte clientverbindingen. |
| 1.3.6.1.4.1.15497.1.2.3.3.7.0 | cacheServerIdleConns | Niet-actieve serververbindingen. |
| 1.3.6.1.4.1.15497.1.2.3.2.8.0 | cacheClientTotalConns | Totale clientverbindingen. |
| 1.3.6.1.4.1.15497.1.2.3.3.8.0 | cacheServerTotalConns | Totale serververbindingen. |
Gerelateerde inhoud
Firewall configureren voor beveiligd webtoestel
Veilige webtoesteltoegangslogs begrijpen
Veilig webtoestel installeren op VMware Esxi
Veilig webtoestel installeren op Microsoft Hyper-V
Configuratie migreren tussen twee SWA's
Veilig webtoestel terugzetten naar vorige versie
Back-up configureren in beveiligd webtoestel
Active Directory-verificatie configureren in SWA
Kerberos Single-Sign-On Authentication configureren in SWA
Verificatie omzeilen in beveiligd webtoestel
Executable File Download blokkeren in SWA
Microsoft O365-huurdersbeperking configureren in SWA
Microsoft-updates voor verkeer in beveiligd webtoestel omzeilen
Specifiek YouTube-kanaal/video inschakelen en rest van YouTube blokkeren in SWA
Aangepaste URL-rubrieken configureren in Secure Web Appliance
Upstream-proxy configureren in beveiligd webtoestel
SNMP configureren en oplossen in SWA
Problemen oplossen met de DNS-service van het beveiligde webtoestel
Packet Capture configureren op apparaat voor contentbeveiliging
Toegang tot logboeken voor beveiligde webtoepassingen
Prestatieparameter configureren in toegangslogboeken
Problemen met beveiligde webapparaatprestaties oplossen met SHD-logboeken
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
6.0 |
28-Oct-2026
|
Hercertificering - bijgewerkte opmaak. |
5.0 |
16-Jul-2026
|
Bijgewerkte spelling, grammatica, zinsstructuur, inleiding, ingevoegde regels voor afzonderlijke secties/leesbaarheid, vaste CCW-waarschuwingen en vaste URL's. |
4.0 |
25-Sep-2024
|
Eerste vrijgave |
1.0 |
10-Apr-2023
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)