Hi almal! My naam is Dmitri Samsonov, ek werk as 'n toonaangewende stelseladministrateur by Odnoklassniki. Ons het meer as 7 duisend fisiese bedieners, 11 duisend houers in ons wolk en 200 toepassings, wat in verskillende konfigurasies 700 verskillende groepe vorm. Die oorgrote meerderheid bedieners loop CentOS 7.
Op 14 Augustus 2018 is inligting oor die FragmentSmack-kwesbaarheid gepubliseer
() en SegmentSmack (). Dit is kwesbaarhede met 'n netwerkaanvalvektor en 'n redelike hoë telling (7.5), wat ontkenning van diens (DoS) dreig weens hulpbronuitputting (CPU). 'n Kernoplossing vir FragmentSmack is nie op daardie tydstip voorgestel nie; dit het boonop baie later uitgekom as die publikasie van inligting oor die kwesbaarheid. Om SegmentSmack uit te skakel, is voorgestel om die kern op te dateer. Die opdateringspakket self is op dieselfde dag vrygestel, al wat oorgebly het, was om dit te installeer.
Nee, ons is glad nie teen die opdatering van die kern nie! Daar is egter nuanses ...
Hoe ons die kern by produksie opdateer
Oor die algemeen is niks ingewikkeld nie:
- Laai pakkette af;
- Installeer dit op 'n aantal bedieners (insluitend bedieners wat ons wolk huisves);
- Maak seker niks is stukkend nie;
- Maak seker dat alle standaard kerninstellings sonder foute toegepas word;
- Wag 'n paar dae;
- Gaan bedienerwerkverrigting na;
- Skakel ontplooiing van nuwe bedieners na die nuwe kern;
- Dateer alle bedieners volgens datasentrum op (een datasentrum op 'n slag om die uitwerking op gebruikers in geval van probleme te minimaliseer);
- Herlaai alle bedieners.
Herhaal vir alle takke van die pitte wat ons het. Op die oomblik is dit:
- Stock CentOS 7 3.10 - vir die meeste gereelde bedieners;
- Vanilla 4.19 - vir ons s'n , want ons benodig BFQ, BBR, ens.;
- Elrepo kernel-ml 5.2 - vir , want 4.19 het vroeër onstabiel gedra, maar dieselfde kenmerke is nodig.
Soos u dalk geraai het, neem die herlaai van duisende bedieners die langste tyd. Aangesien nie alle kwesbaarhede van kritieke belang is vir alle bedieners nie, herlaai ons net dié wat direk vanaf die internet toeganklik is. In die wolk, om nie buigsaamheid te beperk nie, bind ons nie ekstern toeganklike houers aan individuele bedieners met 'n nuwe kern nie, maar herlaai alle gashere sonder uitsondering. Gelukkig is die prosedure daar eenvoudiger as met gewone bedieners. Byvoorbeeld, staatlose houers kan eenvoudig na 'n ander bediener skuif tydens 'n herlaai.
Daar is egter nog baie werk, en dit kan 'n paar weke neem, en as daar enige probleme met die nuwe weergawe is, tot 'n paar maande. Aanvallers verstaan dit baie goed, so hulle het 'n plan B nodig.
FragmentSmack/SegmentSmack. Werk om
Gelukkig bestaan daar vir sommige kwesbaarhede so 'n plan B, en dit word Workaround genoem. Meestal is dit 'n verandering in kern-/toepassingsinstellings wat die moontlike effek kan verminder of die uitbuiting van kwesbaarhede heeltemal kan uitskakel.
In die geval van FragmentSmack/SegmentSmack hierdie oplossing:
«Jy kan die verstekwaardes van 4MB en 3MB in net.ipv4.ipfrag_high_thresh en net.ipv4.ipfrag_low_thresh (en hul eweknieë vir ipv6 net.ipv6.ipfrag_high_thresh en net.ipv6.ipfrag_low_thresh) en onderskeidelik 256 kB of 192 kB verander laer. Toetse toon klein tot beduidende dalings in SVE-gebruik tydens 'n aanval, afhangende van hardeware, instellings en toestande. Daar kan egter 'n mate van prestasie-impak wees as gevolg van ipfrag_high_thresh=262144 grepe, aangesien slegs twee 64K-fragmente op 'n slag in die hersamestellingsry kan pas. Daar is byvoorbeeld 'n risiko dat toepassings wat met groot UDP-pakkies werk, sal breek".
Die parameters self soos volg beskryf:
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.
Ons het nie groot UDP's op produksiedienste nie. Daar is geen gefragmenteerde verkeer op die LAN nie; daar is gefragmenteerde verkeer op die WAN, maar nie betekenisvol nie. Daar is geen tekens nie - jy kan Oplossing uitrol!
FragmentSmack/SegmentSmack. Eerste bloed
Die eerste probleem wat ons teëgekom het, was dat wolkhouers die nuwe instellings soms net gedeeltelik toegepas het (slegs ipfrag_low_thresh), en soms glad nie toegepas het nie - hulle het eenvoudig aan die begin neergestort. Dit was nie moontlik om die probleem stabiel te reproduseer nie (alle instellings is sonder enige probleme met die hand toegepas). Om te verstaan hoekom die houer aan die begin ineenstort, is ook nie so maklik nie: geen foute is gevind nie. Een ding was seker: die terugrol van die instellings los die probleem op met houerongelukke.
Waarom is dit nie genoeg om Sysctl op die gasheer toe te pas nie? Die houer woon in sy eie toegewyde netwerk Naamruimte, so ten minste in die houer kan verskil van die gasheer.
Hoe presies word Sysctl-instellings in die houer toegepas? Aangesien ons houers onbevoorreg is, sal jy nie enige Sysctl-instelling kan verander deur by die houer self in te gaan nie - jy het eenvoudig nie genoeg regte nie. Om houers te laat loop, het ons wolk destyds Docker (nou ). Die parameters van die nuwe houer is deur die API aan Docker deurgegee, insluitend die nodige Sysctl-instellings.
Terwyl u deur die weergawes gesoek het, het dit geblyk dat die Docker API nie alle foute opstuur nie (ten minste in weergawe 1.10). Toe ons probeer om die houer te begin via "doker run", het ons uiteindelik ten minste iets gesien:
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.
Die parameterwaarde is nie geldig nie. Maar hoekom? En hoekom is dit nie net soms geldig nie? Dit het geblyk dat Docker nie die volgorde waarborg waarin Sysctl-parameters toegepas word nie (die nuutste getoetsde weergawe is 1.13.1), so soms het ipfrag_high_thresh probeer om op 256K gestel te word toe ipfrag_low_thresh nog 3M was, dit wil sê, die boonste limiet was laer as die onderste limiet, wat tot die fout gelei het.
Op daardie tydstip het ons reeds ons eie meganisme gebruik om die houer na aanvang te herkonfigureer (vries die houer daarna en die uitvoering van opdragte in die naamruimte van die houer via ), en ons het ook skryf Sysctl-parameters by hierdie deel gevoeg. Die probleem is opgelos.
FragmentSmack/SegmentSmack. Eerste bloed 2
Voordat ons tyd gehad het om die gebruik van Workaround in die wolk te verstaan, het die eerste seldsame klagtes van gebruikers begin opdaag. Op daardie tydstip het 'n paar weke verloop sedert die begin van die gebruik van Workaround op die eerste bedieners. Die aanvanklike ondersoek het getoon dat klagtes teen individuele dienste ontvang is, en nie alle bedieners van hierdie dienste nie. Die probleem het weer uiters onseker geraak.
Eerstens het ons natuurlik probeer om die Sysctl-instellings terug te draai, maar dit het geen effek gehad nie. Verskeie manipulasies met die bediener en toepassing instellings het ook nie gehelp nie. Herlaai het gehelp. Om Linux te herlaai is so onnatuurlik soos wat dit in die ou dae normaal was vir Windows. Dit het egter gehelp, en ons het dit opgetel tot 'n "kernfout" toe ons die nuwe instellings in Sysctl toegepas het. Hoe ligsinnig was dit nie...
Drie weke later het die probleem herhaal. Die konfigurasie van hierdie bedieners was redelik eenvoudig: Nginx in instaanbediener/balanseerdermodus. Nie veel verkeer nie. Nuwe inleidende nota: die aantal 504 foute op kliënte neem elke dag toe (). Die grafiek toon die aantal 504 foute per dag vir hierdie diens:
Al die foute is omtrent dieselfde backend - oor die een wat in die wolk is. Die geheueverbruikgrafiek vir pakketfragmente op hierdie agterkant het soos volg gelyk:
Dit is een van die mees voor die hand liggende manifestasies van die probleem in bedryfstelselgrafieke. In die wolk, net op dieselfde tyd, is nog 'n netwerkprobleem met QoS (Traffic Control) instellings reggestel. Op die grafiek van geheueverbruik vir pakkiefragmente het dit presies dieselfde gelyk:
Die aanname was eenvoudig: as hulle dieselfde lyk op die grafieke, dan het hulle dieselfde rede. Boonop is enige probleme met hierdie tipe geheue uiters skaars.
Die kern van die vaste probleem was dat ons die fq-pakketskeduleerder met verstekinstellings in QoS gebruik het. By verstek, vir een verbinding, laat dit jou toe om 100 pakkies by die tou te voeg, en sommige verbindings, in situasies van kanaaltekorte, het die tou tot kapasiteit begin verstop. In hierdie geval word pakkies laat val. In tc-statistieke (tc -s qdisc) kan dit soos volg gesien word:
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" is die pakkies wat gelaat is as gevolg van die oorskryding van die toulimiet van een verbinding, en "gedrop 464545" is die som van alle weggegooide pakkies van hierdie skeduleerder. Nadat die toulengte na 1 duisend verhoog is en die houers weer begin het, het die probleem opgehou om te voorkom. Jy kan terugsit en 'n smoothie drink.
FragmentSmack/SegmentSmack. Laaste Bloed
Eerstens, 'n paar maande na die aankondiging van kwesbaarhede in die kern, het 'n oplossing vir FragmentSmack uiteindelik verskyn (laat ek jou herinner dat saam met die aankondiging in Augustus, 'n oplossing slegs vir SegmentSmack vrygestel is), wat ons 'n kans gegee het om Workaround te laat vaar, wat ons nogal baie moeilikheid besorg het. Gedurende hierdie tyd het ons reeds daarin geslaag om van die bedieners na die nuwe kern oor te dra, en nou moes ons van die begin af begin. Waarom het ons die kern opgedateer sonder om te wag vir die FragmentSmack-oplossing? Die feit is dat die proses van beskerming teen hierdie kwesbaarhede saamgeval (en saamgesmelt het) met die proses om CentOS self op te dateer (wat selfs meer tyd neem as om net die kern op te dateer). Boonop is SegmentSmack 'n gevaarliker kwesbaarheid, en 'n oplossing daarvoor het onmiddellik verskyn, so dit het in elk geval sin gemaak. Ons kon egter nie bloot die kern op CentOS bywerk nie, want die FragmentSmack-kwesbaarheid, wat tydens CentOS 7.5 verskyn het, is eers in weergawe 7.6 reggestel, so ons moes die opdatering na 7.5 stop en van voor af begin met die opdatering na 7.6. En dit gebeur ook.
Tweedens het seldsame gebruikersklagtes oor probleme na ons teruggekeer. Nou weet ons reeds vir seker dat hulle almal verband hou met die oplaai van lêers van kliënte na sommige van ons bedieners. Boonop het 'n baie klein aantal oplaaie van die totale massa deur hierdie bedieners gegaan.
Soos ons onthou uit die storie hierbo, het die terugrol van Sysctl nie gehelp nie. Herlaai het gehelp, maar tydelik.
Vermoedens rakende Sysctl is nie verwyder nie, maar hierdie keer was dit nodig om soveel moontlik inligting in te samel. Daar was ook 'n groot gebrek aan vermoë om die oplaaiprobleem op die kliënt te reproduseer om meer presies te bestudeer wat aan die gebeur was.
Ontleding van alle beskikbare statistieke en logs het ons nie nader gebring om te verstaan wat aan die gebeur was nie. Daar was 'n akute gebrek aan vermoë om die probleem te reproduseer om 'n spesifieke verband te "voel". Uiteindelik het die ontwikkelaars, met behulp van 'n spesiale weergawe van die toepassing, daarin geslaag om 'n stabiele reproduksie van probleme op 'n toetstoestel te bewerkstellig wanneer hulle via Wi-Fi gekoppel is. Dit was 'n deurbraak in die ondersoek. Die kliënt het gekoppel aan Nginx, wat gevolmagtig is na die agterkant, wat ons Java-toepassing was.
Die dialoog vir probleme was soos volg (opgestel aan die Nginx-instaanbedienerkant):
- Kliënt: versoek om inligting te ontvang oor die aflaai van 'n lêer.
- Java-bediener: antwoord.
- Kliënt: POST met lêer.
- Java-bediener: fout.
Terselfdertyd skryf die Java-bediener aan die logboek dat 0 grepe data van die kliënt ontvang is, en die Nginx-instaanbediener skryf dat die versoek meer as 30 sekondes geneem het (30 sekondes is die tydsverloop van die kliënttoepassing). Hoekom die uitteltyd en hoekom 0 grepe? Vanuit 'n HTTP-perspektief werk alles soos dit moet, maar die POST met die lêer lyk asof dit van die netwerk verdwyn. Boonop verdwyn dit tussen die kliënt en Nginx. Dit is tyd om jouself te bewapen met Tcpdump! Maar eers moet jy die netwerkkonfigurasie verstaan. Nginx-instaanbediener is agter die L3-balanseerder . Tonneling word gebruik om pakkies vanaf die L3-balanseerder na die bediener af te lewer, wat sy opskrifte by die pakkies voeg:
In hierdie geval kom die netwerk na hierdie bediener in die vorm van Vlan-gemerkte verkeer, wat ook sy eie velde by die pakkies voeg:
En hierdie verkeer kan ook gefragmenteer word (dieselfde klein persentasie van inkomende gefragmenteerde verkeer waaroor ons gepraat het toe ons die risiko's van Workaround beoordeel het), wat ook die inhoud van die opskrifte verander:
Weereens: pakkies word ingekapsuleer met 'n Vlan-etiket, ingekapsuleer met 'n tonnel, gefragmenteer. Om beter te verstaan hoe dit gebeur, kom ons volg die pakkieroete van die kliënt na die Nginx-instaanbediener.
- Die pakkie bereik die L3-balanseerder. Vir korrekte roetering binne die datasentrum, word die pakkie in 'n tonnel ingekapsuleer en na die netwerkkaart gestuur.
- Aangesien die pakkie + tonnelopskrifte nie in die MTU pas nie, word die pakkie in fragmente gesny en na die netwerk gestuur.
- Die skakelaar na die L3-balanseerder, wanneer 'n pakkie ontvang word, voeg 'n Vlan-etiket daarby en stuur dit aan.
- Die skakelaar voor die Nginx-instaanbediener sien (gebaseer op die poortinstellings) dat die bediener 'n Vlan-ingekapsuleerde pakkie verwag, so dit stuur dit soos dit is, sonder om die Vlan-merker te verwyder.
- Linux neem fragmente van individuele pakkette en voeg dit saam in een groot pakket.
- Vervolgens bereik die pakkie die Vlan-koppelvlak, waar die eerste laag daarvan verwyder word - Vlan-inkapseling.
- Linux stuur dit dan na die Tunnel-koppelvlak, waar 'n ander laag daarvan verwyder word - Tunnel-enkapsulasie.
Die moeilikheid is om dit alles as parameters na tcpdump deur te gee.
Kom ons begin van die einde af: is daar skoon (sonder onnodige kopskrifte) IP-pakkies van kliënte, met vlan en tonnel-inkapseling verwyder?
tcpdump host <ip клиента>
Nee, daar was nie sulke pakkette op die bediener nie. Die probleem moet dus vroeër daar wees. Is daar enige pakkies met slegs Vlan-inkapseling verwyder?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx is die kliënt IP-adres in hex-formaat.
32:4 — adres en lengte van die veld waarin die SCR IP in die Tonnel-pakkie geskryf is.
Die veldadres moes met brute geweld gekies word, want op die internet skryf hulle omtrent 40, 44, 50, 54, maar daar was geen IP-adres daar nie. Jy kan ook na een van die pakkies in hex kyk (die -xx of -XX parameter in tcpdump) en die IP-adres wat jy ken, bereken.
Is daar pakkie fragmente sonder Vlan en tonnel inkapseling verwyder?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Hierdie magie sal ons al die fragmente wys, insluitend die laaste een. Waarskynlik kan dieselfde ding deur IP gefiltreer word, maar ek het nie probeer nie, want daar is nie baie sulke pakkies nie, en die wat ek nodig gehad het, is maklik in die algemene vloei gevind. Hier is hulle:
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 ..............
Dit is twee fragmente van een pakkie (dieselfde ID 53652) met 'n foto (die woord Exif is sigbaar in die eerste pakkie). As gevolg van die feit dat daar pakkette op hierdie vlak is, maar nie in die saamgevoegde vorm in die stortingsterreine nie, is die probleem duidelik by die samestelling. Uiteindelik is daar dokumentêre bewyse hiervan!
Die pakkie-dekodeerder het geen probleme geopenbaar wat die bou sou verhoed nie. Het dit hier probeer: . Aanvanklik, wanneer jy iets daar probeer indruk, hou die dekodeerder nie van die pakkieformaat nie. Dit het geblyk dat daar 'n paar ekstra twee oktette tussen Srcmac en Ethertype was (nie verwant aan fragmentinligting nie). Nadat dit verwyder is, het die dekodeerder begin werk. Dit het egter geen probleme getoon nie.
Wat 'n mens ook al mag sê, niks anders is gevind behalwe daardie Sysctl. Al wat oorgebly het, was om 'n manier te vind om probleembedieners te identifiseer om die skaal te verstaan en op verdere aksies te besluit. Die vereiste teller is vinnig genoeg gevind:
netstat -s | grep "packet reassembles failed”
Dit is ook in snmpd onder OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"Die aantal foute wat deur die IP-hersamestellingsalgoritme opgespoor is (om watter rede ook al: uitgetel, foute, ens.)"
Onder die groep bedieners waarop die probleem bestudeer is, het hierdie teller op twee vinniger toegeneem, op twee stadiger, en op nog twee het dit glad nie toegeneem nie. Die vergelyking van die dinamika van hierdie teller met die dinamika van HTTP-foute op die Java-bediener het 'n korrelasie aan die lig gebring. Dit wil sê, die meter kan gemonitor word.
Om 'n betroubare aanwyser van probleme te hê, is baie belangrik sodat u akkuraat kan bepaal of die terugrol van Sysctl help, aangesien ons uit die vorige storie weet dat dit nie onmiddellik uit die toepassing verstaan kan word nie. Hierdie aanwyser sal ons toelaat om alle probleemareas in produksie te identifiseer voordat gebruikers dit ontdek.
Nadat Sysctl teruggerol is, het die moniteringsfoute gestop, dus is die oorsaak van die probleme bewys, asook die feit dat die terugrol help.
Ons het die fragmentasie-instellings op ander bedieners teruggedraai, waar nuwe monitering ter sprake gekom het, en iewers het ons selfs meer geheue vir fragmente toegewys as wat voorheen die verstek was (dit was UDP-statistieke, waarvan die gedeeltelike verlies nie teen die algemene agtergrond opmerklik was nie) .
Die belangrikste vrae
Waarom word pakkies op ons L3-balanseerder gefragmenteer? Die meeste van die pakkies wat van gebruikers na balanseerders kom, is SYN en ACK. Die groottes van hierdie pakkette is klein. Maar aangesien die aandeel van sulke pakkies baie groot is, het ons teen hul agtergrond nie die teenwoordigheid van groot pakkies opgemerk wat begin fragmenteer nie.
Die rede was 'n stukkende konfigurasieskrif op bedieners met Vlan-koppelvlakke (daar was op daardie stadium baie min bedieners met gemerkte verkeer in produksie). Advmss stel ons in staat om die inligting aan die kliënt oor te dra dat pakkies in ons rigting kleiner in grootte moet wees sodat hulle nie gefragmenteer hoef te word nadat tonnelopskrifte daaraan geheg is nie.
Waarom het Sysctl-terugrol nie gehelp nie, maar herlaai wel? Deur Sysctl terug te rol, het die hoeveelheid geheue wat beskikbaar is vir die samevoeging van pakkette verander. Terselfdertyd het die feit van geheue-oorloop vir fragmente blykbaar gelei tot verlangsaming van verbindings, wat daartoe gelei het dat fragmente vir 'n lang tyd in die tou vertraag is. Dit wil sê, die proses het in siklusse verloop.
Die herlaai het die geheue skoongemaak en alles het na orde teruggekeer.
Was dit moontlik om sonder Oplossing te doen? Ja, maar daar is 'n hoë risiko om gebruikers sonder diens te laat in die geval van 'n aanval. Natuurlik het die gebruik van Workaround verskeie probleme tot gevolg gehad, insluitend die verlangsaming van een van die dienste vir gebruikers, maar nietemin glo ons dat die aksies geregverdig was.
Baie dankie aan Andrey Timofeev () vir hulp met die uitvoer van die ondersoek, asook Alexey Krenev () - vir die titaniese werk om Centos en pitte op bedieners op te dateer. ’n Proses wat in hierdie geval verskeie kere van die begin af begin moes word, daarom het dit vir baie maande gesloer.
Bron: will.com