Como posso parar um ataque de bot no meu site?

14

Eu tenho um site (construído com wordpress) que está atualmente sob um ataque de bot (o melhor que posso dizer). Um arquivo está sendo solicitado repetidamente e o referenciador é (quase sempre) turkyoutube.org/player/player.swf. O arquivo que está sendo solicitado está dentro dos meus arquivos de tema e é sempre seguido por " ?v=" e uma string longa (ie r.php?v=Wby02FlVyms&title=izlesen.tk_Wby02FlVyms&toke).

Tentei definir uma regra .htaccess para esse referenciador, que parece funcionar, exceto que agora minha página 404 está sendo carregada repetidamente, o que ainda está usando muita largura de banda. Existe uma maneira de criar uma regra .htaccess que não exija uso de largura de banda da minha parte?

Eu também tentei criar um arquivo robots.txt, mas o ataque parece estar ignorando isso.

#This is the relevant part of the .htaccess file:
RewriteCond %{HTTP_REFERER} turkyoutube\.org [NC]
RewriteRule .* - [F]

htaccess botattack

— Travis Northcutt
fonte

2

O ataque vem sempre do mesmo IP?

— Ben Hoffman

Sua .htaccessregra está ativando intencionalmente o arquivo 404? Parece que lançar um erro de permissão simples negado seria menos uso de largura de banda.

— Artlung

Esta é a parte relevante do arquivo .htaccess: RewriteCond% {HTTP_REFERER} turkyoutube \ .org [NC] RewriteRule. * - [F]

— Travis Northcutt

No entanto, mesmo que meus logs de acesso mostrem "Código Http: 404", parece que meu uso de largura de banda parou quando fiz essa alteração .htaccess.

— Travis Northcutt

Você tem o .htaccesscódigo que postou antes ou depois das principais .htaccessregras do wordpress ?

— Artlung

8

Que tal uma pequena manobra de corbomita ?

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http(s)?://(www\.)?turkyoutube.org.*$ [NC]
RewriteRule ^(.*)$ http://127.0.0.1/$1 [R=401,L]

Observe que não foi testado , mas deve redirecionar solicitações deles de volta para si mesmos com um 401 Not Authorizedcódigo de status. Ou seja, se o bot manipular redirecionamentos (muito improvável), mas ainda verá o código de status. Um código de status 404 pode ser mais eficaz. Qualquer um deve dizer ao bot que provavelmente deve desistir.

A regra que você postou nos comentários também é mais que adequada se você ampliar a expressão para corresponder um pouco mais ao host. Eu uso algo próximo (na regra real) para bloquear a correspondência de agentes do usuário libwww-perl:

RewriteCond %{HTTP_USER_AGENT} libwww-perl.*
RewriteRule .* - [F,L]

— Tim Post
fonte

Você acha que muitos bots têm HTTP_USER_AGENT = libwww-perl? Parece que a maioria dos bots mentiria.

— Liam

@ Liam - surpreendentemente, uma porcentagem decente deles nunca tenta se disfarçar como um navegador real (embora certamente, mais do que não). Eu pensei que era estranho também :)

— Tim Post

Observe que você está usando muita regex muito lenta aqui. O .*$é equivalente a nada que é muito mais rápido. Também RewriteRule .* - [F,L]não é necessário, *pois você ignora a entrada de qualquer maneira.

— Alexis Wilke

2

Além do bloqueio de IP, eu examinaria os arquivos que estão sendo solicitados. É algo bastante comum que sistemas de código aberto, como WordPress e Joomla, sejam explorados, e esse é um dos motivos pelos quais eles são atualizados com frequência. Se você negligenciou algumas atualizações, é possível que alguém tenha penetrado no seu site.

Já tive esse cenário duas vezes, uma vez em um site de teste que nunca foi totalmente implantado (mas foi deixado no local) e outra em um site da empresa em que um funcionário com acesso válido "roubou" um phpBB para sua família comunicar - as atualizações teriam evitado os problemas. Nos dois casos, o problema foi encontrado na análise, pois parece ser verdade no seu caso. O ataque do Joomla injetou javascript que fazia com que o navegador do usuário carregasse o software, enquanto o último permitia que o hacker enviasse arquivos para o servidor que faziam parte de um site alternativo distribuído do Google, que levava o usuário a p * rn sempre. Embora não seja inteiramente um hack comum, verifique a tabela de usuários do banco de dados, apenas por precaução.

Certamente não pretendo causar alarme, mas nunca é demais gastar tempo para vasculhar seu site de vez em quando para saber exatamente o que está acontecendo. Às vezes, você ficará surpreso com o que encontra.

— bpeterson76
fonte

Eu acho que é exatamente isso que está acontecendo, na verdade. Parece que o arquivo solicitado não deveria estar lá. Felizmente, um colaborador amigável do núcleo do wordpress entrou em contato comigo, então eu sinto que vamos resolver isso.

— Travis Northcutt

1

Se o ataque vier do mesmo número de IP a cada vez (ou de um pequeno conjunto de números de IP), você deverá bloquear esse número de IP no firewall. Isso não deve custar largura de banda ou carga no seu servidor web.

Se você o estiver hospedando em uma máquina Linux com acesso root a este artigo, explica como fazer isso.

— Kris
fonte

Ele não vem do mesmo IP todas as vezes.

— Travis Northcutt

0

Eu uso DenyHosts [1] em todos os meus servidores. DenyHosts não permite todos os IPs que falharam no login após n vezes. Você também pode enviar notificações. Então você tem uma ótima visão geral de onde ips / hosts vieram; e também possui uma função de atualização da web e outros ótimos recursos. Mas ainda é muito simples de instalar.

Um outro método é proibir todas as faixas / blocos de IP (por exemplo) da China ou de outros países que não são o seu grupo-alvo. Isso pode ser feito com "Listas negras" on-line ou apenas com o arquivo hosts.deny (como DenyHosts).

[1] http://denyhosts.sourceforge.net/

— fwaechter
fonte

-1

Basta fazer o redirecionamento 301 para o site fbi.

RewriteEngine em RewriteCond% {HTTP_REFERER} ^ http (s)?: // (www.)? Turkyoutube.org. $ [NC] RewriteRule ^ (. ) $ Http://www.fbi.gov [R = 301, L]

— Bizzle quente
fonte