Serveurs DNS récursifs publics - règles iptables

Nous exécutons des serveurs DNS récursifs accessibles au public sur des machines Linux. Nous avons été utilisés pour des attaques d'amplification DNS. Existe-t-il des iptablesrègles recommandées qui permettraient d'atténuer ces attaques?

La solution évidente consiste simplement à limiter les paquets DNS sortants à un certain niveau de trafic. Mais j'espérais trouver quelque chose d'un peu plus intelligent pour qu'une attaque bloque simplement le trafic vers l'adresse IP de la victime.

J'ai cherché des conseils et des suggestions, mais ils semblent tous être "ne pas exécuter de serveurs de noms récursifs accessibles au public". Malheureusement, nous sommes plongés dans une situation où des choses qui ne sont pas faciles à changer se briseront si nous ne le faisons pas, et cela est dû à des décisions prises il y a plus de dix ans avant que ces attaques ne soient un problème.

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 tcpdumpfiltrage 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).

1. "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 SERVFAILdes 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 SERVFAILré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".

2. "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 NXDOMAINou les SERVFAILré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.

Cela dépend du type de limitation de débit que vous souhaitez effectuer.

La limitation de débit avec iptablesest vraiment plus destinée à limiter les paquets entrants, car les paquets jusqu'à la limite correspondront au filtre et auront la cible spécifiée appliquée (par exemple, ACCEPT). Vous auriez probablement une cible ultérieure pour les DROPpaquets qui ne correspondent pas au filtre. Et bien qu'il iptablesait une QUEUEcible, il passe simplement le paquet à l'espace utilisateur où vous devez fournir votre propre application de mise en file d'attente. Vous pouvez également limiter le nombre de paquets sortants, mais peu de gens veulent vraiment commencer à supprimer le trafic sortant.

iptables baisse de la limite de taux:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

Utiliser hashlimitplutôt que limitvous donnera une limitation de débit par IP de destination. C'est-à-dire que cinq paquets à 8.8.8.8 qui atteignent la limite empêcheront les paquets d'être envoyés à 8.8.4.4 tandis qu'avec hashlimitsi 8.8.8.8 est au maximum, vous pouvez toujours atteindre 8.8.4.4, ce qui ressemble plus à ce que vous voulez.

Si vous ne voulez pas que les paquets dépassant la limite soient supprimés, alors ce que vous voulez vraiment, c'est tc. tcva réguler le débit pour obtenir un joli flux régulier plutôt que beaucoup de trafic éclatant. Sur le côté entrant, les paquets sont livrés à l'application plus lentement mais arriveront tous dans l'ordre. Sur les paquets sortants laissera votre application aussi vite que possible mais placée sur le fil dans un flux cohérent.

Je n'ai pas tcbeaucoup utilisé , mais voici un exemple de limitation de débit ICMP que vous pouvez probablement adapter facilement pour DNS.

Voici une chose que vous pouvez faire pour atténuer potentiellement les réponses aux requêtes usurpées, mais cela demande du travail:

Tout d'abord, consultez votre journal du canal de sécurité et recherchez une adresse IP qui est usurpée.

Exécutez ensuite un tcpdump en utilisant cette IP source (10.11.12.13) comme ceci:

tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S

Vous obtiendrez quelque chose comme ceci:

18: 37: 25.969485 IP (tos 0x0, ttl 52, id 46403, offset 0, drapeaux [aucun], proto: UDP (17), longueur: 45) 10.11.12.13.51169> 01.02.03.04.domaine: 4215+ ANY ? . (17)
        0x0000: 4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-. C..4 .......
        0x0010: 0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... w ..
        0x0020: 0001 0000 0000 0000 0000 ff00 0100 ..............

Maintenant, la partie amusante! Ouvrez rfc1035 sur http://tools.ietf.org/html/rfc1035 et passez à la section 4.1.1.

Il est temps de traduire les résultats de tcpdump et de trouver un modèle que nous pouvons utiliser pour créer un filtre au niveau des paquets.

L'ID de l'en-tête commence à 0x1C, nous avons donc quelques drapeaux à 0x1E, le QDCOUNT à 0x20, l'ANCOUNT à 0x22, le NSCOUNT à 0x24 et l'ARCOUNT à 0x26.

Cela laisse la question réelle à 0x28, qui dans ce cas est nulle (ROOT) pour le NOM, 0xFF pour QTYPE = ANY et 0x01 pour QCLASS = IN.

Pour faire une histoire assez longue, j'ai trouvé que l'ajout des règles iptables suivantes bloque plus de 95% des requêtes usurpées qui demandent TOUT enregistrement DANS ROOT:

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

Votre kilométrage peut varier ... j'espère que cela vous aidera.

Utilisation tcet mise en file d'attente des disciplines sous Linux pour le port sortant 53 UDP:

IFACE=eth0    
tc qdisc  add dev ${IFACE} root handle 1: htb default 0
tc class  add dev ${IFACE} parent 1: classid 1:1 htb rate   10mbit burst 20m
tc qdisc  add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

Vous configurera avec un nombre disclimité à 10 Mo pour tout paquet avec la marque de pare-feu «1». Les marquages ​​du pare-feu sont uniquement internes au pare-feu et ne modifient pas le paquet. Juste la manipulation du paquet par la discipline de file d'attente. Voici comment vous utilisez iptablespour créer les marquages ​​du pare-feu:

iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1

Modifiez à votre convenance pour exclure les sous-réseaux et / ou destinations de confiance. La -o eth0limite la mise en forme aux paquets sortants uniquement. J'espère que cela t'aides.

J'essaierais de composer une liste de tous les clients qui dépendent de vos résolveurs récursifs orientés vers l'extérieur. Commencez par un jour ou deux de traces de paquets sur les boîtes DNS. À partir de là, commencez à créer des règles iptables pour autoriser le trafic que vous reconnaissez et autorisez. La valeur par défaut sera éventuellement de réduire le trafic à 53 / tcp et 53 / udp. Si cela casse quelque chose, affinez vos règles.

selon la «position» du réseau dans laquelle vous vous trouvez [ayant plusieurs flux bgp ou étant à la «fin» d'Internet - en tant que réseau de stub], vous pouvez essayer quelque chose comme uRPF pour empêcher l'usurpation d'adresse source.

autre source d'information.

Ces appareils sont-ils toujours sous contrat de support? Si c'est le cas, contactez vos clients. Faites-leur savoir qu'Internet a un peu évolué au cours de la dernière décennie et afin de continuer à fournir une résolution de noms pour ces appareils, vous devrez connaître l'adresse IP du SRC pour recevoir des requêtes. Fixez une date ~ 6 mois dans le futur à laquelle vous ne pourrez plus servir des clients inconnus et respectez-la. Ceci est assez courant dans l'industrie. Si ces appareils ne sont plus sous contrat de support ... cela ressemble à une décision commerciale. Combien de temps votre entreprise a-t-elle l'intention de consacrer des ressources à des produits anciens qui ne génèrent plus de revenus?

Ils ressemblent à des appareils spécialisés, sont-ils si spécialisés que vous pouvez raisonnablement prédire pour quels domaines s'attendre à des requêtes légitimes? bind prend en charge les vues, créez une vue publique qui ne fait que la récursivité pour ces domaines.

Utilisez-le comme une opportunité d'apprentissage, si vous ne l'avez pas déjà fait, arrêtez de publier des produits où vous n'avez pas la possibilité de corriger les bugs. C'est ça, un bug. Celui qui assurera certainement la fin de cet appareil prématurément, tôt ou tard.

De nanog quelque part, ceci:

iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP 

Ce n'est pas l'idéal. Il pourrait être préférable d'autoriser moins de paquets par seconde et d'avoir une rafale plus élevée.

Voici une solution que j'ai utilisée plusieurs fois contre les attaques DDOS, elle n'est pas parfaite mais m'a aidé. La solution consiste en un script qui est appelé toutes les N minutes (comme 1,2,3 etc. minutes) par le cron et bloque les IP qui créent un nombre de connexions plus grand que celui donné dans le script:

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp