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 Central 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.

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.

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 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.

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 Central eller Syslog styrs under System services > Log settings. Den som kortar Report-retention minskar inte automatiskt lokala Event Logs.

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 Central 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.
• 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 Central 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 bör bara användas efter att nödvändiga logs har säkrats. Förenklat tar system diagnostics purge-old-logs bort äldre komprimerade logs, medan system diagnostics purge-all-logs tar bort alla Troubleshooting Logs. För enskilda subsystems finns mer specifika varianter. Vid osäkerhet är en riktad export under Diagnostics > Tools oftast renare än en generell purge.

Justera rapportlagring i WebAdmin

Om lokala rapporter är orsaken bör lagringstiden kontrolleras först. I många miljöer har on-box-rapporter historiskt gjorts, även om själva utvärderingen nu görs centralt.

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

Reports > Show Reports settings > Data management

Där kan retentionstiden justeras per reportmodul och sparas med Apply. Ändringen påverkar Reports, inte Event Logs. Sophos anger också att ändringar av Report-retention börjar gälla först kl. 00:00.

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

• Utvärderas verkligen lokala rapporter fortfarande?
• Finns det redan central rapportering, 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 Central bör man dessutom kontrollera vilka loggtyper som skickas till Central under System services > Log settings. Aktivering beskrivs i Aktivera Central Firewall Reporting.

Radera rapporter på ett kontrollerat sätt

Om tjänster inte längre fungerar korrekt på grund av fullt minne kan manuell rengöring av rapporter bli nödvändig. Men detta bör vara en kontrollerad återhämtningsåtgärd, inte den normala driftprocessen.

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

Där kan Reports raderas riktat efter modul och tidsperiod. Processen kan vara långsam eftersom firewall medvetet utför Report purge kontrollerat för att spara systemresurser.

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, central rapportering 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 Central 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

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 Central 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 Reports, 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.

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.
• Central rapportering, 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.
• Central Rapportering 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