J'ai régulièrement et depuis belle lurette des essais de demandes récursives
sur mon DNS (en gros 3500 par jour). Ce sont des demandes espacées d'une 50 de
secondes émanant de la chine (essentiellement de 202.46.0.0/16). Cependant
depuis 2-3 jours, la technique change et j'ai affaire à un flux pouvant
atteindre une 50 de demandes à la seconde. La machine n'est pas très puissante
et elle a accusé le coup, pas sur la charge (elle est resté à un niveau
très raisonnable (<=2-3), mais dans le temps de réponse réseau notamment du
serveur NTP.
Je suis très confiant sur la configuration du serveur DNS (la multitude de
lignes «denied» la confirmant) mais deux petites choses me perturbent:
1) L'origine de ces requêtes est variée. Y-a-t-il une faiblesse récente
permettant de faire une attaque avec un rebond sur un serveur DNS (celui ci
renvoyant un paquet UDP d'erreur)? (Je ne sais pas si je me fais bien
comprendre)
2) Y-a-t-il un paramétrage permettant d'être silencieux à une requête non
autorisée? (peut être cela n'est pas souhaitable)
Merci de toute réponse
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20140206215030.dfab05ee5c5c72a6cc64a4fa@maison.homelinux.net
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
David S
Le 06/02/2014 21:50, François Boisson a écrit :
Bonjour à tous
J'ai régulièrement et depuis belle lurette des essais de demandes récursives sur mon DNS (en gros 3500 par jour). Ce sont des demandes espacées d'une 50 de secondes émanant de la chine (essentiellement de 202.46.0.0/16). Cependant depuis 2-3 jours, la technique change et j'ai affaire à un flux pouvant atteindre une 50 de demandes à la seconde. La machine n'est pas très puissante et elle a accusé le coup, pas sur la charge (elle est resté à un niveau très raisonnable (<=2-3), mais dans le temps de réponse réseau notamment du serveur NTP. Je suis très confiant sur la configuration du serveur DNS (la multitude de lignes «denied» la confirmant) mais deux petites choses me perturbent:
1) L'origine de ces requêtes est variée. Y-a-t-il une faiblesse récente permettant de faire une attaque avec un rebond sur un serveur DNS (celui ci renvoyant un paquet UDP d'erreur)? (Je ne sais pas si je me fais bien comprendre)
2) Y-a-t-il un paramétrage permettant d'être silencieux à une requête non autorisée? (peut être cela n'est pas souhaitable)
Merci de toute réponse
François Boisson
Bonsoir,
1/ C'est l'attaque à la mode, avec NTP, les enfants jouent facilement avec hélas...
2/ Si tu sais quelles machines ont besoin du ntp/dns/autre_service_en_udp de ton serveur, le plus simple est de limiter via iptables/filter quelles ip ont le droit de causer sur les ports 53/123/etc, ainsi la requête ne finit pas au niveau de ton démon qui logue...
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 06/02/2014 21:50, François Boisson a écrit :
Bonjour à tous
J'ai régulièrement et depuis belle lurette des essais de demandes récursives
sur mon DNS (en gros 3500 par jour). Ce sont des demandes espacées d'une 50 de
secondes émanant de la chine (essentiellement de 202.46.0.0/16). Cependant
depuis 2-3 jours, la technique change et j'ai affaire à un flux pouvant
atteindre une 50 de demandes à la seconde. La machine n'est pas très puissante
et elle a accusé le coup, pas sur la charge (elle est resté à un niveau
très raisonnable (<=2-3), mais dans le temps de réponse réseau notamment du
serveur NTP.
Je suis très confiant sur la configuration du serveur DNS (la multitude de
lignes «denied» la confirmant) mais deux petites choses me perturbent:
1) L'origine de ces requêtes est variée. Y-a-t-il une faiblesse récente
permettant de faire une attaque avec un rebond sur un serveur DNS (celui ci
renvoyant un paquet UDP d'erreur)? (Je ne sais pas si je me fais bien
comprendre)
2) Y-a-t-il un paramétrage permettant d'être silencieux à une requête non
autorisée? (peut être cela n'est pas souhaitable)
Merci de toute réponse
François Boisson
Bonsoir,
1/ C'est l'attaque à la mode, avec NTP, les enfants jouent facilement
avec hélas...
2/ Si tu sais quelles machines ont besoin du
ntp/dns/autre_service_en_udp de ton serveur, le plus simple est de
limiter via iptables/filter quelles ip ont le droit de causer sur les
ports 53/123/etc, ainsi la requête ne finit pas au niveau de ton démon
qui logue...
Un article de Stéphane Bortzmeyer pour NTP :
http://www.bortzmeyer.org/ntp-reflexion.html et DNS :
http://www.bortzmeyer.org/dns-attaque-ns-point.html
Bonne lecture :-)
D.S.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/52F3FA1D.5040109@davidsanchez.fr
J'ai régulièrement et depuis belle lurette des essais de demandes récursives sur mon DNS (en gros 3500 par jour). Ce sont des demandes espacées d'une 50 de secondes émanant de la chine (essentiellement de 202.46.0.0/16). Cependant depuis 2-3 jours, la technique change et j'ai affaire à un flux pouvant atteindre une 50 de demandes à la seconde. La machine n'est pas très puissante et elle a accusé le coup, pas sur la charge (elle est resté à un niveau très raisonnable (<=2-3), mais dans le temps de réponse réseau notamment du serveur NTP. Je suis très confiant sur la configuration du serveur DNS (la multitude de lignes «denied» la confirmant) mais deux petites choses me perturbent:
1) L'origine de ces requêtes est variée. Y-a-t-il une faiblesse récente permettant de faire une attaque avec un rebond sur un serveur DNS (celui ci renvoyant un paquet UDP d'erreur)? (Je ne sais pas si je me fais bien comprendre)
2) Y-a-t-il un paramétrage permettant d'être silencieux à une requête non autorisée? (peut être cela n'est pas souhaitable)
Merci de toute réponse
François Boisson
Bonsoir,
1/ C'est l'attaque à la mode, avec NTP, les enfants jouent facilement avec hélas...
2/ Si tu sais quelles machines ont besoin du ntp/dns/autre_service_en_udp de ton serveur, le plus simple est de limiter via iptables/filter quelles ip ont le droit de causer sur les ports 53/123/etc, ainsi la requête ne finit pas au niveau de ton démon qui logue...
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Bonjour,
Le jeudi 06 février 2014, François Boisson a écrit...
2) Y-a-t-il un paramétrage permettant d'être silencieux à une requête non
autorisée? (peut être cela n'est pas souhaitable)
Quelqu'un de mes connaissances a utilisé le module geoip d'iptables pour
bloquer les requêtes sur un serveur DNS attaqué.
--
jm
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20140206205725.GE23006@espinasse
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
François Boisson
Le Thu, 06 Feb 2014 22:09:49 +0100 David S <ml+ a écrit:
1/ C'est l'attaque à la mode, avec NTP, les enfants jouent facilement avec hélas...
2/ Si tu sais quelles machines ont besoin du ntp/dns/autre_service_en_udp de ton serveur, le plus simple est de limiter via iptables/filter quelles ip ont le droit de causer sur les ports 53/123/etc, ainsi la requête ne finit pas au niveau de ton démon qui logue...
Pour NTP, je connaissais (j'ai 3 machines dans le pool NTP et j'essaye de faire attention) et je n'ai pas de souci,. Pour le DNS, j'avais pourtant fouillé le blog de Stéphane (j'ai même failli directement lui demander) pour retrouver cet article dont je me rappelais. L'attaque évoquée n'est pas celle là car les demandes concernent des machines exotiques et non la racine «.».
Du coup j'ai épluché les logs car tout de même, j'ai du mal à croire que cela suffise à écrouler ma machine. Je me suis aperçu que le souci constaté sur le serveur NTP, que j'avais attribué à un délai dans la réponse, était en fait un crash noyau dans l'interruption correspondant à l'horloge système (sombre histoire de 32 bits, uptime et nombre de1/250 ième de seconde dans cet uptime).
J'ai changé de noyau (c'était un vieux lenny 2.6.26 de toute façon). Ça devrait être réglé.
Merci des réponses, ça m'a incité à éplucher les (longs) logs.
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le Thu, 06 Feb 2014 22:09:49 +0100
David S <ml+debian@davidsanchez.fr> a écrit:
1/ C'est l'attaque à la mode, avec NTP, les enfants jouent facilement
avec hélas...
2/ Si tu sais quelles machines ont besoin du
ntp/dns/autre_service_en_udp de ton serveur, le plus simple est de
limiter via iptables/filter quelles ip ont le droit de causer sur les
ports 53/123/etc, ainsi la requête ne finit pas au niveau de ton démon
qui logue...
Un article de Stéphane Bortzmeyer pour NTP :
http://www.bortzmeyer.org/ntp-reflexion.html et DNS :
http://www.bortzmeyer.org/dns-attaque-ns-point.html
Pour NTP, je connaissais (j'ai 3 machines dans le pool NTP et j'essaye de
faire attention) et je n'ai pas de souci,. Pour le DNS, j'avais pourtant
fouillé le blog de Stéphane (j'ai même failli directement lui demander) pour
retrouver cet article dont je me rappelais. L'attaque évoquée n'est
pas celle là car les demandes concernent des machines exotiques et non la
racine «.».
Du coup j'ai épluché les logs car tout de même, j'ai du mal à croire que cela
suffise à écrouler ma machine. Je me suis aperçu que le souci constaté sur le
serveur NTP, que j'avais attribué à un délai dans la réponse, était en fait un
crash noyau dans l'interruption correspondant à l'horloge système (sombre
histoire de 32 bits, uptime et nombre de1/250 ième de seconde dans cet uptime).
J'ai changé de noyau (c'était un vieux lenny 2.6.26 de toute façon). Ça
devrait être réglé.
Merci des réponses, ça m'a incité à éplucher les (longs) logs.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20140208102550.ace3ca6f408c7241e215e86e@maison.homelinux.net
Le Thu, 06 Feb 2014 22:09:49 +0100 David S <ml+ a écrit:
1/ C'est l'attaque à la mode, avec NTP, les enfants jouent facilement avec hélas...
2/ Si tu sais quelles machines ont besoin du ntp/dns/autre_service_en_udp de ton serveur, le plus simple est de limiter via iptables/filter quelles ip ont le droit de causer sur les ports 53/123/etc, ainsi la requête ne finit pas au niveau de ton démon qui logue...
Pour NTP, je connaissais (j'ai 3 machines dans le pool NTP et j'essaye de faire attention) et je n'ai pas de souci,. Pour le DNS, j'avais pourtant fouillé le blog de Stéphane (j'ai même failli directement lui demander) pour retrouver cet article dont je me rappelais. L'attaque évoquée n'est pas celle là car les demandes concernent des machines exotiques et non la racine «.».
Du coup j'ai épluché les logs car tout de même, j'ai du mal à croire que cela suffise à écrouler ma machine. Je me suis aperçu que le souci constaté sur le serveur NTP, que j'avais attribué à un délai dans la réponse, était en fait un crash noyau dans l'interruption correspondant à l'horloge système (sombre histoire de 32 bits, uptime et nombre de1/250 ième de seconde dans cet uptime).
J'ai changé de noyau (c'était un vieux lenny 2.6.26 de toute façon). Ça devrait être réglé.
Merci des réponses, ça m'a incité à éplucher les (longs) logs.
