Scripts maliciosos. Procuramos e removemos códigos maliciosos no WordPress. Neutralizando scripts de servidor

WordPress é um dos sistemas de gerenciamento de conteúdo mais populares, usado para diversos fins, desde blogs até comércio eletrônico. Existe uma ampla seleção de plug-ins e temas do WordPress. Acontece que algumas dessas extensões caem nas mãos de webmasters depois que algum invasor trabalhou nelas.

Para seu próprio benefício, ele pode deixar neles links publicitários ou códigos com os quais administrará seu site. Muitos usuários do WordPress não têm muita experiência em programação web e não sabem como lidar com essa situação.

Para eles, revisei nove das ferramentas mais eficazes para detectar alterações maliciosas no código de um site em execução ou em complementos instalados.

1. Verificador de autenticidade de tema (TAC)

Theme Authenticity Checker (TAC) – plugin do WordPress que verifica todos tema estabelecido para elementos suspeitos, como links invisíveis ou código criptografado Base64.

Tendo detectado tais elementos, o TAC os reporta ao administrador do WordPress, permitindo-lhe analisar de forma independente e, se necessário, corrigir os arquivos do tema fonte:

2. Scanner de exploração

O Exploit Scanner verifica todo o código-fonte do seu site e o conteúdo do banco de dados WordPress em busca de inclusões questionáveis. Assim como o TAC, este plugin não evita ataques nem combate suas consequências automaticamente.

Ele mostra apenas sintomas detectados de infecção ao administrador do site. Se você quiser excluir Código malicioso, você terá que fazer isso manualmente:

3. Segurança Sucuri

Sucuri é uma solução de segurança WordPress bem conhecida. O plugin Sucuri Security monitora arquivos carregados em um site WordPress, mantém sua própria lista de ameaças conhecidas e também permite que você verifique remotamente o site usando o Sucuri SiteCheck Scanner gratuito. Atrás taxa de inscrição Você pode fortalecer ainda mais a proteção do seu site instalando o poderoso Firewall de Sites Sucuri:

4. Antimalware

Anti-Malware é um plugin para WordPress que pode localizar e remover scripts de Trojan, backdoors e outros códigos maliciosos.

As configurações de digitalização e exclusão podem ser personalizadas. Este plugin pode ser usado após registro gratuito no gotmls.

O plugin acessa regularmente o site do fabricante, transmitindo estatísticas de detecção de malware e recebendo atualizações. Portanto, se você não deseja instalar em seu site plug-ins que monitorem seu funcionamento, evite usar Anti-Malware:

5. Proteção de site antivírus WP

WP Antivirus Site Protection é um plugin que verifica todos os arquivos enviados para um site, incluindo temas WordPress.

O plugin possui seu próprio banco de dados de assinaturas, que é atualizado automaticamente via Internet. Ele pode remover ameaças automaticamente, notificar o administrador do site e-mail E muito mais.

O plugin é instalado e funciona gratuitamente, mas possui vários complementos pagos aos quais vale a pena prestar atenção:

6. Antivírus para WordPress

AntiVirus para WordPress é um plugin fácil de usar que pode verificar seu site regularmente e notificá-lo sobre problemas de segurança por e-mail. O plugin possui uma lista de permissões personalizável e outros recursos:

7. Verificador de malware Quterra Web

O scanner do Quterra verifica um site em busca de vulnerabilidades, injeções de código de terceiros, vírus, backdoors, etc. O scanner possui recursos interessantes como varredura heurística e detecção de links externos.

Os recursos básicos do scanner são gratuitos, enquanto alguns serviços adicionais custarão US$ 60 por ano:

8. Cerca de palavras

Se você está procurando uma solução abrangente para os problemas de segurança do seu site, não procure mais, o Wordfence.

Este plugin fornece proteção constante para WordPress contra tipos conhecidos de ataques, autenticação de dois fatores, suporte para uma “lista negra” de endereços IP de computadores e redes usadas por hackers e spammers e verificação do site em busca de backdoors conhecidos.

Este plugin é gratuito em sua versão básica, mas também possui funcionalidade premium, para a qual o fabricante solicita uma modesta taxa de assinatura:

9.Wemahu

Wemahu monitora alterações no código do seu site e procura códigos maliciosos.

O banco de dados no qual o malware é detectado é reabastecido usando o método crowdsourcing: os próprios usuários o reabastecem enviando os resultados da verificação de instalações infectadas do WordPress para o site do autor do plugin. O plugin também suporta o envio de relatórios por e-mail e outros recursos úteis.

Deve ser feito em conjunto. Se você eliminar a causa original do hack (por exemplo, uma vulnerabilidade na extensão CMS), mas não remover todos os arquivos maliciosos, o invasor poderá obter acesso ao site novamente usando um de seus scripts. Se você remover todos os scripts maliciosos baixados, mas não eliminar a causa do hack, o invasor poderá hackear o site novamente e baixar scripts nele novamente.

Um especialista com conhecimento e experiência adequados deve realizar trabalhos para remover scripts maliciosos e analisar as causas do hacking:

• Para remover scripts maliciosos, você precisa de conhecimento da linguagem de programação PHP, bem como conhecimento do “interior” de CMS populares (Joomla, WordPress, etc.) e extensões para eles. Esse conhecimento é necessário para distinguir scripts diretamente do CMS e suas extensões de arquivos estranhos, e também para ser capaz de determinar inequivocamente quais ações eles executam ao encontrar scripts duvidosos.
• Para analisar as causas do hacking, é necessária experiência em administração de servidores. Isso é necessário para analisar o estado dos arquivos da conta, a hora em que foram alterados e também para comparar esses dados com os logs do servidor para determinar quais ações do invasor levaram ao hackeamento de sites.

Portanto, se o seu site foi hackeado, é recomendável, para evitar repetidos hacks, não fazer o trabalho sozinho, mas entrar em contato com um especialista que fará os diagnósticos necessários e recomendará ou executará ações necessárias para resolver o problema e quem pode garantir a qualidade do resultado obtido.

No entanto, existem uma série de medidas que, em alguns casos, ajudam a restaurar o funcionamento seguro do local sem conhecimentos especiais. A limitação do método abaixo é que para retomar o funcionamento do site é necessária uma cópia de backup do mesmo criada antes do hack. Se a data da violação for desconhecida, você pode tentar este método usando o backup mais antigo disponível. A segunda limitação, como consequência da primeira, é que após a restauração do site, foram criados dados adicionados ao site após o backup de restauração (por exemplo, novos artigos, imagens ou documentos). Se você precisar restaurar o site mantendo novos dados, entre em contato com um especialista.

Estas medidas não nos permitem determinar a causa do hack do site, mas cada uma delas visa eliminar uma das potenciais causas de penetração. Como o motivo exato do hack é desconhecido, é necessário realizar todos eles. As ações são organizadas de forma a eliminar completamente a possibilidade de o invasor continuar suas atividades no site ou hospedar a conta em atualmente e impedir que um invasor entre no site no futuro.

As etapas abaixo pressupõem que você tenha apenas um site em sua conta de hospedagem. Se houver vários sites na conta, eles também poderão ser invadidos e o site poderá ser invadido por meio deles. É necessário transferir o site com o qual o trabalho de restauração está sendo realizado para uma conta separada ou realizar a restauração de todos os sites hospedados na conta ao mesmo tempo.

A ordem das ações é importante, por isso é necessário realizá-las exatamente na ordem em que estão localizadas abaixo.

Imediatamente após descobrir que um site foi hackeado, é necessário bloquear completamente o acesso dos visitantes ao mesmo. Isso, em primeiro lugar, impedirá que o invasor realize atividades maliciosas no site e, em segundo lugar, não permitirá que ele interfira nos trabalhos de restauração. Esta etapa é muito importante, pois a remoção de scripts maliciosos e a eliminação da causa do hack não acontecem da noite para o dia - via de regra, leva várias horas. Se o site permanecer acessível externamente, o invasor poderá reenviar os scripts para a seção do site que já foi limpa. Nesse caso, um invasor pode usar endereços IP diferentes para se conectar, portanto, negar acesso apenas a uma lista de endereços IP não funcionará. Para garantir que o site seja limpo de scripts maliciosos detectados, é necessário bloquear completamente a capacidade do invasor de acessar o site, o que só pode ser feito bloqueando completamente o site para quaisquer visitantes. Entre em contato com o serviço de suporte técnico da hospedagem que hospeda seu site para bloqueá-lo.

Após bloquear o site, você precisa verificar os computadores nos quais você trabalhou com o site com um antivírus moderno com bancos de dados de vírus atualizados. Se o site foi invadido por meio do roubo de senhas de contas por meio de vírus, você deve certificar-se de que o trabalho posterior com o site invadido seja realizado a partir de um computador que não contenha vírus, caso contrário, após alterar as senhas de acesso, elas poderão ser roubadas novamente.

Após bloquear o site e verificar se há vírus, é necessário alterar todas as senhas de acesso à sua conta: acesso via FTP, via SSH, bem como acesso ao painel de controle da hospedagem. Se um invasor acessou os arquivos da conta usando um desses métodos, depois que as senhas forem alteradas, ele não poderá mais fazê-lo.

Após alterar as senhas, você deve destruir todos os processos do servidor em execução na conta na qual o site é mantido. Os processos iniciados por um invasor em segundo plano, sem serem destruídos, poderão substituir scripts maliciosos no site após a execução do trabalho de restauração. Para evitar que isso aconteça, todos os processos em execução antes do bloqueio do site devem ser destruídos. O site já deve estar bloqueado neste momento para que o invasor não consiga lançar novos processos acessando um de seus scripts no site. Para destruir processos em execução na sua conta, entre em contato com o serviço de suporte técnico da hospedagem que hospeda seu site.

Agora é impossível penetrar no local de fora e você pode começar a restaurá-lo.

Antes de qualquer ação adicional, exclua todos os arquivos existentes do site para garantir que não haja scripts maliciosos ou scripts CMS nos quais o invasor tenha inserido código malicioso. Esta etapa também é importante porque ao restaurar um site a partir de um backup, nem sempre os arquivos que existiam antes da restauração são excluídos. Se, após a restauração de um backup, scripts maliciosos antigos permanecerem no site, o invasor poderá entrar novamente no site. Você pode evitar isso excluindo todos os arquivos do site antes de realizar a recuperação.

Depois de excluir todos os arquivos do site, restaure o site a partir de um backup criado antes de ser hackeado. Muitas vezes basta restaurar apenas os arquivos do site, mas se após restaurá-los forem observados erros no funcionamento do site, é necessário restaurar o site por completo: tanto os arquivos quanto o banco de dados.

Após restaurar a partir de um backup, atualize seu sistema de gerenciamento de conteúdo (CMS) e extensões para as versões mais recentes. Isso é necessário para excluir a presença de vulnerabilidades conhecidas no site através das quais ele possa ser hackeado. Via de regra, a atualização pode ser feita através da seção de administração do CMS. Para conseguir instruções completas Para atualizar o CMS, você deve acessar o site do desenvolvedor do sistema. É importante atualizar não só o próprio CMS, mas também todas as suas extensões, pois muitas vezes o hacking ocorre através de uma vulnerabilidade presente em uma das extensões do CMS (por exemplo, plugins, temas, widgets, etc.). Neste momento ainda é impossível desbloquear o site para visitantes, pois ele ainda pode estar vulnerável. Para acessar seu site para atualização, entre em contato com o suporte técnico da hospedagem que hospeda seu site e peça para permitir o acesso ao site apenas a partir do endereço IP do seu computador. Você pode descobrir seu endereço IP, por exemplo, em inet.yandex.ru.

Após atualizar o sistema de gerenciamento do site e suas extensões, vá até a seção de administração do site e altere a senha de acesso do administrador. Certifique-se de que entre os usuários do site não haja outros usuários com privilégios administrativos (eles podem ter sido adicionados por um invasor) e, se algum for encontrado, exclua-o.

Agora que o site foi restaurado a partir de um backup e não contém scripts maliciosos, o CMS e suas extensões foram atualizados para as versões mais recentes que não contêm vulnerabilidades e as senhas de acesso ao site e à conta de hospedagem foram alteradas, você pode reabrir o site aos visitantes.

Todas as ações acima devem ser realizadas de acordo com a ordem especificada, sem omissões ou alterações. Se as ações forem executadas de maneira imprecisa, scripts maliciosos ou vulnerabilidades podem permanecer no site, e como resultado ele pode ser hackeado novamente por um invasor após um curto período de tempo. Se por algum motivo não for possível realizar os passos acima na forma em que estão indicados, entre em contato com um especialista para realizar trabalhos de restauração do site após um hack.

Para proteger seu site contra hacks repetidos no futuro, você deve seguir as seguintes recomendações:

Acompanhe as atualizações do CMS e extensões nos sites dos desenvolvedores e atualize-as imediatamente para as versões mais recentes. Se um comentário de atualização indicar que ela corrige uma vulnerabilidade, instale a atualização o mais rápido possível.

Trabalhe com o site e a conta de hospedagem apenas em computadores protegidos contra vírus por antivírus modernos com bancos de dados de vírus constantemente atualizados.

Use senhas complexas para que não possam ser adivinhadas por meio de uma pesquisa no dicionário.

Não salve senhas de FTP e SSH em programas de conexão ao site, e não salve a senha de acesso à área administrativa do site e ao painel de controle da hospedagem em seu navegador.

Periodicamente (por exemplo, uma vez a cada três meses), altere as senhas de acesso ao site e à conta de hospedagem.

Se foram detectados vírus no computador a partir do qual você estava trabalhando com o site, altere as senhas de acesso ao site e à conta de hospedagem o mais rápido possível. É necessário alterar todas as senhas: as senhas de acesso via FTP, SSH, a senha do painel administrativo do site, bem como a senha do painel de controle da hospedagem.

Não forneça acesso ao site a terceiros, a menos que tenha certeza de que eles também seguirão estas diretrizes.

Código malicioso entra no site por negligência ou intenção maliciosa. Os objetivos do código malicioso variam, mas essencialmente prejudicam ou interferem no funcionamento normal de um site. Para remover código malicioso do WordPress, você deve primeiro encontrá-lo.

O que é código malicioso em um site WordPress?

Por aparência, na maioria das vezes, o código malicioso é um conjunto de letras e símbolos do alfabeto latino. Na verdade, este é um código criptografado pelo qual esta ou aquela ação é executada. As ações podem ser muito diferentes, por exemplo, suas novas postagens são publicadas imediatamente em um recurso de terceiros. Isso é essencialmente roubar seu conteúdo. Os códigos também têm outras “tarefas”, por exemplo, colocar links de saída nas páginas do site. As tarefas podem ser as mais sofisticadas, mas uma coisa é certa: códigos maliciosos precisam ser caçados e removidos.

Como os códigos maliciosos chegam a um site?

Existem também muitas brechas para a entrada de códigos no site.

Na maioria das vezes, são temas e plug-ins baixados de recursos “esquerdos”. Embora essa penetração seja típica dos chamados links criptografados. O código explícito não acaba no site.

A penetração de um vírus quando um site é hackeado é a mais perigosa. Via de regra, hackear um site permite que você coloque não apenas um “código único”, mas também instale código com elementos de malware ( malware). Por exemplo, você encontra um código e o exclui, mas ele é restaurado depois de algum tempo. Existem, novamente, muitas opções.

Deixe-me observar imediatamente que é difícil combater esses vírus e a remoção manual requer conhecimento. Existem três soluções para o problema: a primeira solução é usar plugins antivírus, por exemplo, um plugin chamado BulletProof Security.

Esta solução dá bons resultados, mas leva tempo, ainda que um pouco. Existe uma solução mais radical para se livrar de códigos maliciosos, inclusive vírus complexos, que é restaurar o site a partir de cópias de backup do site feitas anteriormente.

Como um bom webmaster faz isso periodicamente, você pode reverter para uma versão não infectada sem problemas. A terceira solução é para os ricos e preguiçosos, basta entrar em contato com um “escritório” especializado ou com um especialista individual.

Como procurar código malicioso no WordPress

É importante entender que o código malicioso no WordPress pode estar em qualquer arquivo do site, e não necessariamente no tema de trabalho. Ele pode criar um plugin, um tema ou um código “caseiro” retirado da Internet. Existem várias maneiras de tentar encontrar código malicioso.

Método 1: Manualmente. Você percorre todos os arquivos do site e os compara com os arquivos de um backup não infectado. Se você encontrar o código de outra pessoa, exclua-o.

Método 2: usando plug-ins de segurança do WordPress. Por exemplo, . Este plugin tem um ótimo recurso, verificando os arquivos do site em busca de código de outras pessoas e o plugin lida perfeitamente com essa tarefa.

Método 3. Se você tiver suporte de hospedagem razoável e parecer que há outra pessoa no site, peça que verifiquem seu site com o antivírus. O relatório deles listará todos os arquivos infectados. Em seguida, abra esses arquivos em editor de texto e remover código malicioso.

Método 4. Se você pode trabalhar com acesso SSH ao diretório do site, vá em frente, ele tem sua própria cozinha.

Importante! Não importa como você pesquisa o código malicioso, antes de pesquisar e excluir o código, feche o acesso aos arquivos do site (ative o modo de manutenção). Lembre-se dos códigos que são restaurados quando são excluídos.

Procure códigos maliciosos usando a função eval

Existe uma função em PHP chamada eval. Ele permite que você execute qualquer código em sua linha. Além disso, o código pode ser criptografado. É por causa da codificação que o código malicioso se parece com um conjunto de letras e símbolos. Duas codificações populares são:

Base64;

Rot13.

Conseqüentemente, nessas codificações a função eval se parece com isto:

• avaliação(base64_decode(...))
• eval (str_rot13 (...)) //entre aspas internas, conjuntos longos e pouco claros de letras e símbolos..

O algoritmo de busca de código malicioso usando a função eval é o seguinte (trabalhamos no painel administrativo):

• vá para o editor do site (Aparência→Editor).
• copie o arquivo funções.php.
• abra-o em um editor de texto (por exemplo, Notepad++) e pesquise a palavra: eval.
• Se você encontrar, não se apresse em excluir nada. Você precisa entender o que essa função “pede” para ser executada. Para entender isso, o código precisa ser decodificado. Para decodificação existem ferramentas online chamadas decodificadores.

Decodificadores/codificadores

Os decodificadores funcionam de forma simples. Você copia o código que deseja descriptografar, cola no campo do decodificador e decodifica.

No momento em que este artigo foi escrito, não encontrei um único código criptografado no WordPress. Encontrei o código no site Joomla. Em princípio, não há diferença na compreensão da decodificação. Vejamos a foto.

Como você pode ver na foto, a função eval, após a decodificação, não exibiu um código terrível que ameaça a segurança do site, mas sim um link de copyright criptografado do autor do template. Ele também pode ser removido, mas voltará após atualizar o modelo se você não usar o .

Concluindo, gostaria de ressaltar, para não pegar vírus no site:

• O código malicioso no WordPress geralmente vem com temas e plug-ins. Portanto, não instale templates e plugins de recursos “esquerdos” não verificados e, se o fizer, verifique-os cuidadosamente quanto à presença de links e funções executivas do PHP. Após instalar plugins e temas de recursos “ilegais”, verifique o site com software antivírus.
• Certifique-se de fazer backups periódicos e realizar outros.

1. Descompacte-o na pasta do site.
2. siga o link seu_site/fscure/
3. tudo

O que ele pode fazer?

1. Pesquisa automática de vírus por assinaturas.
2. Procure uma string nos arquivos
3. Excluindo arquivos
4. Corrija código malicioso usando expressões regulares

O script não fará todo o trabalho para você e requer algum conhecimento mínimo. Recomenda-se fazer um backup do site antes do trabalho.

Como funciona?

Quando iniciado pela primeira vez, ele cria um índice de arquivos. O arquivo fscure.lst está na pasta. Exibe uma lista de arquivos contendo assinaturas potencialmente maliciosas. “Potencialmente malicioso” significa que você terá que decidir se é um vírus ou não. A lista de assinaturas é configurada no arquivo config.php, constante SCAN_SIGN. Com as configurações padrão, o script não verifica arquivos js e não contém assinaturas para eles.

Problemas mais comuns

Primeiro, não cria o índice fscure.lst. Pode acontecer se não houver direitos suficientes. Coloque 777 na pasta fscure

2. Erro 5xx. Na maioria das vezes, "Tempo limite do gateway 504". O script não tem tempo para ser processado e trava devido ao tempo limite. Nesse caso, existem várias maneiras de agilizar seu trabalho. A velocidade depende principalmente do tamanho do índice. Está no arquivo fscure.lst. Normalmente, um arquivo de até 5 MB pode ser processado em 90% dos casos. Se não tiver tempo, você pode reduzir a “ganância” do script proibindo a digitalização *.jpg;*.png;*.css na configuração.
No arquivo config.php.

// delimitador; define("FILES_EXCLUDE","*.js;*.jpg;*.png;*.css");

3. A hospedagem emite um aviso como
(HEX)base64.inject.unclassed.6: u56565656: /var/www/u65656565/data/www/34535335353.ru/fscure/index.php

Não há vírus no script e nunca houve. E (HEX)base64.inject.unclassed.6 é uma construção como "echo base64_decode(" , que é frequentemente encontrada e por si só é bastante inofensiva. No entanto, em última versão, substituí este código.

O que fazer se você não conseguir encontrar o vírus sozinho?

Você pode entrar em contato comigo para obter ajuda. Minhas taxas são modestas. Garanto meu trabalho por 6 meses. O custo da obra é de 800 rublos. para 1 local. Se houver vários sites na sua conta, o preço é determinado individualmente.

Se você conseguisse fazer tudo sozinho, ficaria grato por uma recompensa financeira ou por um link para meu site.

Meus requisitos:
Yandex
41001151597934

webmoney
Z959263622242
R356304765617
E172301357329

A verdade da vida é que o site pode ser hackeado mais cedo ou mais tarde. Depois de explorar com sucesso a vulnerabilidade, o hacker tenta ganhar uma posição no site, colocando web shells e downloaders de hackers nos diretórios do sistema e introduzindo backdoors no código de script e no banco de dados CMS.

Os scanners ajudam a detectar web shells carregados, backdoors, páginas de phishing, emails de spam e outros tipos de scripts maliciosos - tudo o que eles conhecem e são pré-adicionados ao banco de dados de assinaturas de códigos maliciosos. Alguns scanners, como o AI-BOLIT, possuem um conjunto de regras heurísticas que podem detectar arquivos com código suspeito que é frequentemente usado em scripts maliciosos, ou arquivos com atributos suspeitos que podem ser baixados por hackers. Mas, infelizmente, mesmo que vários scanners sejam usados ​​na hospedagem, pode haver situações em que alguns scripts de hackers passam despercebidos, o que na verdade significa que o invasor fica com uma “porta dos fundos” e pode invadir o site e obter controle sobre ele. controlo total a qualquer momento.

Os scripts modernos de malware e hackers são significativamente diferentes daqueles de 4 a 5 anos atrás. Atualmente, os desenvolvedores de códigos maliciosos combinam ofuscação, criptografia, decomposição, carregamento externo de código malicioso e outros truques para enganar o software antivírus. Portanto, a probabilidade de faltar novo malware é muito maior do que antes.

O que pode ser feito neste caso para detectar vírus no site e scripts de hackers na hospedagem com mais eficiência? É necessário utilizar uma abordagem integrada: digitalização inicial automatizada e posterior análise manual. Este artigo discutirá opções para detectar código malicioso sem scanners.

Primeiro, vamos ver exatamente o que você deve procurar durante um hack.

Scripts de hackers.
Na maioria das vezes, ao hackear, os arquivos baixados são web shells, backdoors, “uploaders”, scripts para correspondências de spam, páginas de phishing + manipuladores de formulários, portas e arquivos marcadores de hacking (fotos do logotipo do grupo de hackers, arquivos de texto com uma “mensagem” de hackers, etc.)

Injeções (injeções de código) em arquivos .
O segundo tipo mais popular de hospedagem de código malicioso e de hacker são as injeções. Redirecionamentos móveis e de pesquisa podem ser injetados em arquivos .htaccess de sites existentes, backdoors podem ser injetados em scripts php/perl e fragmentos virais de javascript ou redirecionamentos para recursos de terceiros podem ser incorporados em modelos .js e .html. As injeções também são possíveis em arquivos de mídia, por exemplo.jpg ou. Freqüentemente, o código malicioso consiste em vários componentes: o próprio código malicioso é armazenado no cabeçalho exif do arquivo jpg e é executado usando um pequeno script de controle, cujo código não parece suspeito para o scanner.

Injeções de banco de dados.
O banco de dados é o terceiro alvo de um hacker. Aqui, são possíveis inserções estáticas, , , , que redirecionam os visitantes para recursos de terceiros, os “espionam” ou infectam o computador/dispositivo móvel do visitante como resultado de um ataque drive-by.
Além disso, em muitos mecanismos de modelo CMS modernos (IPB, vBulletin, modx, etc.) permitem que você execute código php, e os próprios modelos são armazenados no banco de dados, de modo que o código PHP de shells da web e backdoors pode ser criado diretamente no banco de dados.

Injeções em serviços de cache.
Como resultado da configuração incorreta ou insegura de serviços de cache, por exemplo, memcached, são possíveis injeções em dados armazenados em cache “on the fly”. Em alguns casos, um hacker pode injetar código malicioso nas páginas de um site sem invadir diretamente o site.

Injeções/elementos iniciados em componentes do sistema do servidor.
Se um hacker obtiver acesso privilegiado (root) ao servidor, ele poderá substituir elementos do servidor web ou servidor de cache por outros infectados. Tal servidor web irá, por um lado, fornecer controle sobre o servidor usando comandos de controle e, por outro lado, de tempos em tempos introduzir redirecionamentos dinâmicos e códigos maliciosos nas páginas do site. Como no caso de uma injeção em um serviço de cache, o administrador do site provavelmente não conseguirá detectar o fato de o site ter sido hackeado, pois todos os arquivos e o banco de dados serão originais. Esta opção é a mais difícil de tratar.

Então, vamos supor que você já tenha verificado os arquivos da hospedagem e o dump do banco de dados com scanners, mas eles não encontraram nada, e o vírus ainda está na página ou o redirecionamento móvel continua funcionando ao abrir as páginas. Como pesquisar mais?

Pesquisa manual

No Unix, é difícil encontrar um par de comandos mais valioso para localizar arquivos e fragmentos do que find/grep.

encontrar . -nome ‘*.ph*’ -mtime -7

encontrará todos os arquivos que foram alterados na última semana. Às vezes, os hackers “distorcem” a data de modificação dos scripts para não detectar novos scripts. Então você pode procurar por arquivos php/phtml cujos atributos foram alterados

encontrar . -nome ‘*.ph*’ -сtime -7

Se precisar encontrar alterações em um determinado intervalo de tempo, você pode usar o mesmo find

encontrar . -nome ‘*.ph*’ -newermt 2015-01-25 ! -newermt 30/01/2015 -ls

Para pesquisar arquivos, o grep é indispensável. Ele pode pesquisar recursivamente em arquivos por um fragmento especificado

grep -ril ‘stummann.net/steffen/google-analytics/jquery-1.6.5.min.js’ *

Ao hackear um servidor, é útil analisar arquivos que possuem o sinalizador guid/suid definido

encontrar / -perm -4000 -o -perm -2000

Para determinar quais scripts estão sendo executados atualmente e carregando a CPU de hospedagem, você pode chamar

lsof +r 1 -p `ps axww | grephttpd | grep -v grep | awk ‘ ( if(!str) ( str= ) else ( str=str””))END(print str)’` | grep vhosts | grepphp

Usamos nossos cérebros e mãos para analisar arquivos na hospedagem

Vamos para os diretórios upload, cache, tmp, backup, log, images, nos quais algo é gravado por scripts ou carregado pelos usuários, e verificamos o conteúdo em busca de novos arquivos com extensões suspeitas. Por exemplo, para joomla você pode verificar os arquivos .php no diretório images:find ./images -name ‘*.ph*’. Provavelmente, se algo for encontrado, será malware.
Para WordPress, faz sentido verificar o diretório wp-content/uploads e os diretórios de tema de backup e cache em busca de scripts.

Procurando arquivos com nomes estranhos
Por exemplo, php, fyi.php, n2fd2.php. Os arquivos podem ser pesquisados

• - por combinações de caracteres não padronizadas,
• - a presença dos números 3,4,5,6,7,8,9 no nome do arquivo

Estamos procurando arquivos com extensões incomuns
Digamos que você tenha um site WordPress ou para eles arquivos com extensões .py, .pl, .cgi, .so, .c, .phtml, .php3 não serão muito comuns. Se algum script e arquivo com essas extensões for detectado, provavelmente serão ferramentas de hacker. A percentagem de falsas detecções é possível, mas não é elevada.

Procuramos arquivos com atributos ou data de criação fora do padrão
A suspeita pode ser causada por arquivos com atributos diferentes daqueles existentes no servidor. Por exemplo, todos os scripts .php foram carregados via ftp/sftp e possuem o usuário user, e alguns foram criados pelo usuário www-data. Faz sentido verificar os mais recentes. Ou se a data de criação do arquivo de script for anterior à data de criação do site.
Para agilizar a busca por arquivos com atributos suspeitos, é conveniente usar o comando find do Unix.

Procuramos portas usando um grande número de arquivos .html ou .php
Se houver vários milhares de arquivos .php ou .html no diretório, provavelmente é uma porta.

Registros para ajudar

Servidor Web, serviço de e-mail e logs de FTP podem ser usados ​​para detectar scripts maliciosos e de hackers.

• Correlação da data e hora de envio da carta (que pode ser consultada no log servidor de e-mail ou cabeçalho de serviço de uma carta de spam) com solicitações de access_log ajudam a identificar o método de envio de spam ou encontrar o script do remetente de spam.

• A análise do log de transferência do FTP xferlog permite entender quais arquivos foram baixados no momento do hack, quais foram alterados e por quem.

• Em um log de servidor de e-mail configurado corretamente ou no cabeçalho de serviço de um e-mail de spam, se o PHP estiver configurado corretamente, haverá um nome ou caminho completo para o script de envio, o que ajuda a determinar a origem do spam.

• Usando os logs de proteção proativa de CMS e plugins modernos, você pode determinar quais ataques foram realizados no site e se o CMS foi capaz de resistir a eles.

• Usando access_log e error_log, você pode analisar as ações de um hacker se souber os nomes dos scripts que ele chamou, o endereço IP ou o User Agent. Como último recurso, você pode visualizar as solicitações POST do dia em que o site foi hackeado e infectado. Freqüentemente, a análise permite encontrar outros scripts de hackers que foram baixados ou que já estavam no servidor no momento do hack.

Controle de integridade

É muito mais fácil analisar um hack e procurar scripts maliciosos em um site se você cuidar de sua segurança com antecedência. O procedimento de verificação de integridade ajuda a detectar alterações na hospedagem em tempo hábil e a determinar o fato da invasão. Um dos mais simples e maneiras eficazes– colocar o site sob sistema de controle de versão (git, svn, cvs). Se você configurar .gitignore corretamente, o processo de controle de alterações será semelhante a chamar o comando git status, e a pesquisa por scripts maliciosos e arquivos alterados será semelhante a git diff.

Além disso você sempre terá cópia de segurança arquivos para os quais você pode “reverter” o site em questão de segundos. Administradores de servidores e webmasters avançados podem usar inotify, tripwire, auditd e outros mecanismos para rastrear o acesso a arquivos e diretórios e monitorar alterações no sistema de arquivos.

Infelizmente, nem sempre é possível configurar um sistema de controle de versão ou serviços de terceiros no servidor. No caso de hospedagem compartilhada, não será possível instalar sistema de controle de versão e serviços de sistema. Mas não importa, existem muitas soluções prontas para CMS. Você pode instalar um plugin ou um script separado no site que rastreará as alterações nos arquivos. Alguns CMS já implementam monitoramento eficaz de alterações e um mecanismo de verificação de integridade (por exemplo, Bitrix, DLE). Como último recurso, se a hospedagem tiver ssh, você pode criar um elenco de referência sistema de arquivo equipe

Promoção “2 pelo preço de 1”

A promoção é válida até o final do mês.

Ao ativar o serviço "Site sob vigilância" para um site, o segundo na mesma conta é conectado gratuitamente. Sites subsequentes na conta - 1.500 rublos por mês para cada site.