Le tout dégage un scénario "pas mon problème" qui n'est pas vraiment de votre faute et qui devrait / pourrait être résolu à 100% en prenant les mesures appropriées, quelle que soit la difficulté ou la difficulté, et cela met fin à votre ouvrir le serveur récursif .
Éliminer progressivement: informer les clients que ce serveur va disparaître à la date X. Passé ce délai, ils doivent installer un correctif (en supposant que vous en ayez un) pour l'empêcher d'utiliser votre serveur DNS. Cela se fait tout le temps. Administrateurs système, administrateurs réseau, gars du helpdesk, programmeurs? Nous l' obtenons ; cette chose en fin de vie se produit tout le temps, parce que sa procédure d'exploitation standard pour un fournisseur / fournisseur de services / partenaire nous dit d'arrêter d'utiliser quelque chose après la date X. Nous ne l'aimons pas toujours, mais c'est une réalité de l'informatique.
Vous dites que vous n'avez pas ce problème sur les appareils actuels, donc je suppose que vous avez résolu ce problème avec une mise à jour ou un patch du firmware. Je sais que vous avez dit que vous ne pouviez pas toucher l'appareil, mais ils le pouvaient sûrement? Je veux dire, s'ils permettent à ces boîtiers de vous téléphoner à la maison, ils ne peuvent pas vraiment être aussi anxieux sur qui fait quoi à leurs appareils; vous pouvez avoir une configuration de proxy inverse pour tout ce qu'ils savent, alors pourquoi ne pas leur faire installer un correctif qui corrige cela ou leur dire d'utiliser leurs propres serveurs DNS . Votre appareil prend sûrement en charge DHCP; Je ne peux pas penser à un périphérique réseau (peu importe son âge / sa fragilité / son étrange) qui ne fonctionne pas .
Si vous ne pouvez pas le faire, la prochaine chose à faire est de contrôler qui peut accéder à votre serveur récursif : vous dites qu'il est "difficile de dire" qui l'utilise et comment, mais il est temps de le vérifier et de commencer à supprimer le trafic qui est pas légitime.
Ce sont des organisations "quasi militaires / gouvernementales", non? Eh bien, ils font probablement partie d'un netblock légitime dont ils sont propriétaires; ces appareils ne sont pas des routeurs domestiques derrière des adresses IP dynamiques. Trouver. Contactez-les, expliquez le problème et comment vous leur faites économiser beaucoup d'argent en ne forçant pas le remplacement d'un micrologiciel ou d'un produit si seulement ils peuvent confirmer le netblock / l'adresse IP que l'appareil utilisera pour accéder à votre serveur DNS.
Cela se fait tout le temps: j'ai plusieurs clients qui limitent ainsi l'accès extranet ou les écouteurs HL7 aux partenaires de santé; ce n'est pas si difficilepour leur faire remplir un formulaire et fournir l'IP et / ou le netblock dont je devrais m'attendre à du trafic: s'ils veulent accéder à l'extranet, ils doivent me donner une IP ou un sous-réseau. Et c'est rarement une cible mouvante, donc ce n'est pas comme si vous alliez être inondé de centaines de demandes de changement IP tous les jours: les grands réseaux hospitaliers de campus qui possèdent leurs propres netblocks avec des centaines de sous-réseaux et des milliers et des milliers d'adresses IP hôtes me donnent régulièrement une poignée d'adresses IP ou un sous-réseau que je devrais attendre; encore une fois, ce ne sont pas des utilisateurs d'ordinateurs portables errant tout le temps sur le campus, alors pourquoi m'attendrais-je à voir des paquets source UDP à partir d'une adresse IP en constante évolution? De toute évidence, je fais une supposition ici, mais je parie que ce n'est pas autant que vous le pensez pour <100s d'appareils. Oui, ce sera une longue liste de contrôle d'accès, et oui,
Si, pour une raison quelconque, les canaux de communication ne sont pas ouverts (ou si quelqu'un a trop peur ou ne peut pas être dérangé pour contacter ces propriétaires d'appareils hérités et le faire correctement), vous devez établir une base de référence d'utilisation / d'activité normale afin de pouvoir formuler une autre stratégie qui aidera (mais n'empêchera pas) votre participation aux attaques d'amplification DNS.
Un tcpdump
filtrage de longue durée devrait fonctionner sur l'UDP 53 entrant et la journalisation détaillée sur l'application serveur DNS. Je voudrais également commencer à recueillir les adresses IP source / netblocks / informations geoip (sont tous vos clients aux États - Unis? Bloquer tout le reste) parce que, comme vous le dites, vous n'êtes pas d' ajouter de nouveaux appareils, vous êtes simplement laisser un héritage service aux installations existantes.
Cela vous aidera également à comprendre quels types d'enregistrement sont demandés et pour quels domaines, par qui et à quelle fréquence : pour que l'amplification DNS fonctionne comme prévu, l'attaquant doit pouvoir demander un type d'enregistrement volumineux (1) à un domaine fonctionnel (2).
"type d'enregistrement volumineux": vos appareils ont-ils même besoin d'enregistrements TXT ou SOA pour pouvoir être résolus par votre serveur DNS récursif? Vous pourrez peut-être spécifier les types d'enregistrement valides sur votre serveur DNS; Je pense que c'est possible avec BIND et peut-être Windows DNS, mais il faudrait creuser. Si votre serveur DNS répond avec SERVFAIL
des enregistrements TXT ou SOA, et au moins cette réponse est un ordre de grandeur (ou deux) inférieur à la charge utile prévue. De toute évidence, vous êtes toujours "partie du problème" parce que la victime usurpée obtiendrait toujours ces SERVFAIL
réponses de votre serveur, mais au moins vous ne les martelez pas et peut-être que votre serveur DNS est "radié" de la liste récoltée (s) les robots utilisent au fil du temps pour ne pas "coopérer".
"domaine fonctionnel": vous ne pourrez peut-être mettre en liste blanche que les domaines valides. Je le fais sur mes configurations de centre de données renforcées où les serveurs n'ont besoin que de Windows Update, Symantec, etc. pour fonctionner. Cependant, vous atténuez simplement les dommages que vous causez à ce stade: la victime serait toujours bombardée NXDOMAIN
ou les SERVFAIL
réponses de votre serveur parce que votre serveur répondrait toujours à l'IP source falsifiée. Encore une fois, le script Bot peut également mettre à jour automatiquement sa liste de serveurs ouverts en fonction des résultats, ce qui pourrait entraîner la suppression de votre serveur.
J'utiliserais également une certaine forme de limitation de débit, comme d'autres l'ont suggéré, soit au niveau de l'application (c'est-à-dire la taille des messages, les demandes par client) ou au niveau du pare-feu (voir les autres réponses), mais encore une fois, vous allez devez faire une analyse pour vous assurer que vous ne tuez pas le trafic légitime.
Un système de détection d'intrusion qui a été réglé et / ou formé (encore une fois, a besoin d'une base de référence ici) devrait également être en mesure de détecter un trafic anormal au fil du temps par source ou volume, mais nécessiterait probablement un babysitting / réglage / surveillance régulier pour éviter les faux positifs et / ou voyez si cela empêche réellement les attaques.
À la fin de la journée, vous devez vous demander si tous ces efforts en valent la peine ou si vous devez simplement insister pour que la bonne chose soit faite et cela élimine le problème en premier lieu.