Être inondé par wpad.dat

Donc, mon serveur apache était lent et j'ai regardé dans les fichiers journaux. Il s'est avéré qu'ils avaient atteint 12 Go d'accès à partir de tonnes et de tonnes d'hôtes différents essayant d'accéder à /wpad.dat sur l'un de mes Vhosts.

Désormais, l'hôte virtuel en question est le vhost «fourre-tout» qui est invoqué lorsqu'un navigateur ne fournit pas de nom d'hôte connu.

Je reçois actuellement des milliers de demandes par minute vers "/wpad.dat" et pour autant que Google puisse me le dire, est-ce quelque chose qui a quelque chose à voir avec les serveurs proxy? Mais je n'utilise pas de serveurs proxy, alors pourquoi suis-je littéralement bombardé par ces demandes.

Je reçois plus de demandes par minute pour ce fichier inexistant que je ne reçois de demandes normales. Donc, mon hypothèse est que je subis une certaine forme d'attaque. Ce qui est drôle, c'est que cela ne se produit généralement que la nuit (ici en Suède) et non le jour.

Un échantillon de la taille des 500 dernières demandes (soit une demi-minute) montre qu'il se compose de 200 hôtes différents, et un petit échantillon de ceux-ci montre qu'ils sont tous des hôtes valides (pas des proxys TOR), de sorte que certains serveurs DNS sont mal configurés ? J'exécute un serveur DNS sur la machine.

Aidez-moi! :)

MODIFIER L'hôte auquel ils accèdent est "cluster.atlascms.se", donc ce qu'ils font, c'est accéder à http://cluster.atlascms.se/wpad.dat des milliers de fois par minute.

Maintenant, cluster.atlascms.se est mon hôte de basculement DNS. Tous mes clients pointent donc leurs sous-domaines vers cluster.atlascms.se, qui à leur tour les pointe vers l'IP actuelle (serveur maître du serveur de basculement).

Comme il semble - cela signifie que je reçois des tonnes et des tonnes de demandes à cluster.arlascms.se - cela pourrait-il signifier que mon DNS est mal configuré?

Il semble que votre zone DNS eklundh.comait un enregistrement générique défini pointant vers cluster.atlascms.se. Cela inclut wpad.eklundh.com. Je vous suggère d'ajouter un enregistrement DNS définissant explicitement wpad.eklundh.com. à 127.0.0.1ou quelque chose.

Les machines rechercheront un fichier WPAD.dat de manière hiérarchique en fonction de leur propre nom de domaine complet, si elles sont configurées pour la découverte automatique du proxy. Donc, si un PC Windows est membre d'un domaine cdecom, il recherchera WPAD.dat dans:

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

Il y a des chances que quelque part, quelqu'un possède un domaine qui est un sous-domaine de l'un de ceux sur lesquels vous hébergez HTTP et qui n'a pas correctement configuré ou désactivé la détection automatique de proxy. En conséquence, ils recherchent probablement hiérarchiquement.

Il est possible qu'un virus leur ait causé cela; probablement, si les machines effectuant la requête sont extrêmement nombreuses et dans des sous-réseaux divers, c'est ce qui se passe.

Si possible, évitez de définir un enregistrement DNS pour le sous-domaine wpad de tout ce que vous n'avez pas l'intention d'utiliser pour la détection automatique de proxy.

Si ce n'est pas une option, vous pouvez envisager d'utiliser le filtrage de couche 7 pour rechercher des requêtes pour wpad.dat et rejeter les paquets avec un message ICMP. Cela pourrait en fait être le moyen le plus efficace d'arrêter le trafic, à moins que les IP ne proviennent toutes du même réseau et que leur contact technique en whois soit réactif.

Les éléments qui pointeront un hôte vers un emplacement particulier pour wpad.dat incluent les paramètres de domaine, l'option de nom de domaine dans les réponses DHCP et un paramètre explicite dans le navigateur Web pour charger les informations de proxy à partir d'une URL.

La première chose que je ferais serait d'essayer de savoir où vont ces demandes , c'est- à -dire leur destination. Apache n'enregistre pas le nom d'hôte par défaut, vous pouvez donc soit utiliser tcpdumppour obtenir une brève capture et l'inspecter pour l'en- Host:tête de la demande, soit modifier votre format de journal Apache pour l'enregistrer. Je préfère l'enregistrer dans le deuxième champ sinon inutile, par exemple:

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

Une fois que vous savez à qui ces demandes erronées sont adressées, que faire ensuite peut devenir clair. Par exemple, cela pourrait s'avérer être une grande entreprise, example.seauquel cas vous pouvez aller trouver leurs administrateurs réseau et leur crier dessus.

Juste pour info, ModSecurityva attraper cela et le bloquer. Il y a un ensemble de règles fourni par Comodo. Voici une entrée de journal. J'ai supprimé les données pertinentes du compte afin qu'elles soient dedans juste pour l'utiliser comme exemple.

Apache-Error: [fichier ""] [] [] [client xxx.xxx.xxx.xxx] ModSecurity: accès refusé avec le code 403 (phase 2). Expression correspondante ".dat /" à TX: extension. [fichier ""] ["] [id" 210730 "] [rév" 2 "] [msg" COMODO WAF: l'extension de fichier URL est limitée par la stratégie "] [données" .dat "] [gravité" CRITICAL "] [nom d'hôte "supprimé"] [uri "/wpad.dat"] [unique_id "WjFa06qDOW3DDPRieFmICgAAAEg"]

A eu ce problème et l'a corrigé en créant un fichier wpad.dat en y mettant la page "cette page laissée vierge".

Le CPU est passé à presque zéro. Le problème semble résolu.