Ataque 404 maciço com URLs inexistentes. Como evitar isso?

14

O problema é uma carga total de erros 404, conforme relatado pelas Ferramentas do Google para webmasters, com páginas e consultas que nunca existiram. Uma delas é viewtopic.php, e também notei um número assustador de tentativas para verificar se o site é um site WordPress ( wp_admin) e para o login do cPanel. Eu já bloqueio o TRACE e o servidor está equipado com alguma defesa contra a verificação / invasão. No entanto, isso não parece parar. O referenciador é, de acordo com o Google Webmaster totally.me,.

Eu procurei uma solução para impedir isso, porque certamente não é bom para os usuários reais reais e pobres, muito menos para as preocupações de SEO.

Estou usando a mini lista negra da Perishable Press ( encontrada aqui ), um bloqueador de referência padrão (para sites pornográficos, de ervas, cassinos) e até mesmo algum software para proteger o site (bloqueio de XSS, injeção de SQL, etc.). O servidor também está usando outras medidas, portanto, seria de supor que o site é seguro (espero), mas não está terminando.

Alguém mais tem o mesmo problema ou eu sou o único vendo isso? É o que eu penso, ou seja, algum tipo de ataque? Existe uma maneira de corrigi-lo, ou melhor, impedir esse desperdício inútil de recursos?

EDIT Eu nunca usei a pergunta para agradecer pelas respostas, e espero que isso possa ser feito. Obrigado a todos por suas respostas perspicazes, o que me ajudou a encontrar o caminho para sair disso. Eu segui as sugestões de todos e implementei o seguinte:

  • um honeypot
  • um script que ouve suspeitas de URLs na página 404 e me envia um email com o user agent / ip, enquanto retorna um cabeçalho 404 padrão
  • um script que recompensa usuários legítimos, na mesma página personalizada 404, caso eles acabem clicando em um desses URLs. Em menos de 24 horas, consegui isolar alguns IPs suspeitos, todos listados no Spamhaus. Todos os IPs registrados até agora pertencem a empresas de hospedagem de spam VPS.

Obrigado a todos novamente, eu teria aceitado todas as respostas se pudesse.

tattvamasi
fonte
Quando as Ferramentas do Google para webmasters dizem que o referenciador é totalmente você, você quer dizer que elas indicam que as páginas do seu site são as páginas de referência?
Stephen Ostermiller
Desculpe meu erro. Eu tenho essas páginas que nunca existiram nas ferramentas para webmasters e o Google diz que não foram encontradas. Uma delas é mysite.com/viewtopic.php?forget_the_value=1 e está vinculada a totally.me. Eu até cliquei ... Não encontrei nada.
Tattvamasi
2
É comum obter muitos 404 em seus logs de acesso para páginas inexistentes, verificar vulnerabilidades (por exemplo, administrador do WP) etc. - você só precisa garantir que seu site esteja seguro. No entanto, para que estes sejam relatados pelo GWT, existem links para essas páginas ou havia um site anterior (como o WordPress) hospedado no seu domínio?
MrWhite
Não. O engraçado é que nunca usei o wordpress e nunca usei as páginas que vi como erros 404. Alguns erros que eu causei (URLs incorretos nos links de entrada, de uma página para outra), mas o arquivo viewtopic.php nunca esteve lá. Esse site tem sido durante anos agora ...
tattvamasi
Quando digo "links para essas páginas", quero dizer de outros sites . Para cada um dos seus erros 404 (no GWT), você deve fazer uma busca detalhada para mostrar de onde está "vinculado".
MrWhite

Respostas:

16

Muitas vezes, vejo outro site com links para várias páginas no meu site que não existem. Mesmo se você estiver clicando nessa página e não estiver vendo o link:

  • O site pode ter anteriormente esses links
  • O site pode estar ocultando e exibindo esses links apenas para o Googlebot e não para visitantes

É um desperdício de recursos, mas não confunde o Google e não prejudica seus rankings. Aqui está o que John Mueller do Google (que trabalha nas Ferramentas para webmasters e Sitemaps) tem a dizer sobre os erros 404 que aparecem nas ferramentas para webmasters :

SOCORRO! MEU SITE TEM 939 ERROS DE RASTEJAMENTO 1

Eu vejo esse tipo de pergunta várias vezes por semana; você não está sozinho - muitos sites têm erros de rastreamento.

  1. Os erros 404 em URLs inválidos não prejudicam a indexação ou a classificação do seu site . Não importa se existem 100 ou 10 milhões, eles não prejudicarão a classificação do seu site. http://googlewebmastercentral.blogspot.ch/2011/05/do-404s-hurt-my-site.html
  2. Em alguns casos, os erros de rastreamento podem resultar de um problema estrutural legítimo no seu site ou no CMS. Como você conta? Verifique novamente a origem do erro de rastreamento. Se houver um link quebrado no seu site, no HTML estático da sua página, vale sempre a pena corrigi-lo. (obrigado + Martino Mosna )
  3. E os URLs descolados que estão "claramente quebrados?" Quando nossos algoritmos gostam do seu site, eles podem tentar encontrar um conteúdo melhor, por exemplo, tentando descobrir novos URLs em JavaScript. Se tentarmos esses "URLs" e encontrarmos um 404, isso é ótimo e esperado. Só não queremos perder nada de importante (insira o meme excessivamente anexado do Googlebot aqui). http://support.google.com/webmasters/bin/answer.py?answer=1154698
  4. Você não precisa corrigir erros de rastreamento nas Ferramentas do Google para webmasters. O recurso "marcar como fixo" serve apenas para ajudá-lo, se você deseja acompanhar o seu progresso lá; ele não altera nada em nosso pipeline de pesquisa na web. Portanto, fique à vontade para ignorá-lo, se você não precisar. http://support.google.com/webmasters/bin/answer.py?answer=2467403
  5. Listamos os erros de rastreamento nas Ferramentas do Google para webmasters por prioridade, com base em vários fatores. Se a primeira página de erros de rastreamento for claramente irrelevante, provavelmente você não encontrará erros de rastreamento importantes em outras páginas. http://googlewebmastercentral.blogspot.ch/2012/03/crawl-errors-next-generation.html
  6. Não há necessidade de "corrigir" erros de rastreamento no seu site. Encontrar 404 é normal e esperado de um site saudável e bem configurado. Se você tiver um novo URL equivalente, o redirecionamento para ele é uma boa prática. Caso contrário, você não deve criar conteúdo falso, não deve redirecionar para a sua página inicial, o robots.txt não deve proibir esses URLs. Todas essas coisas dificultam o reconhecimento da estrutura do site e o processamento adequado. Chamamos esses erros de "soft 404". http://support.google.com/webmasters/bin/answer.py?answer=181708
  7. Obviamente - se esses erros de rastreamento estão aparecendo para os URLs de seu interesse, talvez URLs no arquivo do Sitemap, é algo que você deve tomar imediatamente. Se o Googlebot não conseguir rastrear seus URLs importantes, eles poderão ser excluídos dos nossos resultados de pesquisa e os usuários também não poderão acessá-los.
Stephen Ostermiller
fonte
obrigado, apesar de eu ter lido sobre alguém alegando que um ataque 404 influenciou negativamente seu page rank (discussão no fórum do webmaster do google, assim que eu o recuperar, postarei aqui), e alguns afirmam que erros 404 contam (Google não diz tudo, afirmam essas pessoas), então essa é uma das minhas preocupações, e a outra pergunta é quem está twittando em massa links errados para o meu site de propósito e por que, se não deveria fazer nada pelo SEO? Aceitou a resposta :)
tattvamasi
totally.me é um site real. Existem muitos milhares de sites de lixo que rastreiam e postam links para atrair usuários. É uma forma de spamdexing. Às vezes, esses links existem apenas por um curto período de tempo. Principalmente, isso é feito para influenciar os mecanismos de pesquisa menores e menos sofisticados, com um público regional mais comum na Rússia e na Polônia, embora existam muitos outros. Links como esses geralmente vêm de bancos de dados passados ​​de esforços de raspagem anteriores, para que ressurgam links antigos e novos sites surjam periodicamente. Não há nada que você possa fazer sobre isso.
Closetnoc 21/05
2
Um "ataque 404" definitivamente NÃO afetará o pagerank do seu site, nem a classificação do mesmo. (Se seus concorrentes estão gastando tempo vinculando a páginas que 404, isso significa menos tempo para fazer algo útil, então seja feliz :).) Os sites deveriam ter 404s, é um sinal de que você configurou o servidor corretamente , por isso, seria um bom sinal para nós.
John Mueller
5

Existem muitos scripts por aí que otimizam digitalmente endereços IP aleatórios na Internet para encontrar vulnerabilidades conhecidas em vários tipos de software. Em 99,99% do tempo, eles não encontram nada (como no seu site) e, em 0,01% do tempo, o script faz o pwn da máquina e faz o que o controlador de script desejar. Normalmente, esses scripts são executados por redes de bots anônimas de máquinas que foram anteriormente pwnd, não da máquina real do kiddie de script original.

O que você deveria fazer?

  1. Verifique se o seu site não está vulnerável. Isso requer vigilância constante.
  2. Se isso gerar tanta carga que o desempenho normal do site seja afetado, adicione uma regra de bloqueio com base em IP para evitar a aceitação de conexões do site específico.
  3. Aprenda a filtrar as varreduras do CMD.EXE ou cPanel ou phpMyAdmin ou de várias outras vulnerabilidades ao examinar os logs do servidor.

Você parece acreditar que qualquer 404 retornado do seu servidor para qualquer pessoa afetará o que o Google pensa sobre o seu site. Isso não é verdade. Somente 404s retornados pelos rastreadores do Google, e talvez usuários do Chrome, afetarão seu site. Enquanto todos os links do seu site forem adequados, e você não invalidar os links que você já havia exposto anteriormente ao mundo, não sofrerá nenhum impacto. Os robôs de script não falam com o Google de forma alguma.

Se você for atacado de maneira real, precisará se inscrever em algum tipo de serviço de provedor de mitigação de DoS. Verisign, Neustar, CloudFlare e Prolexic são todos os fornecedores que têm vários tipos de planos para vários tipos de ataques - desde o simples proxy da Web (que pode até estar livre de alguns fornecedores) até o DNS com base na demanda, até o BGP completo oscilações baseadas no ponto de presença que enviam todo o seu tráfego através da "limpeza" de data centers com regras que atenuam ataques.

Mas, pelo que você está dizendo, parece que você está apenas vendo os scripts de vulnerabilidade normais que qualquer IP na Internet verá se está escutando na porta 80. Você pode literalmente montar uma nova máquina, iniciar um Apache vazio, e dentro de algumas horas, você começará a ver essas linhas no log de acesso.

Jon Watte
fonte
muito obrigado - vou procurar alguns filtros extras, embora as proteções do servidor e do site sejam tão altas que às vezes um usuário legítimo acabe na página proibida. Em resposta a "Apenas 404s retornados por rastreadores do Google e talvez usuários do Chrome", devo acrescentar que encontrei esses links nas Ferramentas do Google para webmasters, então acho que posso assumir com segurança que eles estão sendo rastreados ...
tattvamasi
Você precisa descobrir por que o Google acessa essas páginas inexistentes. Por exemplo, se você permitir que terceiros participem de seus registros de acesso, seria uma maneira de o Google acessá-los. Você não deve deixar terceiros entrar neles. Além disso, a segurança é muito mais uma correção bem aplicada, do que uma "proteção" heurística que você adiciona do lado de fora. Eu vejo "plugins de segurança" de terceiros com ceticismo. Quando o site faz exatamente o que eu quero, e somente isso, é (por definição) seguro.
Jon Watte
3

Provavelmente, isso não é realmente um ataque, mas uma verificação ou investigação.

Dependendo do scanner / prober, pode ser benigno, o que significa que está apenas procurando problemas em algum tipo de capacidade de pesquisa ou pode ter uma função de atacar automaticamente se encontrar uma abertura.

Os navegadores da Web colocam informações válidas sobre o referenciador, mas outros programas podem apenas criar o referenciador que quiserem.

O referenciador é simplesmente uma informação que é opcionalmente fornecida pelos programas que acessam seu site. Pode ser qualquer coisa que eles escolham para configurá-lo como totally.meou random.yu. Pode até ser um site real que eles acabaram de selecionar.

Você realmente não pode consertar ou impedir isso. Se você tentou bloquear todas as solicitações desse tipo, acaba tendo que manter uma lista muito grande e não vale a pena.

Desde que o seu host acompanhe as correções e evite as vulnerabilidades, isso não deve causar nenhum problema real.

Grax32
fonte
1
Se 404 aparecer no Google WMT, é de um link real em algum lugar. totally.me é um site real.
Closetnoc 21/05
yes totally.me é um site real, e alguns links errados vindos de lá foram minha culpa (erros de digitação no botão do tweet). Agora, existe essa massa com um link para uma página viewtopic.php /? Qualquer que seja, no meu site, que eu juro nunca tenha estado lá. Posso até identificar o usuário que twittou isso (agora não há nada nessa página, mas presumo que havia muito). As tags de tendência também tinham um URL deliberadamente errado. O que me preocupa é a experiência do usuário, o uso de recursos e o fato de o Google rastrear os 404 falsos. Por outro lado, não posso banir o mundo inteiro por uma página não encontrada. Não tenho certeza do que fazer.
Tattvamasi 23/05
3

Na verdade, parece frenesi de bot. Também fomos atingidos por milhares de IPs em muitos hosts, provavelmente sem o conhecimento do site OP. Antes de oferecer algumas soluções úteis, uma pergunta que tenho é:

P: Como você vê 404 do seu site como um todo nas ferramentas para webmasters do Google? GWT é o resultado das descobertas do Googlebots, não o resultado de outros bots. Além disso, esses outros bots não executam JS para análise ... você tem alguma coisa de API indo para o GWT, onde você pode ver as estatísticas do servidor? Caso contrário, pode ser motivo de alarme, pois é o próprio googlebot que encontra erros.

  • Se isso é APENAS erros do googlebot, isso pode indicar que alguém plantou links para o seu site em fóruns e itens para alvos de bots maliciosos de PC humano-real atingindo-o. Pense no harverstor + plantador em execução em algum servidor explorado, configurando uma tonelada de destinos para futuros "contratos de spam" a serem portalados.

  • Se você realmente sabe que está relatando suas estatísticas completas do servidor, precisará de algumas ferramentas. Alguns aplicativos e serviços podem ajudá-lo a reduzi-lo. Supondo que você esteja executando um servidor Linux:

1) Comece adicionando IPs ofensivos a uma lista negra de htaccess. Parece "negar de 192.168.1.1" e 403 será proibido. Não se empolgue, apenas bloqueie os biggens. Verifique-os nos sites na etapa 4) para garantir que eles não sejam provedores de serviços de Internet reais. Você pode copiar esse arquivo e colá-lo em qualquer conta / aplicativo além do firewall.

2) Instale o APF. é muito fácil gerenciar o firewall via SSH no linux. À medida que você constrói o ht, adicione-os no APF como "apf -d 192.168.1.1". Ht parece redundante por causa do APF, mas é portátil.

3) Instale o cPanel Hulk e certifique-se de colocar os seus IP na lista de permissões, para que nunca bloqueie você se você esquecer um passe. Essa também será uma boa fonte de IP para adicionar ao ht + apf. Ele tem alguns pontos inteligentes para mitigar de forma inteligente as tentativas de login de força bruta.

4) Conecte-se com stopforumspam.com e projecthoneypot.org e instale seus módulos. Ambos ajudam muito a negar solicitações conhecidas e a identificar + relatar novos brutes / redes / chinaspam. Você também pode usar filtros de e-mail, mas o Gmail é o proprietário quando se trata de filtro de spam.

5) Como os bots nunca param, proteja seus caminhos de administrador. Se você executar o wordpress, altere o caminho do administrador, adicione captcha, etc. Se você usa o SSH, altere a porta de login para algo não utilizado e, em seguida, desative o login raiz do SSH. Crie um "radmin" no qual você deve fazer login primeiro e depois su para root.

  • Uma observação sobre o captcha, se você executar o seu próprio captcha em um site de alto volume e não negar o frenesi do bot no nível do firewall / ht, eles podem estar martelando seus ciclos de CPU devido à geração de imagens em todos os widgets "antispam".

  • Uma observação sobre o carregamento, se você executar o CentOS no seu servidor e tiver habilidades de VPS, o CloudLinux é fantástico para proteger e controlar a carga. Digamos que um bot passe, o CageFS está lá para limitá-lo a uma conta. Digamos que eles decidam fazer DDoS .... O LVE existe para manter a carga da conta (site) limitada para não travar o servidor. É um bom complemento para acentuar todo o sistema de "gerenciamento incorreto de entidades" :)

Apenas alguns pensamentos, espero que ajude você

dhaupin
fonte
obrigado. O fato de eu ver esses erros no Google Webmasters me faz pensar - como você indica corretamente - que existe algum tipo de técnica "NSEO" (plantar centenas de links para o meu site que nunca estiveram lá). O site é seguro, porque esses tipos de ataques não fazem nada. Não tenho certeza se sou seguro quanto à experiência de SEO / usuário (se o google começar a indexar páginas inexistentes, estou com problemas. Os erros já fizeram o site cair no ranking, aliás). Obrigado novamente.
Tattvamasi 23/05
1
O Gbot não indexa 404 páginas, por isso realmente não afeta seu SEO. Pode armazenar em cache as outras páginas que enviam tráfego, mas não as suas. Se isso se tornar um problema para humanos reais, faça um redirecionador enorme para os links de beliches, como wp-admin, faça com que todos tenham uma boa redação para os humanos sobre por que eles podem estar vendo esta página. Dê a eles um "sinto muito pelo cupom 404" se você estiver interessado. Lembre-se de marcar todos eles como corrigidos no GWT para indexar + armazenar em cache seu novo lander. Opcionalmente, coloque um buraco negro para os badbots nele. Independentemente disso, esteja preparado para acessos diretos se este spamnet tiver links para você por aí.
Dhaupin
obrigado. Por enquanto, estou tentando ver se um 404 suave em caso de erros gerados atenua um pouco a bagunça. A página 404 já é personalizada e fornecerá links relacionados úteis (se possível). No caso de erros de ortografia por mim, estou lançando um redirecionamento 301 para a página correta (o Google os vê como soft 404, acho). No caso de esse lixo /RK=0/RS=YkUQ9t4mR3PP_qt7IW8Y2L36PFo-/, /blog/wp-login.php/, /user/create_form/, /m/, /RK=0/RS=lznPhspsSDFHMiuIUDmmo01LA7w-/(etc ...) Eu estou registrando o usuário e retornando 404. Espero que eu estou fazendo a coisa certa
tattvamasi
1

Explicação do problema

Antes de tudo, você não é o único com esse problema - todo mundo é. O que você viu é o resultado de robôs automatizados rastreando todos os IPs e procurando vulnerabilidades comuns. Então eles basicamente tentam descobrir o que você está usando e, se você usa o phpmyadmin, eles tentam mais tarde várias combinações padrão de senha de nome de usuário.

Estou surpreso que esse tipo de coisa que você encontrou agora (você pode ter acabado de iniciar seu servidor). O problema é que você não pode bloquear o endereço IP para sempre (provavelmente esse computador está infectado e o usuário real não sabe o que está fazendo, também existem muitos IPs).

Efeito SEO

Não tem nenhum efeito. Significa apenas que alguém tentou acessar algo no seu computador e não estava lá

Isso realmente importa?

Claro, essas pessoas tentam investigar você quanto a alguns problemas. Além disso, eles estão desperdiçando seus recursos (seu servidor precisa reagir de alguma forma) e poluindo seu arquivo de log

Como devo corrigi-lo

Eu tive o mesmo problema que tentei corrigir e a melhor ferramenta (simplicidade de uso versus o que posso fazer com ele) que consegui encontrar é fail2ban

Você também tem sorte, porque eu já encontrei uma maneira de corrigir o mesmo problema e até o documentei aqui (para que você não precise descobrir como instalá-lo e como fazê-lo funcionar). Verifique minha pergunta no ServerFault . Mas leia um pouco sobre o fail2ban para saber como ele está funcionando.

Salvador Dalí
fonte
1

Como muitos já disseram, isso não é um ataque, mas uma tentativa de analisar ou verificar o aplicativo do site e / ou os recursos do servidor. A melhor maneira de filtrar todo esse tráfego inútil e verificações potencialmente perigosas é implementar um WAF (Web Application Firewall). Isso capturará todas as tentativas diferentes e as sinalizará e só então enviará o tráfego limpo legítimo real para seus servidores e aplicativos da web.

Você pode usar DNS WAF baseado em nuvem ou dispositivos dedicados. Eu pessoalmente uso Incapsula e F5 ASM para diferentes sites de clientes. Os custos são tão baixos quanto $ 500 por mês e ajudam tremendamente. Também oferece melhor proteção aos seus clientes e diminui os recursos nos próprios servidores da Web, o que poupa dinheiro e aumenta a velocidade, além de oferecer dispositivos de conformidade com o PCI 6.6 e revisar relatórios.

Espero que isto ajude.

Tony-Caffe
fonte
Se isso foi simplesmente uma "tentativa de sondar", como você explica o fato de que esses 404s foram aparentemente relatados no GWT?
precisa saber é o seguinte