Imunify360 Malware Scanner: funcionalidades, atualizações e limitações

O Imunify360 como segurança de alojamento em várias camadas

O Imunify360 não é um programa de deteção de vírus isolado, mas sim uma solução de segurança para Linux com vários níveis de proteção. O Verificador de malware analisa ficheiros à procura de conteúdos conhecidos ou suspeitos. A firewall e o IDS/IPS monitorizam e restringem atividades de rede suspeitas, enquanto uma firewall de aplicações Web (WAF) avalia as solicitações HTTP antes de estas chegarem à aplicação, com base em regras. As verificações de reputação fornecem sinais adicionais para a classificação de fontes e atividades.

Esta divisão é fundamental para os operadores de alojamento, porque as camadas atuam em diferentes pontos. Um ataque HTTP a uma vulnerabilidade conhecida pode ser bloqueado pelo WAF antes de o WordPress, o Joomla ou o Magento processarem o pedido. Por outro lado, um upload malicioso torna-se relevante na verificação de ficheiros. Se for executado um webshell em PHP, pode Defesa proativa abordar comportamentos suspeitos durante a execução do PHP; no entanto, não se trata de uma análise retroativa de todo o incidente.

O modelo chama-se Defesa em Profundidade: Uma única falha ou um elemento detetado que tenha passado despercebido não deve, por si só, determinar a segurança da conta de um cliente. A deteção de malware pode revelar código malicioso existente, mas não impede necessariamente a exploração inicial. Da mesma forma, um WAF pode bloquear um ataque sem limpar ficheiros já armazenados ou conteúdos de bases de dados manipulados.

Nenhum destes níveis substitui as tarefas operacionais básicas. O núcleo do CMS, os plugins, os temas e as extensões necessitam de atualizações de segurança atempadas; direitos de acesso restritivos aos ficheiros e credenciais de acesso separadas limitam as consequências de uma conta comprometida. As cópias de segurança verificadas permitem a recuperação e, caso seja detetada uma intrusão, só uma análise do incidente permite esclarecer a via de entrada, o alcance e a possível persistência. Imunify360 fornece, para tal, sinais de proteção e deteção, mas não a prova definitiva de que o ambiente está livre de ameaças.

Diferenciar o Imunify360, o ImunifyAV e o ImunifyAV+

As listas de funções têm de ser associadas ao produto em questão. Imunify360 é a solução de segurança de servidores mais abrangente; o ImunifyAV e o ImunifyAV+ são produtos distintos, com funcionalidades relacionadas com malware. Quem equiparar estes nomes poderá, por exemplo, confundir uma função de análise existente com proteção por firewall, em tempo real ou para PHP e, a partir daí, criar expectativas erradas relativamente a um servidor gerido ou de revenda.

É particularmente relevante que, de acordo com a documentação do fabricante, a verificação em tempo real e a defesa proativa não estejam disponíveis no ImunifyAV nem no ImunifyAV+ da mesma forma que no Imunify360. A verificação em tempo real permite detetar ficheiros novos ou alterados de forma imediata; a Defesa Proativa considera a execução de PHP como um ponto de intervenção específico. Ambas as funções complementam as verificações programáveis de ficheiros, mas não as tornam supérfluas nem substituem a manutenção das aplicações.

A extensão do WordPress denominada «Imunify Security Plugin» também não constitui um substituto autónomo do agente do servidor. É gerida pelo agente Imunify e não é disponibilizada através do diretório do WordPress.org. No backend do WordPress, pode disponibilizar informações sobre análises e proteção; no entanto, as funcionalidades que aparecem dependem do produto Imunify utilizado e das versões necessárias do agente e da extensão.

Para a documentação operacional, recomenda-se, portanto, um inventário claro: a variante do produto, a versão do agente instalada, o painel de alojamento e os módulos de proteção ativados devem constar, em conjunto, na documentação de alterações. Um administrador do WordPress pode, assim, classificar as notificações no backend sem partir do princípio de que o plugin controla regras de firewall ou protege outras contas de utilizador no servidor. A arquitetura de segurança do lado do servidor continua a ser determinante.

O que as deteções de malware realmente revelam

As análises em segundo plano e a pedido disponibilizam os resultados na interface de gestão, indicando a hora, o caminho do ficheiro e o motivo da deteção. Estas informações constituem um ponto de partida para a triagem: o caminho associa uma descoberta a uma conta de cliente e a uma aplicação, enquanto a hora ajuda a cruzar dados com implementações, uploads ou registos de log suspeitos. No entanto, não substituem uma verificação do conteúdo específico e da sua origem.

Para a definição de prioridades, o tipo de deteção é importante. A presença de código malicioso infiltrado num ficheiro, de resto legítimo, sugere frequentemente que se deve investigar a origem desse ficheiro, as suas alterações e outras manipulações na mesma conta. Por outro lado, um ficheiro reconhecido como malicioso por si só pode indicar a existência de um webshell armazenado, de um dropper ou de uma ferramenta de administração indesejada. Ambos os casos exigem contexto, em vez de conclusões automáticas.

A deteção de um problema não prova que todos os ficheiros da conta tenham sido comprometidos, nem descreve automaticamente a extensão de uma intrusão. Por outro lado, uma análise sem deteções não comprova a integridade total: novos tipos de explorações, código camuflado ou persistência fora da área analisada podem exigir uma investigação adicional. Da mesma forma, a ausência de deteção por WAF ou por scanners não constitui prova de que não tenha ocorrido um ataque.

Se, por exemplo, o scanner detetar um ficheiro PHP dentro de um plugin do WordPress, o administrador deve, em primeiro lugar, guardar o histórico de deteções e o caminho de acesso e comparar o ficheiro com uma fonte fiável do fabricante ou com uma cópia de segurança verificada. Em seguida, devem ser verificadas a versão do plugin, os administradores, os dados de acesso e possíveis backdoors. Para a integração organizacional de vários projetos WordPress, as orientações sobre Requisitos de segurança na hospedagem do Blogger, mas não substituem a análise forense específica de cada caso.

Métodos de digitalização, requisitos e alcance

As análises regulares de ficheiros do Imunify360 verificam os ficheiros armazenados no conjunto de ficheiros de alojamento. São adequadas tanto para execuções recorrentes em segundo plano como para uma verificação específica na sequência de uma indicação proveniente da monitorização ou do apoio técnico. No entanto, o resultado diz respeito apenas ao conjunto de ficheiros analisado: conteúdos numa base de dados, um ataque durante um pedido HTTP ou um acesso já comprometido requerem verificações adicionais e camadas de proteção.

O Análise em tempo real alarga esta verificação a determinados canais de transmissão. Para a análise de uploads HTTP e HTTPS, a documentação indica o ModSecurity como pré-requisito; os uploads FTP requerem o Pure-FTPd. Por conseguinte, é necessário verificar, para cada servidor, se estes serviços estão ativos e devidamente configurados. A funcionalidade não é automaticamente disponibilizada para todos os canais de upload apenas com a instalação do agente.

O âmbito da verificação inclui também a análise de arquivos. De acordo com a documentação, os arquivos ZIP são verificados por predefinição desde a versão 6.2 do Imunify360. Isto é particularmente útil no caso de pacotes de plugins, arquivos de cópias de segurança ou extensões carregadas, mas não indica se uma aplicação irá posteriormente descompactar o arquivo de forma insegura ou se o seu conteúdo é tecnicamente admissível.

O Analisador de bases de dados de malware (MDS) complementa a análise de ficheiros quando é detetado código malicioso, por exemplo, em publicações, opções ou conteúdos de widgets de um CMS. O seu suporte documentado limita-se ao WordPress, ao Joomla e ao Magento 2. No caso de aplicações próprias, estruturas de bases de dados diferentes ou outros sistemas de lojas online, não se deve inferir daqui uma cobertura completa da base de dados.

Planear o RapidScan e as verificações da base de dados

O RapidScan altera o processo das verificações repetidas, mas não o objetivo fundamental de uma verificação de malware. Para tal, o Imunify360 armazena localmente os metadados e os hashes dos ficheiros e compara os hashes com uma base de dados na nuvem. Em análises posteriores, a análise local pode concentrar-se nos ficheiros que foram alterados ou que ainda são desconhecidos.

A primeira execução requer, inicialmente, uma verificação normal do inventário. O fabricante indica que as verificações subsequentes podem ser de cinco a vinte vezes mais rápidas. Este intervalo é uma indicação do fabricante que depende da situação, não constituindo uma garantia fiável para todos os servidores: a dimensão e a composição do conjunto de ficheiros, a taxa de alterações, o desempenho de E/S disponível e as condições da rede influenciam o resultado.

Em termos de planeamento, isto significa que um servidor com muitos ficheiros Web inalterados pode ser RapidScan beneficia-se mais do que uma conta que gera continuamente uploads, caches ou ficheiros de registo. Por isso, não se limite a medir o tempo total de execução, mas documente, antes de efetuar alterações, os caminhos afetados, o volume de ficheiros e o tempo de espera de E/S. Desta forma, é possível definir janelas de análise e exclusões com base em causas concretas, em vez de suposições.

No caso de publicações do WordPress que tenham sido manipuladas ou de scripts introduzidos nas opções, uma simples verificação de ficheiros pode não ser suficiente. O MDS pode, inicialmente, ser utilizado em modo não intrusivo para as bases de dados do WordPress suportadas --scan verificar. Este passo não altera quaisquer dados e cria uma base para avaliar os locais de ocorrência, o impacto no site e a possibilidade de recuperação antes de se tomar uma decisão.

A limpeza ou a restauração, por outro lado, são intervenções em conteúdos produtivos. Antes disso, é necessário dispor de uma cópia de segurança atualizada e verificada, uma autorização técnica para o site em questão e um plano de contingência, caso sejam alterados conteúdos legítimos. Em muitos projetos separados de clientes, é útil uma separação clara dos conteúdos, tal como também acontece em Alojamento Multidomínio O que é importante: delimita as competências e facilita a atribuição dos achados.

O MDS não substitui uma análise completa do incidente. A reaparecimento de código malicioso na base de dados pode indicar um plugin vulnerável, credenciais de acesso comprometidas ou um backdoor num ficheiro. Após a deteção, devem, portanto, ser analisados, para além do conteúdo da base de dados, o CMS, as extensões, as contas de utilizador e a origem da operação de gravação.

Integração com o WordPress e atualizações controladas do WAF

A extensão do WordPress denominada «Imunify Security Plugin» é gerida pelo Imunify Agent no servidor e não é disponibilizada através do diretório do WordPress.org. Permite aos administradores do WordPress visualizar informações de estado e, dependendo do produto Imunify utilizado, outras funcionalidades de segurança no backend. Como tal, constitui uma interface e um complemento, mas não um substituto dos mecanismos de análise e proteção do lado do servidor.

No que diz respeito à funcionalidade básica, a documentação refere, no mínimo, o Imunify360 8.4.1 no lado do servidor. Funcionalidades como a integração WAF ou a gestão de bots por IA são desenvolvidas separadamente e estão associadas a versões específicas de agentes e plug-ins. Por isso, antes de uma implementação, verifique a combinação concreta de versões, em vez de deduzir a existência de uma determinada função de proteção apenas com base na presença do plugin.

A WAF também deve ser operada como uma camada independente. A partir de imunify360-firewall 8.6.0 Existe um procedimento documentado para desativar as atualizações automáticas das regras do ModSecurity, listar as versões disponíveis das regras e selecionar uma versão específica. Isto permite aos operadores de alojamento agendar alterações nas regras de forma controlada e, se necessário, reverter para uma versão conhecida.

Um processo adequado consiste em introduzir, numa primeira fase, uma nova versão da regra num servidor de teste com páginas representativas do WordPress, promoções da loja e ficheiros carregados. Só quando não forem detetados bloqueios indevidos relevantes ou problemas de funcionamento é que se procede à implementação gradual no ambiente de produção. O controlo de versões diz respeito às regras do ModSecurity, não às assinaturas de malware em geral, ao agente na sua totalidade ou a outros componentes do Imunify.

Controlada Atualizações das regras do WAF Não evitam todas as falhas, mas estabelecem responsabilidades claras: quem verifica as alterações, quais as aplicações que servem como casos de teste e quando se deve reverter as alterações? Estas questões devem fazer parte do processo operacional. Continuam a ser necessárias atualizações atempadas do CMS e das extensões, direitos de acesso restritivos e cópias de segurança testadas, porque nenhum WAF elimina as vulnerabilidades conhecidas no software instalado.

Verificar e tratar com segurança as detecções de malware

A deteção de malware é um processo de análise e não implica automaticamente uma ordem de eliminação. Verifique primeiro o histórico de deteções, a data e hora, o caminho completo e o motivo da deteção na interface. Estas informações ajudam a determinar se o ficheiro pertence a um plugin, a um tema, a um diretório de uploads ou a uma aplicação desenvolvida individualmente, e se a mesma deteção já ocorreu anteriormente.

Compare um ficheiro PHP suspeito com uma fonte fiável do fabricante da mesma versão ou com uma cópia de segurança verificada. No caso de componentes padrão, uma nova comparação completa é, na maioria das vezes, mais reveladora do que a análise isolada de linhas de código individuais, que podem estar dissimuladas. Guarde a descoberta e os registos associados antes de qualquer alteração, para que seja possível rastrear posteriormente a via de entrada.

A análise das causas reais vai além do caminho indicado: atualize as versões afetadas do CMS, dos plugins e dos temas, verifique as contas de utilizador e, em caso de suspeita fundamentada, altere as credenciais de acesso. Procure também por outras webshells, administradores desconhecidos e tarefas agendadas suspeitas. A remoção de um ficheiro não exclui a possibilidade de o atacante ter deixado um segundo ponto de acesso.

A deteção de um problema na base de dados exige especial cautela, uma vez que as intervenções de correção podem alterar conteúdos ou configurações. Uma verificação é, em primeiro lugar, uma análise; a correção ou a restauração pressupõem a existência de uma cópia de segurança disponível, uma aprovação técnica e um plano de contingência. O Malware Database Scanner suporta apenas os casos documentados nas bases de dados do WordPress, Joomla e Magento 2, não sendo uma verificação geral de quaisquer esquemas de aplicações.

Se o Adminer for detetado, a ferramenta pode ter sido instalada de forma legítima, mas, devido ao seu conjunto de funcionalidades suscetíveis de abuso, a sua deteção é compreensível. Em vez de desativar globalmente uma categoria de deteção, deve verificar a necessidade, a integridade e a proteção de acesso do ficheiro em questão. Se for inevitável abrir uma exceção, uma exclusão restrita ao caminho do ficheiro limita melhor a lacuna de segurança do que uma deteção desativada a nível de conta ou de servidor.

Analisar a carga, os falsos alarmes e a persistência

Se a utilização da CPU ou o tempo de espera de E/S aumentarem, a exclusão não deve ser a primeira medida a tomar. Registe, em primeiro lugar, os eventos de análise, os percursos afetados, as taxas de alteração, os processos ativos e o período de duração da carga. Só a correlação temporal revela se a análise em tempo real poderá estar envolvida ou se, por exemplo, uma cópia de segurança, uma importação, aplicações com erros ou outro serviço estão a consumir os recursos.

Os ficheiros de registo frequentemente descritos podem desencadear atividades de análise repetidas e, por isso, constituir uma possível causa de carga adicional. Um caso de suporte documentado aborda este padrão para ficheiros de registo do WordPress, mas não comprova uma regra geral de causa e efeito para todos os servidores sobrecarregados. Por isso, verifica especificamente os caminhos dos ficheiros e as frequências de gravação, em vez de excluir preventivamente diretórios inteiros de clientes do Verificador de malware excluir.

As exceções devem ter um objetivo bem definido, uma pessoa responsável e uma revisão periódica. No caso de um caminho gerado de forma legítima e muito ativo, uma exceção limitada pode ser justificável após análise. No entanto, esta não pode ser alargada, sem que se perceba, a diretórios de upload ou de aplicações, nos quais os atacantes poderiam armazenar ou alterar ficheiros.

A recorrência de resultados positivos após uma limpeza sugere a realização de um exame para detetar Persistência em vez de se limitar a apagar os ficheiros. Para além do conjunto de ficheiros e da base de dados, a verificação deve incluir tarefas Cron, contas de administrador desconhecidas, dados de acesso, registos do servidor Web e processos em execução. Em particular, as tarefas agendadas podem voltar a descarregar código malicioso ou substituir um webshell remoto.

O Imunify360 documenta uma verificação dos crontabs do sistema e dos utilizadores desde a versão 6.10 como uma funcionalidade experimental e desativada por predefinição. Isto alarga a interface de verificação, mas não substitui a avaliação manual de uma tarefa suspeita. Antes de ativar esta funcionalidade, deve verificar a carga, a compatibilidade e o impacto nas suas próprias operações; tal não implica uma ativação generalizada para todos os ambientes de alojamento.

Decidir sobre a operação, a migração e a implementação

Para um pequeno servidor com poucos sites, podem ser suficientes análises em segundo plano programáveis, notificações claras e a aprovação manual das medidas a tomar. Em ambientes de revenda e de alojamento partilhado, por outro lado, os requisitos em relação a Procedimentos de escalamento: Quem avalia as descobertas, quem contacta os clientes, quem pode definir exceções e quando é que uma conta é restringida? As responsabilidades documentadas evitam que intervenções corretivas ou falhas de segurança fiquem por resolver entre o apoio ao cliente e a administração.

A proteção em tempo real, os intervalos de verificação e as notificações devem estar adequados à taxa de alterações e aos recursos do servidor. Muitas contas de clientes independentes beneficiam de procedimentos consistentes e de um registo de atividades rastreável. Um único projeto crítico para o negócio requer, muitas vezes, um processo de manutenção e aprovação coordenado. Medidas de proteção básicas, como atualizações, direitos mínimos e cópias de segurança testadas, continuam a ser necessárias independentemente disso.Critérios para a escolha de um serviço de alojamento web adequado

O repositório de produção e as instalações de teste devem ser rigorosamente separados. O fabricante implementa versões estáveis no canal de produção de forma gradual, prevendo um período de até cerca de duas semanas para esse efeito. Uma funcionalidade que só esteja disponível no repositório de teste ou após uma instalação com --beta O facto de estar visível não significa, por isso, que esteja automaticamente disponível de forma estável.

Um controlado Lançamento Começa com a identificação da versão e um servidor de teste ou piloto representativo. Após a atualização, verifica o estado do agente, a gestão de pacotes, os registos suspeitos e as funcionalidades importantes para os clientes. Só quando o processo decorrer sem anomalias é que se procede à implementação faseada. Isto não elimina todos os riscos, mas torna as anomalias visíveis mais cedo e facilita uma reação específica.

A migração voluntária do Patchman é uma decisão operacional, não uma modernização automática. Após a migração, já não é possível recuperar ficheiros da quarentena anterior do Patchman; de acordo com a documentação, o Imunify cria cópias de segurança dos ficheiros limpos. Por isso, antes de proceder à migração, os operadores devem definir de forma vinculativa as regras de conservação, os procedimentos de recuperação, a comunicação com os clientes e as responsabilidades.

Um problema específico com a atualização em imunify-common A versão 1.3.21-1 no CloudLinux 8 com base de dados RPM baseada no Berkeley DB foi corrigida, segundo o fabricante, a partir da versão 1.3.22-2. Isto não constitui um argumento geral contra as atualizações. No entanto, sublinha a razão pela qual as janelas de manutenção, as versões documentadas e as verificações posteriores da gestão de pacotes fazem parte de um processo profissional de atualização.