Sophos Firewall Kontrollera lagringsutrymme och hantera rapporter

Om en Sophos Firewall varnar för lågt lagringsutrymme bör filer inte raderas och reports inte stängas av direkt. Först måste det vara klart vilken partition som påverkas, om lokala rapporter, loggar, e-postköer, karantän, supportfiler eller en för liten virtuell hårddisk är orsaken.

Artikeln förklarar hur man kontrollerar lagringsstatusen på Sophos Firewall, hanterar lokala rapporter på ett kontrollerat sätt och bara inaktiverar on-box-rapportering när konsekvenserna är förstått. För långsiktig logglagring är Sophos Fusion Firewall Reporting ofta ett bättre tillägg eftersom du inte bara är beroende av lokal rapportdata på enheten.

⚠️ Viktigt: Att ta bort rapporter eller inaktivera on-box-rapporter kan oåterkalleligt ta bort lokala rapporter och loggdata. Innan sådana åtgärder vidtas bör det kontrolleras om de nödvändiga uppgifterna exporteras, lagras centralt eller inte längre behövs för support- och revisionsändamål.

När lagringsutrymme blir kritiskt

Lagringsproblem dyker inte alltid upp direkt. Typiska meddelanden är:

• Varningsmeddelande eller kontrollcentermeddelande om hög minnesförbrukning.
• Rapporter laddas långsamt, förblir tomma eller visar inte aktuella data.
• Lokala loggfiler växer snabbt.
• Rapport- eller databastjänster ger fel.
• Firmware-uppgradering eller snabbkorrigeringsinstallation rapporterar om otillräckligt ledigt minne.
• Virtual Firewall distribuerades med en disk som var för liten.
• E-postskydd, karantän eller hög webb-/applikationstrafik genererar mycket lokal data.

Om I/O-fel, ovanliga omstarter eller databasproblem också uppstår samtidigt bör inte bara lagringsutrymme frigöras. Då bör även SSD-tillståndet via SMART och relevanta Tjänster och loggar kontrolleras.

Om brandväggen redan är i Failsafe-läge ska Reports eller filer inte tas bort först. Med Kontrollera Sophos Firewall i Failsafe-läge sparas orsaken som SFOS har identifierat innan den riktade lagringsanalysen börjar.

För Reports finns en viktig tröskel: som standard varnar firewall när den relevanta partitionen når 70 procents användning. Från 80 procent stoppas report generation. Därefter räcker det normalt inte att bara radera några data. Användningen måste tillbaka under varningströskeln för att Reports ska skapas tillförlitligt igen.

E-post- och SNMP-aviseringen vid den högre tröskeln är som standard avstängd. Under System services > Notification list > Disk/Memory aktiveras Reports disk usage exceeded threshold för e-post, SNMP eller båda målen. Detta ersätter inte övervakningen av den tidigare varningen: Control Center och Log Viewer visar redan den lägre tröskeln och den senare överskridningen.

På mycket små appliances är beslutet ännu tydligare: XGS 87/87w och XGS 88/88w har inget On-Appliance Reporting. För dessa modeller är central retention via Sophos Fusion (tidigare Sophos Central), Syslog eller SIEM därför inte en senare optimering, utan en del av driftkonceptet.

Vad som tar upp lagring på brandväggen

Många lokala driftdata ligger under /var. Där lagrar brandväggen bland annat Reports, Event Logs, Troubleshooting Logs och data från andra komponenter. De enskilda områdena har egna kvoter beroende på appliance-modell och funktion. En liten branch-firewall beter sig därför inte som en stor appliance med mer lokal kapacitet.

Viktigt är att skilja mellan:

• Reports: Reports sparas inte längre korrekt eller måste förkortas respektive raderas. Risken är kortare lokal historik och saknade utvärderingar.
• Event Logs: Äldre loggar tas bort, nya events kan fortsätta skrivas. Den historiska analysen blir därmed kortare.
• Troubleshooting Logs: Äldre komprimerade loggfiler tas bort. För supportanalyser kan ett viktigt tidsfönster saknas.
• E-postkarantän: Äldre karantänmeddelanden kan tas bort. Spårbarhet och frisläppningsprocesser påverkas.
• Temporära filer eller manuellt kopierade filer: Sådana filer kan blockera lagring i onödan. Orsaken förblir dold om man bara raderar Reports.

Kvoten för Event Logs beror på appliance-modellen. Som exempel för större modeller anger Sophos högst 15 procent av hela /var-partitionen eller 50 procent av det för tillfället lediga utrymmet i /var, beroende på vilket värde som är lägst. Det är ingen fast kvot för varje modell och ingen garanti för en viss lagringstid.

SFOS genererar som standard endast en varning om nästan fullt komponentutrymme för Reports. Event Logs tar bort äldre poster, Troubleshooting Logs äldre komprimerade filer och e-postkarantänen äldre meddelanden utan en egen lagringsvarning. Extern lagring och monitoring måste därför planeras innan ett nödvändigt tidsfönster försvinner automatiskt.

Disk Usage-grafen i WebAdmin hjälper vid första bedömningen. Där visas signaturer, konfigurationsdata, Reports och temporär lagring separat. Det ersätter ingen detaljanalys, men visar om det snarare är Reports, temporära data eller andra områden som sticker ut.

Reports och logs ska inte blandas ihop. Report-retention under Reports > Show Reports settings > Data management påverkar Reports. Event Logs för Log Viewer, Sophos Fusion eller Syslog styrs under System services > Log settings. Den som kortar Report-retention minskar inte automatiskt lokala Event Logs.

Efter en avstängning eller omstart kan SFOS bearbeta reportdata som fortfarande väntar och tilldela dem dagen före omstarten i stället för den faktiska tidpunkten för händelsen. En post med det datumet bevisar därför inte ensam att trafiken inträffade då. För en incidenttidslinje korreleras reporten, uptime, Event Logs och tillgängliga externa loggar.

Sedan SFOS 21.0 kan firewall också hantera Reports före och efter en upgrade i separata reportdatabaser. På upgrade-dagen kan reportvyn därför visa ett motsvarande urval. Viktigt vid rollback: Om man efter en upgrade går tillbaka till en äldre firmwareversion kan Reports som skapats sedan uppgraderingen gå förlorade. Nödvändiga Reports bör därför exporteras eller centraliseras före firmwarearbete.

Kontrollera lagringsutrymme i Device Console

För en snabb översikt kan du kontrollera använd lagring i Device Console. Kommandot visar de relevanta minnesområdena för Sophos Firewall:

system diagnostics show disk

Device Console är avsedd för Sophos-specifika kommandon. Om åtkomst via SSH behöver förberedas hjälper Sophos Firewall ansluta via SSH. Den beskriver också varför SSH endast bör tillåtas från pålitliga administratörsnätverk.

Kontrollera lagringsutrymme i Advanced Shell

I Advanced Shell kan du ta en närmare titt på filsystemen. Detta kommando visar storlek, använt minne, ledigt minne och procentuell användning:

df -hkm

Om det är oklart om hela utdata är för omfattande kan man titta specifikt på /var, eftersom många lokala driftdata ligger där:

df -h /var

Kommandot är skrivskyddat. Filer i systemkataloger bör inte raderas manuellt bara för att en partition ser full ut. Först bör orsaken begränsas.

Om /var sticker ut bör man först kontrollera de avsedda Sophos-områdena i stället för att radera kataloger på måfå. För en grov bedömning är särskilt Reports, Event Logs och Troubleshooting Logs relevanta. Kontrollera dessutom om Packet Capture, Debug-Logging, supportfiler eller manuellt kopierade filer tar upp lagring.

För tre typiska Sophos-lagringsblock anger Sophos dessa läskommandon i Advanced Shell:

du -kh reportdb_16
du -kh eventlogs
du -kh tslog

Kommandona är endast till för klassificering. De ersätter inte stödd rensning via WebAdmin, Device Console eller avsedda diagnostikfunktioner.

Begränsa orsaken

En full disk kan ha flera orsaker. Nästa steg beror på vilken data som växer.

• Reports tar upp mycket lagring: Kontrollera retention under Reports > Show Reports settings > Data management, exportera Reports eller använd Sophos Fusion Reporting.
• Lokala Logs växer snabbt: Kontrollera Log settings, Debug-Logging och berörda services.
• Troubleshooting Logs växer snabbt: Kontrollera Debug-Logging, aktiv supportanalys eller återkommande tjänstefel.
• /var är tydligt fullt: Kontrollera Reports, Logs, databas, supportfiler eller Mailqueue.
• Disk Graph visar mycket temporär lagring: Kontrollera pågående captures, supportfiler eller temporära processer.
• E-postkarantän eller Mail Spool växer: Kontrollera Email > Quarantine settings och Email > Mail spool. Fastnade meddelanden bör kontrolleras, levereras igen kontrollerat eller raderas.

Konfigurera och testa karantänsammanställningar på Sophos Firewall förklarar den automatiska rensningen av karantänområdet vid 90 procent, sammanställningen, användartilldelningen och frisläppningstestet.

• Virtuell brandvägg är för snålt dimensionerad: Kontrollera diskstorlek och plattformskrav i hypervisorn.
• Varning före firmware-upgrade: Starta inte uppgraderingen i blindo, utan kör först SFOS 22 Upgrade Check.
• HA-kluster påverkat: Kontrollera båda noder separat, eftersom lokala Logs och Reports inte måste vara identiska.

Om det finns aktiva fel bör loggar först sparas medan felet är färskt. Artikeln Sophos Firewall Säkerhetskopiera loggar för support och analys beskriver hur man exporterar lokala loggdata.

Om Event Logs belastar lokal lagring är Report-retention inte rätt verktyg. Då bör man under System services > Log settings kontrollera vilka moduler som lagras lokalt, skickas till Sophos Fusion eller vidarebefordras till Syslog. Log Suppression kan hjälpa till att minska onödiga upprepningar. Säkerhetsrelevanta events som senare behövs för Incident Response, support eller compliance bör däremot inte försvinna.

Ta inte bort manuellt i filsystemet

Även om Advanced Shell visar ledig lagring och kataloger bör man inte ta bort filer direkt i /var, /log eller databaskataloger. Manuella raderingar kan skada Reports, tjänster, databaser eller supportanalyser och göra senare orsaksanalys svårare.

Bättre process:

• Dokumentera lagringsstatus och påverkad partition.
• Säkra relevanta loggar eller CTR om ett supportärende är troligt.
• Kontrollera om Packet Capture eller Debug-Logging fortfarande är aktivt.
• Kontrollera Report-retention via WebAdmin.
• Töm endast rapporter via den avsedda konsolpunkten om det är tydligt att lokal data kan utelämnas.
• Om konsumtionen fortsätter att öka, kontrollera orsaken: felsökningsloggning, e-postkö, karantän, databas, virtuell disk eller ovanligt hög lokal trafik.

Om det är oklart vilka data som tar upp lagringen bör man inte arbeta med rm. Då är det säkrare att säkra loggar och involvera support eller Avanet med aktuell status.

För Troubleshooting Logs finns separata purge-kommandon i Device Console. De ersätter inte orsaksanalysen och används först när nödvändiga loggar har säkrats och berört delsystem har fastställts entydigt:

system diagnostics purge-old-logs
system diagnostics purge-all-logs
system diagnostics subsystems <subsystem> purge-old-log
system diagnostics subsystems <subsystem> purge-log

De två första kommandona påverkar alla Troubleshooting Logs: purge-old-logs tar bort komprimerade rotationer, medan purge-all-logs även tar bort aktuella filer. De två delsystemsvarianterna begränsar samma åtgärder till ett delsystem som stöds. Kontrollera det giltiga namnet med CLI-hjälpen eller Tab Completion före körning. En purge kan inte ångras; vid osäkerhet är en riktad export under Diagnostics > Tools säkrare.

Ändra skrivrättigheter för rapportpartitionen endast kontrollerat

Device Console kan globalt tillåta eller blockera skrivning till rapportpartitionen. SFOS 22-syntaxen anger endast report; partition-name är ett nyckelord och inte en platshållare för en valfri sökväg. Läs status före en ändring:

system filesystem enforce-disk-write partition-name report show

Standardvärdet är enable. disable är ingen lagringsrensning och tar inte bort rapporter. Det förhindrar skrivning till rapportpartitionen och kan därför göra lokala rapportdata, vyer och beroende processer ofullständiga. Ändra inställningen endast som en planerad recovery- eller supportåtgärd, inte som tuning:

system filesystem enforce-disk-write partition-name report disable
system filesystem enforce-disk-write partition-name report show

Tillåt skrivning igen vid återställning och kontrollera status på nytt:

system filesystem enforce-disk-write partition-name report enable
system filesystem enforce-disk-write partition-name report show

enable i sig bevisar inte att rapportdatabasen och lokala vyer skriver korrekt igen. Efter återställningen kontrolleras en ny rapportperiod, Generate now, lokala dashboards, schemalagda rapporter och lagringstrenden. Om partitionen förblir skrivskyddad eller I/O-fel uppstår ska inställningen inte växlas upprepade gånger. Kontrollera i stället SSD, virtuell rapportdisk, monteringsstatus och supportärende.

Justera rapportlagring i WebAdmin

Om lokala rapporter är orsaken bör du först kontrollera lagringstiden. I många miljöer sparas On-Box Reports fortfarande av gammal vana, trots att analysen numera sker centralt.

Sophos-sökvägen för lokal Report-retention är:

Reports > Show Reports settings > Data management

Där kan du ange högst ett års lagringstid per reportmodul och spara med Apply. SFOS räknar bakåt från föregående månad, så den pågående månaden är inte den första lagringsmånaden. Ändringar börjar gälla kl. 00:00. Inställningen påverkar Reports, inte Event Logs.

Användbara frågor innan du gör en förändring:

• Utvärderas verkligen lokala rapporter fortfarande?
• Finns det redan Sophos Fusion Reporting, syslog eller en SIEM?
• Hur länge måste logg- och rapportdata lagras internt?
• Finns det några efterlevnads- eller supportkrav?
• Är kortare lokal retention tillräckligt när central lagring är aktiv?

Om Logs och Reports behövs i Sophos Fusion bör man dessutom kontrollera vilka loggtyper som skickas till Sophos Fusion under System services > Log settings. Aktivering beskrivs i Aktivera Sophos Fusion Firewall Reporting.

Anpassa och slutför en rapportexport

Under Reports > Show Reports settings > Data management styr Export customization vilka rapporter som ingår i en export och hur många poster som exporteras per rapport. Välj endast de rapporter som behövs och ange antalet poster per rapport innan exporten startas. Inställningen är separat från lagringstiden och raderar inga lokala data.

Slutför exporten i WebAdmin enligt följande. Rapporter kan inte hämtas via CLI:

1. Gå till Reports och öppna Applications & web.
2. Välj rapportkriterier i Show och ange datumintervallet.
3. Välj Generate och kontrollera resultatet.
4. Välj önskat filformat för att hämta rapportdata.
5. Öppna den hämtade filen och bekräfta att avsedda rapporter, tidsperioden och antalet poster finns med innan den används som säkerhetskopia eller revisionsunderlag.

Det konfigurerade antalet poster per rapport begränsar det hämtade innehållet. En slutförd hämtning bevisar därför inte att alla lokala poster har exporterats. Jämför omfattningen med verksamhets- eller efterlevnadskraven.

Radera rapporter på ett kontrollerat sätt

Om tjänster inte längre fungerar korrekt på grund av fullt lagringsutrymme kan rapporter behöva rensas manuellt. Behandla det som en kontrollerad återställningsåtgärd, inte som rutinunderhåll.

Kontrollera i förväg:

• Säkerhetskopiering av aktuell konfiguration tillgänglig
• Obligatoriska rapporter exporterade eller tillgängliga centralt
• påverkade perioder dokumenterade
• Orsaken till lagringstillväxten förstås
• Underhållsfönster eller supportärende förberett om brandväggen redan är instabil

Första vägen bör vara WebAdmin:

Reports > Show Reports settings > Manual purge

När du har valt reportmodul och kriterium kan du ange ett eget tidsintervall eller radera alla data för modulen. Med Purge startar åtgärden omedelbart och kan inte ångras. Rensningen är avsiktligt långsam: SFOS behandlar fem databastabeller per minut för att skona systemresurserna.

Om detta inte räcker eller om firewall redan är i ett recovery-läge finns konsolpunkten:

5. Device Management > 4. Flush Device Reports

Efter raderingen ska du inte bara återgå till den dagliga driften. Det är viktigt att kontrollera om det lediga minnet verkligen ökar och om rapporter, Log Viewer, Sophos Fusion Reporting och de berörda tjänsterna sedan fungerar rimligt igen.

Flush Device Reports raderar Reports som är sparade på firewall och startar om firewall. Under denna tid är enheten inte nåbar via nätverket i cirka tio minuter. Därför hör steget hemma i ett underhållsfönster eller i en dokumenterad recovery-process.

Om brandväggen redan påverkar tjänster på grund av full lagring måste det vara klart vilka data som saknas efter raderingen. Lokala Reports är ofta användbara för change reviews, användaranalys, säkerhetsspårbarhet eller supportfrågor. Den som raderar dem behöver en kort notering med tidsperiod, orsak och tillgänglig ersättningskälla, till exempel Sophos Fusion Reporting eller Syslog.

Kontrollera eller avaktivera on-box-rapporter

On-Box Reports sparar rapporter lokalt på brandväggen. Detta är praktiskt, men kan använda minne för små apparater, hög trafik eller lång lagring.

Status kontrolleras i Device Console:

show on-box-reports

Detta kommando besvarar inte samma fråga som system diagnostics show disk: show on-box-reports visar om lokala reports i princip är aktiva, medan system diagnostics show disk visar aktuell lagringsanvändning för de olika områdena. För en ren diagnos behövs oftast båda vyerna.

Om lokala rapporter inte behövs och ett annat lagringsalternativ är tillgängligt, kan du inaktivera on-box-rapporter:

set on-box-reports off

Rollback förbereds innan rapporterna stängs av. on startar lokal reportgenerering igen; en lucka från den inaktiverade perioden förutsätts inte fyllas i efterhand:

set on-box-reports on
show on-box-reports

Kontrollera därefter ett nytt lokalt report, Log Viewer, ett schemalagt report och lagringstrenden. Enbart status on bevisar inte att reportingdatabasen och reportvyerna fungerar rimligt igen.

Detta bör bara göras medvetet. Reports är viktiga för analys, support och drift. I många produktiva miljöer är det bättre att minska lokal retention och samtidigt använda Sophos Fusion Reporting, Syslog eller ett SIEM. Om längre central retention behövs är Sophos Central Firewall Reporting Advanced ett möjligt alternativ.

Viktigt: On-Box Reports kan bara aktiveras eller inaktiveras som helhet, inte selektivt per modul. Om bara enskilda reportområden använder för mycket lagring är kortare retention eller riktad purging oftast bättre än att stänga av On-Box Reporting helt.

Om On-Box Reports stängs av bör man efteråt inte bara kontrollera lagringen. Även interna processer förändras: lokala Report-vyer, schemalagda PDF-rapporter, säkerhetsutvärderingar och snabba ad hoc-analyser på firewall kan försvinna eller bli mindre användbara. Därför är detta ett driftbeslut, inte spontan lagringsstädning.

Klassificera varningströsklar och alerts

Sophos Firewall kan skapa Control Center-alerts och Event Logs vid hög /var-användning. Varningströskeln kan styras via Device Console med set var-partition-usage watermark. Det är däremot ingen lagringsfix. En lägre eller högre varningströskel ändrar bara när en varning visas, inte varför lagring används.

Det tillåtna intervallet är 50 till 75 procent, standard är 70 procent. Reporting stoppas vid 80 procent och detta stopp är inte en lämplig driftgräns, utan redan ett feltillstånd. En högre varningströskel gör inte firewall stabilare, utan minskar reaktionstiden.

Läs det aktuella värdet i Device Console före en ändring. Den fullständiga syntaxen för SFOS 22 är:

show var-partition-usage watermark
set var-partition-usage watermark <50-75>
set var-partition-usage watermark default

default ställer in varningströskeln på 70 procent och återställer inte automatiskt ett tidigare anpassat värde. För återställning anges uttryckligen det tal som tidigare registrerats med show. Kommandot ändrar varken gränsen på 80 procent som stoppar Reporting eller raderar reports, logs eller en befintlig kapacitetsbrist.

För drift är det oftast mer meningsfullt att:

• aktivera e-post- eller SNMP-meddelanden för lagringsvarningar
• inte skjuta upp lagringsvarningar till nästa underhållsfönster
• justera retention, Debug-Logging och lokal Report-användning vid återkommande varningar
• medvetet kontrollera ledig lagring före firmware-upgrades

Om användningen ökar tydligt eller Reports redan stannar bör man först frigöra lagring och klargöra orsaken. En ändrad varningströskel får inte användas för att dölja ett verkligt kapacitetsproblem.

Var uppmärksam på virtuella brandväggar

Med virtuella Sophos Firewalls finns inte alltid orsaken i rapporter eller loggar. Ibland distribuerades den virtuella enheten med för lite disk eller växte under flera år utan att omvärdera plattformskraven.

I virtuella miljöer bör du också kontrollera:

• Storleken på den virtuella disken.
• Ledigt utrymme i dataarkivet.
• Ögonblicksbilder, säkerhetskopieringsjobb och lagringsfördröjning.
• Övervakning av hypervisorn.
• Om brandväggsversionen anger ytterligare minneskrav.
• Om den virtuella disken får utökas online eller om ett reimage med restore är den renare vägen.

Om disken i grunden är för liten är det bara en kortvarig lättnad att ta bort rapporter. Den virtuella plattformen ska då vara ordentligt anpassad och säkrad med backup, underhållsfönster och återställningsplan.

Före SFOS 22 är denna punkt särskilt viktig: Om brandväggen visar en lagringsvarning eller en upgrade-blocker för virtuell disk bör man först arbeta igenom SFOS 22 Upgrade Check. Där länkas de officiella Sophos-hänvisningarna om virtuell disk. Utökningen hör hemma i ett planerat underhållsfönster med backup, kontrollerad hypervisor-lagring och efterföljande validering av partitionerna.

För hardware appliances är däremot diskutökning inte den normala vägen. Där bör man kontrollera lagringsförbrukning, Reports, Logs, karantän och SSD-tillstånd och vid hårdvarumisstanke förbereda ett support- eller RMA-flöde.

Checklista

Kontrollera omedelbart

• Varningsmeddelande, tid och påverkad brandvägg dokumenteras.
• system diagnostics show disk körd i Device Console.
• df -hkm kontrollerad i Advanced Shell.
• Ovanlig partition märkt.
• Disk Usage-grafen i WebAdmin kontrollerad för grov bedömning.
• Rapporter, loggar, e-postkö, karantän och virtuell disk utvärderas som möjliga orsaker.
• Packet Capture och Debug-Logging kontrollerade som kortsiktiga lagringskällor.

Innan du tar bort eller avaktiverar

• Nödvändiga rapporter och loggar säkerhetskopierade.
• Sophos Fusion Reporting, syslog eller annan central lagring kontrollerad.
• Säkerhetskopierings- och återställningsväg tillgänglig.
• Underhållsfönster definieras när produktiva tjänster påverkas.
• Vid HA kontrolleras båda noderna separat.
• Tidsperiod och orsak till en Report-rensning dokumenterade.

Efter rengöring

• Ledigt minne kontrollerat igen.
• Rapporter och Log Viewer testade.
• Sophos Fusion Reporting eller Syslog kontrolleras för aktuella data.
• Orsak till minnestillväxt dokumenterad.
• Lagringsperiod, logginställningar och granskningsprocess justerade.
• Aviseringar för framtida lagringsvarningar kontrollerade.

FAQ