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:

• lämplig licens med Web Protection eller Application Control
• 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 kan kontrolleras under System > Administration > Licensing. Typiska Sophos-brandväggspaket med Web Protection inkluderar Application Control. Den specifika licenslogiken bör fortfarande kontrolleras före produktiv implementering, särskilt i fallet med utgångna prenumerationer eller testlicenser.

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: sammanfattar applikationer som ett objekt. Användbar för återanvändbara grupper när samma urval används flera gånger.
• 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 ren blockering eller tillåt policy är Application Filter den viktigaste ingångspunkten. Application Objects och trafikformning blir bara intressanta när applikationsvalet behöver återanvändas eller bandbredden behöver kontrolleras specifikt.

Synkroniserad Application Control är inte en ersättning för rena brandväggsregler. Den behöver Sophos Central, Security Heartbeat och lämplig Sophos-ändpunktstä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.

Skapa Application Filter

Menysökväg:

Applications > Application filter

I äldre navigeringsvyer 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.

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:

Protect > 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 känna igen vissa applikationer även utan en fullständig TLS Inspection. Med många moderna HTTPS- och molntjänster ser brandväggen endast begränsad information som IP-adress, SNI, certifikatdata, värdnamn eller anslutningsmetadata utan dekryptering.

Detta räcker inte alltid för tillförlitlig upptäckt. 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?
• finns det QUIC eller HTTP/3 som gör kontrollen svår?
• 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.

En triad rekommenderas därför för molnappsrapportering: Aktivera Logga brandväggstrafik, dekryptera HTTPS där det är organisatoriskt och tekniskt försvarbart och använd en webbpolicy som inte bara är None. Detta gör applikationskontrolldata mycket mer användbar i driften.

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.

Programkontrollhändelser visas i Log Viewer som program- eller innehållsfiltreringshändelser. Brandväggen Rule ID, användare, applikation, kategori, risk, åtgärd, källa och mål är särskilt relevanta för acceptans. För syslog- eller SIEM-utvärdering bör fält som fw_rule_id, application_name, application_filter_policy, application_category, application_risk, status och appresolvedby också kontrolleras. Den senare hjälper till att klassificera om applikationen kändes igen via signatur, proxylogik eller synkroniserad Application Control.

Application Control använder ofta ips.log i den tekniska sökvägen. 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.
• Molnappdetaljer saknas: Utan HTTPS-dekryptering eller utan webbpolicy är uppladdnings-, nedladdnings- och filtypsinformation begränsad. Kontrollera molnappsrapportering och TLS-status.
• 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