Scripts na Sophos Firewall sem Cronjob: alternativas seguras
Quem pretende executar regularmente um comando numa Sophos Firewall começa rapidamente a procurar Cronjobs, scripts de arranque ou ficheiros Shell persistentes. No entanto, a documentação pública de administração do SFOS não descreve qualquer método operacional geral para esse fim. A firewall é uma Security Appliance e não deve ser transformada num servidor de automatização.
Para alterações de configuração, a XML API, o Sophos Central ou as funções nativas do SFOS são a melhor opção. Os estados e erros devem ser monitorizados por sistemas externos através de Syslog, SNMP ou sFlow. Um workaround Shell local só deve ser colocado numa firewall quando a Sophos o descrever publicamente para o caso concreto ou quando for acompanhado pelo Sophos Support ou pelos Professional Services.
⚠️ Importante: Um backup da configuração não prova que ficheiros criados pelo utilizador, mecanismos de arranque ou processos em segundo plano são guardados e voltam a estar disponíveis após um restauro, um failover de HA ou uma atualização de firmware.
Decisão rápida
Antes de qualquer solução técnica, é necessário esclarecer que tarefa se pretende automatizar. Esta classificação impede que um pequeno script se transforme, sem que se dê por isso, num componente crítico da operação da firewall.
| Tarefa | Método operacional adequado |
|---|---|
| Alteração de configuração recorrente | XML API a partir de um sistema de automatização controlado |
| A mesma policy em várias firewalls | Sophos Central Firewall Group |
| Backup regular da configuração | Agendamento em Backup & firmware > Backup & restore |
| Monitorizar estado, tráfego ou erros | Syslog, SNMP, sFlow ou Sophos Central Reporting |
| Diagnóstico pontual | WebAdmin, Device Console ou um comando documentado pela Sophos |
| Workaround específico do produto | Instruções exatas da Sophos ou caso de suporte confirmado |
Se um script tiver de reiniciar serviços, eliminar ficheiros ou repor ligações regularmente, isso não constitui uma solução de automatização. Provavelmente está a ocultar uma avaria. Nesse caso, deve começar-se por analisar os logs, o armazenamento, a versão do firmware e o problema concreto.
Por que motivo os scripts locais são problemáticos
Um script Shell pode ser tecnicamente pequeno e, ainda assim, tornar a operação difícil de controlar. Encontra-se fora da configuração WebAdmin normal, muitas vezes não tem Audit Trail e pode entrar em conflito com outros ficheiros, serviços ou permissões após uma atualização.
Há quatro riscos particularmente relevantes:
- Backup e restauro: A Sophos descreve o backup como uma cópia de segurança da configuração da firewall. Não existe qualquer garantia geral de restauro para ficheiros Shell ou mecanismos de arranque próprios.
- HA: A Sophos sincroniza a configuração do Primary para o Auxiliary. Daqui não se pode concluir que quaisquer ficheiros locais ou processos desenvolvidos pelo utilizador funcionam de forma idêntica em ambos os Nodes.
- Firmware: Uma atualização pode alterar caminhos internos, serviços ou o comportamento em tempo de execução. Por conseguinte, uma adaptação local tem de ser reavaliada após cada atualização.
- Suporte: A Sophos presta suporte às APIs oficiais e aos scripts Sophos não modificados. Para integrações desenvolvidas pelo cliente, a Sophos remete para parceiros ou Professional Services.
Acrescem ainda Secrets em texto simples, volumes de logs descontrolados, ciclos infinitos e uma resolução de problemas em que já ninguém sabe ao certo se é o SFOS ou o workaround local que está a causar o comportamento.
Alternativas suportadas
Utilizar uma função nativa do SFOS
Comece por verificar se o próprio SFOS já executa a tarefa. Backups agendados, notificações, routing, SD-WAN, monitorização e registo centralizado devem ser configurados nos menus previstos para esse efeito. Por exemplo, um backup recorrente não requer um script Shell; o agendamento encontra-se em Backup & firmware > Backup & restore.
Para tarefas de routing ou System Traffic, uma policy corretamente configurada é muitas vezes preferível a um comando após cada reinício. O artigo Routing SD-WAN para Reply Packets e System Traffic explica o método suportado.
Gerir várias firewalls através do Sophos Central
Se várias firewalls tiverem de receber a mesma policy, uma Firewall Group no Sophos Central pode ser mais adequada do que um script próprio. O caminho é My Products > Firewall Management > Firewalls. As Group Policies são aplicadas às firewalls atribuídas; o estado pode ser consultado em Tasks Queue.
Os grupos do Central não são simplesmente uma função universal de cópia. As regras locais e geridas centralmente podem influenciar-se mutuamente na ordenação, e nem todas as configurações podem ser representadas em todas as estruturas de grupos. Por isso, deve começar-se por testar com um grupo de teste e, em seguida, verificar a Task Queue e as regras efetivamente aplicadas.
Utilizar a XML API externamente
Para alterações recorrentes em objetos ou policies, a XML API é o método programático previsto. A automatização deve ser executada num sistema gerido, no qual seja possível controlar o código, os Secrets, os logs, o agendamento e o rollback.
A firewall é preparada da seguinte forma:
- Em Profiles > Device access, crie um perfil de administrador apenas com as permissões realmente necessárias e guarde-o com Save.
- Em Authentication > Users, clique em Add, defina User type como Administrator, selecione o novo perfil, restrinja deliberadamente Login restriction for device access e guarde com Save.
- Em Hosts and services > IP host, registe o sistema de automatização como um objeto Host restrito.
- Em Administration > API access, selecione API access.
- Em Allowed IP hosts, selecione apenas o objeto Host preparado, adicione-o com o botão Add e guarde com Apply. O SFOS permite, no máximo, 64 entradas nesta área.
- Em Administration > Device access, confirme se HTTPS é permitido a partir da zona necessária. Para acesso WAN, prefira uma Local service ACL exception rule restrita a permitir HTTPS globalmente para WAN.
API access está desativado por predefinição. Após uma atualização para o SFOS 22.0, os endereços IP anteriormente permitidos são convertidos em objetos Host com o prefixo apiconfig; estas autorizações antigas devem ser incluídas na próxima revisão de acessos.
O artigo Proteger o acesso à XML API da Sophos Firewall aborda em detalhe a conta de serviço, o comportamento de MFA, a porta de administração, a Local Service ACL e a proteção de Secrets. Para alterações de configuração preparadas ou comparadas, o Sophos Firewall Config Studio também pode ser útil.
⚠️ A API não é automaticamente segura: Restrinja o endereço IP de origem, não utilize uma conta pessoal com privilégios totais de administrador, não guarde Secrets no repositório, no ticket ou no histórico da Shell e teste primeiro as operações de escrita num ambiente de teste.
Executar a monitorização fora da firewall
Um sistema de monitorização deve observar a firewall a partir do exterior. Caso contrário, o processo local pode estar indisponível precisamente quando a própria firewall tem uma avaria. Consoante o objetivo, podem ser adequados a Monitorização de hardware por SNMP, a Monitorização por sFlow ou o Central Firewall Reporting.
Para a análise de eventos e de segurança a longo prazo, um recetor Syslog ou SIEM externo é mais adequado do que ficheiros de log locais adicionais. Desta forma, os dados continuam disponíveis mesmo que a firewall reinicie, falhe ou seja substituída.
Quando um workaround local pode ser aceitável
Alguns casos de suporte ou Cloud Deployments requerem um workaround estritamente delimitado. O que importa não é se o comando funciona tecnicamente, mas se existe uma instrução atual da Sophos ou uma orientação de suporte confirmada para esse cenário específico.
Antes da implementação, a versão, a plataforma, o modo HA e o procedimento de reversão têm de corresponder às instruções. Um script proveniente de uma publicação antiga da Community, de outro modelo de Appliance ou de uma versão anterior do SFOS não constitui uma aprovação fiável para o ambiente em causa.
Se existir apenas uma solução desenvolvida internamente, esta deve primeiro ser esclarecida com o parceiro Sophos ou com os Professional Services. Uma instrução genérica para integrar scripts de arranque próprios seria aqui mais perigosa do que útil.
Substituir um script existente em segurança
Não elimine imediatamente um script existente. Primeiro, é necessário tornar visível a dependência operacional que existe em relação ao mesmo.
- Congelar alterações: Não faça, por enquanto, mais alterações ao script, ao mecanismo de arranque nem à firewall afetada.
- Registar o objetivo: Documente o sintoma, o trigger, o resultado pretendido, o caminho, o utilizador, o agendamento, os Secrets e a pessoa responsável.
- Observar o efeito: Registe os logs, o estado do processo, os ficheiros criados e as rotas, os serviços ou as interfaces afetadas. Em HA, verifique os dois Nodes separadamente.
- Escolher o método de destino: Associe a função a uma definição nativa do SFOS, ao Central, à XML API ou a monitorização externa.
- Testar a substituição: Teste o novo processo fora da firewall de produção e registe o sucesso, os erros e o rollback.
- Efetuar a transição de forma controlada: Durante a janela de manutenção, ative a substituição, desative o script local e execute o teste funcional específico.
- Planear a verificação posterior: Volte a verificar após um reinício, um failover e a próxima atualização de firmware, desde que estes eventos sejam relevantes para a função.
Antes da alteração, é necessário um backup atual. O artigo Criar ou restaurar um backup da Sophos Firewall explica a Secure Storage Master Key, o restauro e a compatibilidade. O backup protege a configuração documentada, mas não substitui um inventário separado das adaptações locais.
Validação e rollback
Uma resposta de API bem-sucedida ou um processo em execução ainda não prova que a tarefa funcional foi cumprida. Após a transição, é necessário testar exatamente o resultado que antes dependia do script: regra presente, rota ativa, backup criado, destino acessível ou alarme recebido na monitorização.
Nas alterações por API, verifique adicionalmente o Audit Trail e os objetos afetados. Se houver impacto no tráfego, a aceitação deve incluir Log Viewer, Rule ID, NAT Rule ID, Policy Test ou Packet Capture. As alterações do Central são verificadas na Tasks Queue e, em seguida, diretamente numa firewall afetada.
O rollback não consiste em reativar precipitadamente o script antigo. Primeiro, reverta a nova alteração e restaure o estado inicial documentado. O workaround antigo só pode ser reativado por tempo limitado se tiver sido deliberadamente verificado como opção de contingência.
Recomendação operacional
Na documentação operacional, os scripts locais devem ser apresentados como uma exceção temporária e não como uma função normal da firewall. Cada exceção necessita de um Owner, uma data de revisão, um procedimento de reversão testado e uma indicação clara das versões da Sophos abrangidas.
Para novos requisitos, aplica-se a seguinte ordem: função nativa do SFOS, Sophos Central, automatização externa por XML API, monitorização externa e, só depois, um caso especial confirmado pela Sophos. Desta forma, as alterações permanecem rastreáveis, HA e restauro tornam-se mais previsíveis e a firewall mantém-se mais próxima do estado de produto suportado.