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

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.

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.

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.

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.

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ê

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.

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.