Sveiki visi! Mano vardas Dmitrijus Samsonovas, dirbu vadovaujančiu sistemos administratoriumi Odnoklassniki. Turime daugiau nei 7 tūkstančius fizinių serverių, 11 tūkstančių konteinerių debesyje ir 200 programų, kurios įvairiomis konfigūracijomis sudaro 700 skirtingų klasterių. Didžioji dauguma serverių veikia „CentOS 7“.
14 m. rugpjūčio 2018 d. buvo paskelbta informacija apie FragmentSmack pažeidžiamumą
() ir SegmentSmack (). Tai pažeidžiamumas su tinklo atakos vektoriumi ir gana aukštu balu (7.5), o tai gresia paslaugų atsisakymu (DoS) dėl išteklių išsekimo (CPU). „FragmentSmack“ branduolio taisymas tuo metu nebuvo pasiūlytas, be to, jis pasirodė daug vėliau nei buvo paskelbta informacija apie pažeidžiamumą. Norint pašalinti SegmentSmack, buvo pasiūlyta atnaujinti branduolį. Pats atnaujinimo paketas buvo išleistas tą pačią dieną, liko tik jį įdiegti.
Ne, mes visiškai neprieštaraujame branduolio atnaujinimui! Tačiau yra niuansų...
Kaip atnaujiname branduolį gamybos metu
Apskritai nieko sudėtingo:
- Parsisiųsti paketus;
- Įdiekite juos daugelyje serverių (įskaitant serverius, kuriuose yra mūsų debesis);
- Įsitikinkite, kad niekas nesulaužytas;
- Įsitikinkite, kad visi standartiniai branduolio nustatymai taikomi be klaidų;
- Palaukite kelias dienas;
- Patikrinkite serverio veikimą;
- Perjungti naujų serverių diegimą į naują branduolį;
- Atnaujinkite visus serverius pagal duomenų centrą (po vieną duomenų centrą, kad būtų sumažintas poveikis vartotojams iškilus problemoms);
- Perkraukite visus serverius.
Pakartokite su visomis mūsų turimų branduolių šakomis. Šiuo metu tai yra:
- Stock CentOS 7 3.10 – daugumai įprastų serverių;
- Vanilė 4.19 - mūsų , nes mums reikia BFQ, BBR ir kt.;
- Elrepo branduolys-ml 5.2 - skirtas , nes 4.19 anksčiau elgėsi nestabiliai, bet reikalingos tos pačios funkcijos.
Kaip jau galėjote atspėti, ilgiausiai užtrunka tūkstančių serverių perkrovimas. Kadangi ne visi pažeidžiamumai yra svarbūs visiems serveriams, iš naujo paleidžiame tik tuos, kurie yra tiesiogiai pasiekiami iš interneto. Debesyje, siekdami neapriboti lankstumo, nepririšame iš išorės pasiekiamų konteinerių prie atskirų serverių su nauju branduoliu, o perkrauname visus be išimties pagrindinius kompiuterius. Laimei, procedūra ten yra paprastesnė nei naudojant įprastus serverius. Pavyzdžiui, konteineriai be būsenos gali tiesiog perkelti į kitą serverį perkrovimo metu.
Tačiau darbo vis dar yra daug ir tai gali užtrukti kelias savaites, o jei kyla problemų dėl naujos versijos, iki kelių mėnesių. Užpuolikai tai puikiai supranta, todėl jiems reikia plano B.
FragmentSmack / SegmentSmack. Sprendimas
Laimei, kai kurių pažeidžiamumų atveju egzistuoja toks planas B ir jis vadinamas Apeitiu. Dažniausiai tai yra branduolio/programos nustatymų pakeitimas, kuris gali sumažinti galimą poveikį arba visiškai panaikinti pažeidžiamumų išnaudojimą.
FragmentSmack / SegmentSmack atveju šis sprendimas:
«Galite pakeisti numatytąsias 4 MB ir 3 MB reikšmes net.ipv4.ipfrag_high_thresh ir net.ipv4.ipfrag_low_thresh (ir jų atitikmenis ipv6 net.ipv6.ipfrag_high_thresh ir net.ipv6.ipfrag_low_thresh) į atitinkamai 256 arba kB arba kB žemesnė. Testai rodo nuo nedidelio iki reikšmingo procesoriaus naudojimo sumažėjimo atakos metu, atsižvelgiant į aparatinę įrangą, nustatymus ir sąlygas. Tačiau ipfrag_high_thresh=192 baitai gali turėti įtakos našumui, nes vienu metu į surinkimo eilę gali tilpti tik du 262144 64 fragmentai. Pavyzdžiui, yra rizika, kad programos, veikiančios su dideliais UDP paketais, suges".
Patys parametrai aprašyta taip:
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.
Mes neturime didelių gamybos paslaugų UDP. LAN nėra suskaidyto srauto; WAN srautas yra suskaidytas, bet nereikšmingas. Nėra jokių ženklų – galite įdiegti Sprendimą!
FragmentSmack / SegmentSmack. Pirmas kraujas
Pirmoji problema, su kuria susidūrėme, buvo ta, kad debesų konteineriai naujus nustatymus pritaikė tik iš dalies (tik ipfrag_low_thresh), o kartais jų netaikė iš viso – jie tiesiog užgesdavo pradžioje. Stabiliai atkurti problemos nepavyko (visi nustatymai buvo pritaikyti rankiniu būdu be jokių sunkumų). Suprasti, kodėl konteineris sugenda pradžioje, taip pat nėra taip paprasta: klaidų nerasta. Vienas dalykas buvo tikras: atšaukus nustatymus išsprendžiama konteinerio gedimų problema.
Kodėl neužtenka pagrindiniame kompiuteryje taikyti Sysctl? Konteineris gyvena tam skirtame tinkle Namespace, taigi bent jau konteineryje gali skirtis nuo pagrindinio kompiuterio.
Kaip tiksliai sudėtiniame rodinyje taikomi Sysctl nustatymai? Kadangi mūsų sudėtiniai rodiniai nėra privilegijuoti, negalėsite pakeisti jokių Sysctl nustatymų įėję į patį sudėtinį rodinį – tiesiog neturite pakankamai teisių. Norėdami paleisti konteinerius, mūsų debesis tuo metu naudojo „Docker“ (dabar ). Naujojo konteinerio parametrai buvo perduoti Docker per API, įskaitant būtinus Sysctl nustatymus.
Ieškant versijų paaiškėjo, kad Docker API nepateikė visų klaidų (bent jau 1.10 versijoje). Kai bandėme paleisti konteinerį per „docker run“, pagaliau pamatėme bent kažką:
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.
Parametro reikšmė neteisinga. Bet kodėl? Ir kodėl jis negalioja tik kartais? Paaiškėjo, kad „Docker“ negarantuoja Sysctl parametrų taikymo tvarkos (naujausia išbandyta versija yra 1.13.1), todėl kartais ipfrag_high_thresh buvo bandoma nustatyti į 256K, kai ipfrag_low_thresh dar buvo 3M, tai yra, viršutinė riba buvo mažesnė. nei apatinė riba, dėl kurios atsirado klaida.
Tuo metu mes jau naudojome savo mechanizmą konteinerio perkonfigūravimui po paleidimo (konteinerio užšaldymas po ir komandų vykdymas konteinerio vardų srityje per ), taip pat į šią dalį įtraukėme Sysctl parametrų rašymą. Problema buvo išspręsta.
FragmentSmack / SegmentSmack. Pirmasis kraujas 2
Dar nespėjus suprasti, kaip naudoti „Woraround“ debesyje, pradėjo sulaukti pirmųjų retų vartotojų skundų. Tuo metu praėjo kelios savaitės nuo „Woraround“ naudojimo pirmuosiuose serveriuose. Pirminis tyrimas parodė, kad skundų buvo gauta dėl atskirų paslaugų, o ne dėl visų šių paslaugų serverių. Problema vėl tapo labai neaiški.
Visų pirma, mes, žinoma, bandėme grąžinti Sysctl nustatymus, tačiau tai neturėjo jokio poveikio. Nepadėjo ir įvairios manipuliacijos su serveriu bei programos nustatymais. Perkrovimas padėjo. „Linux“ perkrovimas yra toks pat nenatūralus, koks buvo įprastas „Windows“ senais laikais. Tačiau tai padėjo, ir pritaikėme naujus „Sysctl“ nustatymus iki „branduolių trikties“. Kaip nerimta buvo...
Po trijų savaičių problema pasikartojo. Šių serverių konfigūracija buvo gana paprasta: Nginx tarpinio serverio / balansavimo režimu. Nedaug srauto. Nauja įžanginė pastaba: 504 klaidų skaičius klientams kasdien didėja (). Diagramoje parodytas 504 šios paslaugos klaidų skaičius per dieną:
Visos klaidos yra apie tą pačią užpakalinę programą – apie tą, kuri yra debesyje. Atminties suvartojimo grafikas paketų fragmentams šiame fone atrodė taip:
Tai vienas ryškiausių problemos apraiškų operacinės sistemos grafikuose. Debesyje tuo pačiu metu buvo ištaisyta kita tinklo problema su QoS (Eismo valdymo) nustatymais. Paketų fragmentų atminties suvartojimo grafike jis atrodė lygiai taip pat:
Prielaida buvo paprasta: jei jie diagramose atrodo vienodai, vadinasi, jų priežastis yra ta pati. Be to, bet kokios problemos su tokio tipo atmintimi yra labai retos.
Ištaisytos problemos esmė buvo ta, kad mes naudojome fq paketų planuoklį su numatytaisiais QoS nustatymais. Pagal numatytuosius nustatymus vienam ryšiui jis leidžia į eilę įtraukti 100 paketų, o kai kurie ryšiai, esant kanalo trūkumui, pradėjo užkimšti eilę iki talpos. Tokiu atveju paketai numetami. Tc statistikoje (tc -s qdisc) tai galima pamatyti taip:
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 flows_plimit“ yra paketai, atmesti dėl vieno ryšio eilės limito viršijimo, o „atmesta 464545“ yra visų šio planuoklio atmestų paketų suma. Padidinus eilės ilgį iki 1 tūkstančio ir iš naujo paleidus konteinerius, problema nustojo kilti. Galite atsisėsti ir išgerti kokteilį.
FragmentSmack / SegmentSmack. Paskutinis kraujas
Pirma, praėjus keliems mėnesiams po pranešimo apie branduolio pažeidžiamumą, pagaliau pasirodė FragmentSmack pataisa (priminsiu, kad kartu su rugpjūčio mėn. pranešimu buvo išleistas tik SegmentSmack pataisymas), kuris suteikė mums galimybę atsisakyti problemos sprendimo, kas mums pridarė nemažai rūpesčių. Per tą laiką kai kuriuos serverius jau spėjome perkelti į naują branduolį, o dabar reikėjo pradėti nuo pradžių. Kodėl atnaujinome branduolį nelaukdami FragmentSmack pataisos? Faktas yra tas, kad apsaugos nuo šių pažeidžiamumų procesas sutapo (ir susiliejo) su pačiu CentOS atnaujinimu (kuris užtrunka net daugiau laiko nei tik branduolio atnaujinimas). Be to, „SegmentSmack“ yra pavojingesnis pažeidžiamumas, o jo pataisa pasirodė iškart, todėl vis tiek buvo prasminga. Tačiau mes negalėjome paprasčiausiai atnaujinti „CentOS“ branduolio, nes „FragmentSmack“ pažeidžiamumas, atsiradęs „CentOS 7.5“ metu, buvo ištaisytas tik 7.6 versijoje, todėl turėjome sustabdyti naujinimą iki 7.5 ir pradėti iš naujo nuo atnaujinimo iki 7.6. Ir tai taip pat atsitinka.
Antra, mums grįžo reti vartotojų skundai dėl problemų. Dabar jau tikrai žinome, kad jie visi susiję su failų įkėlimu iš klientų į kai kuriuos mūsų serverius. Be to, per šiuos serverius nukeliavo labai mažas įkėlimų skaičius iš visos masės.
Kaip prisimename iš aukščiau pateiktos istorijos, Sysctl atšaukimas nepadėjo. Perkrovimas padėjo, bet laikinai.
Įtarimai dėl Sysctl nebuvo pašalinti, tačiau šį kartą reikėjo surinkti kuo daugiau informacijos. Taip pat labai trūko galimybės atkurti įkėlimo problemą klientui, kad būtų galima tiksliau ištirti, kas vyksta.
Visos turimos statistikos ir žurnalų analizė nepadėjo mums suprasti, kas vyksta. Labai trūko gebėjimo atkurti problemą, kad „pajustų“ konkretų ryšį. Galiausiai kūrėjams, naudojant specialią programos versiją, pavyko pasiekti stabilų problemų atkūrimą bandomajame įrenginyje, kai buvo prijungtas per „Wi-Fi“. Tai buvo lūžis tyrime. Klientas prisijungė prie „Nginx“, kuris buvo tarpinis serveris, kuris buvo mūsų „Java“ programa.
Dialogas dėl problemų buvo toks (ištaisyta Nginx tarpinio serverio pusėje):
- Klientas: užklausa gauti informaciją apie failo atsisiuntimą.
- Java serveris: atsakymas.
- Klientas: POST su failu.
- Java serveris: klaida.
Tuo pačiu metu „Java“ serveris įrašo į žurnalą, kad iš kliento buvo gauta 0 baitų duomenų, o „Nginx“ tarpinis serveris rašo, kad užklausa užtruko daugiau nei 30 sekundžių (30 sekundžių yra kliento programos laikas). Kodėl skirtas laikas ir kodėl 0 baitų? Žvelgiant iš HTTP perspektyvos, viskas veikia taip, kaip turėtų, bet atrodo, kad POST su failu dingsta iš tinklo. Be to, jis išnyksta tarp kliento ir „Nginx“. Atėjo laikas apsiginkluoti Tcpdump! Bet pirmiausia turite suprasti tinklo konfigūraciją. „Nginx“ tarpinis serveris yra už L3 balansavimo priemonės . Tuneliavimas naudojamas paketams iš L3 balansavimo priemonės pristatyti į serverį, kuris prie paketų prideda savo antraštes:
Šiuo atveju tinklas ateina į šį serverį Vlan pažymėto srauto pavidalu, kuris taip pat prideda prie paketų savo laukus:
Be to, šis srautas taip pat gali būti suskaidytas (ta pati nedidelė gaunamo fragmentuoto srauto procentinė dalis, apie kurią kalbėjome vertindami riziką, kylančią dėl problemos sprendimo), o tai taip pat keičia antraštių turinį:
Dar kartą: paketai yra uždengti Vlan žyma, įkapsuliuoti tuneliu, suskaidyti. Norėdami geriau suprasti, kaip tai vyksta, atsekime paketo maršrutą nuo kliento iki Nginx tarpinio serverio.
- Paketas pasiekia L3 balansuotoją. Siekiant teisingo maršruto duomenų centre, paketas yra įdėtas į tunelį ir siunčiamas į tinklo plokštę.
- Kadangi paketo + tunelio antraštės netelpa į MTU, paketas supjaustomas į fragmentus ir siunčiamas į tinklą.
- Po L3 balansyro esantis jungiklis, gavęs paketą, prideda prie jo Vlan žymą ir išsiunčia.
- Priešais Nginx tarpinį serverį esantis jungiklis mato (remiantis prievado nustatymais), kad serveris tikisi Vlan inkapsuliuoto paketo, todėl siunčia jį tokį, koks yra, nepašalindamas Vlan žymos.
- Linux paima atskirų paketų fragmentus ir sujungia juos į vieną didelį paketą.
- Toliau paketas pasiekia Vlan sąsają, kur iš jo pašalinamas pirmasis sluoksnis – Vlan inkapsuliacija.
- Tada „Linux“ siunčia jį į „Tunnel“ sąsają, kur iš jo pašalinamas kitas sluoksnis – Tunelio inkapsuliacija.
Sunkiausia visa tai perduoti kaip parametrus tcpdump.
Pradėkime nuo pabaigos: ar yra švarių (be nereikalingų antraščių) IP paketų iš klientų, iš kurių pašalinta vlan ir tunelinė inkapsuliacija?
tcpdump host <ip клиента>
Ne, tokių paketų serveryje nebuvo. Taigi problema turi atsirasti anksčiau. Ar yra paketų, iš kurių pašalinta tik „Vlan“ kapsulė?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx yra kliento IP adresas šešioliktainiu formatu.
32:4 – adresas ir ilgis lauko, kuriame SCR IP įrašomas tunelio pakete.
Lauko adresą reikėjo pasirinkti žiauria jėga, nes internete jie rašo apie 40, 44, 50, 54, tačiau ten nebuvo IP adreso. Taip pat galite pažvelgti į vieną iš paketų hex (parametras -xx arba -XX tcpdump) ir apskaičiuoti žinomą IP adresą.
Ar yra paketų fragmentų, nepašalintų Vlan ir Tunnel inkapsuliacijos?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Ši magija parodys mums visus fragmentus, įskaitant paskutinį. Tikriausiai tą patį galima filtruoti ir pagal IP, bet aš nebandžiau, nes tokių paketų nėra labai daug, o tuos, kurių man reikėjo, nesunkiai rasiu bendrame sraute. Jie yra čia:
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 ..............
Tai du vienos pakuotės fragmentai (tas pats ID 53652) su nuotrauka (pirmoje pakuotėje matomas žodis Exif). Dėl to, kad yra tokio lygio paketų, bet ne sujungtos formos sąvartynuose, problema akivaizdžiai susijusi su surinkimu. Pagaliau yra dokumentiniai to įrodymai!
Paketų dekoderis neatskleidė jokių problemų, kurios trukdytų kurti. Išbandė čia: . Iš pradžių, kai bandai ką nors ten įkišti, dekoderiui nepatinka paketo formatas. Paaiškėjo, kad tarp Srcmac ir Ethertype buvo keletas papildomų oktetų (nesusiję su fragmento informacija). Juos pašalinus pradėjo veikti dekoderis. Tačiau tai neparodė jokių problemų.
Kad ir ką sakytume, nieko daugiau, išskyrus tuos Sysctl, nerasta. Liko tik rasti būdą, kaip nustatyti probleminius serverius, kad būtų galima suprasti mastą ir nuspręsti dėl tolesnių veiksmų. Reikiamas skaitiklis buvo rastas pakankamai greitai:
netstat -s | grep "packet reassembles failed”
Jis taip pat yra snmpd pagal OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
„Gedimų, aptiktų IP pakartotinio surinkimo algoritmo, skaičius (dėl bet kokios priežasties: baigėsi skirtasis laikas, klaidos ir pan.).“
Tarp serverių grupės, kurioje buvo tiriama problema, dviejuose šis skaitiklis didėjo greičiau, dviejuose lėčiau, o dar dviejuose iš viso nepadidėjo. Palyginus šio skaitiklio dinamiką su HTTP klaidų dinamika Java serveryje, paaiškėjo koreliacija. Tai yra, skaitiklis gali būti stebimas.
Labai svarbu turėti patikimą problemų rodiklį, kad galėtumėte tiksliai nustatyti, ar Sysctl atšaukimas padeda, nes iš ankstesnės istorijos žinome, kad to negalima iš karto suprasti iš programos. Šis indikatorius leistų mums nustatyti visas problemines gamybos sritis, kol naudotojai jį atranda.
Sugrąžinus Sysctl stebėjimo klaidos sustojo, todėl buvo įrodyta problemų priežastis bei tai, kad atšaukimas padeda.
Atšaukėme suskaidymo nustatymus kituose serveriuose, kur atsirado naujas stebėjimas, o kai kur skyrėme dar daugiau atminties fragmentams, nei buvo numatyta anksčiau (tai buvo UDP statistika, kurios dalinis praradimas nebuvo pastebimas bendrame fone) .
Svarbiausi klausimai
Kodėl mūsų L3 balansuotojo paketai yra suskaidyti? Dauguma paketų, kuriuos vartotojai pasiekia balansuotojams, yra SYN ir ACK. Šių pakuočių dydžiai yra nedideli. Tačiau kadangi tokių paketų dalis yra labai didelė, jų fone nepastebėjome didelių paketų, kurie pradėjo fragmentuotis.
Priežastis buvo sugadintas konfigūracijos scenarijus serveriuose su Vlan sąsajomis (tuo metu gamyboje buvo labai mažai serverių su pažymėtu srautu). Advmss leidžia perduoti klientui informaciją, kad mūsų kryptimi esantys paketai turėtų būti mažesnio dydžio, kad prie jų pritvirtinus tunelines antraštes nereikėtų fragmentuoti.
Kodėl Sysctl atšaukimas nepadėjo, o perkrovimas padėjo? Sugrąžinus Sysctl, pasikeitė laisvos atminties kiekis paketams sujungti. Tuo pačiu metu, matyt, pats fragmentų atminties perpildymo faktas lėmė ryšių sulėtėjimą, dėl ko fragmentai ilgą laiką buvo uždelsti eilėje. Tai yra, procesas vyko ciklais.
Perkrovimas išvalė atmintį ir viskas grįžo į savo tvarką.
Ar buvo galima apsieiti be išeities? Taip, bet yra didelė rizika, kad atakos atveju vartotojai bus palikti be paslaugų. Žinoma, „Woraround“ naudojimas sukėlė įvairių problemų, įskaitant vienos iš paslaugų vartotojams sulėtėjimą, tačiau vis dėlto manome, kad veiksmai buvo pagrįsti.
Labai ačiū Andrejui Timofejevui () už pagalbą atliekant tyrimą, taip pat Aleksejui Krenevui () - už titanišką darbą atnaujinant Centos ir branduolius serveriuose. Procesas, kurį šiuo atveju teko kelis kartus pradėti nuo pradžių, todėl užsitęsė ilgus mėnesius.
Šaltinis: www.habr.com