Pourquoi les pirates attaqueraient-ils un serveur DNS avec un DoS ?
Je me réveille ce matin sur un serveur redémarré. Le serveur DNS fonctionnait à plus de 100 %. Après un peu de travail, j'ai mis en place fail2ban pour bloquer toutes ces demandes.
Les requêtes elles-mêmes sont valides, juste répétées des centaines de fois par seconde. Une fois que le bloc a obtenu plusieurs (centaines) d'adresses IP, je peux voir que je bloque 1 million de visites UDP toutes les quelques heures.
Est-ce juste une attaque [D]DoS ? (probablement considéré comme dynamique car de nombreux ordinateurs sont impliqués et une fois qu'un a été bloqué assez longtemps, il semble qu'il arrête les requêtes)
La seule autre possibilité à laquelle je peux penser est que l'attaquant essaie de planter le serveur DNS et d'y accéder lorsqu'il redémarre ou plante tout l'ordinateur et tente de se connecter à d'autres services. (c'est-à-dire au cas où vous ne sauriez pas comment mettre en place votre pare-feu avant de démarrer vos services)
Depuis la dernière réinitialisation de mon pare-feu, voici mes statistiques :
Accès : 2 346 742
Nombre d'adresses IP : 473
Ça va vite. Plusieurs centaines de coups par seconde. Le nombre d'adresses IP n'augmente pas beaucoup, cependant.
Réponses
D'après le commentaire de @Schroeder, j'ai effectué quelques recherches supplémentaires et j'en ai découvert beaucoup plus sur ce type d'attaque.
J'étais la cible !
Tout d'abord, il semble que je sois la cible de l'attaque. Pourquoi? Car l'attaque DNS Amplification signifie que le port source des requêtes DNS est fixé à 53. Cela permet de forcer mon DNS à envoyer une réponse non demandée à un autre serveur (voir graphique ci-dessous). Étant donné que moins de 0,1 % de ces accès utilisent ce port, je ne pense pas vraiment que mon DNS ait été utilisé pour l'amplification, mais plutôt que c'était la cible.
Comment fonctionne l'attaque ?
L'attaquant configure un ordinateur avec un logiciel envoyant des paquets UDP à certains serveurs DNS aléatoires demandant un nom de domaine. Le paquet semble normal à l'exception du fait que l'attaquant met l'adresse IP d'un autre ordinateur au lieu de son adresse IP comme source. Le résultat est que le DNS envoie la réponse au mauvais ordinateur :
10.0.0.1 10.0.0.2 10.0.0.3
+------------+ +------------+ +------------+
| | | | | |
| Attacker +-->| Some DNS +-->| Me |
| | | | | |
+------------+ +--+---------+ +------------+
| ^
v |
+---------+--+ This step is not required, it happens if
| | your DNS is setup to accept recursive
| Master DNS | requests (which is not a good idea)
| |
+------------+
10.0.0.4
Dans l'exemple ci-dessus, la demande de l'attaquant doit avoir 10.0.0.1 comme adresse d'origine UDP. Mais à la place, l'attaquant change son adresse IP avec 10.0.0.3. Par conséquent, lorsque le DNS à 10.0.0.2 reçoit le paquet UDP et est prêt à envoyer une réponse, il envoie les données à 10.0.0.3.
Le DNS maître du domaine sera utilisé si le DNS de 10.0.0.2 ne sait rien du nom de domaine interrogé.
REMARQUE IMPORTANTE : cela est vrai pour tous les services UDP. Le DNS est probablement le pire en termes d'amplification, mais le NTP, par exemple, peut également être ciblé.
Pourquoi ne pas simplement vérifier l'adresse source ?
Ce n'est pas possible à partir de 10.0.0.2 car UDP n'a aucun souvenir de la véritable source du paquet.
Ce qui est possible, c'est que les FAI vérifient que tous les paquets sortant d'un ordinateur donné ont l'adresse IP dudit ordinateur. Certains le font, je pense, mais la plupart ne le font probablement pas. Cela a un petit impact sur la vitesse... ce qui, bien sûr, avec une amplification DNS est à rire (l'amplification DNS a un effet bien pire sur Internet qu'une petite vérification des origines des paquets UDP).
L'autre chose peut être qu'un utilisateur peut toujours être en mesure de le faire en se connectant à Internet de manière à contourner la vérification du FAI. Je ne sais pas si et/ou comment cela serait possible, mais je ne serais pas surpris que cela puisse être fait.
En fait, c'est très problématique car l'origine de telles attaques est difficile à retracer et c'est certainement pourquoi elles se produisent encore en masse.
Pourquoi est-ce un DDoS ?
Le paquet pour demander un enregistrement DNS, ce qui se passe ici, est très petit, peut-être 300 octets. Ainsi, l'attaquant n'a qu'à envoyer un petit paquet UDP.
La réponse, cependant, peut être plusieurs kilo-octets de données. Plus précisément, un domaine est utilisé dans ces attaques :
peacecorps.gov
et ce domaine renvoie plus de 3 Ko de données ! (Il définit de nombreux champs 'TXT' qui sont utilisés dans cette attaque d'amplification.) C'est pourquoi on l'appelle Amplification Attack.
En conséquence, les requêtes de l'attaquant sont transformées en réponses environ 10 fois plus grandes et l'ordinateur attaqué (10.0.0.3) est submergé par un grand nombre de paquets UDP plutôt volumineux.
Ici, je montre l'entrée résultante dans iptables. Le premier nombre représente le nombre de hits sur mon ordinateur DNS après environ 40 minutes (donc plus de 10 000 hits par minute...) :
pkts bytes target prot opt in out source destination
61637 4376227 DROP udp -- eno1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 STRING match "|0a7065616365636f72707303676f76|" ALGO name bm TO 65535
Remarquez également comment la chaîne a été entièrement transformée en nombres hexadécimaux.
Une requête HTTP ne serait-elle pas encore pire ?!
HTTP 0.9/1.0/1.1/2 utilise TCP qui est un protocole bidirectionnel et aucune amplification ne peut être générée avec TCP. c'est-à-dire que TCP s'interrompt si vous ne vous êtes pas d'abord correctement connecté avec la poignée de main complète.
HTTP/3, cependant, introduit le protocole QUIC qui est HTTP sur des paquets UDP. Jusqu'à présent, je n'ai pas entendu parler de problèmes majeurs avec QUIC, mais le protocole a beaucoup changé au cours des 6-7 dernières années et il n'est pas encore largement mis en œuvre. Voici un article sur le fait que QUIC a intégré des fonctionnalités pour empêcher les attaques d'amplification, il y a donc de l'espoir qu'il a été pris en charge.
Certaines personnes parlent d'utiliser HTTP pour rechercher des noms de domaine. (DoH — Domaine sur HTTP). Espérons que cela ne serait pas implémenté à l'aide de QUIC ...
Comment puis-je résoudre le problème ?
L'amplification se produit parce que votre DNS est configuré pour accepter les demandes de noms de domaine que vous ne contrôlez pas (c'est-à-dire des domaines dont vous n'êtes pas le propriétaire).
BIND a une option qui lui permet de faire de l'amplification, appelée récursivité dans le jargon DNS. Cette fonctionnalité est maintenant désactivée par défaut, mais vous l'avez peut-être activée (par erreur ?).
Voici le mauvais réglage :
allow-recursion { any; };
Ce que vous voulez, c'est utiliser les bons paramètres :
trusted-servers { 192.0.2.4; } // list all your trusted servers
allow-recursion { trusted-servers; };
Cela obligera votre serveur à refuser automatiquement toutes ces demandes. Donc, si vous ne l'êtes pas peacecorps.govet que vous recevez une telle demande, BIND s'arrêtera là et écrira une note dans vos journaux DNS à propos de la demande refusée.
Puis-je bloquer l'adresse IP de ces requêtes ?
Oui. J'ai commencé par faire cela parce que mon serveur tournait bien à plus de 100% en temps CPU. Cependant, il n'est peut-être pas judicieux de le faire. Sur l'image ci-dessus, vous pouvez voir que votre serveur DNS se situe entre un attaquant et une victime. Si vous bloquez l'adresse IP source, ce n'est pas l'IP de l'attaquant que vous bloquez, c'est celle de la victime. Cela signifie que vous empêchez en fait la victime de voir vos noms de domaine et de faire des demandes légitimes. Ce n'est probablement pas ce que vous voulez !
Au début, j'ai généré un message de journal à partir de mon pare-feu. Si je devais détecter 5 requêtes ou plus au port 53 (UDP) à partir de la même adresse IP en peu de temps (5 secondes), alors je bloquerais l'adresse IP. Pour ce faire, j'ai utilisé fail2ban.
Premièrement, j'ai un filtre qui détecte les liens avec UDP et le port 53 comme destination :
# Filter: /etc/fail2ban/filter.d/named-fast-requests.conf
[Definition]
failregex = \sIN=[a-z0-9]+ .* SRC=<HOST> .* PROTO=UDP .* DPT=53\s
Deuxièmement, j'ai une jail qui donne les autres paramètres :
# Jail: /etc/fail2ban/jail.d/named-fast-requests.conf
[named-fast-requests]
enabled = true
filter = named-fast-requests
action = named-action[scheme=all,period=year,reason=named fast requests]
logpath = /var/log/iptables/iptables.log
maxretry = 5
findtime = 5
bantime = 1036800
Le point principal ici est le maxretryet findtimequi sont réglés à 5 fois en 5 secondes ou moins. Lorsque cela se produit, je bloque le <HOST>.
Vous voudrez mettre à jour l'action avec votre propre truc. J'utilise mon propre iplockoutil ici. La commande que j'utilise dans l'action :
actionban = /usr/sbin/iplock -s named -b <ip>
Par défaut, fail2ban utilise iptablesdirectement. Rechercher leurs actions pour voir comment c'est fait.
Ne soyez pas la source d'amplification
Vous devez bloquer les requêtes dont le port UDP source est inférieur à 1024. Celles-ci ne sont pas valides. Si vous proposez un serveur, le port 53 sera un port de destination et non une source.
iptables -I INPUT 123 -i eth0 -p udp -m udp --sport 0:1023 -j DROP
ATTENTION : remplacer la position (123) par le bon chiffre !
Cette règle indique que pour tout paquet UDP entrant sur eth0, dont le port source est compris entre 0 et 1023, supprimez le paquet. Cela empêche quelqu'un d'utiliser votre serveur DNS pour l'amplification. Cependant, cela ne protège pas votre propre serveur contre l'amplification des autres. Notez que même avec la allow-recursionconfiguration appropriée, vous n'empêcherez pas une attaque par amplification si l'attaquant sélectionne correctement l'un de vos noms de domaine pour l'attaque.
Remarque : si vous spécifiez un serveur de noms différent pour résoudre les noms de domaine sur votre ordinateur, vous souhaiterez peut-être ouvrir ces connexions avant de tout bloquer du port 0 à 1023. Cela ressemblerait à ceci :
iptables -I INPUT 123 -i eth0 -p udp -m udp --sport 53 -s 8.8.8.8 \
-d <your-static-ip> -j ACCEPT
Il s'agit des données renvoyées par le serveur de noms 8.8.8.8, que vous souhaitez probablement recevoir. Il est peu probable que votre fournisseur ou un autre serveur de noms officiel soit la source directe d'une attaque UDP. Si vous n'avez pas d'adresse IP statique, vous n'avez pas besoin d'inclure l' -doption.
Cependant, il est probablement préférable d'utiliser la ESTABLISHEDfonctionnalité qui est maintenant disponible pour les messages UDP (cela fait un moment maintenant, mais je me souviens d'une époque où ce n'était pas disponible...) :
iptables -I INPUT 123 -i eth0 -p udp -m state \
--state ESTABLISHED,RELATED -m udp -d <your-static-ip> -j ACCEPT
Cela signifie que vous accepterez automatiquement les réponses de votre fournisseur de serveur de noms de domaine puisque le pare-feu saura que vous avez envoyé une demande et que vous souhaitez accepter les réponses. Cette règle doit apparaître avant la DROPrègle ci-dessus.
Supprimer les demandes indésirables plus tôt
De toute évidence, le fait que BIND accepte toutes ces demandes peacecorps.govn'est pas quelque chose que tout le monde souhaite. Vous pouvez en fait les bloquer directement dans votre pare-feu. Cela fonctionne car les paquets UDP ne sont pas cryptés, le nom de domaine est donc visible.
Voici une règle que l'on peut utiliser pour bloquer ces demandes de nom de domaine :
sudo iptables -I INPUT 123 -i eno1 -p udp -m udp --dport 53 \
-m string --hex-string "|0A|peacecorps|03|gov|" --algo bm -j DROP
Évidemment, si votre DNS a un domaine ou un sous-domaine incluant "peacecorps.gov", il ne devrait pas utiliser cette iptablesrègle. Pour la plupart d'entre nous, même si cela devrait être rare.
L' --hex-stringoption vous permet de spécifier une chaîne. La façon dont il est défini dans le paquet UDP utilise une forme de chaîne P (taille + données). Comme "peacecorps" comporte 10 caractères, nous mettons 0x0A juste avant. Encore une fois, le "gov" est composé de trois lettres, nous utilisons donc 0x03. Si nous devions utiliser la chaîne "peacecorps.gov", cela ne fonctionnerait pas car la période ne correspondrait pas à l'octet 0x03. La première taille est cependant facultative (bien que vous correspondiez à tout ce qui ressemble à la même chose, comme "bestpeacecorps").
Avoir une telle règle permettra à votre service de nom de domaine d'économiser une tonne de trafic totalement indésirable.
Mise à jour : Bien que l'attaque se soit arrêtée environ deux semaines après que j'ai posté ma question, le problème "peacecorps.gov" se produit encore environ 10 fois par jour.
La source:https://defragged.org/2020/05/20/tips-and-tricks-blocking-dns-requests-via-iptables/
Débogage de votre DNS
Afin de voir quelle requête votre serveur DNS reçoit et répond, vous pouvez exécuter les commandes suivantes dans votre console :
sudo rndc querylog
Maintenant, regardez les journaux, généralement ici :
less /var/log/named.log
Regardez en bas (appuyez Gsur less) et vous devriez commencer à voir les requêtes provenant d'adresses IP distantes. Les journaux incluent le nom de domaine en cours de vérification. C'est très pratique, surtout si vous avez oublié d'entrer certains de vos propres noms de domaine dans votre DNS secondaire ou tertiaire.