Konfigurera och testa Sophos Firewall Application Control

Application Control på Sophos Firewall känner igen applikationer oavsett den rena porten. Detta gör att till exempel fjärrkontrollverktyg, tunnlingsapplikationer, streaming, molnlagring, meddelanden eller riskfyllda webbläsarförbikopplingar specifikt tillåts, blockeras eller loggas.

Den praktiska fördelen uppstår dock bara när Application Control är aktiv i rätt brandväggsregel, applikationen faktiskt känns igen och loggar utvärderas. En sparad Application Filter-policy blockerar ingenting.

Kort svar

Application Control används i två steg:

1. Planera eller skapa en Application Filter-policy under Applications > Application filter.
2. Välj lämplig brandväggsregel under Andra säkerhetsfunktioner under Identifiera och kontrollera applikationer (Appkontroll).

Du måste sedan använda en riktig testklient för att kontrollera om trafiken körs via denna regel och om applikationen känns igen korrekt i Log Viewer. För krypterad trafik kan TLS Inspection vara avgörande eftersom brandväggen annars ser färre detaljer, beroende på applikation.

När Application Control är vettigt

Application Control är särskilt användbar när portar ensamma inte ger tillräckligt med information. Många applikationer använder HTTPS, ändrade destinationer eller molninfrastruktur. En ren portregel ser då bara 443, men inte om det är en tillåten företagstjänst, ett fjärrkontrollverktyg eller en oönskad molnlagring.

Typiska tillämpningar:

• Blockera TeamViewer, AnyDesk, Tor eller proxyverktyg
• Begränsa streaming eller sociala medier på vissa nätverk
• Styr molnlagring
• Begränsa budbärare eller spel i gäst- eller skolnätverk
• Aktivera applikationsupptäckt för rapportering och analys
• Förbered trafikformning för upptäckta applikationer

Om det inte handlar om upptäckt eller blockering, utan om prioritering eller bandbreddsbegränsning, är Konfigurera applikationstrafikformning på Sophos Firewall också lämpligt.

Krav

Före konfigurering bör dessa punkter kontrolleras:

• giltig Web Protection Subscription
• Den berörda brandväggsregeln är känd
• Loggbrandväggstrafik är aktiv för testregeln
• Den önskade applikationen eller kategorin är tekniskt tydlig
• Testklient och testmål definieras
• För HTTPS-applikationer är det klart om TLS Inspection ska användas
• Applikationssignaturer och mönsteruppdateringar fungerar

Licensstatusen kontrolleras under Administration > Licensing. Application Control, inklusive Synchronized Application Control, ingår i Web Protection Subscription. Synchronized Application Control kräver dessutom Security Heartbeat och därmed en Network Protection Subscription, ett Sophos Central-konto samt ett hanterat Sophos Endpoint med utvärderings- eller fullständig licens. Före produktionsinförandet bör man därför kontrollera både brandväggspaketet och endpoint-statusen.

Application Filter plan

En bra Application Filter är inte bara en lång blockeringslista. Först bör det vara klart vad som ska uppnås.

• Blockera riskabla fjärrkontrollverktyg: Blockera riktade applikationer eller kategori.
• Begränsa gäst WLAN: Blockera oönskade kategorier och lämna tillåtna bastjänster öppna.
• Endast loggapplikation: använd initialt Allow med loggning och rapporter.
• Undvik falska positiva: Använd ett smalare program istället för en bred kategori.
• Prioritera affärskritisk applikation: Kombinera Application Control med trafikformning.

Ett övervakningsläge är ofta vettigt för produktiva nätverk: Aktivera först Application Control, kontrollera loggar och rapporter och blockera det sedan specifikt. På så sätt kan du se vilka applikationer som verkligen finns och om ett blockering skulle störa legitima processer.

Om kriterierna är breda bör framtida vård beaktas. Nya applikationer inkluderas automatiskt i Application Filter-policyer och brandväggsregler genom uppdateringar av applikationssignaturdatabasen. Till exempel, om en regel blockerar alla högriskapplikationer, kan en ny högrisksignatur blockeras senare utan ytterligare manuella policyändringar. Detta är önskvärt, men måste vara känt i förändrings- och granskningsarbetet.

Planera utbyggnaden i etapper

Application Control bör inte aktiveras för alla nätverk i ett stort steg. Det är bättre att ha en liten utrullning med en tydlig testgrupp, synlig loggning och ett definierat beslut om när en observation blir ett block.

En praktisk process:

• Inventering: Ta reda på vilka applikationer som faktiskt förekommer. För att göra detta, använd Application Filter med loggning, fortfarande utan bred blockering.
• Pilot: Kontrollera valda användare eller ett testnät. Blockera enskilda riskfyllda applikationer och kontrollera noggrant Rule ID och loggar.
• Produktion: Tillämpa bekräftad policy på målnätverket. Aktivera filter i produktiva regler och dokumentundantag.
• Operation: Övervaka effekt och biverkningar. Kontrollera rapporter, Log Viewer, Central Reporting eller syslog regelbundet.

När du hör det live är det tydligt att du kommer att kunna se vad som händer. Detta inkluderar ofta uppdateringar, fjärrsupport, samarbetsverktyg, molnlagring, telefon- eller filialspecifik applikation. Om dessa beroenden blir synliga efter blockeringen, fungerar Application Control snabbt som en störande faktor är tillgänglig för en skyddande funktion.

För acceptans är det värt att göra en kort beslutslista: Vilken applikation är blockerad, vilken användargrupp berörs, vilket undantag är tillåtet, vem är teknisk ägare och när kommer policyn att kontrolleras igen? Denna dokumentation är viktigare än ett perfekt första filter.

Skilj mellan Application Filter, Application Object och formning

Termerna ligger nära varandra, men löser olika uppgifter. Denna separation sparar mycket felsökning:

• Application Filter: bestämmer vilka applikationer som är tillåtna, blockerade eller loggade. Typiskt för fjärrstyrningsverktyg, molnlagring eller ett observationsläge.
• Application Object: grupperar applikationer för en applikationsbaserad SD-WAN route. Det avgör alltså vilken applikationstrafik som ska routas gemensamt via specifika gateways och ersätter inte ett Application Filter.
• Applikationsbaserad trafikformning: prioriterar eller begränsar upptäckta applikationer. Typiskt för Teams prioritering, strömningsbegränsning eller gäst-WLAN-strykning.
• Synkroniserad Application Control: kompletterar applikationsupptäckt med data från Sophos slutpunktssystem via Security Heartbeat. Detta är särskilt användbart för program som brandväggen annars bara skulle känna igen generiskt eller inte alls.

För en Block- eller Allow-policy är Application Filter rätt utgångspunkt. Ett Application Object behövs endast för applikationsbaserade SD-WAN routes; proceduren beskrivs i Konfigurera en Sophos Firewall SD-WAN route med Gateway Failover. Traffic Shaping är separat och läggs till när identifierade applikationer ska prioriteras eller begränsas.

Synchronized Application Control är inte en ersättning för rena brandväggsregler. Det kräver de nämnda subscriptions, Sophos Central, Security Heartbeat och lämplig Sophos Endpoint-täckning. Nyligen upptäckta applikationer visas i sina egna kategorier som SyncAppCtl discovered och bör inte blockeras blint. Kontrollera först, kategorisera sedan och lägg sedan till dem i Application Filter.

Identifierade applikationer får automatiskt en statusetikett: New för fortfarande okända applikationer, Mapped för applikationer som automatiskt tilldelats en kategori och Customized för manuellt justerade poster. Sophos stöder Synchronized Application Control för upp till 15 000 applikationer och sparar endast de senaste fem förekomsterna per applikation och slutpunkt för att spara lagringsutrymme. Denna gräns är särskilt relevant när man i efterhand måste utreda hur ofta en applikation förekom på en slutpunkt.

Efter en migrering till SFOS 21.0 eller senare aktiveras dessutom automatisk rensning med en standardperiod på tolv månader när Synchronized Application Control är aktivt. Individuellt tillagda applikationer tas vid rensningen även bort från Application Filter Policies. Den som behöver historiska data eller manuellt underhållna filter bör därför kontrollera denna period medvetet.

Hantera identifierade applikationer på ett säkert sätt

Vid den första användningen måste Synchronized Application Control vara aktiverat i Sophos Central. Öppna därefter Applications > Synchronized Application Control, sök efter namn, sökväg, kategori eller slutpunkt och expandera posten för att kontrollera de identifierade förekomsterna.

För en okänd post i SyncAppCtl discovered väljer man Customize under Manage > More options. Ange ett begripligt namn och den kategori som passar verksamheten. Acknowledge markerar en granskad post som behandlad utan att ändra den, Hide döljer den bara i den aktuella vyn och Show gör den synlig igen.

Delete är inte bara en rensningsåtgärd: applikationen tas också bort från Application Filter Policies. Om en slutpunkt senare identifierar den igen visas den på nytt i listan. Före radering måste man därför kontrollera vilka filter som använder applikationen; därefter testas policyn, förväntad Firewall Rule ID och ett verkligt trafikflöde på nytt.

För det konkreta användningsfallet generativ AI visar Identifiera och kontrollera generativ AI med Sophos Firewall hur Application Filter, endpointtelemetri, pilotdrift och rapportering samverkar.

Skapa Application Filter

Menysökväg:

Applications > Application filter

På äldre SFOS-versioner kan sökvägen visas som Protect > Applications > Application filter.

Procedur:

1. Öppna Lägg till.
2. Tilldela ett meningsfullt namn, till exempel Block_Remote_Control_Tools.
3. Välj en befintlig policy som mall, till exempel en tillåt alla-policy som utgångspunkt för riktade blockregler.
4. Spara policy.
5. Öppna policyn igen och lägg till en regel i filtret.
6. Välj Applikation, Kategori, Risk, Egenskaper, Teknik, Klassificering eller Smart Filter.
7. Ställ in åtgärd, till exempel Deny eller Allow.
8. Ställ in schema om regeln bara ska gälla tillfälligt.
9. Spara regeln och spara sedan policyn.

Konfigurera scheman för regler och policyer i Sophos Firewall förklarar hur schemat skapas och valideras mot brandväggstid, regelordning och fallbackregler.

Du bör vara försiktig med kategorier. En bred kategori kan möta fler ansökningar än förväntat. För inledande tester är individuella applikationer eller tydligt definierade grupper ofta bättre än ett stort samlingsblock.

Det finns två typiska sätt att arbeta när man lägger till en regel. Välj alla med filter är lämpligt om en hel grupp avses, till exempel Kategori Filöverföring, Egenskaper Överför filer och Teknik Webbläsarbaserad. Välj individuell applikation är bättre om bara enskilda applikationer som AnyDesk, TeamViewer eller en specifik molntjänst ska påverkas. Smartfiltret söker efter namn och beskrivning av en applikation; den ersätter inte en teknisk undersökning av träfflistan.

Filtret Klassificering gäller endast molnapplikationer. Om en molnapp senare omklassificeras uppdaterar Sophos Firewall även regler baserat på den klassificeringen. Sådana regler är bekväma men mer dynamiska än en fast lista med individuella applikationer.

Exempel: Blockera webbläsarbaserade filöverföringar

Ett bra första exempel är att blockera webbläsarbaserade filöverföringar på ett gäst- eller klientnätverk. Hela File Transfer-kategorin är inte blockerad över hela linjen, utan valet är snarare begränsat till webbläsarbaserade filöverföringar.

Konfiguration i Application Filter:

1. Öppna Applications > Application filter.
2. Skapa en policy, till exempel Block_File_Transfer.
3. Välj en lämplig tillåtspolicy som mall.
4. Spara policyn och öppna igen.
5. Öppna Lägg till för en ny filterregel.
6. Använd Markera alla och begränsa urvalet med Kategori: Filöverföring, Egenskaper: Överför filer och Teknik: Webbläsarbaserat.
7. Ställ in Åtgärd på Deny.
8. Ställ in Schema till All the time om ingen tidskontroll önskas.
9. Spara filterregeln och spara sedan policyn.

Det här exemplet är avsiktligt smalare än ett ramblock för alla filöverföringsprogram. I många företag skulle legitima moln-, uppdaterings-, backup- eller samarbetstjänster annars påverkas. Innan produktiv användning bör filtret i Log Viewer testas med riktiga klienter.

Aktivera i brandväggsregeln

Application Control träder bara i kraft när filtret är valt i en brandväggsregel.

Menysökväg:

Rules and policies > Firewall rules

Procedur:

1. Öppna brandväggsregeln genom vilken den påverkade trafiken faktiskt körs.
2. Öppna avsnittet Andra säkerhetsfunktioner.
3. Välj Application Filter för Identifiera och kontrollera applikationer (Appkontroll).
4. Aktivera Logga brandväggstrafik, åtminstone för testning och acceptans.
5. Spara regel.
6. Testa med en definierad klient.

Ordningen på reglerna är avgörande. Om trafiken redan bearbetas av en mer allmän regel ovan kommer den inte att nå regeln med Application Control. Då ser konfigurationen i WebAdmin korrekt ut, men har ingen effekt.

När en ny LAN-WAN-regel skapas måste NAT betraktas separat. Sophos-exempel använder ofta Create linked NAT rule med MASQ för enkel tillgång till internet. Med befintliga produktiva regler bör du inte slarvigt skapa nya NAT-regler, utan snarare kontrollera vilken SNAT/MASQ-regel som redan gäller för denna trafik.

För användar- eller gruppbaserade programkontrollpolicyer måste brandväggsregeln verkligen matcha användarkontexten. Matcha kända användare och fungerande autentisering är då lika viktigt som själva Application Filter. Utan användarkontext gäller policyn endast nätverks-, zon- och tjänstekriterier.

När det kommer till nya regler bör du också medvetet välja mellan IPv4 och IPv6. Application Control är aktiverad i respektive brandväggsregel. Om en klient tar en annan väg över IPv6 än över IPv4 ser testet annars rent ut, även om en del av trafiken går förbi den förväntade regeln.

Grunderna för källa, destination, tjänster, säkerhetsfunktioner och regelordning finns i Sophos Firewall-Förstå och säkert konfigurera regler.

Kontrollera medvetet regeljämförelse

Innan du sparar bör regeln läsas som ett testfall:

• Källzon och källnätverk: Testklienten måste verkligen komma över denna zon och detta nätverk.
• Destinationszon och destinationsnätverk: Breda mål kan fungera, men är svårare att förstå.
• Tjänster: TCP 80/443 är ofta relevant för webbtrafik; QUIC körs över UDP 443.
• Webbpolicy, IPS och TLS Inspection: Flera säkerhetsfunktioner kan påverka samma flöde.
• Logga brandväggstrafik: Utan loggning är effekten i Log Viewer svår att bevisa.

Om Application Control införs bör den första regeln vara lite smalare och lätt mätbar. En enorm LAN till WAN regel med många undantag är mycket svårare att acceptera.

TLS Inspection och detektering

Application Control kan identifiera signaturbaserade applikationer även utan fullständig TLS Inspection. URL-baserade Micro Apps, exempelvis filöverföringar i Dropbox eller Gmail, identifieras däremot av DPI engine i krypterad trafik först via den dekrypterade URL:en. En matchande SSL/TLS inspection rule måste därför faktiskt dekryptera trafiken.

Om en applikation över HTTPS inte känns igen som förväntat bör du kontrollera:

• körs trafiken genom rätt brandväggsregel?
• är Application Control aktiv i denna regel?
• är applikationen allmänt erkänd av Sophos?
• är TLS Inspection nödvändigt och acceptabelt för denna trafik?
• använder klienten QUIC eller HTTP/3? QUIC kan inte skannas och kringgår Web Filtering; för kontrollerad webbtrafik bör Block QUIC protocol kontrolleras i den matchande brandväggsregeln.
• Gäller webbpolicy, IPS eller DNS Protection också?

TLS Inspection bör införas gradvis och med undantag. Lämplig procedur finns i Sophos Firewall TLS Inspection introducera korrekt. För QUIC och HTTP/3 passar Sophos Firewall Blockera QUIC och HTTP/3 korrekt.

Skillnaden är särskilt synlig i molnapplikationer: grundläggande bytes och användningsdata kräver i första hand aktiverad brandväggsloggning. Mer detaljerad uppladdning/nedladdning och filtypsinformation kan dock endast ses tillförlitligt om HTTPS är dekrypterad. Vissa program överför filer med sina egna mekanismer; då kan detaljfält förbli tomma eller visas ofullständiga även om trafik är tillgänglig.

För Cloud App Reporting rekommenderas därför tre delar: aktivera Log firewall traffic för grundläggande byte-data, dekryptera HTTPS där uppladdnings-/nedladdningsräknare och filtyper behövs och använd för högre noggrannhet en Web Policy som inte är None. Web Policy är då en ytterligare Sophos-rekommendation; det fasta kravet för dessa filuppgifter är HTTPS-decryption.

Testa effekten

Efter aktivering ska du inte bara vänta på feedback från användare. Ett rent test sparar mycket tid.

Praktisk process:

1. Ställ in testklient och käll-IP.
2. Starta applikationen medvetet eller ring upp målet.
3. Filtrera i Loggvisaren efter käll-IP, destination, tjänst och applikation.
4. Kontrollera vilken brandvägg Rule ID som träffades.
5. Kontrollera om Application Control känner igen applikationen.
6. Notera applikations-ID, kategori, åtgärd och Application Filter.
7. Vid blockering kontrollera om spärren är tekniskt önskvärd.
8. Om upptäckten är otydlig, lägg till Packet Capture, serviceloggar och central loggning i syslog-fälten.

Loggtypen beror på åtgärden: en blockerad träff i ett Application Filter visas som Content Filtering > Application > Denied. Tillåten trafik som endast har identifierats finns däremot i brandväggsloggen som Firewall > Firewall Rule > Allowed. Firewall Rule ID, användare, applikation, kategori, risk, åtgärd, källa och mål är särskilt relevanta för acceptans.

Vid Syslog- eller SIEM-analys måste även utdataformatet beaktas. I det aktuella Central Reporting Format heter viktiga fält fw_rule_id, app_filter_policy_id, app_name, app_category, app_risk, app_resolved_by, qualifier och status. Device Standard Format (Legacy) använder bland annat application_filter_policy, application_name, application_category, application_risk och appresolvedby. De båda uppsättningarna fältnamn får inte blandas i SIEM. Det aktuella identifieringsfältet visar om en signatur, proxy- eller Micro App-identifiering eller Synchronized Application Control (EAC) var inblandad.

Application Filter och DPI engine-applikationsidentifieringen loggar tekniska detaljer i ips.log. Loggtilldelningen finns i Sophos Firewall Felsökning: tjänster och loggar. Sophos Firewall regeltest med Log Viewer, Policy Test och Packet Capture hjälper till att skilja mellan Log Viewer och Packet Capture.

Växla från att titta till att blockera

Skiftet från ren upptäckt till blockering bör göras medvetet. I många miljöer är det bättre att först använda Application Control som ett observations- och rapporteringsverktyg. Därefter blockeras endast applikationer vars risk, användarbas och affärsberoende förstås.

Innan du blockerar bör du kontrollera:

• Vilka användare, nätverk eller enheter använder faktiskt applikationen?
• Vilken brandväggsregel och Rule ID kan du se i Log Viewer?
• Är applikationen pålitligt igenkänd eller bara som en generisk kategori?
• Finns det legitima affärsanvändningar, supportärenden eller leverantörsverktyg?
• Ska applikationen blockeras överallt eller bara på gäst-, skola-, klient- eller servernätverk?
• Vem godkänner ett undantag och när kommer det att ses över igen?

En kort process är praktiskt taget ren: samla först in loggdata, blockera sedan enskilda applikationer eller små grupper, validera sedan med testklienten och Log Viewer. Om ett block verkar för brett bör du inte inaktivera hela Application Filter, utan snarare specifikt justera den berörda applikationen, kategorin eller regelpositionen.

Om Application Control inte fungerar

Om problem uppstår ska inte hela filtret avaktiveras omedelbart. Kontrollera först var avloppet går sönder.

• Ingen loggpost för testanslutningen: Loggning saknas eller trafik når inte brandväggsregeln. Kontrollera Rule ID, källzon och Packet Capture.
• Log Viewer visar andra Rule ID: En mer allmän regel finns ovan. Rätt regelordning och matchningskriterier.
• Ansökan förblir unknown eller generisk: Erkännande räcker inte utan mer sammanhang. TLS Inspection, QUIC och kontrollera applikationssignaturer.
• Blockera träffar för många tjänster: Kategori eller Smart Filter är för brett. Använd individuella applikationer eller små grupper.
• Efter en mönsteruppdatering blockeras plötsligt mer: En bred regel om risk, kategori eller klassificering träffar nya signaturer. Kontrollera kontrollkriterier och förändringsprocess.
• Cloud App-detaljer saknas: uppladdnings-/nedladdningsräknare och filtyper kräver HTTPS-decryption. En Web Policy som inte är None förbättrar dessutom noggrannhet och detaljnivå. Kontrollera Cloud App Reporting, TLS-status och Web Policy separat.
• Blockering fungerar bara för vissa klienter: Kontrollera annan regel, zon, användargrupp eller webbläsarsökväg. Jämför testklient, användare och nätverkssökväg.
• IPv6 beter sig annorlunda än IPv4: Separat IPv6-regel, annan DNS-sökväg eller annan webbläsarsökväg möjlig. Testa medvetet båda protokollen eller ta korrekt hänsyn till IPv6 i reglerna.

Den viktigaste testpunkten är Rule ID. Om den förväntade regeln inte uppfylls är applikationskontrollpolicyn nästan aldrig grundorsaken.

Behandla falska positiva rent

Om Application Control blockerar legitim trafik bör du inte omedelbart inaktivera hela filtret.

Förnuftig ordning:

1. Dokumentera den berörda applikationen och loggposten.
2. Kontrollera vilken brandväggsregel och vilken Application Filter som är inblandade.
3. Kontrollera applikation, kategori och åtgärd i filtret.
4. Kontrollera om applikationen känns igen annorlunda av TLS Inspection.
5. Ange undantaget så snävt som möjligt: applikation, källnätverk, användargrupp eller mål.
6. Dokumentägare och granskningsdatum för undantaget.

Ett undantag för Any eller en bred kategori löser ofta det aktuella fallet snabbt, men försvagar kontrollen permanent. Ett litet, förståeligt undantag med en tydlig anledning är bättre.

Typiska misstag

• Application Filter skapad men inte vald i regeln: Ingen effekt på trafiken. Aktivera filter i den riktiga brandväggsregeln.
• Trafiken passerar genom en annan regel: Filtret nås aldrig. Kontrollera Rule ID i Log Viewer.
• För bred kategori blockerad: Legitima moln- eller företagstjänster kan påverkas. Använd individuella applikationer eller smalare grupper.
• Dynamiska filter förstås inte: Risk, Kategori eller Klassificering kan få nya träffar genom signatur- och molnappuppdateringar. Kontrollera regelbundet.
• HTTPS-detektion överskattad: Applikationen detekteras inte på ett tillförlitligt sätt. Kontrollera beteendet TLS Inspection och QUIC.
• Loggning saknas: Effekten förblir osynlig. Aktivera regelloggning för testning och drift.
• Undantaget för brett: Skyddsfunktionen är praktiskt taget eliminerad. Sätt undantaget snävt och med granskningsdatum.

Driftskontroll

Application Control bör kontrolleras regelbundet. Applikationer förändras, molntjänster använder nya slutpunkter, användare använder nya verktyg och signaturer uppdateras.

Du bör dokumentera:

• Syftet med Application Filters
• påverkade brandväggsregler
• blockerade eller tillåtna applikationer
• kända undantag
• teknisk ägare
• Granskningsdatum
• senaste relevanta ändringen

Om Application Control används för kritiska affärsapplikationer, skolnätverk eller efterlevnadskrav, bör Central Reporting, Syslog eller SIEM också kontrolleras. För central utvärdering är Aktivera central brandväggsrapportering eller Sophos Firewall Konfigurera syslog och SIEM lämplig.

Checklista

• Licensstatus kontrollerad.
• Berörd brandväggsregel tydligt identifierad.
• Application Filter skapad med ett tydligt syfte.
• Mall, dynamiska filter och regelkriterier dokumenterade.
• Filter valt i rätt brandväggsregel.
• Regelloggning aktiv.
• Testklient och testapplikation definierade.
• Log Viewer har markerats för Rule ID och Application Control.
• Verklig användning, ägare och undantagsregel förtydligas innan blockering.
• IPv4- och IPv6-sökvägen kontrolleras om båda är aktiva i nätverket.
• TLS Inspection och QUIC utvärderas när HTTPS-detektering är otydlig.
• Molnapprapportering kontrolleras med HTTPS-dekryptering och webbpolicy om det behövs.
• Undantag noggrant dokumenterade.
• Granskningsdatum satt.

Vanliga frågor