Best practices voor veilige webapparaten gebruiken
Inhoud
Inleiding
In dit document worden de best practices beschreven voor het configureren van de Cisco Secure Web Appliance (SWA).
Achtergrondinformatie
Deze handleiding 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 best practices die zijn gedocumenteerd belangrijk zijn voor alle beheerders, architecten en operators om te begrijpen, zijn het 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 fungeert tegelijkertijd als een webserver en een webclient. Op zijn minst maakt het gebruik van server-side IP-adres spoofing en man-in-the-middle technieken om HTTPS-transacties te inspecteren. Het kan IP-adressen van clients vervalsen, waardoor de implementatie nog ingewikkelder wordt en extra eisen worden gesteld aan de ondersteuning van netwerkconfiguraties. Deze handleiding behandelt de meest voorkomende problemen met betrekking tot netwerkapparaatconfiguraties.
De configuratie van het SWA-beleid heeft niet alleen gevolgen voor de doeltreffendheid en handhaving van de beveiliging, maar ook voor de prestaties van het apparaat. In deze handleiding wordt beschreven hoe de complexiteit van een configuratie van invloed is op de systeembronnen. Het definieert complexiteit in deze context en beschrijft hoe deze kan worden geminimaliseerd in beleidsontwerp. Daarnaast wordt er melding gemaakt van specifieke functies en hoe deze moeten worden geconfigureerd om de beveiliging, schaalbaarheid en effectiviteit te vergroten.
In het gedeelte Monitoring en waarschuwingen van dit document worden de meest effectieve manieren uitgelegd om het toestel, de prestaties en beschikbaarheid en het gebruik van systeembronnen te bewaken. Het biedt ook informatie voor eenvoudige probleemoplossing.
netwerkomgeving
ICMP
Path MTU Discovery, zoals gedefinieerd in RFC 1191, bepaalt het mechanisme 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-fragmentbit (DF) in de IP-header van het pakket in te stellen. Als een apparaat bij een koppeling langs het pad het pakket niet kan doorsturen zonder een fragment, wordt een ICMP-bericht (Internet Control Message Protocol) Fragmentatie nodig (Type 3, Code 4) naar de bron verzonden. De klant verzendt dan een kleiner pakket. 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 door een bepaalde link kan worden geplaatst.
Omdat het proces van pakketfragmentatie ernstige gevolgen kan hebben voor de prestaties van een TCP-stroom, maakt de SWA gebruik van Path MTU Discovery. De genoemde ICMP-berichten moeten op relevante netwerkapparaten zijn ingeschakeld, zodat de SWA de MTU voor zijn pad door het netwerk kan bepalen. Dit gedrag kan in de SWA worden uitgeschakeld door de opdracht pathmudiscovery in CLI uit te voeren. Als u dit doet, daalt de standaard MTU naar 576 bytes (per RFC 879), wat de prestaties ernstig beïnvloedt. De beheerder moet een extra stap zetten bij het handmatig configureren van de MTU in de SWA via de CLI-opdracht etherconfig.
In het geval van het Web Cache Communication Protocol (WCCP) wordt het webverkeer omgeleid naar de SWA vanaf een ander netwerkapparaat langs het clientpad naar het internet. 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. Het bericht wordt echter niet aan de SWA bezorgd. Als dit een mogelijkheid is in het netwerk, moet Path MTU Discovery worden uitgeschakeld. Zoals gezegd is bij deze configuratie de extra stap vereist om de MTU handmatig in te stellen op de SWA door de opdracht etherconfig in CLI uit te voeren.
firewalls
In een standaardconfiguratie vervalst de SWA het IP-adres van de client niet bij het proxyeren van een verbinding. Dit betekent dat al het uitgaande webverkeer afkomstig is van het SWA IP-adres. U moet ervoor zorgen dat de Network Address Translation (NAT)-apparaten een voldoende grote pool van externe adressen en poorten hebben om dit mogelijk te maken. Het is een goed idee om hiervoor een specifiek adres te kiezen.
Sommige firewalls maken gebruik van Denial-of-Service (DoS)-beveiligingen of andere beveiligingsfuncties die worden geactiveerd wanneer grote aantallen gelijktijdige verbindingen afkomstig zijn van één IP-adres van de client. Als client-IP-spoofing niet is ingeschakeld, moet het SWA-IP-adres van deze beveiliging worden uitgesloten.
Unicast Reverse Path Forwarding
De SWA spoofs het IP-adres van de server wanneer deze communiceert met een client, en kan optioneel worden geconfigureerd om spoofs het IP-adres van de client wanneer het communiceert met een upstream server. Beveiligingen zoals Unicast Reverse Path Forwarding (uRPF) kunnen worden ingeschakeld op switches 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 deze op de verwachte poort is aangekomen. De SWA moet waar nodig van deze bescherming worden vrijgesteld.
IP-spoofing met WCCP
Wanneer de functie IP-spoofing is ingeschakeld in de SWA, wordt het bronadres van het oorspronkelijke clientverzoek gebruikt voor uitgaande verzoeken. 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 naar de client die het verzoek heeft ingediend.
Wanneer WCCP wordt geïmplementeerd op een netwerkapparaat (router, switch of firewall), wordt een service-ID gedefinieerd die overeenkomt met het verkeer op basis van een toegangscontrolelijst (ACL). De service-ID wordt vervolgens toegepast op een interface en gebruikt om verkeer af te stemmen voor omleiding. Als IP-spoofing is ingeschakeld, moet een tweede service-ID worden gemaakt om ervoor te zorgen dat het retourverkeer ook wordt omgeleid naar de SWA.
SWA-netwerkconfiguratie
Interfaces
De SWA heeft vijf bruikbare netwerkinterfaces: M1, P1, P2, T1 en T2. Elk van deze moet waar mogelijk worden ingezet voor hun specifieke doel. Het is nuttig om elke haven te gebruiken om zijn eigen redenen. De M1-interface moet worden aangesloten op een speciaal beheernetwerk en split-routing 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 zorgt voor een betere segmentatie in het netwerkontwerp.
De T1- en T2-poorten zijn beschikbaar voor de Layer 4 Traffic Monitor (L4TM)-functie. Deze bewaakt 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 de bestemming IP-adressen van het verkeer en verzendt een TCP-reset pakket, of Port Onbereikbaar 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 op een gespiegelde poort zijn aangesloten. In het geval van WCCP kent de SWA alleen het bron- en bestemmings-IP-adres van een inkomend pakket en moet hij een beslissing nemen om het te proxy of om het te omzeilen op basis van die informatie. De SWA lost alle items in de lijst met bypass-instellingen elke 30 minuten op, ongeacht de records Time to Live (TTL). Als de L4TM-functie echter is ingeschakeld, kan de SWA gesnuffelde DNS-query's gebruiken om deze records vaker bij te werken. Dit vermindert het risico op een fout-negatief in een scenario waarin de klant een ander adres dan het SWA-adres heeft opgelost.
netwerkbeheerroutering
Als het toegewezen beheernetwerk geen internettoegang heeft, kan elke service worden geconfigureerd om de tabel voor gegevensroutering te gebruiken. Dit kan worden aangepast aan de netwerktopologie, maar in het algemeen wordt aanbevolen om het beheernetwerk te gebruiken voor alle systeemservices en het datanetwerk voor clientverkeer. 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 egresfilters van beheerverkeer kunnen statische adressen worden geconfigureerd voor gebruik in deze services:
Externe URL-feeds:
1. Aangepast; hangt af van waar ze worden gehost.
2. reputatie en analyse van AMP-bestanden.
3. cloud-sa.amp.cisco.com (Noord-Amerika).
4. cloud-sa.eu.amp.cisco.com (Europa).
5. cloud-sa.apjc.amp.cisco.com (Asia Pacific).
Bijwerken en upgraden:
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 categorisering en identificatie van webbedreigingen en leidt tot een betere bescherming tegen de SWA en andere Cisco-beveiligingsoplossingen.
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 binnen een lokaal domein en één voor recursieve resolutie van internetdomeinen. Met de SWA kunnen DNS-servers worden geconfigureerd voor specifieke domeinen. Als er slechts één DNS-server beschikbaar is voor zowel lokale als recursieve query's, overweeg dan 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.
De SWA-cache bevat standaard minimaal 30 minuten een DNS-record, 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 cachet en de SWA een ander adres voor dezelfde server cachet. Om dit tegen te gaan, kan de standaard-TTL van SWA worden verlaagd naar vijf minuten met 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 de IP 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 | Time-out zoekopdracht (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 alleen geavanceerde DNS-opties beschikbaar via de CLI. Deze opties zijn beschikbaar in CLI door de opdracht Advanced proxyconfig > DNS uit te voeren.
Selecteer een van de volgende opties:
- 0 - Gebruik altijd DNS-antwoorden in volgorde
- 1 - Gebruik het door de client opgegeven adres en vervolgens DNS
- 2 - Beperkt gebruik van DNS
- 3 - Zeer beperkt DNS-gebruik
- Voor optie 1 en 2 wordt DNS gebruikt als Web Reputation is ingeschakeld.
- Voor optie 2 en 3 wordt DNS gebruikt voor expliciete proxyverzoeken. Als er geen upstream-proxy is, of als de geconfigureerde upstream-proxy mislukt.
- Voor alle opties wordt DNS gebruikt wanneer IP-adressen van de bestemming 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 en hostnaam van de bestemming. De SWA moet beslissen of hij het oorspronkelijke IP-adres van de bestemming voor de TCP-verbinding vertrouwt of dat hij zijn eigen DNS-resolutie voltooit en het opgeloste adres gebruikt. De standaard is "0 = Gebruik altijd DNS-antwoorden in volgorde", wat betekent dat de SWA de client niet vertrouwt om het IP-adres te verstrekken.
- Optie 1- De SWA probeert het door de client opgegeven IP-adres voor de verbinding, maar valt terug naar het opgeloste adres als dit mislukt. Het opgeloste adres wordt gebruikt voor beleidsevaluatie (webcategorie, webreputatie, enzovoort).
- Optie 2—De SWA gebruikt alleen het door de client opgegeven adres voor de verbinding en valt niet terug. Het adres wordt gebruikt voor beleidsevaluatie (webcategorie, webreputatie, enzovoort).
- Optie 3—De SWA gebruikt alleen het door de client opgegeven adres voor de verbinding en valt niet terug. Het door de klant opgegeven IP-adres wordt gebruikt voor beleidsevaluatie (webcategorie, webreputatie, enzovoort).
De gekozen optie hangt af 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-zoekopdrachten te voorkomen.
taakverdeling
WCCP maakt een transparante verdeling van de verkeersbelasting mogelijk 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 taakverdeler wordt aanbevolen bij gebruik van 8 SWA's of meer.
Best practices voor WCCP-configuratie variëren op basis van het gebruikte platform. Voor Cisco Catalyst®-switches zijn de best practices gedocumenteerd in het whitepaper van Cisco Catalyst Instant Access Solution.
WCCP heeft beperkingen bij gebruik in combinatie met een Cisco Adaptive Security Appliance (ASA). IP-spoofing van de client 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 het verkeer om te leiden. WCCP-configuratie op het ASA-platform wordt beschreven in WCCP op ASA: Concepts, Limitations, and Configuration.
Voor expliciete implementaties is een PAC-bestand (Proxy Auto-Configuration) de meest gebruikte methode, maar het heeft nadelen en beveiligingsimplicaties 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 veel voorkomend doelwit is voor aanvallers en gemakkelijk kan worden gebruikt als het verkeerd is geconfigureerd. De SWA kan meerdere PAC-bestanden hosten en hun vervaldatum in de cache van de browser regelen.
Een PAC-bestand kan rechtstreeks worden aangevraagd bij de SWA via 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 dienen op basis van de HTTP-hostheader die in het verzoek aanwezig is.
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 in implementaties met hoge beschikbaarheid voor meer informatie.
actieve verificatie
Kerberos is veiliger en wordt op grotere schaal ondersteund door het verificatieprotocol dan de NT LAN Manager Security Support Provider (NTLMSSP). Het Apple OS X-besturingssysteem ondersteunt NTLMSSP niet, maar het kan Kerberos gebruiken om te verifiëren of een domein is aangesloten. Basisverificatie mag niet worden gebruikt, omdat het inloggegevens onversleuteld verzendt in de HTTP-header en gemakkelijk kan worden gesnuffeld door een aanvaller op het netwerk. Als basisverificatie moet worden gebruikt, moet inlogcodering zijn ingeschakeld om ervoor te zorgen dat inloggegevens via een gecodeerde tunnel worden verzonden.
Er moet meer dan één domeincontroller aan de configuratie worden toegevoegd om de beschikbaarheid te garanderen, maar er is geen inherente taakverdeling van dit verkeer. De SWA verzendt een TCP SYN-pakket naar alle geconfigureerde domeincontrollers en de eerste die reageert, wordt gebruikt voor verificatie.
De redirect-hostnaam die is geconfigureerd op de pagina 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 de omleiding zich in de zone Vertrouwde sites in het configuratiescherm voor internetopties bevinden. Het Kerberos-protocol vereist dat de Fully Qualified Domain Name (FQDN) wordt gebruikt om een resource op te geven, wat betekent dat de "shortname" (of "NETBIOS" -naam) niet kan worden gebruikt als Kerberos het beoogde authenticatiemechanisme is. De FQDN moet handmatig worden toegevoegd aan de vertrouwde sites (bijvoorbeeld via groepsbeleid). Bovendien moet de automatische aanmelding met de gebruikersnaam en het wachtwoord worden ingesteld in het configuratiescherm voor internetopties.
In Firefox zijn aanvullende instellingen vereist om de verificatie met netwerkproxies te voltooien. Deze instellingen kunnen worden geconfigureerd op de pagina about: config. Om Kerberos succesvol te voltooien, moet de redirect-hostnaam worden toegevoegd aan de network.negotiate-auth.trusted-uris-optie. Voor NTLMSSP moet het worden toegevoegd aan de optie network.automatic-ntlm-auth.trusted-uris.
Authenticatie-surrogaten worden gebruikt om een geverifieerde gebruiker voor een bepaalde duur te onthouden nadat de verificatie is voltooid. IP-surrogaten moeten waar mogelijk worden gebruikt om het aantal actieve authenticatiegebeurtenissen te beperken. Het actief authenticeren van een client is een resource-intensieve taak, vooral wanneer Kerberos wordt gebruikt. De time-out voor surrogaat 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 gebruikmaken van andere Cisco-beveiligingsplatforms om proxygebruikers passief te identificeren. Passieve gebruikersidentificatie elimineert verificatieprompts 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 dat beheerders helpt hun verificatieservices te centraliseren en een uitgebreide set netwerktoegangscontroles te gebruiken. Wanneer ISE informatie krijgt over een gebruikersverificatiegebeurtenis (via Dot1x-verificatie of webverificatie-omleiding), wordt een sessiedatabase gevuld met informatie over de gebruiker en het apparaat dat bij de verificatie is betrokken. 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 is 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 for SWA. Voor meer informatie over de stappen voor volledige integratie raadpleegt u de Handleiding voor eindgebruikers voor webbeveiligingstoestellen.
Cisco kondigt het einde van de levenscyclus van Cisco Context Directory Agent (CDA)-software aan, 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 zich te abonneren op het Windows Security Event Log om gebruikers-naar-IP-toewijzingen te genereren (bekend als "sessies"). In het geval van CDA, de SWA queries 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.
Configuratie van services
webproxy
Caching moet zijn ingeschakeld in de webproxyconfiguratie om bandbreedte te besparen en de prestaties te verbeteren. Dit wordt minder belangrijk naarmate het percentage HTTPS-verkeer toeneemt, omdat de SWA HTTPS-transacties standaard niet in cache opslaat. Als de proxy is geïmplementeerd om alleen expliciete clients te bedienen, moet de doorstuurmodus worden opgegeven om verkeer te weigeren dat niet specifiek is bestemd voor de proxyservice. Op die manier wordt het aanvalsoppervlak van het apparaat verkleind en worden de beste praktijken toegepast (uitschakelen als dit niet nodig is).
Range request 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 worden deze headers door SWA verwijderd, zodat het volledige bestand kan worden opgehaald voor antivirusscans (AV), bestands- en reputatieanalyse en Application Visibility Control (AVC). Door het doorsturen van range request headers wereldwijd in de proxy-instellingen in te schakelen, kunnen beheerders individuele toegangsregels maken die deze headers doorsturen of strippen. Meer informatie over deze configuratie vindt u in het gedeelte Toegangsbeleid.
HTTPS-proxy
Best practices voor beveiliging suggereren dat privésleutels moeten worden gegenereerd op het apparaat waar ze worden gebruikt en nooit ergens anders worden vervoerd. Met de HTTPS-proxy-wizard 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 certificeringsinstantie (CA). In een Active Directory (AD)-omgeving is dit de beste methode, omdat alle leden van het domein automatisch vertrouwen hebben in een geïntegreerde AD-CA 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. Door Decrypt voor EUN in te schakelen, kan de SWA een blokpagina presenteren waarin de reden voor het blok wordt uitgelegd. Als dit niet is ingeschakeld, leiden alle HTTPS-sites die worden geblokkeerd, tot een browserfout. Dit leidt tot meer helpdesktickets en een veronderstelling van het gebruikersgedeelte 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 instelt, kan het systeem geen nuttige foutmeldingen registreren als certificaatproblemen voorkomen dat een site wordt geladen.
Net als bij 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 worden ingesteld op Decrypt om het registreren van relevante foutmeldingen mogelijk te maken. Authority Information Access Chasing (AIA chasing) is waar een client de ondertekenaar van het certificaat en een URL kan verzamelen waar extra certificaten kunnen worden opgehaald.
Als een van een server ontvangen certificaatketen bijvoorbeeld onvolledig is (als er een tussenliggend of hoofdcertificaat ontbreekt), 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 met 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 een volledige vertrouwensketen aan klanten 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 moeten worden verbonden met een netwerktap of een monitorsessie van de switch. Dit stelt SWA in staat om passief al het verkeer van klanten te controleren. 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 Port Unreach-bericht verzenden. Bij het configureren van de monitorsessie kunt u het beste alle verkeer uitsluiten dat is bestemd voor de beheerinterface van de SWA om te voorkomen dat de functie mogelijk de toegang tot het apparaat verstoort.
Naast het controleren op kwaadaardig verkeer, snuffelt de L4TM ook DNS-query's om de lijst met bypass-instellingen 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 lijst met bypass-instellingen worden niet verwerkt door de proxy. De lijst kan IP-adressen of servernamen bevatten. De SWA lost alle items in de lijst met bypass-instellingen elke 30 minuten op, ongeacht de TTL van de record. Als de L4TM-functie echter is ingeschakeld, kan de SWA gesnuffelde DNS-query's gebruiken om deze records vaker bij te werken. Dit vermindert het risico op een fout-negatief in een scenario waarin de klant een ander adres dan het SWA-adres heeft opgelost.
Beleidsconfiguratie
De juiste beleidsconfiguratie staat centraal in de prestaties en schaalbaarheid van de SWA. Effectief beleid beschermt klanten en handhaaft bedrijfsvereisten. Beleidsconfiguratie heeft echter ook invloed op het gebruik van bronnen, de gezondheid van apparaten en de prestaties. Complexe of slecht ontworpen beleidsregels veroorzaken instabiliteit en trage reacties
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 de dimensionering van de SWA wordt een basisset beleidselementen gemaakt die drie niveaus van configuratiecomplexiteit vertegenwoordigen. Een configuratie met een lage complexiteit bevat 10 identiteitsprofielen, decoderingsbeleid, toegangsbeleid en aangepaste categorieën (met 10 regex-items, 50 server-IP's en 420 hostnamen). Verdubbeling of verdrievoudiging van deze waarden resulteert in een configuratie met gemiddelde of hoge complexiteit.
Wanneer een configuratie te complex wordt, omvatten de eerste symptomen meestal een langzame respons in de webinterface en CLI. In het begin kan er 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 geregistreerd in het track_stats-log. Dit betekent dat het gebruikerstijdpercentage kan worden berekend als (gebruikerstijd + systeemtijd) / 300. Aangezien de gebruikerstijd 270 nadert, besteedt het proces te veel CPU-cycli in de gebruikersmodus, en dit komt meestal omdat de configuratie te complex is om efficiënt te worden ontleed.
Opmerking: de SWA heeft de maximale beperking van 60.000 gelijktijdige clientverbindingen en 60.000 gelijktijdige serververbindingen.
Identificatieprofielen
De ID-profielen zijn de eerste beleidselementen die worden geëvalueerd wanneer een nieuw verzoek wordt ontvangen. Alle informatie die is geconfigureerd in de eerste sectie van het ID-profiel wordt geëvalueerd met een logische EN. Dit betekent dat alle criteria moeten overeenkomen om het verzoek aan te passen aan het profiel. 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 uitgestrekte configuraties. Gebruikmaken van de user-agent string in de HTTP headers, aangepaste categorie lijst, of subnet zijn over het algemeen een betere strategie om de reikwijdte van een profiel te beperken.
Over het algemeen worden beleidsregels waarvoor verificatie is vereist onderaan geconfigureerd en worden uitzonderingen bovenaan toegevoegd. Bij het bestellen van beleid dat geen authenticatie vereist, moet het meest gebruikte beleid zo dicht mogelijk bij de top zijn. Vertrouw niet op mislukte authenticatie om de toegang te beperken. Als een bekende client op het netwerk niet kan worden geverifieerd op een proxy, moet deze worden vrijgesteld van verificatie en worden geblokkeerd in het toegangsbeleid. Cliënten 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 moet zijn en het bijbehorende decoderings- en toegangsbeleid. Dit is een inefficiënte strategie voor beleidsconfiguratie. Waar mogelijk moeten beleidsregels worden "samengevouwen", zodat een enkel ID-profiel kan worden gekoppeld aan meerdere decoderings- en toegangsbeleidsregels. Dit zorgt ervoor dat alle criteria in een bepaald beleid met elkaar moeten overeenkomen (zowel het verkeer als het beleid). Over het algemeen zorgt het authenticatiebeleid en het resulterende beleid voor minder beleid als geheel.
Decoderingsbeleid
Net als bij het ID-profiel worden de criteria in het decoderingsbeleid geëvalueerd als een logische EN, met één belangrijke uitzondering wanneer informatie uit de ISE wordt gebruikt. Zo werkt beleidsmatching, afhankelijk van welke elementen zijn geconfigureerd (AD-groep, gebruiker of SGT):
- Advertentiegroepen en gebruikers - Geen wijziging in eerder gedrag; het beleid wordt aangepast als de gebruiker lid is van een groep OF als de gebruiker is opgegeven in het beleid.
- SGT- en AD-groepen en -gebruikers - Het beleid komt overeen 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 afgestemd als de gebruiker is gekoppeld aan de SGT of de gebruiker is gespecificeerd in het beleid.
Van de diensten die door de SWA worden uitgevoerd, is de evaluatie van HTTPS-verkeer het belangrijkst vanuit prestatieoogpunt. Het percentage gedecodeerd verkeer heeft een directe invloed op de grootte van het apparaat. Een beheerder kan erop rekenen dat ten minste 75% van het webverkeer HTTPS is.
Na de eerste installatie moet het percentage gedecodeerd verkeer worden bepaald om ervoor te zorgen dat de verwachtingen voor toekomstige groei nauwkeurig worden vastgesteld. Na inzet moet dit aantal eenmaal per kwartaal worden gecontroleerd. Het vinden van het percentage van gedecodeerd 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 voorbeeldopdrachten 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 passthrough-actie wordt gebruikt wanneer de client en 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 starten 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-handshake uitvoert, is wanneer de servernaam of het IP-adres in een aangepaste categorie aanwezig is. Dit is ingesteld op passthrough 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 op aan de proxy voordat de TLS-sessie wordt gestart (in de host-header), zodat dit veld wordt vergeleken met de aangepaste categorie.
In een transparante implementatie controleert SWA het veld Server Name Indication (SNI) in het Hello-bericht van de TLS-client en evalueert het met de aangepaste categorie. Als de host-header of SNI niet aanwezig is, moet SWA de handshake met de server voortzetten om de velden Subject Alternative Name (SAN) en Common Name (CN) op het certificaat te controleren (in deze volgorde).
Om het aantal TLS-handshakes te verminderen, stelt u vertrouwde servers in op passthrough uit aangepaste rubrieklijsten. In tegenstelling tot webcategorieën of reputatiescores (waarvoor SWA nog steeds een TLS-handshake moet voltooien), omzeilt dit de volledige handshake, maar voorkomt het geldigheidscontroles van certificaten.
Gezien de snelheid waarmee nieuwe sites op het web verschijnen, is het waarschijnlijk dat een aantal sites ongecategoriseerd worden gevonden door de webreputatie en categorisatiedatabanken die door SWA worden gebruikt. Dit betekent niet dat de site is meer kans om kwaadaardig te zijn, en al deze sites zijn nog steeds onderworpen aan AV-scanning, AMP-bestand reputatie en analyse, en elk object blokkeren. Om deze redenen wordt het niet aanbevolen om ongecategoriseerde sites te laten vallen (in de meeste omstandigheden). Het is het beste om deze te decoderen en te scannen door de AV-engines en te evalueren door AVC, AMP, toegangsbeleid, enzovoort. Meer informatie over ongecategoriseerde sites vindt u in het gedeelte Toegangsbeleid.
Toegangsbeleid
Net als het ID-profiel worden de criteria die in het decoderingsbeleid zijn vastgesteld ook geëvalueerd als een logische EN met een belangrijke uitzondering wanneer informatie van de ISE wordt gebruikt. Het gedrag voor beleidsmatching wordt vervolgens uitgelegd op basis van welke elementen zijn geconfigureerd (AD-groep, gebruiker of SGT):
- Advertentiegroepen en gebruikers - Geen wijziging in eerder gedrag omdat het beleid is afgestemd als de gebruiker lid is van een groep, OF als de gebruiker is opgegeven in het beleid.
- SGT- en AD-groepen en -gebruikers - Het beleid komt overeen 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 komt overeen als de gebruiker is gekoppeld aan de SGT OF de gebruiker is gespecificeerd in het beleid.
HTTP-verkeer wordt onmiddellijk na authenticatie geëvalueerd aan de hand van het toegangsbeleid. HTTPS-verkeer wordt geëvalueerd nadat het is geverifieerd en als de decoderingsactie wordt toegepast volgens het overeenkomende decoderingsbeleid. Voor gedecodeerde verzoeken zijn er twee access_log-items. Het eerste logboekitem toont de actie die is toegepast op de eerste TLS-verbinding (decoderen) en een tweede logboekitem toont de actie die door het toegangsbeleid is toegepast op het gedecodeerde HTTP-verzoek.
Zoals uitgelegd in de sectie Web Proxy, worden range request headers gebruikt om een specifiek byte-bereik van een bestand aan te vragen en worden deze vaak gebruikt door OS- en applicatie-update services. De SWA verwijdert deze headers standaard van uitgaande verzoeken, omdat het zonder het hele bestand onmogelijk is om malware te scannen of AVC-functies te gebruiken. Als veel hosts op het netwerk vaak kleine bytebereiken aanvragen om updates op te halen, kan dit SWA ertoe aanzetten om het hele bestand meerdere keren tegelijk te downloaden. Dit kan snel de beschikbare internetbandbreedte uitputten en serviceonderbrekingen veroorzaken. De meest voorkomende oorzaken van dit storingsscenario zijn Microsoft Windows-updates en Adobe-software-update-daemons.
Om dit te beperken, is de beste oplossing om het verkeer helemaal rond de SWA te sturen. Dit is niet altijd haalbaar voor transparant geïmplementeerde omgevingen, en in deze gevallen is de volgende beste optie om een speciaal toegangsbeleid voor het verkeer te maken en het doorsturen van bereikaanvragen op dat beleid in te schakelen. U moet er rekening mee houden dat AV-scanning en AVC niet mogelijk is voor deze verzoeken en dat het beleid zodanig moet zijn ontworpen dat alleen het beoogde verkeer wordt getarget. De beste manier om dit te bereiken is door de user-agent string in de request header te matchen. De user-agent string voor algemene 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 wordt beschreven in de sectie Decryptiebeleid, wordt het niet aanbevolen om ongecategoriseerde sites te laten vallen in het decryptiebeleid. Om dezelfde redenen wordt het niet aanbevolen om ze te blokkeren in het toegangsbeleid. De DCA-engine (Dynamic Content Analysis) kan de inhoud van een bepaalde site gebruiken, samen met andere heuristische gegevens voor gecategoriseerde sites die zonder categorie worden gemarkeerd door URL-database-zoekopdrachten. 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 om verkeer te identificeren te onderzoeken 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-categorieën
De aangepaste rubrieklijsten worden gebruikt om een server te identificeren op basis van 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 als dat nodig is. Een "." kan worden toegevoegd aan het begin van een domeinnaam om overeen te komen met een subdomein zonder regex te gebruiken.
Bijvoorbeeld, ".cisco.com" komt ook overeen met "www.cisco.com." Zoals uitgelegd in de sectie Complexiteit, wordt lage complexiteit gedefinieerd als 10 aangepaste rubrieklijsten, 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 proxy's voor al het Office 365-verkeer te omzeilen om de prestaties te optimaliseren. Microsoft-documentatie vermeldt:
Let op: "Hoewel SSL Break and Inspect de grootste latentie creëert, kunnen andere services zoals proxyverificatie en reputatieonderzoek slechte prestaties en een slechte gebruikerservaring veroorzaken. Bovendien hebben deze perimeternetwerkapparaten voldoende capaciteit nodig om alle netwerkverbindingsverzoeken te verwerken. We raden aan om uw proxy- of inspectieapparaten te omzeilen voor directe Office 365-netwerkverzoeken." Ga voor meer informatie naar: Microsoft 365-eindpunten beheren.
Vanaf AsyncOS versie 11.8 kunt u de dynamische categorielijst die is opgehaald van de Office365 API gebruiken om de lijst met bypass-instellingen 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 begeleiding te gebruiken in een transparante proxy-omgeving.
Het omzeilen van al het Office 365-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 nodig is voor de toepassingen. De grootte moet op de juiste manier worden aangepast om de extra TCP-verbindingen die vereist zijn voor Office365-toepassingen mogelijk te maken. Dit kan het totale aantal verbindingen verhogen tussen 10% en 15% persistente TCP-sessies per gebruiker.
De decrypt en re-encrypt acties uitgevoerd door de HTTPS-proxy introduceren een kleine hoeveelheid latentie voor de verbindingen. Office365-applicaties kunnen gevoelig zijn voor latentie, en als andere factoren zoals langzame WAN-verbindingen en ongelijksoortige geografische locatie verbinding, kan deze gebruikerservaring lijden.
Sommige Office365-toepassingen maken gebruik van eigen TLS-parameters die voorkomen dat de HTTPS-proxy een handshake 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 SNI-veld (Server Name Indication) in het Hello-bericht van de TLS-client, u moet dit verkeer volledig omzeilen. AsyncOS v11.8 introduceerde de mogelijkheid om verkeer alleen op basis van het IP-adres van de bestemming te omzeilen, zonder certificaatcontroles om dit scenario aan te pakken.
Monitoren en waarschuwingen
CLI-monitoren
De SWA CLI biedt opdrachten voor realtime bewaking 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, inclusief uptime, gebruikte bandbreedte, responssnelheid, 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 124502Het uitvoeren van de opdracht rate toont realtime informatie over het percentage CPU dat wordt gebruikt door het prox-proces, het aantal verzoeken per seconde (RPS) en cachestatistieken. Deze opdracht blijft pollen en geeft nieuwe uitgangen weer 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 44Als u de opdracht tcpservices uitvoert, wordt informatie weergegeven over geselecteerde procesluisterpoorten. 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 de hoeveelheid en samenstelling van het verkeer dat door het apparaat wordt geleid regelmatig opnieuw te beoordelen. U moet het percentage gedecodeerd verkeer regelmatig controleren (eenmaal per kwartaal) om ervoor te zorgen dat de grootte in overeenstemming is met de verwachtingen en specificaties van de eerste installatie. Dit kan worden gedaan met een logbeheerproduct zoals Advanced Web Security Reporting (AWSR) of met Bash- of PowerShell-opdrachten met toegangslogboeken. Het aantal RPS moet regelmatig opnieuw worden beoordeeld om ervoor te zorgen dat het apparaat voldoende overhead heeft om rekening te houden met pieken in het verkeer en mogelijke failover in een configuratie met hoge beschikbaarheid en taakverdeling.
Het log track_stats wordt elke vijf minuten toegevoegd en bevat verschillende uitvoersecties die rechtstreeks verband houden met het prox-proces en de objecten in het geheugen. In prestatiebewaking omvatten de gemiddelde latentieaanvraagprocessen, DNS-opzoektijd, AV-motorscantijd en nog veel meer enkele nuttige velden. Dit log kan niet worden geconfigureerd vanuit de GUI of de CLI en is alleen toegankelijk via het Secure Copy Protocol (SCP) of het File Transfer Protocol (FTP). Dit is een belangrijk logboek om te hebben bij het oplossen van problemen met de prestaties, omdat het vaak moet worden gepolst.
Elke 60 seconden wordt een afzonderlijke SHD-logregel geschreven die velden bevat die belangrijk zijn voor prestatiemonitoring, waaronder latentie, RPS, totale client-side en server-side verbindingen. Dit is een voorbeeld van een SHD-loglijn:
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.0Extra aangepaste velden kunnen worden toegevoegd aan de access_logs die latentiegegevens voor individuele verzoeken aangeven. Deze velden omvatten serverrespons, DNS-resolutie en latentie van de AV-scanner. De velden moeten aan het logboek worden toegevoegd om waardevolle informatie te verzamelen voor het oplossen van problemen. Dit is de aanbevolen aangepaste veldtekenreeks voor gebruik:
[ 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] Informatie over de prestaties die is afgeleid van deze waarden wordt weergegeven in de tabel:
| Aangepast veld | Beschrijving |
| %: <a | Wacht tijd om het antwoord van het webproxyverificatieproces te ontvangen nadat de webproxy het verzoek heeft verzonden. |
| %:<b | Wacht tijd om na de koptekst een verzoektekst naar de server te schrijven. |
| %:<d | Wacht tijd om het antwoord van het web proxy DNS-proces te ontvangen nadat de web proxy het verzoek heeft verzonden. |
| %: <h | Wacht tijd om een aanvraagheader naar de server te schrijven na de eerste byte. |
| %:<r | Wacht tijd om het antwoord van de webreputatiefilters te ontvangen nadat de webproxy het verzoek heeft verzonden. |
| %: <s | Wacht tijd om het vonnis van de web proxy anti-spyware proces te ontvangen nadat de web proxy het verzoek verzendt. |
| %:> | Wacht op de eerste byte van de server. |
| %:>a | Wacht tijd om het antwoord van het webproxyverificatieproces te ontvangen. Inclusief de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:>b | Wacht na ontvangst van de koptekst op de volledige antwoordtekst. |
| %:>c | Tijd die de webproxy nodig heeft om een antwoord uit de schijfcache te lezen. |
| %:>d | Wacht tijd om het antwoord van het web proxy DNS proces te ontvangen. Inclusief de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:>h | Wacht op de serverheader na de eerste antwoordbyte. |
| %:>r | Wacht tijd om het vonnis te ontvangen van de webreputatiefilters. Inclusief de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:>s | Wacht tijd om het vonnis van de web proxy antispyware proces te ontvangen. Inclusief de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:1< | Wachttijd voor de eerste byte-aanvraag van een nieuwe clientverbinding. |
| %:1> | Wacht op de eerste byte die naar een client is geschreven. |
| %:b< | Wachttijd voor een volledige klantenkring. |
| %:b> | Wachttijd voor het volledige lichaam geschreven aan een klant. |
| %:e> | Wacht tijd om het antwoord van de AMP-scanengine te ontvangen nadat de webproxy het verzoek heeft verzonden. |
| %:e< |
Wacht tijd om het vonnis van de AMP-scanengine te ontvangen. Inclusief de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:h< | Wacht op de volledige clientkoptekst na de eerste byte. |
| %:h> | Wacht op de volledige koptekst die naar een client is geschreven. |
| %:m< | Wacht tijd om het vonnis van de McAfee-scanengine te ontvangen. Inclusief de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %:m> | Wacht op het antwoord van de McAfee-scanengine. Nadat de webproxy het verzoek heeft verzonden. |
| %F | Client-bronpoort. |
| %p | Webserverpoort. |
| %k | IP-adres van gegevensbron (IP-adres van webserver). |
| %: w< | Wacht tijd om het vonnis van de webroot scanning engine te ontvangen. Inclusief de tijd die de webproxy nodig heeft om het verzoek te verzenden. |
| %: w> | Wacht tijd om het antwoord van de webroot scanning engine te ontvangen. Nadat de webproxy het verzoek heeft verzonden. |
Het SWA-licentiemodel maakt het hergebruik van fysieke toestellicenties voor virtuele apparaten mogelijk. U kunt hiervan profiteren en SWAv-testapparaten implementeren 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 ingezet om de rapportage van gegevens van SWA te waarborgen, met name in omgevingen waar veel SWA's worden ingezet. Deze oplossing is schaalbaarder dan het gebruik van gecentraliseerde rapportage op een Security Management Appliance (SMA) en biedt aangepaste rapportagekenmerken die diepte en maatwerk aan uw gegevens toevoegen. Rapporten kunnen worden gegroepeerd en aangepast aan de behoeften van elke organisatie. Cisco Advanced Services Group moet worden ingezet bij de dimensionering van AWSR.
E-mailbericht
Het ingebouwde e-mailwaarschuwingssysteem op SWA kan het beste worden gebruikt als een basiswaarschuwingssysteem. Het moet op de juiste manier worden aangepast om aan de behoeften van de beheerder te voldoen, omdat het lawaaierig kan zijn als alle informatiegebeurtenissen zijn ingeschakeld. Het is belangrijk om de waarschuwingen te beperken en actief te controleren dan het is om alles te waarschuwen en te negeren als spam.
| Waarschuwingsinstellingen | Configuratie |
| Van adres naar gebruik bij het verzenden van waarschuwingen | Automatisch gegenereerd |
| Eerste aantal seconden wachten voordat u een dubbele waarschuwing verzendt | 300 seconden |
| Maximum aantal seconden wachten voordat u een dubbele waarschuwing verzendt | 3600 seconden |
Beschikbaarheidsbewaking
Er zijn twee methoden die kunnen worden gebruikt om de beschikbaarheid van een webproxy te bewaken.
- 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 op regelmatige tijdstippen naar het adres te sturen en te controleren op een antwoordpakket. De attributen van het antwoord, zoals TTL en latentie, kunnen worden geparseerd om de gezondheid van de netwerklaag te bepalen.
- Het is mogelijk dat een apparaat reageert op pings, maar de proxy-processen reageren niet 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-antwoordcode verwacht. Dit test de bereikbaarheid van de netwerkinterface, de responsiviteit van de proxydiensten en de levensvatbaarheid van upstreamdiensten als om 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 resource. De HEAD-methode vraagt om de headers terug te sturen en de client moet een GET-verzoek verzenden. Dit omvat alleen de antwoordkoppen zonder gegevens.
- Als u een L7-controletool of -script gebruikt, moet u ervoor zorgen dat het verkeer is vrijgesteld van verificatie. Anders resulteert dit in authenticatiefouten en verbruik van bronnen. Wanneer u een aangepaste user-agent-tekenreeks gebruikt in het controleprogramma, moet deze worden gebruikt om 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 aanvaardbare statistieken rond de proxy-respons vaststellen en deze gebruiken om waarschuwingsdrempels 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 toestel (traps) te ontvangen of om verschillende Object Identifiers (OID's) te peilen om informatie te verzamelen. Er zijn veel OID's beschikbaar op de SWA die het gebruik van hardware voor bronnengebruik beschrijven om individuele en statistische informatie te verwerken.
Er zijn een aantal specifieke Machine Information Base (MIB) die moeten worden gecontroleerd voor zowel hardware en prestaties gerelateerde redenen. Raadpleeg de volledige lijst met MIB's.
Dit is een lijst van 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 CLI-opdracht voor statusdetails:
| OID | Naam | Statusdetailveld |
| Systeembronnen | ||
| 1.3.6.1.4.1.15497.1.1.1.2.0 | procentCPUgebruik | CPU |
| 1.3.6.1.4.1.15497.1.1.1.1.0 | percentageGeheugengebruik | RAM |
| Transacties per seconde | ||
| 1.3.6.1.4.1.15497.1.2.3.7.1.1.0 | cacheThruputNow | Gemiddelde transacties per seconde in de laatste minuut. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.2.0 | cacheThruput1hrPeak | Maximum aantal transacties per seconde in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.3.0 | cacheDoorvoer1 uurGemiddelde | 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 proxyherstart. |
| 1.3.6.1.4.1.15497.1.2.3.7.1.9.0 | cacheThruputLifeMean | Gemiddelde transacties per seconde sinds proxy opnieuw wordt gestart. |
| 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 | cacheBwidthTotaal 1hrPeak | Maximale bandbreedte in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.3.0 | cacheBwidthTotaal1uGemiddelde | Gemiddelde bandbreedte in het laatste uur. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.8.0 | cacheBwidthTotalLifePeak | Maximale bandbreedte sinds proxyherstart. |
| 1.3.6.1.4.1.15497.1.2.3.7.4.9.0 | cacheBwidthTotalLifeMean | Gemiddelde bandbreedte sinds proxyherstart. |
| reactietijd | ||
| 1.3.6.1.4.1.15497.1.2.3.7.9.1.0 | cacheHitsNow | Gemiddelde cache hit rate op het laatste moment. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.2.0 | cacheHits1hrPeak | Maximale cachesnelheid 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 cachesnelheid sinds proxyherstart. |
| 1.3.6.1.4.1.15497.1.2.3.7.9.9.0 | cacheHitsLifeMean | Gemiddelde cachesnelheid sinds proxyherstart. |
| Cachesnelheid | ||
| 1.3.6.1.4.1.15497.1.2.3.7.5.1.0 | cacheHitsNow | Gemiddelde cache hit rate op het laatste moment. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.2.0 | cacheHits1hrPeak | Maximale cachesnelheid 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 cachesnelheid sinds proxyherstart. |
| 1.3.6.1.4.1.15497.1.2.3.7.5.9.0 | cacheHitsLifeMean | Gemiddelde cachesnelheid sinds proxyherstart. |
| Verbindingen | ||
| 1.3.6.1.4.1.15497.1.2.3.2.7.0 | cacheClientIdleConns | Inactieve 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 | Totaal aantal serververbindingen. |
Nuttige links
- Firewall configureren voor Secure Web Appliance
- Inzicht in de toegangspunten voor veilige webapparaten
- Secure Web Appliance installeren op VMware ESXi
- Secure Web Appliance installeren op Microsoft Hyper-V
- Configuratie tussen twee SWA's migreren
- Secure Web Appliance terugzetten naar vorige versie
- Back-up configureren in Secure Web Appliance
- Active Directory-verificatie configureren in SWA
- Eenmalige aanmeldingsverificatie van Kerberos configureren in SWA
- Verificatie omzeilen in Secure Web Appliance
- Executable File Download blokkeren in SWA
- Microsoft O365-huurdersbeperking configureren in SWA
- Microsoft Updates-verkeer omzeilen in Secure Web Appliance
- Specifieke YouTube-kanaal / video inschakelen en de rest van YouTube blokkeren in SWA
- Aangepaste URL-categorieën configureren in Secure Web Appliance
- Upstream-proxy configureren in Secure Web Appliance
- SNMP configureren en oplossen in SWA
- Problemen oplossen met de DNS-service van een beveiligd webapparaat
- Packet Capture configureren op Content Security Appliance
- Toegang tot beveiligde logbestanden van webapparaten
- Prestatieparameter configureren in toegangslogboeken
- Problemen met de prestaties van veilige webapparaten oplossen met SHD-logboeken
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
5.0 |
16-Jul-2026
|
Bijgewerkte spelling, grammatica, zinsstructuur, introductie, ingevoegde regels om secties / leesbaarheid te scheiden, 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)