Sur cette page
À retenir
- UDP n’est plus activé par défautMemcached désactive UDP par défaut depuis la version 1.5.6. Vérifiez le processus lancé et la configuration du paquet installé.
- Vérifier le sens du traficLes réponses réfléchies utilisent généralement le port source 11211. Une règle portant uniquement sur le port de destination ne vise pas le même trafic.
- Protéger le lien limitantFiltrer après une livraison saturée ne restitue pas la capacité déjà consommée en amont.
Comment la réflexion Memcached atteint un service sans rapport avec le cache
Une instance Memcached exposée avec UDP activé peut répondre à une adresse usurpée dans une requête. Si cette adresse appartient à votre service, votre réseau reçoit les réponses même si vous n’exploitez aucun cache public. La réflexion désigne cette redirection ; l’amplification désigne une réponse plus volumineuse que la requête.
Toute installation Memcached n’est pas un réflecteur. UDP est désactivé par défaut depuis la version 1.5.6, publiée en février 2018. Un ancien paquet ou une configuration explicite peut se comporter autrement. Le numéro de version ne suffit pas à connaître les sockets réellement en écoute.
Chemin d’une réflexion Memcached
- Adresse source usurpée
La requête présente la victime comme son émetteur.
- Cache UDP exposé
Un réflecteur joignable génère la réponse.
- Réseau de la victime
Les réponses traversent ses liens amont et son chemin de livraison.
Identifier le trafic avant de décider quoi bloquer
Situer le point d’observation
Notez l’interface, le sens, la fenêtre horaire et le taux d’échantillonnage. Comparez les compteurs d’entrée aux estimations de l’exporteur et aux erreurs du service affecté. Un lien amont saturé peut empêcher le serveur d’observer toute l’attaque.
Distinguer les ports source et destination
Examinez les réponses UDP entrantes avec un port source 11211, leurs destinations et la taille des paquets. Les requêtes adressées à un cache concernent habituellement le port de destination 11211. Aucun de ces ports ne prouve à lui seul une attaque : comparez avec les services et clients réellement autorisés.
Vérifier les fragments et la visibilité des requêtes
Les fragments IPv4 suivants ne contiennent pas l’en-tête UDP. Un filtre fondé uniquement sur les ports ou un relevé de flux échantillonné peut donc omettre une partie du trafic. L’absence de requête dans une capture unidirectionnelle ne prouve pas qu’aucune n’a été envoyée : routage asymétrique et échantillonnage peuvent les masquer.
Mesurer l’effet sur le service
Distinguez bande passante, débit de paquets, pertes, files d’attente et réussite des opérations applicatives. Un PPS élevé avec de la bande passante disponible peut révéler une limite de traitement ; un fort débit peut saturer une livraison avant même de solliciter le CPU local.
Si vous exploitez un serveur Memcached
Liez le cache à l’adresse privée ou de bouclage prévue et limitez son accès à ses vrais clients. Si UDP est inutile, l’option de démarrage Memcached -U 0 le désactive. Contrôlez la configuration effective du service sans présumer des valeurs par défaut de la distribution.
Préparez le changement avec l’application : identifiez les clients TCP ou UDP, vérifiez les sockets en écoute et conservez une possibilité de retour arrière. Après intervention dans une fenêtre adaptée, vérifiez le fonctionnement du cache et les erreurs applicatives. Fermer votre cache exposé retire un réflecteur potentiel ; cela n’empêche pas des serveurs tiers de réfléchir du trafic vers vous.
Si votre adresse est la victime
Repérez la première limite de capacité : port côté opérateur, lien partagé, réseau sous-jacent du tunnel, livraison ou carte réseau du serveur. Un filtrage local peut protéger l’application tant qu’il reste de la capacité, mais ne restitue pas les paquets perdus avant le filtre. Si le lien entrant est saturé, il faut intervenir en amont de cette limite.
Définissez une règle visant la destination protégée et le trafic effectivement identifié. Préservez les échanges nécessaires au cache et les autres services UDP. Un blocage UDP global peut faire baisser le graphique d’attaque tout en interrompant jeux, VPN ou DNS. Vérifiez sur l’équipement utilisé le filtrage par port source, le traitement des fragments et les actions disponibles.
Pour un chemin détourné, validez l’autorisation du préfixe, l’installation des routes, l’extrémité de réception, la MTU et le trafic retour. Désignez le responsable de l’expiration des règles et du retrait des routes. Un tunnel transporte les paquets ; il ne reconnaît pas seul le trafic d’attaque.
Exemple : filtrer avant une livraison à 1 Gbit/s
Prenons un lien de livraison à 1 Gbit/s portant 100 Mbit/s de trafic légitime. Si 2 Gbit/s de réponses réfléchies se présentent avant ce lien, un pare-feu placé derrière ne peut pas lui faire transporter tous les paquets nécessaires. Il s’agit d’un exemple de capacité, pas d’une mesure client ni d’un test de performance du filtrage.
Une validation utile relève le trafic d’attaque avant filtrage, la charge résiduelle après filtrage et les transactions légitimes réussies à travers la livraison. La capacité de réception restante compte : un graphique d’attaque en baisse ne démontre pas à lui seul le rétablissement du service.
Erreurs fréquentes pendant l’incident
- Bloquer le port de destination 11211 alors que les paquets entrants concernés sont des réponses provenant du port source 11211.
- Considérer l’absence de requêtes dans une capture comme la preuve d’un trafic non sollicité sur tout le réseau.
- Ignorer les fragments non initiaux ou appliquer une politique de fragmentation non testée aux services légitimes.
- Confondre la correction de la configuration d’un cache avec une protection contre des réflecteurs externes indépendants.
- Laisser une règle d’urgence active sans responsable, condition d’expiration ni contrôle du rétablissement.
Éléments à conserver pour l’opérateur et le rétablissement
Conservez la destination affectée, les horaires précis et leur fuseau, l’interface entrante, les variations des compteurs, les paramètres d’échantillonnage et un échantillon limité de vos propres paquets. Distinguez le trafic d’attaque présenté de la livraison après filtrage. Ne vous fiez pas à un pic isolé ou à une capture effectuée après l’apparition des pertes.
Après mitigation, vérifiez l’application cliente et les accès attendus au cache, puis le PPS résiduel, les pertes et les files d’attente. Retirez les règles temporaires selon la procédure convenue et confirmez le fonctionnement du chemin normal. Conservez les preuves pour revoir les seuils, sans transformer le profil d’un incident en signature universelle permanente.
Questions fréquentes
Puis-je être visé sans utiliser Memcached ?
Oui. La réflexion utilise des serveurs distants. Votre adresse figure dans des requêtes usurpées et leurs réponses arrivent donc sur votre réseau.
Le port source 11211 prouve-t-il que le trafic est malveillant ?
Non. C’est un indice de protocole utile. Vérifiez le rôle de la destination, les clients autorisés, le contexte des données et le sens du trafic avant de choisir le filtrage.
Mettre mon cache à jour résout-il une attaque contre mon IP publique ?
Cela peut supprimer un réflecteur exposé que vous exploitez, mais ne corrige pas les serveurs tiers et ne désature pas un chemin amont déjà saturé.
