Införa Sophos Firewall TLS-inspektion korrekt

Med TLS Inspection avslutar Sophos Firewall klientens krypterade anslutning och upprättar en andra anslutning till destinationsservern. Den kan inspektera klartexten mellan de två. Brandväggen signerar om ett ursprungligen betrott servercertifikat för klienten med sin egen CA (Certificate Authority). Om klienten inte litar på denna CA, visar den en certifikatvarning eller avslutar anslutningen.

Detta gör det möjligt att inspektera dekrypterat innehåll, exempelvis skanning efter skadlig kod och innehållsskanning. Utan dekryptering kan skyddsfunktioner begränsas, beroende på modul, till information som IP-adress, domän, SNI, certifikat eller protokollmetadata. Det motiverar inte en bred initial distribution: certifikatfästning, sekretess, programkompatibilitet och den extra brandväggsbelastningen måste åtgärdas innan lanseringen.

Den säkra korta versionen är: bestäm om du ska använda DPI- eller webbproxy-sökvägen, distribuera den omsignerande CA till en liten grupp, dokumentera det aktuella tillståndet, skapa en Dekryptera-regel med snäv omfattning, kör ett positivt och ett negativt test, och först därefter utöka omfattningen.

Bestäm dig innan piloten

Licens, CA och ansvar

SSL/TLS-inspektionsregler och URL-grupper som används i dem tillämpas med Base License. Web Protection är inte en generell förutsättning för TLS-inspektion. Det krävs när webbkategorier används som regelkriterier eller när motsvarande webbskyddsfunktioner behövs. Skanning efter skadlig kod, Zero-Day-skydd och andra kontroller kräver respektive prenumeration. Vilka Sophos Firewall-paket är tillgängliga? och Förstå Sophos Firewall Base License förklarar skillnaderna.

Förtydliga följande innan du skapar den första regeln:

• Dokumentera SFOS-versionen som används, den tillgängliga licensen och den avsedda inspektionsvägen.
• Definiera en hanterad pilotgrupp och ett tydligt tidsfönster. Exemplet nedan använder klienten 10.20.30.50 från testnätverket 10.20.30.0/24; ersätt dessa värden med dina egna objekt.
• Skaffa godkännande från ansvariga integritetsintressenter för omfattning, loggning, lagring och användarmeddelande.
• Säkerhetskopiera det exakta initiala tillståndet för brandväggsregeln, TLS-regler, dekrypteringsprofil, CA och eventuella globala inställningar. Dokumentera hela den matchande regelkedjan före piloten, den regel som kommer att matcha efter att piloten inaktiveras (inklusive eventuella lägre placerade, bredare Decrypt-regler) och varje pilotspecifik ändring av brandväggsregler, DPI/proxyläge, webbpolicy och globala inställningar. Definiera de exakta godkända återställningsstegen före aktivering.
• Namnge ägaren, avbrytkriterier, undantagsprocess och återställningsväg.

Den omsignerande certifikatutfärdaren måste finnas i förtroendearkivet för de berörda operativsystemen eller webbläsarna. Alternativt kan du använda en underordnad företags-CA. En offentligt betrodd CA är inte tillgänglig för detta ändamål eftersom brandväggen signerar om certifikat för tredjepartsdomäner. Med en extern certifikatutfärdare måste både rot- och underordnad certifikatutfärdare importeras; om den undertecknande CA innehåller en EKU-sektion måste den tillåta TLS Web Server Authentication. Installera Sophos Firewall CA-certifikat för HTTPS-skanning beskriver distribution, medan Sätt upp en underordnad CA för Sophos Firewall TLS-inspektion täcker företags-CA-metoden.

⚠️ Börja inte med alla användare. Enheter utan ett hanterbart förtroendearkiv, BYOD och applikationer som använder certifikatpinning bör initialt förbli i ett separat omfång. Ett undantag återställer anslutningen, men tar bort dess innehåll från dekryptering.

Håll DPI och webbproxy åtskilda

SFOS använder DPI engine som standard. På den här vägen bearbetar brandväggen brandväggsregeln först och sedan SSL/TLS-inspektionsreglerna. Inspektionsregeln tillåter inte i sig trafik: till och med Services: Any betyder bara att TLS-trafik som redan är tillåten av brandväggsregeln på någon TCP-port är kvalificerad för denna inspektionsregel.

För DPI-sökvägen, öppna Rules and policies > Firewall rules, redigera den relevanta LAN-till-WAN-regeln och kontrollera Security features > Web filtering:

1. Lämna Use web proxy instead of DPI engine inaktiverad.
2. Välj en webbpolicy endast om det planerade skyddet kräver det; det är inte en förutsättning för dekrypteringsregeln.
3. Scan HTTP and decrypted HTTPS möjliggör skanning av skadlig programvara för HTTP och HTTPS som redan har dekrypterats. Alternativet aktiverar inte i sig HTTPS-dekryptering.

I Web Proxy Mode hanterar proxyn HTTPS-dekryptering. Decrypt HTTPS during web proxy filtering är den relevanta inställningen på proxysökvägen. DPI-regler under Rules and policies > SSL/TLS inspection rules gäller inte anslutningar som dekrypteras av webbproxyn. Med den transparenta proxyn passerar portarna 80 och 443 genom proxyn medan SSL/TLS på andra portar fortfarande kan hanteras av DPI-sökvägen; med den explicita proxyn utför webbproxyn dekryptering.

CA:erna är också separata: DPI använder CA från SSL/TLS-inställningarna eller den valda dekrypteringsprofilen. Webproxyn använder CA från Web > General settings. När du byter läge, kontrollera inte bara reglerna utan även den CA som faktiskt presenteras. Välj DPI-motor eller webbproxy korrekt förklarar skillnaderna mer i detalj.

Denna utgående inspektionsväg är inte avsedd för webbservrar publicerade på internet. Web Server Protection / WAF eller en omvänd proxy är vanligtvis den lämpligare arkitekturen där. SSL/TLS-inspektionsregler gäller för utgående trafik, så endast interna zoner kan väljas som Source zones. De upptäcker TLS på vilken TCP-port som helst, men tillämpas inte över UDP.

Motstridig dokumentation om riktningen: Guiden för att skapa regler nämner inkommande och utgående anslutningar, men begränsar senare uttryckligen Source zones till interna zoner och utgående trafik. Den allmänna formuleringen bevisar inte stöd för inkommande WAN-inspektion. Denna utrullning håller sig till den beskrivna interna klientvägen; inkommande serveranslutningar kräver förtydligande från Sophos Support för aktuell build innan någon ändring görs.

Routing, DNS och tillåten internetåtkomst måste redan fungera före dekrypteringstestet. Kontrollera under Rules and policies > NAT rules vilken SNAT-regel som faktiskt matchar; i en vanlig IPv4-internetdesign kan det vara Default SNAT IPv4 med Translated source (SNAT): MASQ. Ersätt inte en fungerande regel med ännu en bred NAT-regel. IPv6 och routade nätverk behöver ett eget designbeslut, inte automatiskt MASQ. Pilotens brandväggsregel behöver Action: Accept och godkänd omfattning för källa, destination och tjänster.

Kontrollera för proxyn också HTTPS scanning certificate authority (CA), Block unrecognized SSL protocols och Block invalid certificates under Web > General settings > HTTPS decryption and scanning. Tillåt för Direct Proxy den konfigurerade lyssnaren under Web > General settings > Web proxy configuration och Administration > Device access > Other services > Web proxy endast för nödvändiga klienter eller zoner. Transparent proxy behöver HTTP/HTTPS-tjänster; Direct Proxy behöver dessutom den konfigurerade lyssnarporten. Den redan länkade DPI/proxy-artikeln beskriver hela arbetsflödet och skyddet av brandväggens lokala webbtjänster.

Föråldrat kompatibilitetsexempel: Den bevarade konfigurationsguiden för SFOS 22/23 kräver TLS 1.1 i sitt proxyexempel, medan profildokumentationen beskriver versioner före TLS 1.2 som osäkra. TLS 1.1 införs därför inte som ett krav för utrullningen. Behåll säkra protokollinställningar; om en äldre applikation behöver ett undantag, klargör först version, berörd väg, risk och snäv omfattning med brandväggens ansvariga. Att sänka TLS globalt är ingen lösning för piloten.

Hantera QUIC medvetet

QUIC, eller HTTP/3, använder UDP. Block QUIC protocol i en brandväggsregel blockerar utgående UDP-paket till portarna 80 och 443 inom den regelns räckvidd, vilket normalt får klienter med ett fungerande TCP-alternativ att försöka igen via TCP; klienter utan ett sådant alternativ kan förlora anslutningen. SFOS väljer alternativet som standard så snart en webbpolicy har valts i regeln eller Scan HTTP and decrypted HTTPS är aktiverat. Detta är per regel, inte globalt, så kontrollera brandväggsregeln som faktiskt matchar. Alternativet omfattar inte UDP på andra portar. Verifiera en faktisk TCP-anslutning, att applikationen fungerar och att den avsedda inspektionsvägen matchar; enbart blockering av UDP bevisar inget av detta.

Detta webbfilter kan inte skanna QUIC. Det betyder inte att alla andra brandväggskontroller förbigås, men den förväntade TCP-TLS- och webbfiltervägen gäller inte. Korrekt blockering av QUIC och HTTP/3 på Sophos Firewall visar regeltestet; Skapa en webbskyddspolicy för Sophos Firewall täcker webbpolicyn.

Välj omfattning efter syfte och risk

Den vanliga utgångspunkten är hanterad användartrafik från LAN till WAN. Ett separat trådlöst företagsnätverk kan följa som Wi-Fi > WAN. För fjärråtkomst är VPN > WAN endast relevant när användarnas internettrafik faktiskt passerar brandväggen genom en full tunnel. Inkludera interna anslutningar från LAN till en DMZ endast när innehållsinspektion har en tydlig fördel där och klienten litar på den omsignerande CA medan brandväggen validerar den ursprungliga servercertifikatkedjan. Vanliga destinationsservrar behöver inte ha denna inspektions-CA installerad. Bedöm kompatibiliteten för ömsesidig TLS (mTLS) separat.

Teknisk kompatibilitet och tillstånd att dekryptera är separata beslut. Bank-, hälso- och sjukvårdsportaler samt myndighetsportaler, lösenordshanterare, identitetsleverantörer, uppdateringar av operativsystem och leverantörer samt röst-, video- och samarbetstjänster kräver en funktions- och sekretessbedömning innan inkludering. Pinning eller ett pilotfel motiverar inte ett generellt undantag för en hel kategori: identifiera först källan, domänen och applikationen som faktiskt krävs.

Konfigurera en komplett pilot

För en pilot som kan testas direkt använder vi dessa exempelvärden:

• Pilotklient: 10.20.30.50 från det dokumenterade testnätverket 10.20.30.0/24
• Brandväggsregel: LAN to WAN - TLS pilot
• SSL/TLS-inspektionsregel: TLS decrypt pilot client
• Källzon: LAN, Destinationszon: WAN
• Destinationsnätverk och tjänster: Any
• Åtgärd: Decrypt
• Dekrypteringsprofil: initialt Block insecure SSL eller en pilotprofil som härrör från den
• Loggning: Log connections aktiverad för piloten

10.20.30.0/24, värd-IP och objektnamn är exempel. Produktionskällan måste vara tillräckligt smal för att identifiera en klient entydigt. Any för destination och tjänst gör det lättare att observera TLS utanför TCP 443 under piloten; den utvidgar inte vad den föregående brandväggsregeln tillåter. Om inspektion endast är tillåten för en specifik destinationsgrupp, lägg till en URL-grupp eller ett annat lämpligt destinationskriterium.

Välj en dekrypteringsprofil

Under Profiles > Decryption profiles finns tre icke-redigerbara standardprofiler tillgängliga:

• Maximum compatibility maximerar kompatibiliteten och begränsar inte chiffer.
• Block insecure SSL blockerar svaga chiffer och tillåter trafik som inte kan dekrypteras.
• Strict compliance tillämpar strikta krav, inklusive krav baserade på PCI DSS.

Maximum compatibility kan hjälpa till att isolera en problematisk klient tillfälligt, men dess avslappnade kontroller gör den olämplig som ett produktionsacceptanskriterium. För piloten är Block insecure SSL eller en medvetet härledd profil den mer transparenta utgångspunkten. Tolerera gamla TLS-versioner eller RSA-nycklar kortare än 2048 bitar endast för en namngiven äldre server och i en regel med snäv omfattning.

Äldre protokoll och funktioner avvisas med Decrypt: Med Action: Decrypt avvisar Sophos Firewall fortfarande anslutningar som använder SSL 2.0 and SSL 3.0, SSL compression eller Unrecognized cipher suites, även om profilen har Allow without decryption valt för dem. Ett uttryckligen godkänt undantag med snäv omfattning för äldre system kräver både Allow without decryption för de relevanta profilfälten och Action: Don’t decrypt; profilens tillåtelse räcker inte i sig.

En anpassad profil kan åsidosätta de globala SSL/TLS-inställningarna. De återsignerande CA-alternativen är Use CAs defined in SSL/TLS settings, Re-sign RSA with och Re-sign EC with. För trafik som inte kan dekrypteras är alternativen Use SSL/TLS settings default, Allow without decryption, Drop och Reject. Den globala standardreferensen gäller inte Unrecognized cipher suites; detta fall måste bedömas uttryckligen i profilen. Beroende på inställningen använder certifikatfel, minsta RSA-storlek, TLS-versioner och blockerade chiffer Drop, Reject eller Reject and notify som deras Block action.

Inspektion gör inte ett självsignerat servercertifikat eller ett med en ofullständig kedja tillförlitligt. Istället för att hastigt utesluta det, kontrollera först värdnamnet, originalcertifikatet och hela kedjan.

För ett självsignerat original ersätter brandväggen nyckeln och signerar med den nyckeln, inte som en betrodd CA: klienten ser fortfarande ett självsignerat certifikat. Om hela kedjan till en CA som brandväggen litar på saknas, används ett systemgenererat certifikat vars CN förklarar problemet. En varning betyder alltså inte automatiskt att CA-distributionen har misslyckats.

Skapa en anpassad profil under Profiles > Decryption profiles > Add, med namn och beskrivning, eller klona en lämplig profil; spara den och tilldela den till inspektionsregeln. RSA- och EC-originalcertifikat kan ofta använda samma signerande CA. Om en applikation kräver en viss nyckeltyp, välj motsvarande CA under Re-sign RSA with eller Re-sign EC with. Hämta varje CA som faktiskt används med knappen bredvid valet; om två olika CA används måste klienterna lita på båda.

Bedöm före sparandet Certificate errors to block, Minimum RSA key size, Minimum SSL/TLS version, Maximum SSL/TLS version och Cipher algorithms to block. TLS under 1.2 och RSA under 2048 bitar är inte säkra standardinställningar. Maximum supported tillåter den högsta protokollversion som stöds. Kontrollen Revoked kräver en importerad CRL (Certificate Revocation List); att bara markera kryssrutan bevisar inte att spärrkontrollen fungerar. Ett Web Exception för HTTPS decryption kan tillåta matchande anslutningar med ogiltiga certifikat och är därför inte enbart en lösning för pinning.

Certifikatfel omfattar Invalid date, Self-signed, Untrusted user, Revoked, Name mismatch och Invalid for other reasons. Name mismatch jämför servernamnet i Client Hello med namnen i certifikatet. Bedöm nyckelutbyte, autentisering, bulk-chiffer och hash-algoritmer var för sig när blockerade chiffer väljs. SSL-komprimering före kryptering har kända sårbarheter; okända chiffer kan inte dekrypteras.

Globala inställningar finns under Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. TLS 1.3 decryption erbjuder Decrypt as 1.3 och Downgrade to TLS 1.2 and decrypt. Det andra alternativet påverkar alla SSL/TLS-inspektionsregler; sänk inte TLS globalt för en normal pilot.

When SSL/TLS connections exceed limit avgör vad som händer när dekrypteringskapaciteten är uttömd: Allow without decryption behåller åtkomsten men tar bort innehållsinspektionen; Drop kastar trafiken utan meddelande och Reject skickar en reset. Detta är ett medvetet beslut mellan tillgänglighet och skydd för piloten, inte bara ett prestandavärde. Reject and notify försöker visa en HTTPS-blockeringssida med felorsaken, men garanterar den inte; dataöverföring till servern förhindras.

Med TLS 1.3 fungerar certifikatfel, minsta RSA-storlek, en global nedgradering och Reject and notify som dokumenterats endast med Action: Decrypt. Med Don’t decrypt eller Deny används istället Reject för denna profilhantering. En global nedgradering till TLS 1.2 introducerar en säkerhetsrisk och är inte en allmän kompatibilitetsfix.

Skapa regeln och kontrollera dess ordning

Under Rules and policies > SSL/TLS inspection rules > Add ställer du in fälten enligt följande:

1. Rule name: TLS decrypt pilot client
2. Rule position: Top, så pilotregeln föregår allmänna anpassade dekrypteringsregler
3. Action: Decrypt
4. Log connections: aktiverad för pilotövervakning
5. Decryption profile: den valda pilotprofilen
6. Source zones: LAN
7. Source networks and devices: värdobjekt för 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: tom eller begränsad till den godkända destinationsomfattningen

Log connections är valfritt och krävs inte för att regeln ska fungera. Det är ändå användbart för en tidsbegränsad pilot eftersom handskakning och anslutningsstängning kan spåras. Lagringen måste följa den överenskomna integritets- och driftpolicyn.

Tabellen utvärderas från topp till botten och behandlingen avbryts vid första matchen. Alla konfigurerade kriterier måste matcha samtidigt. Den fasta standardregeln Exclusions by website or category förblir överst och kan inte föregås genom att välja Rule position: Top. Placera anpassade Don't decrypt-undantag omedelbart under det, följt av specifika pilotregler och, slutligen, bredare Dekryptera-regler.

Användar- och gruppkriterier är tillförlitliga endast om SFOS känner till användarkontexten för anslutningen. Om detta inte är garanterat, börja med en entydig värd eller nätverksobjekt och lägg till identitetskriterier först efter ett separat matchningstest.

Kontrollera efter Save återigen regelns status och position i tabellen. More options ger möjlighet att redigera, klona, lägga till bredvid en regel och ta bort; Rule handle ändrar ordningen. Filter för Source, Destination och Rule ID hjälper vid jämförelsen; Reset filter visar hela tabellen igen. Action: Deny förhindrar att anslutningen upprättas och är inte samma sak som Don’t decrypt. Categories and websites identifieras via SNI i TLS-handskakningen. Nya installationer aktiverar SSL/TLS-inspektionsregler som standard, men faktisk status måste fortfarande kontrolleras före piloten.

Skilj mellan TLS-konfigurationer via XML API

Vid automatiserade utrullningar är Inspection Rule, de globala DPI-inställningarna och konfigurationen för HTTP-/HTTPS-skanning tre olika objekt. Ett CA-val aktiverar varken pilotregeln eller skanningen i Firewall Rule. Följande mappningar gäller SFOS 22/23. Före en skrivåtgärd ska den explicita operationen och den fullständiga nyttolasten bekräftas i API help för den installerade builden. Tillåtna källor, konto, TLS-verifiering, hemligheter och skillnaden mellan HTTP-framgång och XML-status förklaras i Begränsa XML API-åtkomst säkert och kontrollera svar.

Inspection Rule: identitet, hierarki och ordning

Objektet heter SSLTLSInspectionRule. Dess direkta fält Name anger regeln; NewName är i exemplet det ändrade namnet vid ett namnbyte, inte namnet på referensregeln vid en flytt. För regelnamnet dokumenteras högst 60 tecken, UTF-8 och inga kommatecken; Description är begränsat till 255 tecken. IsDefault är skrivskyddat och används inte för att göra en egen pilotregel till standardregel.

Matchningsfälten ligger kvar under sina respektive föräldranoder, även om parametertabellen listar samma barnnamn flera gånger:

• SourceZones > Zone och SourceNetworks > Network: intern källzon och det godkända värdobjektet för piloten.
• DestinationZones > Zone och DestinationNetworks > Network: målzon och godkända målobjekt.
• Identity > Members: källanvändare eller grupper, endast med verifierad identitetsmatchning.
• Services > Service: tjänsteobjekt för den godkända omfattningen.
• Websites > Activity > Name och Websites > Activity > Type: namn och typ för webbplatskriteriet; exemplet anger Web Category och URL Group.
• MoveTo > Name och MoveTo > OrderBy: referensregel och relativ position; OrderBy använder Before eller After.

Zone, Network, Service och webbplatsaktiviteter kan förekomma flera gånger. Ett platt Name eller Network utan rätt föräldranod beskriver inte samma syfte. Objektbeteckningar hämtas från den befintliga konfigurationen; omfattning och profil ersätts inte av saknade fält eller overifierade standardvärden.

Position använder Top eller Bottom och används endast vid ADD för den inledande placeringen. Om inget anges anger exemplet Bottom; för UPDATE eller APIImport krävs inte Position, och det används här inte som flyttmekanism. Det valfria MoveTo tillämpas vid ADD efter Position. Den som anger båda måste därför kontrollera den resulterande relativa positionen, inte bara det inledande Top-värdet. Det fasta standardundantaget ligger kvar allra överst; den ovan beskrivna ordningen för godkända undantag, pilotregler och bredare dekrypteringsregler gäller fortfarande.

De direkta fälten Enable, LogConnections, DecryptAction och DecryptionProfile har separata uppgifter: regelstatus, loggning, dekrypteringsbeslut och profiltilldelning. För Enable anger tabellen Yes, No, t, f; för LogConnections anges Enable, Disable, t, f. DecryptAction använder exakt Decrypt, Do not decrypt eller Deny. UI-etiketten Don’t decrypt är därför inte ett XML-värde som får användas utan verifiering. Den valda profilen tilldelas under DecryptionProfile med sitt faktiska namn; en snävt avgränsad källa och hela den godkända mål-/tjänsteomfattningen är obligatoriska även vid automatisering.

De objektspecifika XML-statusraderna skiljer mellan operation och symbol:

Message.* förblir här en dokumentationsidentifierare som inte har slagits upp, inte en garanterad text vid körning och inte en slutgiltig felorsak. Före varje nytt försök stäms det sanerade svaret av mot det faktiskt sparade tillståndet: ursprungligt eller nytt regelnamn, status, fullständiga kriterier, DecryptionProfile och position i förhållande till de andra reglerna. Inte heller en 200-rad ersätter denna avstämning eller testet med nya anslutningar. Vid oklart tillstånd ska arbetet stoppas och tillståndet klarläggas, i stället för att skapa en andra eller bredare regel genom ännu en ADD eller en annan position.

Globala DPI-inställningar: CA är ingen på-/av-knapp

Under SSLTLSInspectionSettings anger RSACA och ECCA direkt valet av CA för omsignering av RSA- respektive EC-servercertifikat. De hänvisar till CA-objekt, inte till filsökvägar eller aktiveringsvärden. Profilen kan åsidosätta CA-valet för sin regel. Före ett byte kontrolleras därför profilen, den CA som faktiskt presenteras, klienternas tillit och rot-/underordnad certifikatkedja tillsammans; om olika CA:er används måste klienterna lita på båda.

Separata från detta är de direkta globala fälten SSLTLSEngine och SSLTLSInspection, båda med Enabled eller Disabled. Det första styr TLS engine, det andra global SSL/TLS Inspection, inte statusen för en enskild pilotregel. Om Inspection stängs av förhindras regeltillämpning och anslutnings-/dekrypteringsdetaljer i Control Center och Log viewer. Om Engine stängs av tas dessutom tillämpningen av DPI-webbpolicyn på HTTPS bort från trafikvägen; HTTPS-dekryptering via proxy påverkas inte av detta. Inget av alternativen är en normal återställningsåtgärd för en pilot.

TLS13Decryption ligger också direkt under SSLTLSInspectionSettings och använder Decrypt as 1.3 eller Downgrade to TLS 1.2 and decrypt. Det väljer den globala hanteringen av TLS 1.3, inte signerings-CA och inte åtgärden för en enskild regel. En nedgradering påverkar alla Inspection Rules och införs inte som en kompatibilitetsåtgärd för en enskild klient. De redan förklarade begränsningarna för TLS 1.3 och Action: Decrypt gäller fortsatt.

De övriga direkta fälten SSLv2SSLv3, SSLCompression och SSLConnectionsExceeded använder vart och ett Allow without decryption, Drop eller Reject. De avser olika fall och likställs inte med DecryptAction. Efter en auktoriserad ändring kontrolleras de sparade globala värdena, profilernas åsidosättningar och pilotens faktiska trafikväg. Endast de dokumenterade pilotrelaterade ändringarna återställs till sitt exakta tidigare tillstånd, utan att kontrollerna generellt inaktiveras.

HTTP-/HTTPS-skanning: beakta den egna föräldranoden

Det separata objektet AntiVirusHTTPsConfiguration innehåller direkt ScanMode, FileSizeThreshold, AudioVideoFileScanning och PUADetection. I barnnoden HTTPSConfigurations finns däremot HTTPSScanningCA, DenyUnknownProtocol, AllowInvalidCertificate och NoHttpsNotification. HTTPSScanningCA hör därmed till HTTP-/HTTPS-konfigurationen för proxyvägen, inte till RSACA eller ECCA i DPI-inställningarna. Dessa fält ersätter varken DPI-regelmatchningen eller Decrypt HTTPS during web proxy filtering i motsvarande Firewall Rule. Skanningskontexten förklaras i Sätt skanning efter skadlig kod på Sophos Firewall i sitt sammanhang.

ScanMode anger RealTime och BatchMode. FileSizeThreshold anges i KB; tabellen anger 1 till 1572864, högst 7 siffror och standardvärdet 1024. Filer över tröskelvärdet skannas inte; det dokumenterade standardvärdet är inte en rekommendation för alla miljöer.

Oklargjord motsägelse mellan värden: För AudioVideoFileScanning visar XML-exemplet Enable/Disable, medan parametertabellen anger on/off och standardvärdet Disable. Inga utbytbara alias härleds från detta. Även för DenyUnknownProtocol och AllowInvalidCertificate visar exemplet Enable/Disable, medan tabellen endast anger on respektive on/off; för PUADetection anges där symboliska värden. Före en automatiserad ändring måste API help eller Support bekräfta vilka värden som gäller för objektet och builden. Utan klarläggande ska den berörda skrivbegäran inte utföras; certifikatkontrollerna får inte lättas för att få en import att fungera.

Efter en godkänd ändring jämförs det sparade CA-valet och kontrollerna under Web > General settings, den proxy-/DPI-väg som faktiskt matchar och den synliga certifikatutfärdaren med det tidigare tillståndet. Först därefter följer funktionstest, positivt test och negativt test av undantag. En formellt accepterad skanningskonfiguration är inget bevis på dekryptering eller effektiv skanning efter skadlig kod.

Håll undantagen snäva

Standardregeln Exclusions by website or category använder Don’t decrypt med Maximum compatibility och förblir i första positionen. Local TLS exclusion list är tom som standard; Managed TLS exclusion list innehåller kända inkompatibla webbplatser och underhålls genom firmwareuppdateringar.

Redigera den lokala listan på:

Web > URL groups > Local TLS exclusion list

URL-grupper eller SNI-matchningar är mer effektiva för domänundantag än många FQDN-värdar. Enligt Sophos, till exempel, orsakar 200 FQDN-värdar 200-uppslagningar för varje ny SSL/TLS-anslutning. Begränsningen för kombinerade käll- och destinationsundantag måste skiljas från normal regelmatchning. Skapa och använd URL-grupper på ett säkert sätt förklarar domänens omfattning, jokertecken och negativa tester.

En anpassad SSL/TLS-inspektionsregel med Action: Don’t decrypt bör registrera domänen, berörd källa, orsak, ärendenummer, ägare och granskningsdatum. Don’t decrypt är inte en ovillkorlig förbikoppling: begränsningarna för den valda dekrypteringsprofilen gäller fortfarande. För att tillåta SSL 2/3, komprimering eller okända chiffer för ett uttryckligen godkänt äldre fall, använd en profil med Allow without decryption tillsammans med Action: Don’t decrypt. Denna kombination hör inte hemma i en bred internetregel.

SSL/TLS-undantag och webbundantag löser olika problem. Ett TLS-undantag styr dekryptering på valfri TCP-port i DPI-läge. Ett webbundantag ändrar valda webbpolicykontroller; i proxyläge påverkar det den relevanta proxysökvägen. Innan du gör en ändring, avgör om Dekryptering eller endast en webbkontroll ska uteslutas. Skapa och testa webbundantag säkert visar arbetsflödet för urval och regex.

Oklart undantagsomfång: Guiden för webbplatsundantag säger att käll- och destinationsundantag inte kan kombineras; regelguiden erbjuder båda matchningsfälten. Detta bevisar inte att ett Web Exception med kombinerad käll- och destinations-IP är tillåtet. Behåll pilotens källbegränsning tillsammans med ett bekräftat värdnamn eller en URL Group. Om även båda IP-undantagskriterierna är obligatoriska, aktivera eller bredda inte undantaget innan Support har klargjort det för aktuell build. Ta inte bort ett kriterium bara för att få en matchning.

För ett uttryckligen godkänt äldre fall, skapa en profil som Allow_non-decryptable_profile under Profiles > Decryption profiles > Add. Sätt endast de fält som verkligen behövs — SSL 2.0 and SSL 3.0, SSL compression eller Unrecognized cipher suites — till Allow without decryption. Tilldela under Rules and policies > SSL/TLS inspection rules > Add profilen till en snäv Don’t decrypt-regel med pilotkällan, intern källomfattning, lämplig destination och ett känt mål. Detta minskar skyddet för ett motiverat äldre fall; det är inget generellt godkännande av dessa protokoll.

Utan användbar SNI kan en URL Group eller domänregex inte identifiera målet. Efter kontroll av det verkliga flödet kan ett snävt IP Host under Destination networks vara lämpligt; ett FQDN Host är fortfarande ett DNS-baserat alternativ med de beskrivna kostnaderna. För regex är en förankrad början ^ och ett negativt test viktiga; breda jokertecken kan också göra bearbetningen långsammare. Länken Web Exceptions ovan förklarar hela den säkra syntaxen och skillnaden mot domänlistor.

Hantera Android med en snäv omfattning

Vissa Android-anslutningar använder certifikatfästning. Anslutningskontroll, Play Butik eller uppdateringar kan då misslyckas under Dekryptering. Arbetsflödet som dokumenterats av Sophos använder ett isolerat VLAN eller trådlöst nätverk och en FQDN-värdgrupp som innehåller:

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• den lokala Google-domänen, till exempel *.google.ch i Schweiz

Skapa gruppen under Hosts and services > FQDN host group > Add. Skapa under Hosts and services > FQDN host > Add en värd per domän och tilldela den direkt till gruppen. Skapa ett nytt trådlöst Sophos-nätverk under Wireless > Wireless networks > Add och dess nätverksobjekt under Hosts and services > IP host > Add, med IP version: IPv4, Type: Network, egen nätverksadress och nätmask. För ett befintligt isolerat VLAN eller trådlöst nätverk, använd lämpligt befintligt objekt i stället för att skapa ett nytt nätverk utan bekräftat behov. Bekräfta den faktiska inkommande zon som tilldelats gränssnittet eller VLAN:et; Wi-Fi är exemplet för Sophos trådlösa nätverk, inte ett krav för alla mobilnätverk.

Den allmänna dokumentationen rekommenderar ett undantag för alla Android-enheter; det konkreta arbetsflödet begränsar det till Google-destinationer i ett isolerat mobilnätverk. Denna utrullning följer det snävare arbetsflödet med positiva och negativa tester, inte en generell förbikoppling för alla Android-anslutningar. Att byta till Web Proxy är ett separat arkitekturbeslut, inte automatiskt en likvärdig lösning för pinning.

Ovanför den allmänna dekrypteringsregeln, lägg till en SSL/TLS-inspektionsregel med Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone inställd på mobilnätverkets faktiska inkommande zon (till exempel Wi-Fi, LAN eller en konfigurerad anpassad zon), mobilenhetsnätverket som Source networks and devices, WAN som Destination zone, och Google-gruppen som Destination networks. Den ligger under den fasta standarduteslutningen men över den allmänna Dekrypteringsregeln. Håll mobilnätverket isolerat från känsliga interna resurser.

Acceptera ändringen med en Android-pilotenhet: verifiera Connectivity Check och webbläsaråtkomst, ladda ner en godkänd testapp från Google Play och uppdatera en installerad app via Google Play. Varje åtgärd måste slutföras utan fel. I Log viewer kan endast de förväntade Google-destinationerna matcha undantaget; en annan HTTPS-destination från samma VLAN måste fortfarande använda den avsedda dekrypteringsregeln. Bekräfta den faktiska källzonen och källobjektet, matchningen mot Google-undantaget och matchningen mot den avsedda dekrypteringsregeln för dessa verkliga trafikflöden. Använd en hanterad pilotenhet vars specifika testwebbläsare eller testapp litar på inspektions-CA:n; verifiera att den fungerar och kontrollera certifikat- och loggbevis för den dekrypterade destinationen. Håll klienter eller appar där tilliten till inspektions-CA:n inte kan hanteras utanför dekrypteringsomfattningen. Detta negativa test förhindrar acceptans av ett undantag som fungerar men är för brett. Skapa webbundantag och TLS-undantag på ett säkert sätt täcker ytterligare metoder och SNI-begränsningar.

Verifiera effekten

En policysimulering, en riktig klient och loggarna svarar på olika frågor. Kombinera dem för ett pålitligt acceptanstest.

Under Diagnostics > Tools > Pop-out tools > Policy tester väljer du Firewall, SSL/TLS, and web och ställer in Käll-IP, Destination eller URL, protokoll och, om det behövs, porten. Utan ett protokoll testar verktyget HTTP med den protokollspecifika standardporten. Policytestare simulerar transparent webbtrafik; den modellerar inte SD-WAN-rutter, och regler med MAC-adresser under Source networks and devices matchar inte där. Web policy only testar endast webbpolicyn. Resultatet är därför en förutsägelse, inte ett bevis på den faktiska datavägen.

Kör fyra riktade tester på klienten:

1. Före ändringen, registrera destinationsdomän, certifikatutfärdare, svarstid och om affärsapplikationen fungerar.
2. Öppna en godkänd positiv destination och verifiera den valda inspektionsvägen. För DPI måste webbläsaren visa den omsignerande CA som valts för DPI som utfärdare, och Log viewer måste visa den förväntade dekrypteringsregeln och dekrypteringsprofilen. För webbproxy, verifiera den CA som valts under Web > General settings > HTTPS scanning certificate authority (CA), den brandväggsregel som faktiskt matchar med Use web proxy instead of DPI engine och Decrypt HTTPS during web proxy filtering, samt motsvarande proxy-/webbloggbevis för den lyckade begäran. Kräv inte en matchning mot en DPI-regel eller DPI-profil eller en post i DPI-widgeten för en anslutning som dekrypterats av proxyn.
3. Öppna en avsiktligt utesluten destination. Den måste matcha den förväntade Don't decrypt-regeln; webbläsaren får inte visa ett certifikat som omsignerats av brandväggen där.
4. En andra, icke-exkluderad destination från samma klientomfattning måste fortfarande dekrypteras. Detta är undantagets negativa test.

Om en webbpolicy är en del av designen, blockera även en testkategori eller test-URL som är specifikt godkänd för detta ändamål. Kör ett test av skadlig kod endast med ett dokumenterat, ofarligt leverantörstestobjekt och ett fördefinierat förväntat resultat. Före och efter piloten, jämför CPU- och minnesbelastning, svarstid och användarfel under samma tidsfönster.

Tolka Control Center och Log viewer korrekt

Kontrollcenterwidgeten heter SSL/TLS connections. Dess detaljer uppdateras var femte minut. Sessioner täcker de senaste 24 timmarna och fel de senaste 7 dagarna; Failed återställs vid midnatt. Den detaljerade informationen inkluderar inte webbproxyanslutningar. Decryption peak visas endast nära eller över toppen, och Decryption limit endast nära den enhetsspecifika gränsen. Det finns därför ingen universell tröskel för alla apparater.

Öppna Log viewer uppe till höger och välj modulen SSL/TLS inspection. En TLS-anslutning loggas efter att handskakningen är klar och när den stängs. Åtgärd, Regel, Dekrypteringsprofil, Källa, Destination, Domän och felorsaken spelar roll; Enbart färger är inte ett tillförlitligt acceptanskriterium. Under Manage > Exclude kan du lägga till domäner eller underdomäner till den lokala TLS-uteslutningslistan och kategorier till standarduteslutningen. Exclude är inte tillgängligt för fel-ID:n 19004 och 19005.

En Don't decrypt-händelse bevisar bara att anslutningen inte dekrypterades. Endast Regel, listmatchningen och det negativa testet visar om undantaget är motiverat och tillräckligt snävt.

Felsök och rulla tillbaka på ett säkert sätt

När en incident inträffar, begränsa initialt ärendet till en klient, en domän, en tidpunkt, en brandväggsregel och en SSL/TLS-inspektionsregel.

• Om webbläsaren visar en certifikatvarning, jämför den synliga utfärdaren med den CA som används av den faktiska DPI- eller proxysökvägen. Kontrollera sedan klientens förtroendelager, rot/underordnad kedja och värdnamn.
• Om SSL/TLS-händelser saknas, kontrollera först brandväggsregeln och läget. Bekräfta sedan att Rules and policies > SSL/TLS inspection rules och Advanced settings > SSL/TLS engine > Enabled är aktiva.
• Om trafik är tillåten men inte dekrypterad, sök uppifrån och ned efter den fasta standarduteslutningen, Managed/Local List eller en anpassad Don't decrypt-regel. Upprepa sedan det negativa testet.
• Om webbfiltret inte gäller, kontrollera den faktiska brandväggsregeln för dess webbpolicy, Scan HTTP and decrypted HTTPS, Block QUIC protocol och DPI/proxy-läge. Förekomsten av en webbpolicy bevisar inte dekryptering.
• Om bara en applikation misslyckas, använd felorsak, TLS-version, chiffer, certifikatkedja och pinning för att vägleda nästa beslut. Håll varje tillfälligt undantag snävt och ge det ett granskningsdatum.
• Om belastningen ökar, minska pilotomfattningen och jämför samma tidsfönster före och efter ändringen. Bedöm topp- eller gränsmeddelanden för den specifika apparaten.

Inaktivera SSL/TLS engine endast kort för felsökning. När den är inaktiverad gäller inga SSL/TLS-inspektionsregler och DPI-motorn tillämpar inte brandväggens webbpolicy på HTTPS; Web Proxy HTTPS-dekryptering förblir opåverkad. Att inaktivera den är därför inte en likvärdig, lågriskersättning för att specifikt inaktivera pilotregeln.

Testa portagnostiska IPS endast med ett känt initialtillstånd

Som standard kontrollerar SFOS dekrypterad trafik mot IPS-signaturer på varje TCP-port. För en reproducerbar falsk positiv, dokumentera signatur-ID, källa, destination, TCP-port, brandväggsregel, inspektionsregel och SFOS-build. Föredra ett snävt signaturundantag med Action: Allow packet i den IPS-policy som faktiskt används; Konfigurera och testa Sophos Firewall IPS beskriver denna metod.

Ett möjligt symtom på ett problem med portagnostisk inspektion är upprepade träffar på samma IPS-signatur på samma webbplats. Upprepningen i sig bevisar inte ett falskt positivt resultat. Kontrollera att exakt Signature ID och destination stämmer överens i loggarna, kontrollera det berörda legitima arbetsflödet och bedöm risken innan ett snävt avgränsat, återkalleligt signaturundantag godkänns.

Den mer omfattande inspektionen av potentiella hot kan öka belastningen och minska genomströmningen för dekrypterad HTTPS-trafik något jämfört med äldre versioner av Sophos Firewall. Detta är en möjlig versionsrelaterad effekt, inte en garanterad minskning eller ett bevis på en regression i den build som används för närvarande. För att sätta resultaten i sitt sammanhang jämför man genomströmning, CPU- och minnesbelastning samt svarstid vid jämförbar trafikbelastning inom samma tidsfönster; en enskild jämförelse ersätter inte en orsaksanalys.

En global jämförelse i Device Console är endast tillåten om det exakta aktuella värdet, on eller off, redan är känt från ändringsposten eller en tillförlitligt säkerhetskopierad konfiguration. Den officiella SFOS 22-dokumentationen anger inget kommando för att läsa av inställningens aktuella tillstånd. Om initialtillståndet är okänt, utför inte testet.

Endast med ett dokumenterat initialtillstånd av on kan du ställa in följande för en förberedd jämförelse:

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

Det andra kommandot här återställer bara det kända initiala tillståndet för on. Om initialtillståndet var off, aktivera det inte blint; behåll off eller återställ det exakt efter en auktoriserad ändring. Denna globala inställning påverkar hela brandväggen och kan minska genomströmningen något eller, med off, begränsa inspektionsomfånget. Dokumentera resultatet och tidsfönstret utan att endast behandla detta som bevis på en allmän orsak.

Rulla tillbaka i en fast ordning

En återställning återställer det dokumenterade initiala tillståndet snarare än att introducera en ny arkitektur:

1. Innan du inaktiverar TLS decrypt pilot client, kontrollera den dokumenterade regel som tar över och den godkända återställningsplanen: en lägre placerad, bredare Decrypt-regel kan ta över. Inaktivera pilotregeln och återställ de dokumenterade pilotspecifika ändringarna av brandväggsregler, DPI/proxyläge, webbpolicy och globala inställningar i den förberedda ordningen, utan orelaterade samtidiga ändringar.
2. Upprätta nya anslutningar från pilotklienten och verifiera den dokumenterade ursprungliga matchande sökvägen, certifikatutfärdaren, loggarna och att applikationen fungerar. Anta inte att befintliga sessioner omedelbart omvärderas. Om en lägre placerad Decrypt-regel tar över eller återställningen misslyckas, stoppa rensningen: återställningen är inte slutförd. Identifiera den faktiska matchningen och återställ endast den godkända regelordning, de kriterier och de inställningar som behövs för att återskapa det initiala tillståndet, och upprepa sedan dessa kontroller med nya anslutningar.
3. Endast om den ursprungliga sökvägen inte dekrypterades och den godkända återställningsplanen kräver det, använd en tidsbegränsad Don't decrypt-regel med snäv omfattning för pilotkällan och de nödvändiga destinationerna, placerad före den oavsiktliga lägre Decrypt-matchningen men under tillämpliga godkända undantag. Kör både dess positiva och negativa test; improvisera inte ett brett undantag och ersätt inte en tidigare verifierad trafikväg med en overifierad.
4. Ta bort tillfälliga undantag, testobjekt och pilotspecifik CA-tillit och CA-inställningar först när återställningen har verifierats och borttagningen har godkänts. Behåll CA-tillit som fortfarande krävs av den aktiva sökvägen tills dessa kontroller har lyckats; ta inte bort delade certifikatutfärdare utan att kontrollera beroenden.
5. Anteckna regel-ID, klient, destination, synlig CA, logghändelse, tid och återställda inställningar i ändringsposten.

Webbpolicyn kan förbli konfigurerad, men utan dekryptering kan den inte skanna den krypterade HTTPS-nyttolasten. Återgå till webbproxy endast om det var det verifierade initiala tillståndet. Inaktivera inte hela SSL/TLS-motorn som standardåterställning eftersom det stoppar alla DPI TLS-regler och tillämpningen av DPI-webbpolicyn på HTTPS.

Stoppa utrullningen så snart en affärskritisk applikation misslyckas, certifikatvarningar visas utanför pilotgruppen, omfattningen matchar bredare än förväntat eller belastning och fel överskrider de fördefinierade gränserna. Utöka källgruppen gradvis först när det positiva testet, undantagets negativa test, affärsapplikationerna, loggarna, användarfeedbacken och belastningsprofilen uppfyller alla överenskomna kriterier under den överenskomna perioden.

Under drift, granska uteslutningar, TLS-fel, nya applikationer, belastning och användarfeedback enligt ett definierat schema. Behåll endast tillfälliga undantag medan ägaren, skälet och granskningsdatumet förblir giltiga; annars, ta bort dem efter ett nytt positivt och negativt test.

Vanliga frågor