Salut tout le monde! Je m'appelle Dmitry Samsonov, je travaille en tant qu'administrateur système principal chez Odnoklassniki. Nous disposons de plus de 7 11 serveurs physiques, 200 700 conteneurs dans notre cloud et 7 applications qui, dans diverses configurations, forment XNUMX clusters différents. La grande majorité des serveurs exécutent CentOS XNUMX.
Le 14 août 2018, des informations sur la vulnérabilité FragmentSmack ont été publiées.
() et SegmentSmack (). Il s'agit de vulnérabilités avec un vecteur d'attaque réseau et un score assez élevé (7.5), qui menacent un déni de service (DoS) en raison de l'épuisement des ressources (CPU). Aucun correctif du noyau pour FragmentSmack n'a été proposé à l'époque ; de plus, il est sorti bien plus tard que la publication des informations sur la vulnérabilité. Pour éliminer SegmentSmack, il a été suggéré de mettre à jour le noyau. Le package de mise à jour lui-même a été publié le même jour, il ne restait plus qu'à l'installer.
Non, nous ne sommes pas du tout contre la mise à jour du noyau ! Il y a cependant des nuances...
Comment nous mettons à jour le noyau en production
En général, rien de compliqué :
- Télécharger des packages ;
- Installez-les sur un certain nombre de serveurs (y compris les serveurs hébergeant notre cloud) ;
- Assurez-vous que rien n'est cassé ;
- Assurez-vous que tous les paramètres standard du noyau sont appliqués sans erreur ;
- Attendez quelques jours ;
- Vérifier les performances du serveur ;
- Basculer le déploiement de nouveaux serveurs vers le nouveau noyau ;
- Mettre à jour tous les serveurs par centre de données (un centre de données à la fois pour minimiser l'effet sur les utilisateurs en cas de problèmes) ;
- Redémarrez tous les serveurs.
Répétez l’opération pour toutes les branches des noyaux que nous avons. Pour le moment c'est :
- Stock CentOS 7 3.10 - pour la plupart des serveurs standards ;
- Vanille 4.19 - pour la nôtre , parce que nous avons besoin de BFQ, BBR, etc. ;
- Elrepo noyau-ml 5.2 - pour , car la version 4.19 se comportait de manière instable, mais les mêmes fonctionnalités sont nécessaires.
Comme vous l'avez peut-être deviné, le redémarrage de milliers de serveurs prend le plus de temps. Puisque toutes les vulnérabilités ne sont pas critiques pour tous les serveurs, nous redémarrons uniquement ceux qui sont directement accessibles depuis Internet. Dans le cloud, afin de ne pas limiter la flexibilité, nous ne lions pas les conteneurs accessibles de l'extérieur aux serveurs individuels avec un nouveau noyau, mais redémarrons tous les hôtes sans exception. Heureusement, la procédure y est plus simple qu'avec les serveurs classiques. Par exemple, les conteneurs sans état peuvent simplement être déplacés vers un autre serveur lors d'un redémarrage.
Cependant, il reste encore beaucoup de travail, et cela peut prendre plusieurs semaines, et en cas de problème avec la nouvelle version, jusqu'à plusieurs mois. Les attaquants le comprennent très bien, ils ont donc besoin d’un plan B.
FragmentSmack/SegmentSmack. solution de contournement
Heureusement, pour certaines vulnérabilités, un tel plan B existe, appelé solution de contournement. Le plus souvent, il s'agit d'une modification des paramètres du noyau/de l'application qui peut minimiser l'effet possible ou éliminer complètement l'exploitation des vulnérabilités.
Dans le cas de FragmentSmack/SegmentSmack cette solution de contournement :
«Vous pouvez modifier les valeurs par défaut de 4 Mo et 3 Mo dans net.ipv4.ipfrag_high_thresh et net.ipv4.ipfrag_low_thresh (et leurs homologues pour ipv6 net.ipv6.ipfrag_high_thresh et net.ipv6.ipfrag_low_thresh) à 256 Ko et 192 Ko respectivement ou inférieur. Les tests montrent des baisses légères à significatives de l'utilisation du processeur lors d'une attaque en fonction du matériel, des paramètres et des conditions. Cependant, il peut y avoir un certain impact sur les performances en raison de ipfrag_high_thresh=262144 octets, puisque seuls deux fragments de 64 Ko peuvent entrer dans la file d'attente de réassemblage à la fois. Par exemple, il existe un risque que les applications qui fonctionnent avec des paquets UDP volumineux soient interrompues.».
Les paramètres eux-mêmes décrit comme suit :
ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
ipfrag_low_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
Nous n’avons pas de gros UDP sur les services de production. Il n'y a pas de trafic fragmenté sur le LAN ; il y a un trafic fragmenté sur le WAN, mais pas significatif. Il n'y a aucun signe : vous pouvez déployer une solution de contournement !
FragmentSmack/SegmentSmack. Premier sang
Le premier problème que nous avons rencontré était que les conteneurs cloud n'appliquaient parfois les nouveaux paramètres que partiellement (uniquement ipfrag_low_thresh), et parfois ne les appliquaient pas du tout - ils plantaient simplement au début. Il n'a pas été possible de reproduire le problème de manière stable (tous les paramètres ont été appliqués manuellement sans aucune difficulté). Comprendre pourquoi le conteneur plante au démarrage n'est pas non plus si simple : aucune erreur n'a été trouvée. Une chose était sûre : la restauration des paramètres résout le problème des plantages de conteneurs.
Pourquoi ne suffit-il pas d'appliquer Sysctl sur l'hôte ? Le conteneur vit dans son propre espace de noms de réseau dédié, donc au moins dans le conteneur peut différer de l'hôte.
Comment exactement les paramètres Sysctl sont-ils appliqués dans le conteneur ? Étant donné que nos conteneurs ne sont pas privilégiés, vous ne pourrez modifier aucun paramètre Sysctl en accédant au conteneur lui-même - vous n'avez tout simplement pas suffisamment de droits. Pour exécuter des conteneurs, notre cloud utilisait à l'époque Docker (maintenant ). Les paramètres du nouveau conteneur ont été transmis à Docker via l'API, y compris les paramètres Sysctl nécessaires.
En parcourant les versions, il s'est avéré que l'API Docker ne renvoyait pas toutes les erreurs (au moins dans la version 1.10). Lorsque nous avons essayé de démarrer le conteneur via « docker run », nous avons finalement vu au moins quelque chose :
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.
La valeur du paramètre n'est pas valide. Mais pourquoi? Et pourquoi n'est-il valable que parfois ? Il s'est avéré que Docker ne garantit pas l'ordre dans lequel les paramètres Sysctl sont appliqués (la dernière version testée est 1.13.1), donc parfois ipfrag_high_thresh essayait d'être défini sur 256 Ko alors que ipfrag_low_thresh était encore 3M, c'est-à-dire que la limite supérieure était inférieure que la limite inférieure, ce qui a conduit à l'erreur.
A cette époque, nous utilisions déjà notre propre mécanisme pour reconfigurer le conteneur après le démarrage (geler le conteneur après et exécuter des commandes dans l'espace de noms du conteneur via ), et nous avons également ajouté l'écriture des paramètres Sysctl à cette partie. Le problème a été résolu.
FragmentSmack/SegmentSmack. Premier sang 2
Avant que nous ayons eu le temps de comprendre l’utilisation de Workaround dans le cloud, les premières rares plaintes des utilisateurs ont commencé à arriver. A cette époque, plusieurs semaines s'étaient écoulées depuis le début de l'utilisation de Workaround sur les premiers serveurs. L'enquête initiale a montré que des plaintes avaient été reçues contre des services individuels et non contre tous les serveurs de ces services. Le problème est redevenu extrêmement incertain.
Tout d'abord, nous avons bien sûr essayé de restaurer les paramètres Sysctl, mais cela n'a eu aucun effet. Diverses manipulations avec les paramètres du serveur et de l'application n'ont pas non plus aidé. Le redémarrage a aidé. Le redémarrage de Linux est aussi contre nature que c'était normal pour Windows autrefois. Cependant, cela a aidé et nous l'avons attribué à un « problème de noyau » lors de l'application des nouveaux paramètres dans Sysctl. Comme c'était frivole...
Trois semaines plus tard, le problème est réapparu. La configuration de ces serveurs était assez simple : Nginx en mode proxy/balancer. Pas beaucoup de trafic. Nouvelle note introductive : le nombre d'erreurs 504 sur les clients augmente chaque jour (). Le graphique montre le nombre de 504 erreurs par jour pour ce service :
Toutes les erreurs concernent le même backend - celui qui se trouve dans le cloud. Le graphique de consommation de mémoire pour les fragments de package sur ce backend ressemblait à ceci :
C'est l'une des manifestations les plus évidentes du problème dans les graphiques du système d'exploitation. Dans le cloud, au même moment, un autre problème de réseau avec les paramètres QoS (Traffic Control) a été résolu. Sur le graphique de consommation de mémoire pour les fragments de paquets, cela ressemblait exactement à :
L’hypothèse était simple : s’ils se ressemblent sur les graphiques, alors ils ont la même raison. De plus, les problèmes liés à ce type de mémoire sont extrêmement rares.
L'essence du problème résolu était que nous utilisions le planificateur de paquets fq avec les paramètres par défaut de QoS. Par défaut, pour une connexion, il permet d'ajouter 100 paquets à la file d'attente, et certaines connexions, dans des situations de pénurie de canaux, ont commencé à obstruer la file d'attente à pleine capacité. Dans ce cas, les paquets sont abandonnés. Dans les statistiques tc (tc -s qdisc), cela peut être vu comme suit :
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
« 464545 flow_plimit » correspond aux paquets abandonnés en raison du dépassement de la limite de file d'attente d'une connexion, et « dropped 464545 » est la somme de tous les paquets abandonnés de ce planificateur. Après avoir augmenté la longueur de la file d'attente à 1 XNUMX et redémarré les conteneurs, le problème a cessé de se produire. Vous pouvez vous asseoir et boire un smoothie.
FragmentSmack/SegmentSmack. Dernier sang
Premièrement, plusieurs mois après l'annonce des vulnérabilités dans le noyau, un correctif pour FragmentSmack est finalement apparu (je vous rappelle qu'avec l'annonce d'août, un correctif uniquement pour SegmentSmack a été publié), ce qui nous a donné l'occasion d'abandonner la solution de contournement, ce qui nous a causé bien des ennuis. Pendant ce temps, nous avions déjà réussi à transférer certains serveurs vers le nouveau noyau, et il fallait maintenant recommencer depuis le début. Pourquoi avons-nous mis à jour le noyau sans attendre le correctif FragmentSmack ? Le fait est que le processus de protection contre ces vulnérabilités a coïncidé (et fusionné) avec le processus de mise à jour de CentOS lui-même (qui prend encore plus de temps que la mise à jour uniquement du noyau). De plus, SegmentSmack est une vulnérabilité plus dangereuse, et un correctif est apparu immédiatement, donc cela avait du sens de toute façon. Cependant, nous ne pouvions pas simplement mettre à jour le noyau sur CentOS car la vulnérabilité FragmentSmack, apparue lors de CentOS 7.5, n'a été corrigée que dans la version 7.6, nous avons donc dû arrêter la mise à jour vers 7.5 et tout recommencer avec la mise à jour vers 7.6. Et cela arrive aussi.
Deuxièmement, de rares plaintes d'utilisateurs concernant des problèmes nous sont revenues. Maintenant, nous savons déjà avec certitude qu'ils sont tous liés au téléchargement de fichiers des clients vers certains de nos serveurs. De plus, un très petit nombre de téléchargements par rapport à la masse totale transitaient par ces serveurs.
Comme nous nous en souvenons de l'histoire ci-dessus, l'annulation de Sysctl n'a pas aidé. Le redémarrage a aidé, mais temporairement.
Les soupçons concernant Sysctl n'ont pas été levés, mais cette fois il a fallu collecter le plus d'informations possible. Il y avait aussi un énorme manque de capacité à reproduire le problème d'upload sur le client afin d'étudier plus précisément ce qui se passait.
L’analyse de toutes les statistiques et journaux disponibles ne nous a pas permis de mieux comprendre ce qui se passait. Il y avait un manque aigu de capacité à reproduire le problème afin de « ressentir » un lien spécifique. Enfin, les développeurs, en utilisant une version spéciale de l'application, ont réussi à obtenir une reproduction stable des problèmes sur un appareil de test lorsqu'il est connecté via Wi-Fi. Ce fut une avancée majeure dans l'enquête. Le client s'est connecté à Nginx, qui a transmis le proxy au backend, qui était notre application Java.
Le dialogue pour les problèmes ressemblait à ceci (corrigé du côté du proxy Nginx) :
- Client : demande de recevoir des informations sur le téléchargement d'un fichier.
- Serveur Java : réponse.
- Client : POST avec fichier.
- Serveur Java : erreur.
Dans le même temps, le serveur Java écrit dans le journal que 0 octet de données a été reçu du client et le proxy Nginx écrit que la demande a pris plus de 30 secondes (30 secondes est le délai d'attente de l'application client). Pourquoi le timeout et pourquoi 0 octet ? Du point de vue HTTP, tout fonctionne comme il se doit, mais le POST avec le fichier semble disparaître du réseau. De plus, il disparaît entre le client et Nginx. Il est temps de vous armer de Tcpdump ! Mais vous devez d’abord comprendre la configuration du réseau. Le proxy Nginx est derrière l'équilibreur L3 . Le tunneling est utilisé pour transmettre les paquets de l'équilibreur L3 au serveur, qui ajoute ses en-têtes aux paquets :
Dans ce cas, le réseau arrive à ce serveur sous la forme d'un trafic balisé Vlan, qui ajoute également ses propres champs aux paquets :
Et ce trafic peut également être fragmenté (le même petit pourcentage de trafic entrant fragmenté dont nous avons parlé lors de l'évaluation des risques de Workaround), ce qui modifie également le contenu des en-têtes :
Encore une fois : les paquets sont encapsulés avec une balise Vlan, encapsulés avec un tunnel, fragmentés. Pour mieux comprendre comment cela se produit, traçons la route des paquets depuis le client jusqu'au proxy Nginx.
- Le paquet atteint l'équilibreur L3. Pour un routage correct au sein du data center, le paquet est encapsulé dans un tunnel et envoyé à la carte réseau.
- Étant donné que les en-têtes paquet + tunnel ne rentrent pas dans la MTU, le paquet est découpé en fragments et envoyé au réseau.
- Le commutateur après l'équilibreur L3, lors de la réception d'un paquet, y ajoute une balise Vlan et l'envoie.
- Le commutateur devant le proxy Nginx voit (en fonction des paramètres du port) que le serveur attend un paquet encapsulé dans un Vlan, il l'envoie donc tel quel, sans supprimer la balise Vlan.
- Linux prend des fragments de packages individuels et les fusionne en un seul gros package.
- Ensuite, le paquet atteint l'interface Vlan, où la première couche en est supprimée - l'encapsulation Vlan.
- Linux l'envoie ensuite à l'interface Tunnel, où une autre couche en est supprimée : l'encapsulation Tunnel.
La difficulté est de passer tout ça en paramètres à tcpdump.
Commençons par la fin : existe-t-il des paquets IP propres (sans en-têtes inutiles) provenant des clients, avec l'encapsulation du vlan et du tunnel supprimée ?
tcpdump host <ip клиента>
Non, il n'y avait pas de tels packages sur le serveur. Le problème doit donc être là plus tôt. Y a-t-il des paquets dont seule l’encapsulation Vlan a été supprimée ?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx est l'adresse IP du client au format hexadécimal.
32:4 — adresse et longueur du champ dans lequel l'adresse IP SCR est écrite dans le paquet tunnel.
L'adresse du champ a dû être sélectionnée par force brute, car sur Internet, ils écrivent environ 40, 44, 50, 54, mais il n'y avait pas d'adresse IP. Vous pouvez également consulter l'un des paquets en hexadécimal (le paramètre -xx ou -XX dans tcpdump) et calculer l'adresse IP que vous connaissez.
Y a-t-il des fragments de paquets sans que l’encapsulation Vlan et Tunnel soit supprimée ?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Cette magie nous montrera tous les fragments, y compris le dernier. Probablement, la même chose peut être filtrée par IP, mais je n'ai pas essayé, car il n'y a pas beaucoup de paquets de ce type et ceux dont j'avais besoin étaient faciles à trouver dans le flux général. Les voici:
14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........
14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
Il s'agit de deux fragments d'un même colis (même ID 53652) avec une photographie (le mot Exif est visible dans le premier colis). Du fait qu'il existe des packages à ce niveau, mais pas sous forme fusionnée dans les dumps, le problème vient clairement de l'assemblage. Il existe enfin des preuves documentaires de cela !
Le décodeur de paquets n’a révélé aucun problème susceptible d’empêcher la construction. Je l'ai essayé ici : . Au début, lorsque vous essayez d’y insérer quelque chose, le décodeur n’aime pas le format des paquets. Il s'est avéré qu'il y avait deux octets supplémentaires entre Srcmac et Ethertype (non liés aux informations sur les fragments). Après les avoir retirés, le décodeur a commencé à fonctionner. Cependant, cela n’a montré aucun problème.
Quoi qu'on en dise, rien d'autre n'a été trouvé à part ces Sysctl. Il ne restait plus qu'à trouver un moyen d'identifier les serveurs problématiques afin d'en comprendre l'ampleur et de décider d'autres actions. Le compteur recherché a été trouvé assez rapidement :
netstat -s | grep "packet reassembles failed”
Il est également dans snmpd sous OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"Le nombre de pannes détectées par l'algorithme de réassemblage IP (pour quelque raison que ce soit : expiration du délai, erreurs, etc.)."
Parmi le groupe de serveurs sur lesquels le problème a été étudié, sur deux ce compteur a augmenté plus rapidement, sur deux plus lentement et sur deux autres il n'a pas augmenté du tout. La comparaison de la dynamique de ce compteur avec la dynamique des erreurs HTTP sur le serveur Java a révélé une corrélation. Autrement dit, le compteur pourrait être surveillé.
Il est très important de disposer d'un indicateur fiable des problèmes afin que vous puissiez déterminer avec précision si la restauration de Sysctl est utile, car d'après l'histoire précédente, nous savons que cela ne peut pas être immédiatement compris à partir de l'application. Cet indicateur nous permettrait d'identifier tous les problèmes en production avant que les utilisateurs ne les découvrent.
Après la restauration de Sysctl, les erreurs de surveillance se sont arrêtées, la cause des problèmes a donc été prouvée, ainsi que le fait que la restauration aide.
Nous avons annulé les paramètres de fragmentation sur d'autres serveurs, où une nouvelle surveillance est entrée en jeu, et quelque part nous avons alloué encore plus de mémoire pour les fragments que ce n'était auparavant la valeur par défaut (il s'agissait de statistiques UDP, dont la perte partielle n'était pas perceptible dans le contexte général) .
Les questions les plus importantes
Pourquoi les paquets sont-ils fragmentés sur notre équilibreur L3 ? La plupart des paquets qui arrivent des utilisateurs aux équilibreurs sont SYN et ACK. Les tailles de ces paquets sont petites. Mais comme la part de ces paquets est très importante, nous n'avons pas remarqué la présence de gros paquets qui ont commencé à se fragmenter.
La raison était un script de configuration cassé sur des serveurs dotés d'interfaces Vlan (il y avait très peu de serveurs avec du trafic balisé en production à cette époque). Advmss nous permet de transmettre au client l'information selon laquelle les paquets dans notre direction doivent être plus petits afin qu'après leur avoir attaché les en-têtes de tunnel, ils n'aient pas besoin d'être fragmentés.
Pourquoi la restauration de Sysctl n'a-t-elle pas aidé, mais le redémarrage l'a-t-il fait ? La restauration de Sysctl a modifié la quantité de mémoire disponible pour la fusion des packages. Dans le même temps, apparemment, le fait même d'un débordement de mémoire pour les fragments a entraîné un ralentissement des connexions, ce qui a entraîné un long retard des fragments dans la file d'attente. Autrement dit, le processus s'est déroulé par cycles.
Le redémarrage a effacé la mémoire et tout est rentré dans l'ordre.
Était-il possible de se passer de la solution de contournement ? Oui, mais le risque est élevé de laisser les utilisateurs sans service en cas d'attaque. Bien entendu, l'utilisation de Workaround a entraîné divers problèmes, notamment le ralentissement d'un des services destinés aux utilisateurs, mais nous pensons néanmoins que les actions étaient justifiées.
Un grand merci à Andrey Timofeev () pour leur aide dans la conduite de l'enquête, ainsi qu'Alexey Krenev () - pour le travail titanesque de mise à jour des Centos et des noyaux sur les serveurs. Un processus qui, dans ce cas, a dû être repris plusieurs fois depuis le début, c'est pourquoi il a duré plusieurs mois.
Source: habr.com