Best practices voor veilige webapparaten gebruiken

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, waaronder de ondersteunde netwerkomgeving, beleidsconfiguratie, bewaking en probleemoplossing. Hoewel de best practices die hier worden beschreven 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 ook de IP-adressen van de client vervalsen, waardoor de implementatie nog ingewikkelder wordt en extra eisen worden gesteld aan de ondersteunende netwerkconfiguratie. In deze handleiding worden de meest voorkomende problemen met betrekking tot de configuratie van netwerkapparaten behandeld.

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. Er wordt ook aandacht besteed aan specifieke functies en hoe deze moeten worden geconfigureerd om de veiligheid, schaalbaarheid en effectiviteit te vergroten.

In het gedeelte Monitoring en waarschuwingen van dit document worden de meest effectieve manieren om het toestel te bewaken toegelicht en wordt ook ingegaan op de monitoring van prestaties en beschikbaarheid, evenals het gebruik van systeembronnen. Het biedt ook nuttige informatie bij het oplossen van basisproblemen.

netwerkomgeving

ICMP

Path MTU Discovery, zoals gedefinieerd in RFC 1191, Het mechanisme bepaalt de maximale grootte van een pakket langs willekeurige paden. In het geval van IPv4 kan een apparaat de maximale transmissie-eenheid (MTU) van elk pakket langs een pad bepalen door het Do not Fragment (DF)-bit in de IP-header van het pakket in te stellen. Als een apparaat bij een link langs het pad het pakket niet kan doorsturen zonder het te fragmenteren, wordt een ICMP-fragmentatie (Internet Control Message Protocol) nodig (Type 3, Code 4) bericht teruggestuurd naar de bron. De klant stuurt dan een kleiner pakket terug. 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 worden uitgeschakeld in de SWA die de opdracht pathmutudiscovery-opdrachtregelinterface (CLI) gebruikt. Als u dit doet, daalt de standaard MTU naar 576 bytes (per RFC 879), wat de prestaties ernstig beïnvloedt. De beheerder moet de extra stap zetten door de MTU handmatig te configureren in de opdracht SWA from etherconfig CLI.

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. In dit geval worden andere protocollen, zoals ICMP, niet doorgestuurd naar de SWA. Het is mogelijk dat de SWA een ICMP Fragmentation Needed-bericht van een router op het netwerk kan activeren, maar het bericht wordt niet aan de SWA geleverd. 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 met behulp van de CLI-opdracht etherconfig.

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. Het is noodzakelijk ervoor te zorgen dat Network Address Translation (NAT)-apparaten een voldoende grote pool van externe adressen en poorten hebben om hieraan tegemoet te komen. 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 het IP-adres van de client te vervalsen wanneer deze communiceert met een upstream server. Beschermingen 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 worden vrijgesteld van deze bescherming.

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 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 het clientaanvraagverkeer, P2 mag daarentegen 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 functie bewaakt een gespiegelde laag 2-poort en voegt de mogelijkheid toe om verkeer te blokkeren 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 is gekoppeld. 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 Time to Live (TTL) van het 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.

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 diensten waarvoor routering kan worden ingesteld:

• Externe URL-feeds
• Advanced Malware Protection (AMP) bestands reputatie en analyse
• Updates en upgrades
• DNS
• Active Directory

Voor extra egresfilters van beheerverkeer kunnen statische adressen worden geconfigureerd voor gebruik in deze services:

• Externe URL-feeds:
  1. Custom 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)

• Updates en upgrades:
  1. downloads-static.ironport.com
  2. updates-static.ironport.com

TALOS-telemetrie

De Cisco Talos-groep 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 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 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 kan zijn 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. De tabel is de time-out voor een query voor maximaal zes DNS-servers:

Er zijn ook geavanceerde DNS-opties die alleen beschikbaar zijn via de CLI. Deze opties zijn beschikbaar in CLI met de opdracht Advanced proxyconfig > DNS.

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 van de bestemming en een hostnaam. De SWA moet beslissen of hij het oorspronkelijke IP-adres van de bestemming voor de TCP-verbinding vertrouwt of zijn eigen DNS-resolutie uitvoert 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 dat 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 in het geval er een mix van toestelmodellen in het netwerk is, en apparaten kunnen zonder downtime worden toegevoegd en verwijderd uit de servicepool. Zodra de behoefte groter is dan wat met acht SWA's kan worden verwerkt, wordt aanbevolen een speciale taakverdeler te gebruiken.

Specifieke best practices voor WCCP-configuratie variëren afhankelijk van het gebruikte platform. Voor Cisco Catalyst®-switches zijn de best practices gedocumenteerd in het witboek 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. Om deze reden 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 Autoconfiguration) de meest gebruikte methode, maar het heeft veel 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 Autodiscover 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 bij gebruik in een omgeving met hoge beschikbaarheid. 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 geen NTLMSSP, maar kan Kerberos gebruiken om te verifiëren of een domein zich heeft 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 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 gebruikersnaam en wachtwoord worden ingesteld in het configuratiescherm Internetopties.

Aanvullende instellingen zijn ook vereist in Firefox voor de browser 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 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 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. Door passief gebruikers te identificeren, is er geen directe verificatie-uitdaging en geen Active Directory-communicatie van de SWA nodig, wat op zijn beurt de latentie en het bronnengebruik op het toestel vermindert. De momenteel 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 ISE Compatibility Matrix for SWA.

Zie Eindgebruikershandleiding voor webbeveiligingsapparatuur voor meer informatie over volledige integratiestappen.

Cisco kondigt het einde van de levenscyclus van de Cisco Context Directory Agent (CDA)-software aan, zie Cisco Context Directory Agent (CDA).

Vanaf CDA-patch 6 is deze 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 bevraagt de SWA deze mappings met RADIUS. In het geval van ISE-PIC worden dezelfde pxGrid- en ERS-verbindingen gebruikt als bij de volledige ISE-implementatie. De ISE-PIC-functionaliteit is beschikbaar in een volledige ISE-installatie en in een zelfstandig virtueel apparaat.

Configuratie van services

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 in de 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 deze manier wordt het aanvalsoppervlak van het apparaat verminderd en wordt een goed beveiligingsprincipe toegepast: schakel het uit als het niet nodig is.

Range request headers worden gebruikt in HTTP-verzoeken om het byte bereik van een te downloaden bestand op te geven. Het wordt vaak gebruikt door het besturingssysteem en applicatie update daemons om kleine delen van een bestand per keer over te dragen. De SWA stript deze headers standaard zodat het hele bestand kan worden gebruikt voor antivirusscans, bestands- en reputatieanalyse en AVC (Application Visibility Control). 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 de sectie Toegangsbeleid.

HTTPS-proxy

Best practices voor beveiliging suggereren dat privésleutels moeten worden gegenereerd op het apparaat waar ze worden gebruikt en nooit elders 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 vervolgens 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 leidde tot meer helpdesktickets en een veronderstelling van de gebruiker dat er iets kapot is, in plaats van de wetenschap dat de SWA de verbinding heeft geblokkeerd. Alle ongeldige certificaatopties moeten zijn ingesteld op ten minste Decrypt. Als u een van deze opties als Monitor laat staan, kunt u geen nuttige foutberichten registreren in het geval dat certificaatproblemen voorkomen dat een site wordt geladen.

Evenzo moeten Online Certificate Services Protocol (OCSP)-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 een manier waarop een client de ondertekenaar van het certificaat kan ophalen, en een URL waaruit aanvullende certificaten kunnen worden opgehaald. Als een van een server ontvangen certificaatketen bijvoorbeeld onvolledig is (er ontbreekt een tussenliggend of hoofdcertificaat), 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 de 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, omdat veel moderne servers op dit mechanisme vertrouwen 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 monitoren 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. Dit geldt niet alleen vanwege de effectiviteit van het beleid zelf bij het beschermen van klanten en het handhaven van bedrijfsvereisten, maar ook omdat welk beleid wordt geconfigureerd een directe invloed heeft op het gebruik van middelen en de algehele gezondheid en prestaties van de SWA. Een te complexe of slecht ontworpen reeks beleidsregels kan leiden tot instabiliteit en een trage respons van het apparaat.

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 de 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. Tien identiteitsprofielen, decoderingsbeleid en toegangsbeleid, samen met tien aangepaste categorieën met tien regex-vermeldingen, vijftig server-IP-adressen en 420 serverhostnamen, worden beschouwd als een configuratie met lage complexiteit. Vermenigvuldiging van elk van deze cijfers met twee en drie resulteert in respectievelijk een configuratie met middelmatige complexiteit en 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 een nuttige manier zijn om een te complexe configuratie te diagnosticeren als de oorzaak van een trage SWA.

De CPU-tijd, in seconden, wordt elke vijf minuten vastgelegd 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 is bijna altijd omdat de configuratie te complex is om efficiënt te worden ontleed.

Opmerking: tot nu toe heeft SWA 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 alleen zo specifiek zijn als absoluut noodzakelijk is. Profielen met individuele hostadressen zijn bijna nooit nodig en kunnen leiden tot uitgestrekte configuraties. Gebruikmaken van de user-agent string in de HTTP headers, custom category list, of subnet is over het algemeen een betere strategie om het bereik van een profiel te beperken.

Over het algemeen worden beleidsregels die verificatie vereisen, onderaan geconfigureerd en worden er uitzonderingen bovenop 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 bekend is dat een 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 zich 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 decoderingsbeleid 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 decryptie- en toegangsbeleidsregels. Dit is mogelijk omdat alle criteria in een bepaald beleid moeten overeenkomen, zodat het verkeer overeenkomt met het beleid. Meer algemeen in het authenticatiebeleid en specifieker in het resulterende beleid zorgt voor minder beleid als geheel.

Decoderingsbeleid

Net als bij het ID-profiel worden de criteria die in het decoderingsbeleid zijn vastgesteld ook geëvalueerd als een logische EN, met één belangrijke uitzondering wanneer informatie uit de ISE wordt gebruikt. Hier ziet u hoe beleidsmatching werkt, 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 wordt aangepast 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 aangepast als de gebruiker is gekoppeld aan de SGT of als de gebruiker is opgegeven in het beleid.

Van alle 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 HTTPS-verkeer dat wordt gedecodeerd door de SWA is eenvoudig te doen met een kopie van de access_logs, zelfs zonder extra logbeheersoftware. Eenvoudige Bash- of PowerShell-opdrachten kunnen worden gebruikt om dit nummer te verkrijgen. Hier zijn de stappen die voor elke omgeving worden beschreven:

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. Dit komt omdat de SWA ervoor moet kiezen om een verbinding te blokkeren op basis van de geldigheid van het certificaat en een TLS-verbinding met de server moet 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 de SWA geen TLS-handshake uitvoert, is wanneer de servernaam of het IP-adres aanwezig is in een aangepaste categorie, die is ingesteld op passthrough, en de servernaam beschikbaar is 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. Bij een transparante implementatie controleert de 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 de SWA de handshake met de server voortzetten om de velden Alternatieve naam onderwerp (SAN) en Gemeenschappelijke naam (CN) op het certificaat in die volgorde te controleren.

Wat dit gedrag betekent voor beleidsontwerp, is dat het aantal TLS-handshakes kan worden verminderd door bekende en intern vertrouwde servers te bepalen en deze in te stellen op passthrough van de aangepaste categorielijst, in plaats van te vertrouwen op webcategorie en reputatiescore, waarvoor de SWA nog steeds een TLS-handshake met de server moet voltooien. Het is echter belangrijk op te merken dat dit ook controles van de geldigheid van certificaten voorkomt.

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 de SWA worden gebruikt. Dit betekent niet dat de site noodzakelijkerwijs meer kans heeft om kwaadaardig te zijn, en bovendien worden al deze sites nog steeds onderworpen aan AV-scanning, AMP-bestands- en reputatieanalyse en elk object dat wordt geblokkeerd of gescand dat is geconfigureerd. Om deze redenen wordt het niet aanbevolen om ongecategoriseerde sites in de meeste omstandigheden te laten vallen. Het is het beste om ze te decoderen en te scannen door de AV-engines en geëvalueerd door AVC, AMP, toegangsbeleid, enzovoort. Meer informatie over ongecategoriseerde sites vindt u in het gedeelte Toegangsbeleid.

Toegangsbeleid

Net als bij het ID-profiel worden de criteria die in het decryptiebeleid 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; 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 wordt aangepast 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 opgegeven 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 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 de SWA activeren 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-update en Adobe-software-update-daemons.

Om dit te beperken, is de beste oplossing om dit 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. Er moet rekening mee worden gehouden dat AV-scanning en AVC niet mogelijk is voor deze verzoeken, en dus moet het beleid zorgvuldig worden ontworpen om alleen het beoogde verkeer te targeten. Vaak is de beste manier om dit te bereiken door de user-agent-tekenreeks in de verzoekheader 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 in het decryptiebeleid te laten vallen. 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 anders zouden worden gemarkeerd door zoekopdrachten in de URL-database. Als u deze functie inschakelt, wordt het aantal niet-gecategoriseerde vonnissen in de SWA verminderd.

De instellingen voor het scannen van objecten van een toegangsbeleid bieden de mogelijkheid om verschillende typen archiefbestanden te inspecteren. Als het netwerk regelmatig archiefbestanden downloadt als onderdeel van toepassingsupdates, kan het inschakelen van archiefbestandsinspectie het CPU-gebruik aanzienlijk verhogen. Dit verkeer moet van tevoren worden geïdentificeerd en vrijgesteld als het de bedoeling is om alle archiefbestanden te inspecteren. De eerste plaats om mogelijke methoden om dit verkeer te identificeren te onderzoeken is de user-agent string, omdat dit kan helpen voorkomen dat IP-toegestane lijsten die omslachtig te onderhouden kan worden.

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 waarmee servernamen kunnen worden gekoppeld. Het gebruik van een regex-patroon om een servernaam te matchen is veel meer arbeidsintensief dan het gebruik van een subtekenreeksovereenkomst, en daarom moeten ze alleen worden gebruikt wanneer dit absoluut noodzakelijk is. Een "." kan worden toegevoegd aan het begin van een domeinnaam om een subdomein te matchen zonder de noodzaak van regex. Bijvoorbeeld, ".cisco.com" komt ook overeen met "www.cisco.com."
Zoals uitgelegd in de sectie Complexiteit, wordt lage complexiteit gedefinieerd als tien aangepaste rubrieklijsten, gemiddelde complexiteit als twintig en hoge complexiteit als dertig. Het wordt aanbevolen om dit aantal onder de twintig 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 veel 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. Omdat deze functie kan worden gebruikt om lijsten op te halen die niet worden onderhouden of beheerd door de SWA-beheerder, is de mogelijkheid om individuele uitzonderingen toe te voegen aan de gedownloade adressen toegevoegd in AsyncOS versie 11.8.

De Office365 API is vooral handig om beleidsbeslissingen te nemen 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." - https://learn.microsoft.com/en-us/microsoft-365/enterprise/managing-office-365-endpoints?view=o365-worldwide

Het kan moeilijk zijn om deze leidraad te gebruiken in een transparante proxy-omgeving. Vanaf AsyncOS versie 11.8 is het mogelijk om de dynamische categorielijst die is opgehaald van de Office365 API te gebruiken om de lijst met bypass-instellingen te vullen. Deze lijst wordt gebruikt om transparant omgeleid verkeer terug te sturen naar het WCCP-apparaat voor directe routering.

Het omzeilen van al het Office365-verkeer creëert een blinde vlek voor beheerders die enkele basisbeveiligingscontroles en rapportage voor dit verkeer nodig hebben. Als Office365-verkeer niet wordt omzeild door de 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 permanente TCP-verbindingen die door Office365-toepassingen worden vereist, mogelijk te maken. Dit kan het totale aantal verbindingen met tien tot vijftien aanhoudende TCP-sessies per gebruiker verhogen.

De decrypt en re-encrypt acties uitgevoerd door de HTTPS-proxy introduceren een kleine hoeveelheid latentie voor de verbindingen. Office365-applicaties kunnen erg gevoelig zijn voor latentie, en als andere factoren zoals een langzame WAN-verbinding en ongelijksoortige geografische locatie dit verergeren, kan de gebruikerservaring daaronder 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. Wanneer dit wordt gecombineerd met een toepassing zoals Skype voor Bedrijven die geen SNI-veld verzendt in het Hello-bericht van de TLS-client, wordt het noodzakelijk om dit verkeer volledig te omzeilen. AsyncOS 11.8 heeft de mogelijkheid geïntroduceerd 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. Het meest nuttig zijn de opdrachten die statistieken tonen met betrekking tot het prox-proces. De opdracht statusdetails is een goede bron voor een overzicht van het gebruik van bronnen en prestatiemetingen, inclusief uptime, gebruikte bandbreedte, responsslatentie, aantal verbindingen en meer. Hier is een voorbeeld van de uitvoer van deze opdracht:

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            124502

De opdracht rate toont realtime informatie over het percentage CPU dat wordt gebruikt door het prox-proces, evenals het aantal requests per second (RPS) en cachestatistieken. Deze opdracht blijft pollen en geeft nieuwe uitvoer weer totdat deze wordt onderbroken. Dit is een voorbeeld van uitvoer van deze opdracht:

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    44

De opdracht tcpservices geeft informatie weer over geselecteerde procesluisterpoorten. Een uitleg van elk proces en de combinatie van adres en poort 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:32137

Logboekregistratie

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 eenvoudige Bash- of PowerShell-opdrachten met de toegangslogboeken. Het aantal RPS moet ook 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. Het nuttigst bij prestatiemonitoring zijn de secties die de gemiddelde latentie voor verschillende aanvraagprocessen weergeven, waaronder DNS-opzoektijd, AV-motorscantijd en nog veel meer 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 het belangrijkste logboek om te hebben bij het oplossen van problemen met de prestaties, dus het moet vaak worden gepolst.

Elke 60 seconden wordt een afzonderlijke SHD-logregel geschreven die veel velden bevat die belangrijk zijn voor prestatiemonitoring, waaronder latentie, RPS en totale client- en serververbindingen. 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.0

Extra 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 die kan worden gebruikt 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]

De informatie over de prestaties op basis van deze waarden is als volgt:

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 op deze manier worden getest om stabiliteit en betrouwbaarheid te garanderen zonder de licentievoorwaarden te schenden.

Advanced Web Security Reporting (AWSR)

AWSR moet worden gebruikt om de rapportagegegevens van de SWA optimaal te benutten. Vooral in omgevingen waar veel SWA's worden geïmplementeerd, is deze oplossing vele malen schaalbaarder dan het gebruik van gecentraliseerde rapportage op een Security Management Appliance (SMA) en biedt deze aangepaste rapportagekenmerken die een enorme hoeveelheid diepte en aanpassing aan de gegevens toevoegen. Rapporten kunnen worden gegroepeerd en aangepast aan de behoeften van elke organisatie. Cisco Advanced Services-groep moet worden gebruikt bij de dimensionering voor AWSR.

E-mailbericht

Het ingebouwde e-mailwaarschuwingssysteem op de 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 erg luidruchtig kan zijn als alle informatiegebeurtenissen zijn ingeschakeld. Het is belangrijker om de waarschuwingen te beperken en actief te controleren dan om alles te waarschuwen en ze als spam te negeren.

Beschikbaarheidsbewaking

Er zijn twee methoden die kunnen worden gebruikt om de beschikbaarheid van een webproxy te bewaken.

1. 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.
2.  Het is mogelijk dat een apparaat reageert op pings, maar dat de proxy-processen niet reageren of intermitterend zijn. Daarom is het raadzaam om een Layer 7 (L7) monitor te gebruiken, die een expliciet proxyverzoek naar het toestel stuurt en een 200 OK HTTP-responscode verwacht. Hierbij wordt niet alleen de bereikbaarheid van de netwerkinterface getest, maar ook de responsiviteit van de proxydiensten en de levensvatbaarheid van upstreamdiensten als om een externe bron wordt gevraagd. Dit type bewaking 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 de headers die zouden worden geretourneerd, moet de client een GET-verzoek verzenden, maar bevat alleen de antwoordheaders en geen gegevens.
   • Als u een L7-controletool of -script gebruikt, is het belangrijk om ervoor te zorgen dat het verkeer is vrijgesteld van verificatie. Anders resulteert dit in regelmatige authenticatiefouten en verbruik van bronnen. Wanneer u een aangepaste user-agent-tekenreeks gebruikt in het controleprogramma, moet deze worden gebruikt 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 aanvaardbare statistieken rond de proxy-respons vaststellen en deze gebruiken om waarschuwingsdrempels te bouwen. U moet tijd besteden aan het verzamelen van de antwoorden van dergelijke controles en voordat u beslist hoe u de drempels en de waarschuwing configureert.

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 te ontvangen (traps) of om verschillende Object Identifiers (OID's) te peilen om informatie te verzamelen. Er zijn veel OID's beschikbaar op de SWA die alles dekken, van hardware tot gebruik van bronnen tot individuele procesinformatie en aanvraagstatistieken.

Er zijn een aantal specifieke Machine Information Base (MIB) die om hardware- en prestatiegerelateerde redenen moeten worden bewaakt. De volledige lijst van MIB's is hier te vinden: https://www.cisco.com/web/ironport/tools/web/asyncosweb-mib.txt.

Dit is een lijst van de aanbevolen MIB's die moeten worden gecontroleerd en geen uitputtende lijst:

Dit zijn OID's die rechtstreeks zijn toegewezen aan de uitvoer van de CLI-opdracht voor statusdetails:

Conclusie

In deze handleiding worden de belangrijkste aspecten van de configuratie, implementatie en bewaking van SWA beschreven. Als referentiegids heeft het tot doel waardevolle informatie te verstrekken aan degenen die wilden zorgen voor het meest effectieve gebruik van de SWA. De best practices die hier worden beschreven, zijn belangrijk voor de stabiliteit, schaalbaarheid en werkzaamheid van het apparaat als beveiligingsinstrument. Het wil ook blijven als een relevante bron vooruit gaat en moet dus regelmatig worden bijgewerkt om veranderingen in netwerkomgevingen en productfunctiesets weer te geven.