Gérer les attaques par réflexion NTP dans IPTables

Nous avons affaire à une attaque de réflexion / amplification NTP sur nos serveurs colocalisés. Cette question est spécifique à la réponse aux attaques par réflexion NTP, et ne s'adresse pas aux DDoS en général.

Voici le trafic:

Il s'agit d'un peu de CPU sur notre routeur:

Malheureusement, il n'est pas assez grand pour que notre fournisseur en amont fasse un trou noir du trafic, ce qui signifie qu'il nous parvient.

Nous avons utilisé la règle suivante pour bloquer le trafic NTP, qui provient du port 123:

-p udp --sport 123 -j DROP

Il s'agit de la première règle dans IPTables.

J'ai beaucoup cherché et je ne trouve pas beaucoup d'informations sur la façon d'utiliser IPTables pour atténuer une attaque par réflexion NTP. Et certaines informations là-bas semblent carrément incorrectes. Cette règle IPTables est-elle correcte? Y a-t-il autre chose que nous pouvons ajouter ou faire pour atténuer une attaque de réflexion / amplification NTP autre que de contacter notre fournisseur de réseau en amont?

Aussi: puisque ces attaquants doivent utiliser des réseaux qui

• permettre l'usurpation d'adresse IP dans les paquets
• ont un code NTP non corrigé vers 2010

existe-t-il un centre d'échange mondial auquel nous pouvons signaler ces adresses IP, afin qu'elles soient corrigées pour cesser d'autoriser les paquets falsifiés et corriger leurs serveurs NTP?

Essentiellement, vous avez de la chance si l'attaque DDoS parvient à remplir le canal que vous avez vers Internet (ce qui est le but de toute attaque de réflexion UDP - pour remplir le canal). Si votre lien en amont peut prendre 1 Gbit / s de trafic et qu'il y a (disons) 2 Gbit / s de trafic total pour descendre le lien, alors la moitié de celui-ci sera abandonnée par le routeur ou le commutateur qui met les paquets sur le lien. L'attaquant ne se soucie pas que la moitié de son trafic d'attaque soit abandonné, mais vos clients le font: 50% de perte de paquets dans une connexion TCP va faire des choses terribles, terribles , aux performances et à la fiabilité de ces connexions.

Il n'y a que deux trois façons d'arrêter une attaque DDoS volumétrique:

1. Ayez un tuyau suffisamment grand pour que le trafic d'attaque ne le remplisse pas.
2. Arrêtez les paquets d'attaque avant qu'ils ne descendent dans le tuyau.
3. Passez à une adresse IP différente qui ne fait pas l'objet d'une attaque par réflexion NTP.

Les bloquer dans iptables ne fera pas de squat, car d'ici là, le trafic d'attaque a déjà évincé le trafic légitime et l'a fait tomber sur le sol, donc l'attaquant a gagné. Étant donné que vous (vraisemblablement) ne contrôlez pas le routeur ou le commutateur en amont qui transfère le trafic d'attaque, oui, vous devrez contacter votre fournisseur de réseau en amont et lui demander de faire quelque chose pour empêcher le trafic d'attaque d'atteindre votre réseau. lien, que ce soit

• bloquer tout le trafic sur le port d'attaque (pas quelque chose que la plupart des FAI sont prêts à faire sur leurs routeurs d'accès client colo, pour $REASONS)

• filtrer les adresses IP source de l'attaque (plus plausible, avec S / RTBH, mais pas quelque chose que chaque fournisseur a déjà disponible)

• pire des cas, noircir l'adresse IP de destination

Notez que le blackholing de l'IP ne fonctionne que si vous avez d'autres adresses IP qui peuvent continuer à fonctionner - si votre fournisseur blackholes votre seule adresse IP, l'attaquant a réussi parce que vous êtes hors d'Internet, ce qu'ils essayaient de réaliser en premier lieu.

Je suppose que vous avez un tuyau vers votre FAI qui se termine sur votre propre routeur / pare-feu. Ensuite, derrière ce routeur / pare-feu, vous avez vos propres machines. Le FAI ne bloquera pas le trafic, vous devez donc le gérer vous-même. Vous voulez bloquer le trafic sur le routeur / pare-feu pour l'empêcher de frapper les machines derrière lui tout en minimisant la charge sur le routeur / pare-feu.

Votre règle semble correcte pour supprimer tout ce qui provenait d'un serveur ntp sur le port standard. N'oubliez pas que si vous utilisez réellement ntp, vous devrez peut-être percer des trous dans vos règles de pare-feu

Si votre pare-feu utilise le suivi des connexions (la plupart le font), vous souhaiterez peut-être utiliser le tableau "brut" pour supprimer les paquets avant qu'ils n'atteignent la machine de suivi des connexions.

iptables -t raw -A PREROUTING -p udp --sport 123 -j DROP

Il semble que nous pouvons signaler les adresses IP pour les abus NTP (et, espérons-le, les correctifs NTP) à

http://openntpproject.org/

En ce qui concerne les réseaux de rapports qui autorisent les adresses IP usurpées, je ne trouve pas grand - chose :

Nos mesures montrent que l'usurpation d'identité est encore répandue parmi environ 25% des systèmes autonomes et des netblocks que nous étudions. Plus important encore, un point d'entrée unique pour le trafic usurpé fournit aux attaquants un moyen d'envoyer du trafic usurpé à l'ensemble d'Internet. Les FAI peuvent utiliser le filtrage [RFC2827] pour garantir que leur trafic sortant n'est pas usurpé.

Peut-être que la seule méthode consiste à contacter directement le FAI?