Countermeasures contre l'attaque de reflection DNS entrante

J'ai actuellement une attaque de reflection DNS vers mon server. Je reçois une quantité énorme de réponses via UDP du Port 53 que mon server n'a jamais demandé:

02: 53: 57.626156 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), longueur 267) REFLECTING.OPEN.DNS.SERVER.domain> mydomain.com.11803: 30781 – q: RRSIG? . 0/13/1 ns:. NS A.SOMENAMESERVER.NET.,. [| Domain]

02: 53: 57.626382 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), longueur 267) REFLECTING.OPEN.DNS.SERVER.domain> mydomain.com.11803: 30781 – q: RRSIG? . 0/13/1 ns:. NS B.SOMENAMESERVER.NET.,. [| Domain]

02: 53: 57.627804 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto UDP (17), longueur 267) REFLECTING.OPEN.DNS.SERVER.domain> mydomain.com.24188: 30781 – q: RRSIG? . 0/13/1 ns:. NS C.SOMENAMESERVER.NET.,. [| Domain]

Donc, la contre-mesure que j'ai pensée est de limiter le nombre de packages entrants avec un port source de 53. Ne devrait-il pas y avoir de problème avec iptables à droite?

Donc, j'ai mis cela avec mes petites compétences iptables:

-A INPUT -s A.TRUSTED.NAMESERVER -j ACCEPT

-A INPUT -s B.TRUSTED.NAMESERVER -j ACCEPT

-A INPUT -s C.TRUSTED.NAMESERVER -j ACCEPT

-A INPUT -p udp -m udp –port 53 -m limite – limite 10 / min -j LOG –log-prefix "53 DENY FROM:" –log-level 7

-A INPUT -p udp -m udp –port 53 -m limite – limite 10 / min – coupure-limite 20 -j ACCEPT

Enregistrement de l'attaque et éclate quand il fait trop. Eh bien, je ne voudrais pas écrire ici si cela fonctionnait.

Quelque chose doit être erroné et je ne peux pas comprendre quoi. Il se connecte correctement, mais il ne DROP aucun package même si le nombre est> limite d'éclatement.

Je suis très reconnaissant pour votre aide.

Salue Marcel

2 Solutions collect form web for “Countermeasures contre l'attaque de reflection DNS entrante”

Je ne vois aucun DROP dans vos règles. Peut-être que vous souhaitez append

-A INPUT -p udp -m udp --sport 53 -j DROP 

à la fin de vos règles?

Si les packages réfléchis sont envoyés à un port UDP fermé, le kernel sur l'extrémité récepsortingce générera un message d'erreur ICMP. Ce traitement est assez bon marché, de sorte que le time de traitement requirejs pour traiter le package UDP et envoyer une erreur ICMP est probablement le less préoccupant.

Dans certains scénarios, la bande passante en amont consommée par les erreurs ICMP peut être une préoccupation réelle. Dans de tels scénarios, la limite de débit des erreurs ICMP peut être nécessaire.

Il est toutefois recommandé de déposer silencieusement tous les packages UDP sans jamais envoyer une erreur ICMP. Les erreurs ICMP sont le seul signal que les propriétaires des servers DNS impliqués, qui pourraient leur dire que leur server DNS est impliqué dans une attaque de reflection. En d'autres termes, en déposant silencieusement les packages, vous cachez l'attaque des personnes mêmes, qui pourrait l'atténuer.

Il est techniquement possible de concevoir un server DNS avec une atténuation automatique des attaques de reflection. Toutefois, une telle atténuation devrait reposer sur des messages d'erreur ICMP. Si de telles methods d'atténuation se répandent, vous ferez de vous une cible plus facile pour une attaque de DDoS en déposant silencieusement tout le trafic d'attaque.

Si les packages UDP réfléchis arrivent sur un port UDP ouvert, le traitement des packages réfléchis devient plus coûteux en termes de time CPU. Dans de tels scénarios, il conviendrait d'utiliser les règles iptables pour REJETER les packages dont le port source est 53 ou tout autre utilisé par les services couramment utilisés dans les attaques de reflection et dont le port de destination est celui du service que vous exécutez. Je ne les supprimerais PAS, mais j'utiliserais la cible REJECT pour produire une erreur ICMP identique à ce qui est vu sur un port fermé.

  • Wireshark ne retire pas les packages envoyés depuis localhost vers localhost via le réseau
  • Reverse proxy pour les services mixtes tcp, udp et http
  • Le port UDP semble être utilisé mais n'est pas affiché dans netstat ou TCPView
  • Connectez-vous à Internet via le protocole udp
  • Changement de port UDP rsyslog
  • Protection DDOS du côté ISP, protocole UDP, list blanche
  • Erreur OpenVPN: erreur TLS: les touches TLS locales / distantes sont désynchronisées:
  • Bloc de packages basé sur la longueur
  • Valeur rmem_max supérieure conduisant à plus de perte de packages
  • Service pour mettre temporairement en attente les packages UDP
  • Différence entre / dev / udp et netcat
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.