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 diskutrymmesstatus på Sophos Firewall, hanterar lokala rapporter på ett kontrollerat sätt och endast inaktiverar On-Box Reporting när konsekvenserna är förstådda. För långsiktig logglagring är Sophos Fusion Firewall Reporting ofta ett bättre komplement, eftersom man då inte enbart är beroende av lokala rapportdata på appliancen.

⚠️ Viktigt: När rapporter raderas tas lokala rapportdata bort oåterkalleligt. Inaktivering av On-Box Reports stänger av all lokal rapportgenerering. Dessa åtgärder ska skiljas från lagring och rensning av Event Logs och Troubleshooting Logs. Innan åtgärderna vidtas bör det kontrolleras om nödvändiga data har exporterats, lagras centralt eller inte längre behövs för support- och revisionsändamål.

När lagringsutrymme blir kritiskt

Lagringsproblem visar sig på olika sätt. Typiska tecken är:

• Varningsmeddelande via e-post eller avisering i Control Center om hög diskutrymmesanvändning.
• 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 hotfix-installation rapporterar för lite ledigt diskutrymme.
• 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 det visade tillståndet och tillgängliga felmeddelanden innan den riktade lagringsanalysen börjar.

För rapporter finns en viktig tröskel: som standard varnar brandväggen när den relevanta partitionen når 70 procents användning. Från 80 procent stoppas rapportgenereringen. Om rapporteringen stoppas räcker det inte att komma strax under 80 procent; användningen måste tillbaka under varningströskeln för att rapporter 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.

Reports använder det tillgängliga utrymmet i /var. Felsökningsloggar (tslog) får däremot ett eget utrymme per komponent beroende på appliance-modell; kritiska komponenter får mer utrymme. När äldre komprimerade filer tas bort fortsätter nya loggar att skapas. Utrymmet för e-postkarantänen väljs under Email > Quarantine settings. Även där fortsätter nya e-postmeddelanden att sättas i karantän efter att äldre har tagits bort. Detta garanterar ingen bestämd lagringstid.

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 man kontrollera använt diskutrymme i Device Console. Kommandot visar de relevanta lagringsområdena på 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 man granska filsystemen mer ingående. Detta kommando visar storlek, använt utrymme, ledigt utrymme 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 ringas in.

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 de tre typiska lagringsområdena anger Sophos dessa läskommandon i Advanced Shell. De relativa katalognamnen förutsätter att /var är arbetskatalogen; kontrollera före körning att du befinner dig där. Utdata avser diskutrymme, inte arbetsminne (RAM):

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.

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

Minska utrymmet för karantän och Mail Spool kontrollerat

Kontrollera kraven på lagring och frisläppning och spara nödvändiga meddelanden innan karantänutrymmet minskas. Om kraven tillåter det, välj det minsta tillgängliga alternativet för diskutrymme för Email quarantine under Email > Quarantine settings. Under Email > Mail spool används Retry för ett kontrollerat nytt leveransförsök och Delete för att radera meddelanden. Kontrollera först meddelandenas identitet, leveransbehov och bevissäkring: Delete är oåterkalleligt. Kontrollera därefter kön, leveransresultatet och ledigt utrymme; Retry garanterar inte en lyckad leverans.

Stoppa diagnostisk insamling före fortsatt rensning

Samordna först eventuell pågående supportinsamling med supporten. Hämta nödvändiga underlag under Diagnostics > Tools med Troubleshooting logs eller Consolidated troubleshooting report och kontrollera de sparade filerna. Stäng av debugloggning för berörda komponenter när de nödvändiga loggarna har samlats in. Stäng även av paketinsamlingen under Diagnostics > Packet capture. Bekräfta att båda insamlingarna har stoppats och kontrollera lagringstrenden igen innan fler loggar rensas. Aktivera debug eller capture igen endast för ett tidsbegränsat diagnostikbehov, inte rutinmässigt efter rensningen.

Styr central rapportering och lokala Event Logs separat

Välj Central reporting för de moduler som behövs under System services > Log settings. En förutsättning är att brandväggen är registrerad för central brandväggshantering i Sophos Fusion (tidigare Sophos Central). Brandväggen skickar Event Logs dit, där rapporter skapas och lagras utifrån loggarna. Detta är varken inställningen för lagringstid för lokala rapporter eller det globala reglaget för On-Box Reports. För kapacitetsplaneringen uppskattas lagringsbehoven med Data Storage Estimation Tool och jämförs med rapporteringslicensens lagringsplaner. Enbart aktiverad överföring garanterar inte en lämplig lagringstid.

Som tillval kan lokal lagring av händelseloggar stängas av för vissa eller alla moduler under System services > Log settings. Bekräfta först mottagning på den externa syslogservern, lagringstid och lämplighet för support och regelefterlevnad; dokumentera de ursprungliga modulvalen. Kontrollera efter ändringen att den externa syslogservern fortsätter att ta emot nya händelser. Kontrollera också att begränsningen i den lokala Log Viewer motsvarar de ändrade modulvalen och följ diskutrymmesanvändningens utveckling. Återställ vid behov de ursprungliga lokala valen och kontrollera nya lokala händelser. Denna återställning har inte produkttestats här och återskapar inte saknade händelser. Lokala tjänsteloggar kan fortfarande behövas; varningen om Log Suppression gäller fortfarande.

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.

Ett strikt begränsat undantag är entydigt identifierade filer som administratören själv har kopierat till /var. Dokumentera exakt sökväg, ursprung och syfte före borttagning, uteslut aktiva beroenden och spara nödvändiga underlag utanför brandväggen. Ta endast bort den identifierade kopian, inte system-, logg- eller databasfiler. Stoppa och kontakta supporten om ursprunget är osäkert. Radering är inget reversibelt återställningssteg. Kontrollera sedan ledigt utrymme och berörda tjänsters tillstånd igen; inget manuellt raderingskommando eller jokertecken anges avsiktligt här.

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.
• Rensa rapporter medvetet först efter att nödvändiga data har säkrats: börja med Manual purge i WebAdmin; använd Flush Device Reports endast om detta inte frigör tillräckligt med diskutrymme och omstarten med tillhörande internetavbrott har förberetts.
• 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. Före en ändring dokumenteras status som lästs med show som det godkända utgångsläget; produktens standardvärde ersätter inte denna dokumentation:

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

Återställningen återför inställningen till exakt det dokumenterade, godkända utgångsläget. Endast om detta var enable och ändrades till disable i detta förfarande tillåts skrivning igen med följande kommandon. Om den godkända policyn redan var disable förblir den inaktiverad eller återställs med disable enligt ovan; därefter läses status igen med show. En aktivering som godkänts av supporten för en avsiktligt inaktiverad policy är en ny återställningsåtgärd, inte en rollback:

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ällning av ett aktiverat utgångsläge eller en ny godkänd aktivering kontrolleras, om On-Box Reporting är aktivt, en ny rapportperiod, Generate now, lokala dashboards, schemalagda rapporter och lagringstrenden. Ett avsiktligt inaktiverat utgångsläge bekräftas däremot som disable med show; lokal rapportgenerering är då inget kriterium för att åtgärden har lyckats. Lagringstrenden och processer som fortfarande behövs, exempelvis extern lagring, kontrolleras ändå. Saknade data eller historik återställs inte i efterhand genom detta. Om partitionen förblir skrivskyddad trots godkänt enable eller om 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:

• En aktuell konfigurationsbackup finns tillgänglig och har kontrollerats.
• Nödvändiga rapporter har exporterats eller finns tillgängliga centralt.
• påverkade perioder dokumenterade
• Orsaken till den ökade diskutrymmesanvändningen är klarlagd.
• 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.

Flush Device Reports används endast om Manual purge i WebAdmin inte frigör tillräckligt med diskutrymme. Enbart ett återställningstillstånd uppfyller inte denna dokumenterade förutsättning. Konsolalternativet är:

5. Device Management > 4. Flush Device Reports

⚠️ Flush Device Reports raderar rapporterna som lagras på brandväggen och startar om brandväggen. Under tiden kan den inte nås via nätverket i ungefär tio minuter. Tills den är online igen är även den aktuella anslutningen via internetgatewayen bruten: internettrafiken som går genom denna brandvägg avbryts. Därför ska underhållsfönster, information till berörda användare och lämplig konsolåtkomst förberedas före körning. De tidigare nämnda exporterna och säkerhetskopiorna måste ha kontrollerats; det får inte förutsättas att raderade rapporter kan återställas med en konfigurationsbackup.

När brandväggen är online igen kontrolleras anslutningen via internetgatewayen, ledigt diskutrymme, rapporter, Log Viewer, Sophos Fusion Reporting och berörda tjänster. Om diskutrymmet fortfarande är otillräckligt eller tjänsterna inte verkar fungera korrekt ska aktuella observationer säkras och supporten kontaktas, i stället för att åtgärden upprepas blint.

Flush Device Reports avser den dokumenterade rapportraderingen med omstart, inte en instruktion för formatering av rapportdisken. Inget ytterligare konsolalternativ för formatering får härledas ur detta. Formatering skulle vara ett separat destruktivt ingrepp och beskrivs inte här som en rensningsmetod.

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 lagrar rapporter lokalt på brandväggen. Det är praktiskt, men kan förbruka diskutrymme på små appliances, vid hög trafik eller med lång lagringstid.

Före en ändring kontrolleras status i Device Console och det visade läget on eller off dokumenteras som utgångsläge:

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

Återställningen förbereds innan rapporteringen stängs av och återför inställningen till exakt det dokumenterade utgångsläget. Följande kommandon med on gäller endast om det sparade läget var on och detta förfarande faktiskt ändrade det till off. Om On-Box Reporting redan var off förblir det avstängt eller återställs med off enligt ovan; därefter kontrolleras status igen med show on-box-reports. En medveten, ny godkänd aktivering av tidigare avstängd rapportering är ett nytt drift- eller återställningsbeslut, inte en rollback. Med on startar den lokala rapportgenereringen igen; en lucka från den inaktiverade perioden förutsätts inte fyllas i efterhand:

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

Efter återställning till on kontrolleras en ny lokal rapport, Log Viewer, en schemalagd rapport och lagringstrenden. Enbart status on bevisar inte att rapportdatabasen och rapportvyerna fungerar rimligt igen. Om det sparade läget var off bekräftas däremot med show on-box-reports att status fortfarande är off, och lagringstrenden, den planerade alternativa lagringen och de Log Viewer- eller rapportprocesser som fortfarande behövs kontrolleras. En ny lokal rapport krävs inte när detta inaktiverade utgångsläge återställs.

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 och dokumentera det aktuella värdet i Device Console före en ändring. Dokumentationen för SFOS 22 använder report-disk-usage för att läsa tröskeln och var-partition-usage för att ställa in den. Kontrollera syntaxen med CLI-hjälpen i målversionen; ändra inte varningströskeln om det aktuella värdet inte kan läsas:

show report-disk-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 datastoren.
• Ögonblicksbilder, säkerhetskopieringsjobb och lagringsfördröjning.
• Övervakning av hypervisorn.
• Om brandväggsversionen anger ytterligare krav på diskutrymme.
• 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.
• Avvikande partition noterad.
• 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 rensningen

• Ledigt diskutrymme kontrollerat igen.
• Rapporter kontrollerade utifrån det dokumenterade aktiva eller inaktiverade utgångsläget, liksom Log Viewer; vid inaktiverad lokal rapportering krävs ingen ny lokal rapportgenerering som kriterium för att åtgärden har lyckats.
• Sophos Fusion Reporting eller Syslog kontrolleras för aktuella data.
• Orsaken till den ökade diskutrymmesanvändningen dokumenterad.
• Lagringsperiod, logginställningar och granskningsprocess justerade.
• Aviseringar för framtida lagringsvarningar kontrollerade.

FAQ