Arquivo de log do Apache - URL de referência que não existe

Question

Depois de ter meu servidor linux de host compartilhado hackeado (~ 25 instalações do WordPress, código mal-intencionado), comecei a procurar nos meus arquivos de log de acesso para ver de onde meu tráfego está vindo (esperava diminuir o ponto de entrada, com sorte mínima).

Eu continuo vendo entradas onde posso verificar se o referenciador não existe. Por exemplo:

103.47.135.111 - - [19/Apr/2016:01:14:53 -0600] "GET /wp-content/themes/wallstreet/style.css?ver=4.5 HTTP/1.1" 200 12562 "http://my_domain.com/yqmmfkv/Cara-pdkt-sama-cewek-lewat-hp.htm" "Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53"

O referenciador ( link ) não existe do que eu posso contar. Ele retorna um erro 404, não há menção dele usando grep -r "yqmmfkv" e parece não existir no meu banco de dados do WP. O arquivo style.css existe, então vejo por que ele está retornando 200, mas como uma página que não existe pode estar solicitando isso?

Além disso, qual é o ganho falsificando o referenciador?

    

Answer 1

Parece que fomos atingidos pelo mesmo tipo de vírus. Se você usasse um plugin de remoção de anti-malware, ele teria deletado o diretório / yqmmfkv onde o vírus instalou um monte de conteúdo (pornografia, links, imagens, vídeos, arquivos de áudio etc) também criou um monte de arquivos html com código registrou seu domínio em um site externo, bem como alguns outros códigos maliciosos base64 codificados e, no meu caso, um horrível arquivo support.php.

A verificação do IP do originador, no link , informa que a solicitação está sendo feita em algum lugar da Indonésia - se isso não for você (eu suspeito que não) significa apenas que eles estão falsificando o http_referer no cabeçalho http.

Originalmente, quando o vírus estava presente no seu servidor, ele provavelmente armazenava algumas informações, incluindo o caminho para o seu style.css remotamente - daí o 200 e o está usando para 'pingar' testar seu site ou pode ter instalado algum malware código dentro desses arquivos anteriormente.

O que eu fiz foi simplesmente detectar o padrão de arquivo na solicitação e proibir o acesso a ele por meio do arquivo .htaccess:

RewriteCond %{HTTP_REFERER} .*yqmmfkv [NC] #checks for requests containing that path
RewriteRule .* - [F]

Isso interromperá as 200 entradas nos seus registros e bloqueará corretamente as solicitações com um 403 proibido. Espero que o invasor acabe não perdendo sua largura de banda nos pedidos bloqueados - para mim, demorou um dia até que os pedidos parassem. Ele também ajudará você a ser rebaixado pelo google SEO - embora eles possam ser inteligentes o bastante para reconhecer esses tipos de ataques já.

Vale a pena olhar para desviar o tráfego de volta para o criador - não é tão aplicável quanto eles estão falsificando seu próprio domínio. E bloqueio de solicitações de IPs específicos na lista negra - aqui está um ótimo artigo: link

Nenhum dos últimos é infalível, pois os IPs podem ser facilmente alterados.

Por que falsificar o referenciador? Provavelmente para contornar problemas de permissão de pasta. Quando o vírus foi instalado, ele provavelmente mudou o acesso aos arquivos e pastas do seu site para o 775, o que permite o tráfego do seu grupo da web do apache (por exemplo, www-data).

Você não deve correr riscos imediatos, mas parece que você foi adicionado a uma lista em algum lugar que vai continuar enviando solicitações até que você fique entediado ou desligado.