Sendo inundado por wpad.dat

12

Portanto, meu servidor apache estava lento e procurei nos arquivos de log. Acontece que eles cresceram para 12 GB de acessos de toneladas e vários hosts diferentes tentando acessar /wpad.dat em um dos meus Vhosts.

Agora, o host virtual em questão é o vhost "catch-all" que é chamado quando um navegador não fornece um nome de host conhecido.

Atualmente, estou recebendo milhares de solicitações por minuto para "/wpad.dat" e, até onde o Google pode me dizer, isso é algo que tem algo a ver com servidores proxy? Mas eu não uso servidores proxy, então por que estou sendo literalmente bombardeado por esses pedidos?

Estou recebendo mais solicitações por minuto para esse arquivo inexistente do que as solicitações normais. Então, suponho que estou sob alguma forma de ataque. O engraçado é que geralmente ocorre apenas à noite (aqui na Suécia) e não durante o dia.

Um tamanho de amostra das 500 solicitações mais recentes (ou seja, meio minuto) mostra que ele consiste em 200 hosts diferentes e uma pequena amostra mostra que todos são hosts válidos (não proxies TOR). Portanto, alguns servidores DNS estão configurados incorretamente ? Eu executo um servidor DNS na máquina.

Por favor ajude! :)

EDIT O host que eles estão acessando é "cluster.atlascms.se", então o que eles fazem é acessar http://cluster.atlascms.se/wpad.dat milhares de vezes por minuto.

Agora, cluster.atlascms.se é meu host de failover de DNS. Portanto, todos os meus clientes apontam seus subdomínios para cluster.atlascms.se, que por sua vez os aponta para o IP atual (servidor principal do servidor de failover).

Como parece - isso significa que estou recebendo muitas e muitas solicitações para cluster.arlascms.se - isso pode significar que meu DNS está configurado incorretamente?

apache-2.2 domain-name-system wpad.dat

— Sandman
fonte

3

Você pode criar seu próprio arquivo WPAD.DAT e realmente se divertir com essas pessoas. > smile <Sério, no entanto, alguém configurou uma configuração horrivelmente em algum lugar se estiver obtendo um WPAD.DAT de uma fonte não confiável. Você redireciona todos os navegadores para um proxy que você controla e o tráfego para o MiTM.

— Evan Anderson

3

Eu seria fortemente tentado a colocar um wpad.datque simplesmente aponte o anfitrião local. Isso deve quebrar as coisas o suficiente, quem quer que esteja causando o problema pode levar tempo para corrigi-lo.

— Zoredache

1

@ Sandman - O arquivo WPAD.DAT precisa ser Javascript para funcionar. Dê uma olhada aqui: en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol

— Evan Anderson

1

Aliás, é extremamente rude você descobrir um problema e tentar jogar o lixo no gramado de outra pessoa. Portanto, não configure seu wpad para apontar para os sistemas de alguém.

— Zoredache

1

O problema com a configuração do DNS é que qualquer um de seus clientes que usa uma entrada dns curinga para apontar todos os seus subdomínios para cluster.atlascms.se, por padrão, estará apontando wpad.theirdomain.what lá também. O que significa que, se eles definirem o nome do host da área de trabalho como algo.theirdomain.whatever, ele procurará wpad.theirdomain.what, obtenha seu IP e solicite repetidamente wpad.dat milhares de vezes por dia.

— 23676 Justin Buser

9

Parece que sua zona DNS eklundh.compossui um registro curinga definido apontando para cluster.atlascms.se. Isso inclui wpad.eklundh.com. Sugiro que você adicione um registro DNS definindo explicitamente wpad.eklundh.com. para 127.0.0.1ou algo assim.

— Zoredache
fonte

7

Eu odeio registros DNS curinga. Eles nunca foram nada além de problemas.

— Evan Anderson

Ok, agora adicionei um subdomínio wpad a todos os meus domínios no meu DNS que apontam para 127.0.0.1 - Tenho que esperar para vê-lo se propagar e ver se isso resolve o problema.

— Sandman

Olhando nos meus arquivos de log, a grande maioria dos pedidos não são dirigidas a um subdomínio wpad, mas para o IP ou para cluster.atlascms.se ...

— Sandman

11

As máquinas procurarão um arquivo WPAD.dat hierarquicamente com base em seu próprio FQDN, se estiverem configuradas para a descoberta automática de proxy. Portanto, se um PC com Windows é membro de um domínio cdecom, procurará o WPAD.dat em:

http://wpad.c.d.e.com/wpad.dat
http://wpad.d.e.com/wpad.dat
http://wpad.e.com/wpad.dat
http://wpad/wpad.dat

Provavelmente, em algum lugar, alguém tem um domínio que é um subdomínio de um dos quais você está hospedando HTTP e não configurou ou desabilitou a descoberta automática de proxy corretamente. Em conseqüência, eles provavelmente estão pesquisando hierarquicamente.

É possível que um vírus os tenha causado; provavelmente, se as máquinas que fazem a consulta são extremamente numerosas e em diversas sub-redes, é isso que acontece.

Se possível, evite definir um registro DNS para o subdomínio wpad de qualquer coisa que você não pretenda usar para a descoberta automática de proxy.

Se isso não for uma opção, você pode considerar o uso da filtragem da camada 7 para encontrar consultas para wpad.dat e rejeitar os pacotes com uma mensagem ICMP. Essa pode ser a maneira mais eficaz de interromper o tráfego, a menos que os IPs sejam todos da mesma rede e seu contato técnico em quem é responsivo.

O que apontará um host em um local específico para o wpad.dat inclui configurações de domínio, a opção de nome de domínio nas respostas DHCP e uma configuração explícita no navegador da Web para carregar informações de proxy de algum URL.

— Falcon Momot
fonte

Não tenho um subdomínio wpad, mas tenho um subdomínio curinga. Acho que o culpado pode ser meu domínio atlascms.se (para o qual não preciso de um subdomínio curinga), que é o domínio que eu uso para meus clientes nos registros CNAME. Eu atualizei meu DNS e terei que esperar para ver se isso corrige as coisas.

— Sandman

O problema é que todas essas centenas de milhares de solicitações que recebo de centenas e centenas de hosts diferentes não poderiam estar pensando que o atlascms.se está em sua própria sub-rede, com certeza?

— Sandman

Não tem nada a ver com sub-redes; são todos os domínios.

— Falcon Momot

Sim, desculpe pela confusão terminológica.

— Sandman

É perfeitamente possível que alguém esteja tentando usar seu domínio para hospedar um wpad.dat malicioso (e com falha). Pode haver um vírus por aí definindo seu URL como o local para obter o wpad.dat explicitamente, ou apontar hosts para lá, ou pode haver uma rede mal configurada por aí.

— Falcon Momot

4

A primeira coisa que eu faria é tentar descobrir onde esses pedidos estão indo para , ou seja, o seu destino. O Apache não registra o nome do host por padrão, portanto, você pode usá tcpdump-lo para obter uma breve captura e inspecioná-lo quanto ao Host:cabeçalho da solicitação ou alterar o formato de log do Apache para registrá-lo. Prefiro registrá-lo no segundo campo inútil, por exemplo:

LogFormat "%h %{Host}i %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined

Depois de saber para quem essas solicitações equivocadas estão sendo endereçadas, o que fazer a seguir pode ficar claro. Por exemplo, pode ser uma grande empresa; example.senesse caso, você pode encontrar os administradores de rede e gritar com eles.

— Michael Hampton
fonte

usando o status do servidor, vejo o host que eles estão "atacando" e nem é um vhost configurado (e é por isso que é registrado pelo vhost catch-all) - o host ao qual todos estão se conectando é "atlas.eklundh. com "

— Sandman

Além disso, todas essas solicitações vêm de centenas e centenas de hosts diferentes de todo o país e de todo o espectro do ISP; isso não vem de uma fonte ou de uma empresa mal configurada. Eu estou querendo saber se eu estou fazendo algo de errado com meu domínio eklundh.com aqui, cujo servidor DNS Eu também executar na máquina

— Sandman

"atlas.eklundh.com" resolve para o mesmo IP que "sandman.net".

— Evan Anderson

1

Você realmente não precisa configurar os sistemas para procurar um wpad.dat. Você só precisa ter um registro DNS válido como wpad.eklundh.com(você possui esse registro) e computadores que possuem um FQDN definido como algo como * .eklundh.com` tentam automaticamente fazer a pesquisa no WPAD.

— Zoredache

1

O problema passa a ser que qualquer computador que pense estar no domínio eklundh.com verá que wpad.eklundh.com é válido e tentará baixar uma configuração de servidor proxy a partir dele. Você pode remover o registro DNS ou reconfigurar todos os computadores.

— Michael Hampton

0

Apenas para sua informação, ModSecurityvai pegar e bloquear. Existe um conjunto de regras fornecido pelo Comodo. Aqui está uma entrada de log. Retirei os dados relevantes da conta para que eles contenham apenas para usá-los como exemplo.

Erro no Apache: [arquivo ""] [] [] [cliente xxx.xxx.xxx.xxx] ModSecurity: acesso negado com o código 403 (fase 2). Frase correspondente ".dat /" em TX: extensão. [file ""] ["] [id" 210730 "] [rev" 2 "] [msg" COMODO WAF: a extensão do arquivo URL é restrita pela política "] [data" .dat "] [severity" CRITICAL "] [hostname "removed"] [uri "/wpad.dat"] [unique_id "WjFa06qDOW3DDPRieFmICgAAAEg"]

— Hospedagem na web islandnet.com
fonte

-1

Teve este problema e o corrigiu criando um arquivo wpad.dat, colocando a página "esta página deixada em branco".

CPU foi quase zero. Problema parece resolvido.

— Brian Tolman
fonte

uma resposta sintaticamente errada, mas um código de resposta de sucesso para um URI que você claramente NÃO pretende veicular está errado.

— Ans

Mas isso resolveu o sintoma. Nesse caso, reduziu a carga do servidor, entrou no site em execução novamente e me deu tempo para refazer os registros A onde o problema real residia.

— Brian Tolman