Tolka User & Device Insights i Sophos Firewall korrekt

Control Center > User & device insights är en triagevy, inte ett enda larmtillstånd. Rutorna använder olika datakällor och tidsperioder. En röd endpoint, hög User Threat Quotient (UTQ), ett TLS-fel och många sessioner kan höra ihop, men behöver inte göra det.

Säker ordning: anteckna ruta och tidsperiod, öppna detaljer, korrelera användare/IP/hostname och tid med loggar och regeln som faktiskt matchade och ändra först därefter policy eller undantag. Spara före ändringen skärmbild eller export, filter, felantal, mål, ägare och förväntat resultat.

Vad varje signal bevisar – och inte bevisar

• Security Heartbeat visar tillståndet som Sophos-endpoints rapporterar. Det bevisar inte att varje anslutning blockerades eller att en grön enhet är helt fri från hot.
• Synchronized Application Control visar applikationer som hanterade enheter rapporterar. En post bevisar identifiering, inte policytillämpning eller skadlig aktivitet.
• Zero-day protection räknar analyserade filer och fynd. Antalet bevisar inte att varje nedladdning var synlig eller skadlig.
• UTQ prioriterar konton utifrån sju dagars surfning. Det är en utredningssignal, inte bevis på skuld eller intrång.
• SSL/TLS connections beskriver observerade anslutningar och vissa dekrypteringsfel. Procenttal bevisar inte skyddet för ett enskilt flöde.
• Firewall sessions visar aktiva anslutningar och närhet till kapacitet. Ett högt antal bevisar ensamt varken attack eller överbelastning.

Sök minst två överensstämmande bevis, exempelvis ruta och detaljlogg eller endpoint-händelse och Firewall Rule ID. För aktiva flöden används Live Connections och Connection List.

Kontrollera Security Heartbeat och applikationer

Tillstånden är At risk (röd), aktiv malware; Missing (röd), trafik finns men hälsostatus saknas; Warning (gul), inaktiv malware eller malware som hittats och rensats; Connected (grön), ingen malware hittad och endpoint rapporterar frisk.

Rutan räknar alla tillstånd, men detaljvyn listar endast röda och gula endpoints med hostname, IP, användare och tid sedan ändringen. Om alla är gröna är vyn tom. Det är inget datafel och ingen fullständig inventering.

Om en endpoint lämnar nätverket medan dess Heartbeat är Missing ligger statusen kvar i Control Center och rapporter. Den ändras först när endpointen ansluter igen. Innan en bekräftat inaktuell post tas bort dokumenteras endpointnamn, statusens ålder, senast kända användare och tid samt aktuell visning i Control Center och rapporten. Slutför först orsaksanalysen, öppna sedan CLI och välj 4. Device Console. Där kan alla Missing-poster som uppnått eller passerat en angiven ålder på 1 till 90 dagar, eller ett exakt endpointnamn, tas bort:

system synchronized-security missing-endpoints delete days-missing 7
system synchronized-security missing-endpoints delete name endpoint1

7 och endpoint1 är exempel som ersätts med godkänd ålder eller exakt namn. Ålderskommandot påverkar alla poster som varit Missing i så många dagar eller längre och kan ta bort fler enheter än avsett från Control Center och rapporter; namnkommandot är snävare för en känd avvecklad enhet. Borttagningen reparerar varken endpointen eller Heartbeat och återställer inte borttagen historik. Läs därefter in Control Center och berörd rapport på nytt, bekräfta att endast avsedda poster försvunnit och verifiera för en enhet som fortfarande används dess återanslutning och nya Heartbeat-status.

För en röd eller gul post kontrolleras först tid och endpoint i Sophos Fusion (tidigare Sophos Central), sedan om matchande brandväggsregel faktiskt har ett Heartbeat-villkor. Enbart synlighet blockerar inget. Ansluta Sophos Firewall till Sophos Fusion beskriver krav och regelverkan; felsöka Missing Heartbeat täcker kvarstående tillstånd.

Rutan Synchronized Application Control visar New, Categorized och totalt antal och öppnar Applications > Synchronized Application Control. Bedöm en ny applikation utifrån enhet, användare och tid, kategorisera den och styr den först därefter med ett Application Filter. Direkt databasrensning är inte triage; vid insamlings- eller lagringsproblem följs den säkra processen. Regeltilldelning beskrivs i Application Control.

Tolka Zero-day-räknare och UTQ

Zero-day-rutan kräver en aktiv Zero-Day Protection-prenumeration. Under Administration > Licensing måste modulen visa Subscribed eller Evaluating; utan prenumeration kan länken i Control Center starta en kostnadsfri 30-dagarsutvärdering.

Perioderna skiljer sig: Recent gäller nya malicious-, suspicious- eller PUA-rapporter under sju dagar; Incidents räknar alla sådana filer och behåller rapporter upp till sex månader, konfigurerbart under Report settings > Data management; Scanned omfattar all upptäckt trafik, även rena filer, beroende på databasens lagringstid.

Subtrahera inte räknarna. Öppna Zero-day protection > Downloads and attachments och korrelera fil, bedömning, användare/IP, tid och webb- eller e-postväg. Saknade fynd kan också bero på licens, policy, trafik som inte har dekrypterats eller lagringstid. Se guiden för Zero-day Protection.

UTQ bedömer sju dagars surfning. Den visar inga riskanvändare eller antalet användare som tillsammans står för 80 procent av nätverksrisken. I Reports > Dashboards kontrolleras användare, Threat Score, kategorier, mål, tider och identitetskvalitet. Delade konton, NAT eller saknad autentisering kan förvränga tilldelningen; ett högt värde motiverar inte automatiskt blockering.

Analysera SSL/TLS connections säkert

Detaljer uppdateras var femte minut. Saknas de i Control Center och Log Viewer, kontrollera SSL/TLS inspection under Rules and policies > SSL/TLS inspection rules och Enabled under SSL/TLS inspection settings > Advanced settings > SSL/TLS engine.

Of traffic är SSL/TLS-andelen av all trafik; Decrypted den dekrypterade andelen SSL/TLS-anslutningar; Failed antal misslyckanden. Failed nollställs vid midnatt och manuellt med Reset ‘Failed’ count. Manuell nollställning kan inte ångras eller återställa föregående värde. Notera först värde, tid och test; upprepa sedan flödet, vänta en cykel och granska loggar. Reset åtgärdar inte orsaken.

Detaljvyn visar sessioner från senaste 24 timmarna och fel från senaste 7 dagarna. Båda utesluter anslutningar via web proxy. Top websites och Top users eller IP avgränsar; klick på felantal öppnar filtrerade loggar med målet i Server name. Listan innehåller bara fel som kan lösas med en SSL/TLS-regel eller tyder på saknat CA-/application trust på klienten, inte blockeringar från Web Policy eller andra Security Policies.

Under Fix errors döljer Hide webbplats, användare eller IP utan att ändra dekryptering; Show hidden och Unhide återställer vyn. Dokumentera filtret så att dolt inte förväxlas med löst.

Exclude from decryption är en säkerhetsändring. Add domain eller Add subdomain lägger målet i gruppen Local TLS exclusion list, redigerbar under Web > URL groups. Dokumentera först exakt FQDN, klienter, Error ID, ägare, slutdatum samt positivt och negativt test. Välj den mer specifika underdomänen om bara en värd påverkas. Verifiera sedan funktion, att flödet inte längre dekrypteras och att andra domäner följer avsedd TLS-regel. Se stegvis TLS Inspection.

Vid återställning tas endast exakt den tillagda posten bort, efter kontroll av ägare och aktuell användning. Upprepa testet och bevaka nya trust-/TLS-fel. Ta aldrig bort ett delat eller befintligt undantag som antagen rollback.

Brandväggssessioner och dekrypteringskapacitet

Grafen erbjuder Live, 24h, 48h, Week, Month och Year. Live uppdateras var 30:e sekund, övriga var femte minut. Kategorier: Other traffic, Undecrypted SSL/TLS och Decrypted SSL/TLS.

Decryption peak är högsta antal samtidiga dekrypterade anslutningar under perioden och visas endast när trafiken närmar sig eller överstiger nivån. Decryption limit är modellens kapacitet och visas också först nära den. En saknad linje betyder inte obegränsad kapacitet. En kort topp bevisar inte överbelastning: jämför perioder och återkommande mönster med latens, resurser, drops och användarfel.

Validera och återställ ändringar

1. Spara utgångsvärde, period, filter, användare/IP/hostname, Error ID och Rule ID.
2. Testa en hypotes med minsta möjliga ändring.
3. Upprepa samma positiva test; för undantag även ett negativt test utanför omfånget.
4. Respektera uppdateringsintervallet och jämför detaljloggar, inte bara procenttal.
5. Om inget förbättras, återställ och kontrollera datakälla, period, web proxy, autentisering och regelmatchning igen.

Hide/Unhide är helt reversibelt. Ett nytt TLS-undantag återställs genom att just den posten tas bort om ingen annan använder den. Ett manuellt nollställt Failed-värde kan inte återställas; dokumentationen före ändringen är den enda tillförlitliga historiken.