Verificar espaço e gerir reports na Sophos Firewall

Se uma Sophos Firewall avisar sobre pouco espaço em disco, não se devem apagar ficheiros nem desativar reports de imediato. Primeiro tem de estar claro que partição está afetada e se a causa são reports locais, logs, mail queue, quarentena, ficheiros de suporte ou um disco virtual demasiado pequeno.

Este artigo explica como verificar o estado de armazenamento na Sophos Firewall, gerir reports locais de forma controlada e desativar On-Box Reporting apenas quando os impactos são compreendidos. Para retenção de logs a longo prazo, Central Firewall Reporting é muitas vezes a melhor adição, porque a operação não fica dependente apenas dos dados locais de reports na appliance.

⚠️ Importante: Apagar reports ou desativar On-Box Reports pode remover de forma irrecuperável relatórios locais e dados de logs. Antes destes passos, deve verificar-se se os dados necessários foram exportados, guardados centralmente ou já não são necessários para suporte e auditoria.

Quando o espaço de armazenamento se torna crítico

Problemas de armazenamento nem sempre se manifestam da mesma forma. Indícios típicos são:

• E-mail de aviso ou indicação no Control Center sobre consumo elevado de armazenamento.
• Reports carregam lentamente, ficam vazios ou não mostram dados atuais.
• Ficheiros de log locais crescem muito.
• Serviços de reports ou de base de dados geram erros.
• Firmware upgrade ou instalação de hotfix indica espaço livre insuficiente.
• Firewall virtual foi disponibilizada com um disco demasiado pequeno.
• Mail Protection, quarentena ou tráfego Web/Application elevado geram muitos dados locais.

Se ocorrerem em paralelo erros de I/O, reinícios invulgares ou problemas de base de dados, não basta libertar espaço. Nesse caso é adequada também a verificação da saúde do SSD por SMART e dos serviços e logs relevantes.

Nos Reports existe um limite importante: por defeito, a firewall avisa quando a partição relevante atinge 70 por cento de utilização. A partir de 80 por cento, a geração de reports é parada. Depois disso, normalmente não basta apagar apenas alguns dados. A utilização tem de voltar a ficar abaixo do limite de aviso para que os reports voltem a ser criados de forma fiável.

Em appliances muito pequenas, a decisão é ainda mais direta: XGS 87/87w e XGS 88/88w não têm On-Appliance Reporting. Nestes modelos, a retenção central através de Sophos Central, Syslog ou SIEM não é uma opção posterior de otimização, mas parte do desenho operacional.

O que ocupa espaço na firewall

Muitos dados operacionais locais ficam na área /var. A firewall guarda aí, entre outros, reports, Event Logs, Troubleshooting Logs e dados de outros componentes. As áreas individuais têm quotas próprias consoante o modelo da appliance e a função. Uma pequena firewall de filial não se comporta como uma appliance grande com mais capacidade local.

É importante distinguir:

• Reports: os reports deixam de ser guardados corretamente ou têm de ser reduzidos ou apagados. O risco é um histórico local mais curto e avaliações em falta.
• Event Logs: logs mais antigos são removidos; novos eventos podem continuar a ser escritos. A análise histórica fica mais curta.
• Troubleshooting Logs: ficheiros de log comprimidos mais antigos são removidos. Para análises de suporte pode faltar uma janela temporal importante.
• Quarentena de e-mail: e-mails de quarentena mais antigos podem ser removidos. A rastreabilidade e processos de libertação ficam prejudicados.
• Ficheiros temporários ou ficheiros copiados manualmente: estes ficheiros podem bloquear espaço desnecessariamente. A causa fica oculta se forem apagados apenas reports.

O gráfico Disk Usage no WebAdmin ajuda na primeira classificação. Ali são apresentados separadamente signatures, dados de configuração, reports e armazenamento temporário. Isto não substitui uma análise detalhada, mas mostra se os reports, dados temporários ou outras áreas chamam mais a atenção.

Reports e logs não devem ser misturados. A retenção de reports em Reports > Show Reports settings > Data management afeta reports. Event Logs para Log Viewer, Sophos Central ou Syslog são controlados através de System services > Log settings. Quem reduz a retenção de reports não reduz automaticamente os Event Logs locais.

Desde SFOS 21.0, a firewall também consegue manter reports antes e depois de um upgrade em bases de dados de reports separadas. No dia do upgrade, a vista de reports pode por isso mostrar uma seleção correspondente. Importante para rollback: se se voltar para uma versão de firmware anterior depois de um upgrade, os reports gerados desde o upgrade podem ser perdidos. Por isso, reports necessários devem ser exportados ou centralizados antes de trabalhos de firmware.

Verificar espaço na Device Console

Para uma visão geral rápida, é possível verificar o armazenamento ocupado na Device Console. O comando mostra as áreas de armazenamento relevantes da Sophos Firewall:

system diagnostics show disk

A Device Console destina-se a comandos específicos Sophos. Se for necessário preparar acesso por SSH, ajuda Ligar à Sophos Firewall por SSH. O artigo também descreve porque é que SSH só deve ser permitido a partir de redes administrativas fiáveis.

Verificar espaço na Advanced Shell

Na Advanced Shell é possível observar os sistemas de ficheiros com mais detalhe. Este comando mostra tamanho, espaço ocupado, espaço livre e percentagem de utilização:

df -hkm

Se não estiver claro se a saída completa é demasiado larga, pode observar-se especificamente /var, porque ali residem muitos dados operacionais locais:

df -h /var

O comando é apenas de leitura. Não se devem apagar manualmente ficheiros em diretórios de sistema só porque uma partição parece cheia. Primeiro deve delimitar-se a causa.

Se /var for suspeito, devem verificar-se primeiro as áreas Sophos previstas, em vez de apagar diretórios ao acaso. Para uma classificação aproximada são especialmente relevantes Reports, Event Logs e Troubleshooting Logs. Adicionalmente, deve verificar-se se Packet Capture, Debug-Logging, ficheiros de suporte ou ficheiros copiados manualmente ocupam espaço.

Para três blocos típicos de armazenamento, a Sophos indica estes comandos de leitura na Advanced Shell:

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

Estes comandos são apenas para classificação. Não substituem uma limpeza suportada através do WebAdmin, Device Console ou das funções de diagnóstico previstas.

Delimitar a causa

Um disco cheio pode ter várias causas. O próximo passo correto depende de que dados estão a crescer.

• Reports ocupam muito espaço: verificar retenção em Reports > Show Reports settings > Data management, exportar reports ou usar Central Reporting.
• Logs locais crescem muito: verificar Log settings, Debug-Logging e serviços afetados.
• Troubleshooting Logs crescem muito: verificar Debug-Logging, análise de suporte ativa ou erros recorrentes de serviços.
• /var está anormalmente cheio: verificar reports, logs, base de dados, ficheiros de suporte ou mail queue.
• Disk Graph mostra muito armazenamento temporário: verificar captures em execução, ficheiros de suporte ou processos temporários.
• Quarentena de e-mail ou Mail Spool cresce: verificar Email > Quarantine settings e Email > Mail spool. Mensagens bloqueadas devem ser revistas, entregues novamente de forma controlada ou apagadas.
• Firewall virtual está demasiado pequena: verificar tamanho do disco e requisitos da plataforma no hypervisor.
• Aviso de espaço antes de firmware upgrade: não iniciar o upgrade às cegas; executar primeiro o SFOS 22 Upgrade Check.
• Cluster HA afetado: verificar ambos os nodes separadamente, porque logs e reports locais não têm de ser idênticos.

Em perturbações ativas, os logs devem ser guardados primeiro enquanto o erro ainda está recente. O artigo Guardar logs da Sophos Firewall para suporte e análise descreve a exportação dos dados de log locais.

Se Event Logs estiverem a ocupar espaço local, a retenção de Reports não é a ferramenta correta. Nesse caso deve verificar-se em System services > Log settings que módulos são guardados localmente, enviados para Sophos Central ou encaminhados para Syslog. Log Suppression pode ajudar a reduzir repetições desnecessárias. Eventos relevantes para segurança, que mais tarde sejam necessários para Incident Response, suporte ou compliance, não devem simplesmente desaparecer.

Não apagar manualmente no sistema de ficheiros

Mesmo que a Advanced Shell mostre espaço livre e diretórios, não se devem remover ficheiros diretamente em /var, /log ou diretórios de base de dados. Ações manuais de eliminação podem danificar reports, serviços, bases de dados ou análises de suporte e dificultam a análise posterior da causa.

Fluxo melhor:

• Documentar estado de armazenamento e partição afetada.
• Guardar logs relevantes ou CTR se for provável um caso de suporte.
• Verificar se Packet Capture ou Debug-Logging ainda está ativo.
• Verificar retenção de reports através do WebAdmin.
• Esvaziar reports apenas pelo ponto de consola previsto, se estiver claro que os dados locais podem desaparecer.
• Se o consumo continuar a crescer, verificar a causa: Debug-Logging, mail queue, quarentena, base de dados, disco virtual ou tráfego local invulgarmente elevado.

Se não estiver claro que dados ocupam o armazenamento, não se deve trabalhar com rm. Nessa situação é mais seguro guardar logs e envolver o suporte ou a Avanet com o estado atual.

Para Troubleshooting Logs existem comandos próprios de purge na Device Console. Não substituem a análise da causa e só devem ser usados depois de os logs necessários estarem guardados. De forma simplificada, system diagnostics purge-old-logs remove logs comprimidos mais antigos e system diagnostics purge-all-logs remove todos os Troubleshooting Logs. Existem variantes detalhadas para subsistemas individuais. Em caso de dúvida, uma exportação direcionada em Diagnostics > Tools é mais limpa do que um purge global.

Ajustar retenção de reports no WebAdmin

Se a causa forem reports locais, deve verificar-se primeiro a duração de retenção. Em muitos ambientes, On-Box Reports foram mantidos historicamente, embora a avaliação efetiva já seja feita de forma centralizada.

O caminho Sophos para a retenção local de Reports é:

Reports > Show Reports settings > Data management

Ali é possível ajustar o período de retenção por módulo de reports e guardar com Apply. A alteração afeta Reports, não Event Logs. A Sophos também indica que alterações à retenção de Reports só entram em vigor às 00:00.

Perguntas úteis antes de uma alteração:

• Os reports locais ainda são realmente avaliados?
• Já existe Central Reporting, Syslog ou SIEM?
• Durante quanto tempo têm de ser guardados internamente dados de logs e reports?
• Existem requisitos de compliance ou suporte?
• Uma retenção local mais curta é suficiente quando o armazenamento central está ativo?

Se forem necessários logs e reports no Sophos Central, deve verificar-se adicionalmente que tipos de log são enviados para Central em System services > Log settings. A ativação está descrita em Ativar Central Firewall Reporting.

Apagar reports de forma controlada

Se serviços deixarem de funcionar corretamente devido a armazenamento cheio, pode ser necessário limpar reports manualmente. Mas isso deve ser uma medida de recovery controlada, não o processo operacional normal.

Verificar previamente:

• backup de configuração atual disponível
• reports necessários exportados ou disponíveis centralmente
• períodos afetados documentados
• motivo do crescimento de armazenamento compreendido
• janela de manutenção ou caso de suporte preparado, se a firewall já estiver instável

O primeiro caminho deve ser o WebAdmin:

Reports > Show Reports settings > Manual purge

Assim, Reports podem ser apagados de forma direcionada por módulo e período. Este processo pode ser lento, porque a firewall executa conscientemente o purge de Reports de forma controlada para poupar recursos do sistema.

Se isso não for suficiente ou se a firewall já estiver em estado de recovery, existe o ponto de consola:

5. Device Management > 4. Flush Device Reports

Após a eliminação, não se deve voltar simplesmente à operação diária. É importante controlar se o espaço livre realmente aumenta e se Reports, Log Viewer, Central Reporting e serviços afetados voltam a funcionar de forma plausível.

Flush Device Reports apaga os Reports guardados na firewall e reinicia a firewall. Durante esse período, o dispositivo fica inacessível pela rede durante cerca de dez minutos. Por isso, este passo pertence a uma janela de manutenção ou a um processo de recovery documentado.

Se a firewall já afeta serviços por falta de espaço, antes da eliminação deve estar claro que dados ficarão ausentes. Reports locais são muitas vezes úteis para change reviews, análise de utilizadores, rastreabilidade de segurança ou questões de suporte. Quem os apaga precisa de uma nota curta com período, motivo e fonte substituta existente, por exemplo Central Reporting ou Syslog.

Verificar ou desativar On-Box Reports

On-Box Reports guardam relatórios localmente na firewall. Isto é prático, mas pode consumir armazenamento em appliances pequenas, com muito tráfego ou retenção longa.

O estado é verificado na Device Console:

show on-box-reports

Este comando não responde à mesma pergunta que system diagnostics show disk: show on-box-reports mostra se os relatórios locais estão genericamente ativos, enquanto system diagnostics show disk mostra a utilização atual de armazenamento das áreas. Para um diagnóstico limpo, normalmente são necessárias as duas perspetivas.

Se os reports locais não forem necessários e existir outra retenção, é possível desativar On-Box Reports:

set on-box-reports off

Isto só deve ser feito conscientemente. Reports são importantes para análise, suporte e operação. Em muitos ambientes produtivos, é melhor reduzir a retenção local e usar em paralelo Central Reporting, Syslog ou SIEM. Se for necessária retenção central mais longa, Sophos Central Firewall Reporting Advanced é uma opção possível.

Importante: On-Box Reports só podem ser ligados ou desligados globalmente, não seletivamente por módulo. Se apenas algumas áreas de reports ocuparem muito espaço, uma retenção mais curta ou purging direcionado costuma ser melhor do que desativar completamente On-Box Reporting.

Se On-Box Reports forem desativados, depois não se deve verificar apenas o armazenamento. Também mudam processos internos: vistas locais de Reports, reports agendados, avaliações de segurança e análises ad hoc rápidas na firewall podem desaparecer ou tornar-se menos úteis. Por isso, este passo é uma decisão operacional, não uma limpeza espontânea de armazenamento.

Classificar limites de aviso e alerts

A Sophos Firewall pode gerar alerts no Control Center e Event Logs quando a utilização de /var é elevada. O limiar de aviso pode ser controlado na Device Console com set var-partition-usage watermark. Mas isto não é uma correção de armazenamento. Um limiar mais baixo ou mais alto altera apenas quando aparece um aviso, não o motivo pelo qual o espaço está a ser consumido.

O intervalo permitido é de 50 a 75 por cento, por defeito 70 por cento. Reporting para aos 80 por cento e essa paragem não é um limite operacional adequado, mas já um estado de erro. Um limite de aviso mais alto não torna a firewall mais estável; apenas reduz o tempo de reação.

Para a operação, normalmente é mais útil:

• Ativar notificações por e-mail ou SNMP para avisos de armazenamento.
• Verificar avisos de armazenamento antes da próxima janela de manutenção.
• Em avisos recorrentes, ajustar retenção, Debug-Logging e utilização local de reports.
• Verificar conscientemente espaço livre antes de firmware upgrades.

Se a utilização subir de forma clara ou os reports já pararem, deve libertar-se primeiro espaço e esclarecer a causa. Um limiar de aviso alterado não pode servir para esconder um problema real de capacidade.

Ter atenção a firewalls virtuais

Em Sophos Firewalls virtuais, a causa nem sempre está em reports ou logs. Por vezes, a appliance virtual foi disponibilizada com pouco disco ou cresceu durante vários anos sem que os requisitos da plataforma fossem reavaliados.

Em ambientes virtuais deve verificar-se adicionalmente:

• Tamanho do disco virtual.
• Espaço livre no datastore.
• Snapshots, jobs de backup e latência de storage.
• Monitoring do hypervisor.
• Se a versão da firewall indica requisitos adicionais de armazenamento.
• Se o disco virtual pode ser expandido online ou se um reimage com restore é o caminho mais limpo.

Se o disco for fundamentalmente demasiado pequeno, apagar reports é apenas um alívio de curto prazo. A plataforma virtual deve então ser adaptada corretamente e protegida com backup, janela de manutenção e plano de restore.

Antes de SFOS 22, este ponto é especialmente importante: se a firewall mostrar um aviso de armazenamento ou um bloqueador de upgrade relativo ao disco virtual, deve ser executado primeiro o SFOS 22 Upgrade Check. Ali estão ligados os avisos oficiais da Sophos sobre disco virtual. A expansão pertence a uma janela de manutenção planeada, com backup, armazenamento do hypervisor verificado e validação posterior das partições.

Em appliances de hardware, pelo contrário, a expansão do disco não é o caminho normal. Aí deve verificar-se consumo de armazenamento, reports, logs, quarentena e estado do SSD, e preparar um processo de suporte ou RMA em caso de suspeita de hardware.

Checkliste

Verificar de imediato

• Mensagem de aviso, hora e firewall afetada documentadas.
• system diagnostics show disk executado na Device Console.
• df -hkm verificado na Advanced Shell.
• Partição suspeita anotada.
• Disk Usage Graph no WebAdmin verificado para classificação aproximada.
• Reports, logs, mail queue, quarentena e disco virtual avaliados como possíveis causas.
• Packet Capture e Debug-Logging verificados como fontes de armazenamento de curto prazo.

Antes de apagar ou desativar

• Reports e logs necessários guardados.
• Central Reporting, Syslog ou outra retenção central verificados.
• Backup e caminho de recovery disponíveis.
• Janela de manutenção definida, se serviços produtivos forem afetados.
• Em HA, ambos os nodes verificados separadamente.
• Período e motivo da limpeza de reports documentados.

Após a limpeza

• Espaço livre verificado novamente.
• Reports e Log Viewer testados.
• Central Reporting ou Syslog verificados quanto a dados atuais.
• Causa do crescimento de armazenamento documentada.
• Duração de retenção, Log settings e processo de review ajustados.
• Notificações para futuros avisos de armazenamento verificadas.

FAQ