Sophos Fusion: configurar e verificar a Server Threat Protection com segurança

Após a instalação de um agente de servidor, a política apresentada ainda não prova que a proteção está a funcionar. Se a instalação e a validação do agente ainda estiverem pendentes: para Windows Server, consulte a instalação e validação do Windows Server; para servidores Linux, siga antes o procedimento de instalação do SPL. Para estabelecer uma configuração de base segura no Sophos Fusion (anteriormente Sophos Central), verifique primeiro o servidor concreto e a respetiva plataforma, mantenha depois as definições recomendadas num pequeno grupo-piloto e, por fim, confirme nos separadores Policies, Status e Events do servidor o que foi efetivamente aplicado. Os servidores Windows e Linux partilham uma interface de políticas, mas não todas as funcionalidades de proteção.

Antes da alteração: registar a plataforma e o âmbito

Registe o tenant, o nome do servidor, o sistema operativo, o agente instalado, a licença existente ou as funcionalidades contratadas, a função do servidor e a política atual. Compare um servidor-piloto Windows e um Linux com o mesmo perfil de produção; servidores de bases de dados, controladores de domínio e hosts de contentores Linux merecem testes separados devido às diferenças de carga e de acesso a ficheiros. Os exemplos Pilot-Windows-App e Pilot-Linux-App são nomes de grupos de servidores à sua escolha, não valores predefinidos pela Sophos. Em My Products > Server > Servers, abra o separador Server Groups e selecione Add Server Group. Crie um grupo para cada plataforma e atribua-lhe servidores individualmente. Um servidor só pode pertencer a um grupo: ao atribuí-lo a um grupo-piloto, remove-o do grupo anterior, o que também pode alterar outras políticas efetivas. Antes disso, documente, para cada servidor, o grupo anterior, as políticas aplicadas e a sua ordem, atribuições e definições, como referência para uma eventual reversão. Comece apenas com alguns servidores representativos, não com toda a produção.

A Base Policy protege os servidores quando não se aplica nenhuma política correspondente de prioridade superior. As políticas adicionais permitem desvios específicos. O Sophos Fusion aplica, para cada tipo de política, a primeira política ativa correspondente, de cima para baixo; as definições de várias políticas de Threat Protection não são combinadas. O artigo sobre os fundamentos das políticas explica este modelo de seleção comum; neste piloto, porém, são as políticas de Server e os grupos de servidores que importam, não os grupos de computadores Endpoint. Coloque a política específica do piloto acima de uma política geral e mantenha as restantes definições na configuração de base recomendada. As alterações a uma política partilhada afetam todos os servidores aos quais está atribuída — confira a atribuição antes de selecionar Save.

Configurar a Server Threat Protection no piloto

Abra My Products > Server > Policies e selecione Add Policy. Se surgir uma escolha, selecione Threat Protection; para uma política existente, abra primeiro o tipo de política e depois o respetivo nome. Em Assigned to, atribua a nova política ao pequeno grupo-piloto e verifique Excluded from, se estiver visível. Não altere inadvertidamente a Base Policy de todos os servidores.
Abra Settings e mantenha a política ativada. Em Show filters > Operating System, selecione primeiro Windows, clique em Apply, repita para Linux e clique novamente em Apply. O filtro mostra as definições disponíveis para cada plataforma; não ativa funcionalidades no agente. Recommended e Enabled/Disabled ajudam a identificar desvios.
Sempre que possível, mantenha Live Protection, Deep Learning e Real-time Scanning - Local Files and Network Shares nas definições recomendadas. Em Real-time Scanning - Local Files and Network Shares, Scan controla a análise em tempo real dos ficheiros locais e dos ficheiros acedidos pela rede; Local limita-a aos ficheiros do próprio dispositivo. A mudança para Local exige um caso de utilização justificado e um teste das partilhas afetadas.
A proteção no acesso em Linux está desativada por predefinição. Para um piloto Linux com proteção no acesso a ficheiros, é necessário instalar o produto SPL antivirus, ou seja, o respetivo plugin AV. Na política de Server Threat Protection efetiva, em Real-time Scanning - Local Files and Network Shares, têm de estar ativadas tanto Scan como Enable scan for Server Protection for Linux Agent; a segunda opção vem desativada de fábrica. Confirme o componente AV instalado no servidor-piloto conforme descrito no artigo de instalação do SPL acima referido. Se faltar o componente AV ou se pelo menos uma das opções Scan ou Enable scan for Server Protection for Linux Agent estiver desativada, o piloto não pode ser validado como protegido no acesso; documente a lacuna e suspenda a expansão. Uma análise agendada não substitui a análise em tempo real: analisa em horários fixos, não quando os ficheiros são acedidos. Enable scheduled scan está disponível em ambas as plataformas; se necessário, escolha um horário de baixa carga. A hora segue o horário local do dispositivo. Em Linux, a análise agendada utiliza Live Protection independentemente da definição correspondente na política.
Sempre que possível, mantenha Enable event journals ativado: sem estes registos, faltam dados para investigações posteriores durante o período em que estiver desativado; os Threat Graphs e, caso esteja em utilização, o Server File Integrity Monitoring também deixam de funcionar. Não configure aqui tamanhos globais dos registos de eventos. Guarde a alteração e confirme a política efetiva no dispositivo antes de atribuir mais servidores.

Não confundir: a análise em tempo real da Internet, a desencriptação HTTPS, a proteção CryptoGuard/contra exploits, AMSI, Adaptive Attack Protection e Security Heartbeat estão documentadas como funcionalidades Windows nesta política. Isto não implica que tenham o mesmo efeito em Linux. Linux runtime detections é uma funcionalidade Linux separada que requer uma licença adequada; a simples presença da opção não comprova nem o direito de utilização nem a deteção em tempo de execução ativa. Verifique a licença concreta e o estado do agente e do tenant antes de planear esta funcionalidade. As opções Linux de análise em tempo real e de terminação dos processos maliciosos associados também não são equivalentes aos módulos de proteção em tempo de execução de Windows.

Exclusões apenas perante um conflito comprovado

Uma exclusão da análise reduz a proteção, mesmo que outras verificações possam continuar a abranger o objeto excluído. Perante um falso positivo, procure no separador Events a data e hora, a deteção e o caminho afetado; compare-os com a versão da aplicação, as indicações do fabricante e um erro reproduzível. Uma aplicação de base de dados também pode sofrer uma degradação mensurável causada pela análise de acessos frequentes a ficheiros sem que haja um evento de deteção: compare, de forma reproduzível, os tempos de execução, a carga e os acessos afetados antes e depois de um teste temporário no grupo-piloto. Um serviço simplesmente lento, sem relação demonstrável com a análise, não justifica uma exclusão.

Em Settings > Exclusions > Add Exclusion, escolha Exclusion Type e indique apenas o objeto concretamente afetado. Para File or folder, limite Active for a Real-time Scanning ou Scheduled Scanning, se não estiver comprovado que ambas são afetadas. Perante uma carga comprovada numa base de dados Windows, considere primeiro Process (Windows) com o caminho completo da aplicação, de acordo com as indicações do fabricante: só os ficheiros utilizados por esse processo ficam excluídos quando ele lhes acede, em vez de se isentar toda uma árvore de ficheiros para os restantes processos. Para Linux, File or folder (Linux) aceita caminhos de ficheiros e pastas, bem como ? e *; um caminho completo como /mnt/hgfs/excluded é um exemplo de sintaxe da documentação da Sophos, não uma recomendação geral para excluir essa pasta. Substitua-o exclusivamente por um caminho verificado no servidor afetado. Não trate as exclusões de processos ou de exploits de Windows como equivalentes em Linux. Não utilize exclusões de Detected Exploits ou de hashing como solução genérica para contornar a análise; para exclusões de hashing, contacte primeiro o Suporte Sophos. Uma exclusão de política só se aplica aos servidores aos quais essa política é aplicada; uma Global Exclusion, pelo contrário, abrange todo o tenant. Ao analisar um evento, não crie uma exclusão global de deteção através de Don’t detect this again. O guia comum de exclusões para Endpoint e Server explica os tipos, o âmbito e a reversão; a escolha aqui continua a ser uma decisão relativa à política de servidores. Documente o evento de deteção ou os dados de desempenho reproduzíveis, as indicações do fabricante, o motivo, os responsáveis, os servidores afetados, o teste e a data prevista para a expiração. Após guardar, verifique o fluxo de trabalho afetado e remova a exclusão assim que a causa estiver resolvida e a reversão tiver sido testada.

Comprovar o efeito no servidor concreto

Abra My Products > Server > Servers, selecione o servidor-piloto e confira:

Policies: em Threat Protection, aparece realmente a política pretendida? Caso contrário, verifique a atribuição, a ativação e a ordem. Ao clicar na política, abre as respetivas definições; as alterações feitas aí afetam também outros servidores aos quais esteja atribuída.
Status: nos servidores Windows mais recentes, Health status e as avaliações de Communication, Operations, Services, System, Threat e Update mostram possíveis problemas. Em Linux e em servidores Windows mais antigos, Security Health mostra, entre outros dados, o último contacto com o Sophos Fusion e os serviços Sophos em execução; não é a mesma avaliação detalhada de Windows. Um indicador verde, por si só, não prova que a proteção contra ataques tenha sido testada.
Events: verifique as mensagens e as atualizações bem-sucedidas no período relevante e, se existir alguma deteção anterior, consulte Details. A ausência de um evento de malware não é um teste funcional. Não desencadeie ações de malware ou de exploits só para testar num servidor de produção. A hora apresentada em Last active pode ser anterior a um evento, pois é atualizada aproximadamente uma vez por hora.

Em Linux, confirme também localmente o produto antivirus/plugin AV instalado e a política recebida (consulte os procedimentos de verificação no artigo de instalação do SPL). Policies, Status, Events e um indicador de integridade verde não comprovam, por si sós, nem a análise ativa no acesso nem a sua capacidade de deteção. Apenas num sistema que não seja de produção, com autorização para o efeito, um teste funcional controlado com o ficheiro de teste inofensivo EICAR, seguindo as instruções da Sophos, permite verificar a reação ao acesso ao ficheiro, a entrada no registo AV e o alerta no Fusion; remova o ficheiro de teste e trate o alerta de teste segundo o procedimento local. Sem esse teste, a capacidade de deteção permanece por confirmar; não faça testes com malware em produção.

Além disso, Account Health Check mostra desvios das políticas de Server Threat Protection face às recomendações da Sophos. Se surgir um aviso, abra a política indicada, examine as definições assinaladas a vermelho e corrija-as de forma seletiva. Fix automatically repõe todas as opções das políticas afetadas nas definições recomendadas e pode substituir desvios intencionais do piloto; antes de confirmar, verifique os servidores afetados e o alcance da alteração. Verifique separadamente o aviso relativo a Policy exclusions arriscadas: esta verificação só deteta exclusões particularmente inseguras; um estado verde não atesta que todas as exclusões sejam seguras. Também aqui, não aplique correções automáticas sem verificar todo o âmbito das políticas afetadas; a correção pode remover exclusões de todas essas políticas. O Audit Log regista as alterações automáticas. Após cada correção, volte a verificar a política, o estado e os eventos no servidor-piloto.

Quando o resultado não corresponde à configuração

Política incorreta ou ausência da política esperada: verifique o tenant, o grupo de servidores, a ativação da política e a prioridade na lista. Leia o nome correto no separador Policies do servidor; não conclua que uma política é efetiva apenas por constar da lista de políticas.
Análise em tempo real de Linux incerta: na política efetiva filtrada para Linux, em Real-time Scanning - Local Files and Network Shares, confira Scan e Enable scan for Server Protection for Linux Agent, bem como o plugin AV do SPL/produto antivirus instalado localmente. Se faltar algum elemento ou o efeito continuar incerto, não afirme que há proteção no acesso, não expanda o piloto e encaminhe os detalhes do agente e da licença e os dados de diagnóstico para o Suporte Sophos.
Aviso ou avaliação de integridade a vermelho: em Windows, abra a avaliação específica de Communication, Services ou Update; em Linux, compare a última atividade no Fusion, os serviços em execução e os alertas. Resolva primeiro os problemas de comunicação ou de atualização e volte depois a confirmar a receção da política.
Aplicação lenta ou ficheiro bloqueado: em caso de bloqueio, verifique se há um evento simultâneo e qual o caminho afetado; perante uma degradação de desempenho sem evento, recolha comparações reproduzíveis de carga e acessos, juntamente com as indicações do fabricante. Não exclua toda uma estrutura de diretórios nem todo o tenant com base em suspeitas. Uma exclusão restrita ao piloto só é aceitável com uma causa comprovada e um plano de reversão. Se o desvio persistir, documente os resultados, a atribuição da política e o estado do agente e escale o caso.

Parar e reverter o piloto

Suspenda a expansão se faltar proteção no acesso em Linux, se a política efetiva estiver errada, se o agente permanecer num estado problemático, se houver bloqueios por esclarecer ou se existir uma perturbação mensurável numa carga de trabalho crítica para o negócio. Registe os servidores afetados e o desvio; coordene a reversão, durante a janela de alteração, com os responsáveis pelas cargas de trabalho. Devolva cada servidor transferido ao seu grupo anterior ou remova-o do grupo-piloto se não pertencia a nenhum grupo. Se as alterações do piloto modificaram uma política existente, a sua prioridade ou atribuição, reponha também a ordem, a atribuição e as definições documentadas; regressar ao grupo anterior, por si só, não repara uma política editada. Reverta as exclusões do piloto de forma seletiva após verificar a carga de trabalho afetada: confirme primeiro que o bloqueio ou a degradação de desempenho anterior não regressará por causa dessa remoção; se necessário, esclareça a causa e documente entretanto a necessidade residual, restrita e temporária, em vez de remover a exclusão sem controlo. Depois, confira em cada servidor afetado a pertença ao grupo, as políticas efetivas, o estado/integridade, os eventos e o fluxo de trabalho anteriormente afetado. Sem comprovação de um resultado satisfatório, mantenha a implementação suspensa e escale o incidente.