Tere kõigile! Minu nimi on Dmitri Samsonov, töötan juhtiva süsteemiadministraatorina "Odnoklassnikutes". Meil on üle 7000 füüsilise serveri, 11000 konteinerit meie pilves ja 200 rakendust, mis erinevates konfiguratsioonides moodustavad 700 erinevat klastrit. Enamik serveritest töötab CentOS 7 all.
14. augustil 2018. aastal avaldati teave haavatavuste kohta FragmentSmack
() ja SegmentSmack (). Need on haavatavused, millel on võrgu rünnaku vektor ja piisavalt kõrge hindamine (7.5), mis ohustab teenuse katkestamist (DoS) ressursside (CPU) ammendumise tõttu. FragmentSmack'i jaoks lahendust tuumas sel ajal ei pakutud, pealegi ilmus see palju hiljem pärast haavatavuse teate avaldamist. SegmentSmack'i kõrvaldamiseks soovitati tuuma uuendada. Uuenduspakk saadeti välja samal päeval, jääb vaid see installida.
Ei, me ei ole tuuma uuendamise vastu! Kuid on mõned nüansid...
Kuidas me tuuma tootmises uuendame
Kokkuvõttes pole midagi keerulist:
- Laadige alla paketid;
- Installige need teatud arvule serveritele (sealhulgas serveritele, mis majutavad meie pilve);
- Veenduge, et midagi pole katki;
- Kontrollige, et kõik tuuma standardseaded on rakendunud ilma vigadeta;
- Oodake paar päeva;
- Kontrollige serverite näitajaid;
- Lülitage uute serverite juurutamine üle uuele tuumale;
- Uuendage kõik serverid andmekeskustesse (üks andmekeskus korraga, et vähendada mõju kasutajatele probleemide korral);
- Taaskäivitage kõik serverid.
Korrake kõigi meie tuumade harude jaoks. Praegu on need:
- Väärtpaber CentOS 7 3.10 – enamikule tavalisest serverist;
- Vanilla 4.19 – meie , sest vajame BFQ, BBR jne;
- Elrepo kernel-ml 5.2 – , sest 4.19 käituda varem ebastabiilselt, aga funktsioonid peavad olema samad.
Kuidas te juba võisite arvata, kõige rohkem aega võtab tuhandete serverite taaskäivitamine. Kuna mitte kõik haavatavused ei ole kriitilised kõikide serverite jaoks, taaskäivitame ainult need, mis on otse internetis kättesaadavad. Pilves, et mitte piirata paindlikkust, ei seosta me väljast kätte saadavaid konteinerite eraldi serveritega uue kerneliga, vaid taaskäivitame kõik hostid ilma eranditeta. Õnneks on seal protseduur lihtsam kui tavaliste serverite puhul. Näiteks saavad ilmaolematud konteinerid lihtsalt liikuda teisele serverile taaskäivitamise ajal.
Siiski on tööd ikkagi palju ja see võib võtta mitu nädalat, ning kui esineb mingeid probleeme uue versiooniga, võib see venida kuni mitu kuud. Kurjategijad mõistavad seda väga hästi, seega on vajalik plaan "B".
FragmentSmack/SsegmentSmack. Töö ümber.
Õnneks on mõnedel haavatavustel selline plaan "B" olemas ja seda nimetatakse Töö ümber. Tüüpiliselt on see kernel/rakenduste seadistuste muutmine, mis võimaldab võimalikke toimeid minimeerida või täielikult vältida haavatavuste ärakasutamist.
FragmentSmack/SsegmentSmack puhul sellist Töö ümber:
«Net.ipv4.ipfrag_high_thresh ja net.ipv4.ipfrag_low_thresh (ja nende analoogid ipv6 net.ipv6.ipfrag_high_thresh ja net.ipv6.ipfrag_low_thresh) vaikeseadeid 4MB ja 3MB saab muuta vastavalt 256 kB ja 192 kB või madalamaks. Testid näitavad, et CPU kasutus võib rünnaku ajal varieeruda olenevalt riistvarast, seadistustest ja tingimustest, alates vähesest kuni märkimisväärse languseni. Siiski võib ipfrag_high_thresh=262144 baitide tõttu olla mingit mõju jõudlusele, sest reas taaskokkupanekuks võivad olla korraga vaid kaks 64K fragmenti. Näiteks on oht, et suured UDP-pakette käsitlevad rakendused võivad tõrkuda.».
Parameetrid ise kirjeldatud on järgmiselt:
ipfrag_high_thresh - PIKK NUMBER
Maksimaalne mälu, mida kasutatakse IP-fragmentide uuesti kokku seadmiseks.
ipfrag_low_thresh - PIKK NUMBER
Maksimaalne mälu, mida kasutatakse IP fragmentide uuesti koostamiseks enne, kui tuumik
alustab puuduvate fragmentide järjekordade eemaldamist ressursside vabastamiseks.
Tuumik aktsepteerib endiselt uusi fragmente defragmenteerimiseks.
Meil ei ole tootmistaseme teenuseid suurte UDP-dega. LAN-is on fragmenteeritud liiklus puudulik, WAN-is on see olemas, kuid mitte oluline. Miski ei ennusta - Workaround'i võib rakendada!
FragmentSmack/SegmentSmack. Esimene veri.
Esimene probleem, millega silmitsi seisisime, oli see, et pilv konteinerid rakendasid mõnikord uusi seadeid vaid osaliselt (ainult ipfrag_low_thresh) ja mõnikord ei rakendanud neid üldse — lihtsalt kukkusid käivitamisel. Probleemi stabiilselt uuesti esile tuua ei õnnestunud (käsitsi rakendati kõik seaded ilma probleemideta). Mõista, miks konteiner käivitamisel kokku kukub, pole samuti lihtne: mingeid vigu ei tuvastatud. Üks oli kindlasti teada: seadete tagasiviimine lahendab konteinerite kokku kukkumise probleemi.
Miks ei piisa Sysctl rakendamisest hostis? Konteiner elab oma eraldatud võrgu Namespace'is, seega vähemalt konteineris võib erinev olla hostist.
Kuidas täpselt rakendatakse Sysctl seadeid konteineris? Kuna meie konteinerid on mitteprivileegitud, ei saa seada ühtegi Sysctl seadet, sisenedes konteinerisse — õigusi lihtsalt ei jätku. Konteinerite käivitamiseks kasutas meie pilv sel ajal Dockerit (praegu juba ). Dockeri API-le edastati uue konteineri parameetrid, sealhulgas vajalikud Sysctl seaded.
Versioonide läbivaatamisel selgus, et Docker API ei andnud kõiki vigu (vähemalt versioonis 1.10). Kui proovisime konteinerit käivitada käsuga “docker run”, nägime lõpuks midagi.
write /proc/sys/net/ipv4/ipfrag_high_thresh: kehtetu argument docker: Daemonilt tulnud veateade: Konteineri käivitamine ei õnnestunud <...>: [9] Süsteemiviga: ei saanud konteineri protsessiga sünkroniseerida.
Parameetri väärtus ei ole kehtiv. Aga miks? Ja miks see pole kehtiv ainult mõnikord? Selgus, et Docker ei garanteeri Sysctl parameetrite rakendamise järjekorda (viimane kontrollitud versioon — 1.13.1), mistõttu mõnikord üritas ipfrag_high_thresh seadistuda 256K-le, kui ipfrag_low_thresh oli veel 3M, see tähendab, et ülemine piir oli madalam kui alumine, mis tõi kaasa vea.
Sel hetkel kasutasime juba oma mehhanismi konteineri seadistamiseks pärast käivitamist (konteineri külmutamine läbi ja käskude täitmine konteineri nimekliendis läbi ), ja lisasime sellesse ossa ka Sysctl parameetrite määramise. Probleem lahendus.
FragmentSmack/SegmentSmack. Esimene veri 2
Me ei jõudnud Workaround'i rakendamisega pilves küllaltki arusaadavalt hakkama saada, kui hakkasid tulema esimesed harvad kaebused kasutajatelt. Sel hetkel oli möödunud mitu nädalat Workaround'i rakendamisest esimestel serveritel. Esialgne uurimine näitas, et kaebused tulid üksikutele teenustele, mitte kõigile nende teenuste serveritele. Probleem omandas taas äärmiselt ebaselge iseloomu.
Esiteks proovisime me muidugi Sysctl seadeid tagasi võtta, kuid see ei andnud mingit tulemusele. Erinevad serveri ja rakenduse seadete manipuleerimised samuti ei aidanud. Aitas reboot. Reboot Linuxis on sama ebanormaalne, kui see oli Windowsi töökingade puhul vanast ajast. Sellegipoolest aitas see, ja me panime kogu selle „tuuma veana” uute Sysctl seadete rakendamisele. Kui kergekäeliselt me seda olime teinud…
Kolme nädala pärast kordus probleem. Nende serverite konfiguratsioon oli üsna lihtne: Nginx proxy / tasakaalustajana. Liiklust oli vähe. Uus täiendav teave: klientidel suureneb iga päev 504 vigu (). Graafikul on näidatud 504 vigu päeval selle teenuse kohta:
Kõik vead puudutavad ühte ja sama tagapinda — seda, mis asub pilves. Pakettide fragmentide mälu tarbimise graafik sellel tagapinnal nägi välja järgnev.
See on üks kõige eredamaid väljendusi probleemist operatsioonisüsteemi graafikutel. Just sel ajal pilves lahendati teine võrguprobleem QoS (Traffic Control) seadistustega. Pakettide fragmentide mälu tarbimise graafik nägi välja täpselt samasugune.
Oletus oli lihtne: kui graafikud näevad välja identsed, siis on ka põhjus sama. Eriti kuna probleeme selle tüüpi mäluga esineb äärmiselt harva.
Lahendatud probleemi olemus seisnes selles, et kasutasime QoS-is pakettide ajakava fq, millel olid vaikeseaded. Vaikimisi lubab see ühe ühenduse jaoks järjekorda lisada 100 paketti ja mõned ühendused olukordades, kus ühenduse ribalaius on piiratud, hakkasid järjekorda täitma. Sellisel juhul visatakse paketid ära. Statistikas tc (tc -s qdisc) on see selgelt nähtav.
qdisc fq 2c6c: vanem 1:2c6c piir 10000p voo_piir 100p korvid 1024 orphan_mask 1023 kvant 3028 algne_kvant 15140 taasalustamise_viivitus 40.0ms
Saadeti 454701676345 baiti 491683359 pkt (langetatud 464545, ületamised 0 uuesti_q 0)
tagasihoid 0b 0p uuesti_q 0
1024 voo (1021 mitteaktiivne, 0 piiratud)
0 gc, 0 kõrgeprioriteet, 0 piiratud, 464545 voo_piir
«464545 flows_plimit» — see on paketid, mis on kukkunud seoses ühe ühenduse järjekorra limiidi ületamisega, ja «dropped 464545» — see on kogus kõikidest selle ajakava kukkunud pakettidest. Pärast järjekorra pikkuse suurendamist 1000-ni ja konteinerite taaskäivitamist probleem kadus. Saate lõõgastuda ja juua smuutit.
FragmentSmack/SegmentSmack. Viimane veri
Esiteks, pärast mitmeid kuulujutte tuumaga seotud haavatavuste kohta ilmus lõpuks FragmentSmacki jaoks parandustoitus (kuidas meeles pidada, et koos kuulutusega augustis ilmus ainult SegmentSmacki jaoks parandustoit), mis andis lootuse loobuda Workaround’ist, mis on meile üsna palju ebamugavusi valmistanud. Osa serveritest oleme selle aja jooksul juba uuele tuumele üle viinud, ning nüüd tuli alustada uuesti. Miks me uuendasime tuuma, ootamata FragmentSmacki parandusena? Asi on selles, et kaitseprotsess nende haavatavuste vastu kattus (ja sulandus) CentOSi uuendamise protsessiga (mis võtab veel rohkem aega kui vaid tuuma uuendamine). Veelgi enam, SegmentSmack on ohtlikum haavatavus ning parandustoit ilmus kohe, seega mõte oli igal juhul olemas. Kuid me ei saanud lihtsalt CentOSi tuuma uuendada, kuna FragmentSmacki haavatavus, mis ilmus CentOS 7.5 ajal, parandati alles versioonis 7.6, seetõttu pidime peatama uuendamise 7.5 juurde ja alustama uuesti 7.6 uuendamisega. Selliseid olukordi juhtub samuti.
Teiseks, me saime harva esinevaid kasutajate kaebusi probleemide kohta. Nüüd teame kindlalt, et need on seotud klientide failide üleslaadimisega meie serverites. Sellest poolest läks väga väike hulk üleslaadimisi kogu massist.
Nagu me eelnevas jutus meenutame, ei aidanud Sysctl'i tagasikerimine. Aitas Reboot, kuid ajutiselt.
Sysctl'i suhtes kahtlused ei olnud kadunud, kuid seekord oli vaja koguda võimalikult palju teavet. Samuti puudus ägedalt võimalus probleem klientide üleslaadimisega korrata, et täpsemalt uurida, mis toimub.
Kogu saadaval oleva statistika ja logide analüüs ei viinud meid arusaamisele, mis toimub. Häda oli selles, et probleemide kordamine puudus, et 'puudutada' konkreetset ühendust. Lõpuks suutsid arendajad eriversioonis rakendusest stabiilselt reprodutseerida probleeme testseadmest ühenduse kaudu Wi-Fi kaudu. See oli läbimurre uurimises. Klient ühendus Nginx'iga, mis proxys backend'ile, mida esindas meie rakendus Java-s.
Probleemide korral oli dialoog järgmine (registreeritud Nginx-proxy poolel):
- Kliendi: päring faili jätkusuutmise kohta.
- Java-server: vastus.
- Kliendi: POST koos failiga.
- Java-server: viga.
Java-server kirjutab logisse, et kliendilt on saadud 0 baiti andmeid, samas kui Nginx-proksi kinnitab, et päring kestis kauem kui 30 sekundit (30 sekundit on kliendi rakenduse ajutine piirang). Miks siis ajutine piirang ja miks 0 baiti? HTTP seisukohalt töötab kõik nii, nagu peab, kuid POST failiga näib nagu kaoks võrgust. See kaob kliendi ja Nginxi vahel. On aeg kasutada Tcpdump'i! Kuid kõigepealt tuleb mõista võrgu konfiguratsiooni. Nginx-proksi asub L3 taseme koormuse tasakaalustaja taga. . Kasutatakse tunnelimist pakettide edastamiseks L3 taseme koormuse tasakaalustajast serverisse, mis lisab pakettidele oma päiseid:
Samuti jõuab see serverisse VLAN-tähistatud liiklusena, mis lisab samuti oma väljad pakettidele:
Ja veel, see liiklus võib frakmenteeruda (see sama väike protsent sisenemisest frakmenteeritud liiklusest, millest rääkisime Workaround'i riskide hindamisel), mis samuti muudab päiseid:
Veel kord: paketid on kapseldatud Vlan-i tähisega, kapseldatud tunnelis, fragmenteeritud. Et paremini mõista, kuidas see toimub, jälgime paketi teed kliendist Nginx-proksini.
- Pakett jõuab L3 taseme koormuse tasakaalustajasse. Õige suunamise tagamiseks andmekeskuses kapseldatakse pakett tunnelisse ja saadetakse võrkaart.
- Kuna pakett + tunnelipead ei mahu MTU-sse, lõigatakse pakett fragmentideks ja saadetakse võrku.
- L3 taseme koormuse tasakaalustaja juures lisab lüliti paketi juurde Vlan-i tähise ja saadab selle edasi.
- Nginx-proksi ees näeb lüliti (porti seadistuste põhjal), et server ootab Vlan-kapseldatud paketti, seetõttu saadab see selle nagu on, eemaldamata Vlan-i tähist.
- Linux saab eraldi paketifragmentid ja liidab need üheks suureks paketiks.
- Seejärel jõuab pakett Vlan-liidesele, kus eemaldatakse esimene kiht — Vlan-kapseldamine.
- Pärast seda saadab Linux selle Tunnel-liidesele, kus eemaldatakse veel üks kiht — Tunnel-kapseldamine.
Raskuseks on kogu selle edastamine parameetritena tcpdumpis.
Alustame lõpust: kas klientidelt on olemas puhtad (ilma liigsete pealkirjadeta) IP-paketid, millest on eemaldatud Vlan- ja tunnel-kapseldamine?
tcpdump host
Ei, serveris selliseid pakette ei olnud. Seega peab probleem olema varasem. Kas on pakette, millest on eemaldatud ainult Vlan-kapseldamine?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx — see on kliendi IP-aadress hex-formaadis.
32:4 — aadress ja välja pikkus, kuhu on salvestatud SCR IP Tunnel-paketis.
Aadressi välja tuli valima, kuna internetis räägitakse 40, 44, 50, 54, kuid seal ei olnud IP-aadresse. Samuti saate vaadata ühte paketti hex-formaadis (parameeter -xx või -XX tcpdumpis) ja arvutada, mille aadressile tuntud IP vastab.
Kas on fragmente pakettidest, millest ei ole eemaldatud Vlan- ja Tunnel-kapseldamine?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
See maagia näitab meile kõiki fragmente, sealhulgas viimast. Ilmselt saab sama IP järgi filtreerida, kuid ma ei proovinud, kuna selliseid pakette ei olnud väga palju ja üldises voos leidsin vajalikud kiiresti. Siin nad on:
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 .faEE.....@.2.m.
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 ..............
Need to take a look at these two fragments of a single packet (same ID 53652) containing a photo (the word Exif is visible in the first packet). Since the packets are present at this level, but missing in the merged dumps, it clearly indicates an issue with the assembly. Finally, this has documentary proof!
The packet decoder did not detect any problems preventing assembly. I tried this here: . Initially, when trying to push something there, the decoder did not like the format of the packet. It turned out that there were some extra two octets between Srcmac and Ethertype (not related to fragment information). After their removal, the decoder started working. However, it showed no problems.
No matter how hard I looked, besides those Sysctl values, nothing else was found. It remained to find a way to identify problematic servers to understand the scale and decide on further actions. I quickly found the right counter:
netstat -s | grep "packet reassembles failed”
It's also available in snmpd under OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
«The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.)».
Serverite grupis, millel probleemi uuriti, kahel suurenes see arvesti kiiremini, kahel aeglasemalt, ning veel kahel ei suurenenud see üldse. Selle arvesti dünaamika võrdlemine Java-serveris esinevate HTTP-vigade dünaamikaga paljastas seose. See tähendab, et arvesti võiks olla jälgimiseks seadistatud.
Usaldusväärse probleemide indikaatori olemasolu on väga oluline, et saaks täpselt kindlaks teha, kas Sysctl'i tagasivõtmine aitab, kuna eelnevast jutust teame, et seda rakenduse põhjal kohe mõista ei saa. See indikaator võimaldaks avastada kõik probleemsed kohad produktsioonis enne, kui kasutajad neid märkavad.
Pärast Sysctl'i tagasivõtmist lõpetasid vead jälgimisel, seega oli probleemi põhjus tõestatud, samuti see, et tagasivõtmine aitab.
Me tagastasime fraktsioonide seaded teistel serveritel, kus uus jälgimine käivitus, ja mõnes kohas eraldasime isegi rohkem mälu fraktsioonide jaoks, kui seda enne vaikimisi oli (see oli udp-statistika, mille osaline kadumine ei olnud üldise tausta peal märgatav).
Kõige olulisemad küsimused
Miks meie L3-koormustasandil pakette fragmenteeritakse? Enamik pakette, mis kasutajatelt koormustasanditele tulevad, on SYN ja ACK. Nende pakettide suurused on väikesed. Kuid kuna nende pakettide osakaal on väga suur, ei märganud me suuremate pakettdi olemasolu, mis hakkasid fragmentatsioonile minema.
Põhjuseks oli katkenud konfiguratsiooniskript. Vlan-liidestega serverites (tootmises oli tol hetkel väga vähe servereid, kus oli märgistatud liiklus). Advmss võimaldab kliendile edastada teavet selle kohta, et meie suunas liikuvad paketid peaksid olema väiksema suurusega, et pärast tunnelipeade lisamist ei peaks neid fragmentima.
Miks Sysctl'i taastamine ei aidanud, aga taaskäivitamine aitas? Sysctl'i taastamine muutis mälu mahtu, mis oli saadaval pakettide ühendamiseks. Samas, tundub, et mälu ületäitumine fraktsioonidega põhjustas ühenduste aeglustumise, mis omakorda tõi kaasa fragmentide pikema viibimise järjekorras. Teisisõnu, protsess jäi ummikusse.
Taaskäivitamine nullis mälu ja kõik tuli korda.
Kas Workaround'ita oleks saanud vältida? Jah, kuid on suur risk jätta kasutajad teeninduseta rünnaku korral. Loomulikult tekitas Workaround'i rakendamine mitmesuguseid probleeme, sealhulgas ühe teenuse aeglustumise kasutajatel, kuid me arvame siiski, et tegevused olid õigustatud.
Suur tänu Andreile Timofejevile () abi eest uurimise läbiviimisel, samuti Alexei Krenjovile () — tohutu töö eest CentOS ja tuumade värskendamisel serverites. Protsess, mida tuli sel juhul mitu korda alustada otsast peale, mistõttu see venis mitme kuu peale.
Allikas: habr.com
