Hæ allir! Ég heiti Dmitry Samsonov, ég vinn sem leiðandi kerfisstjóri hjá Odnoklassniki. Við erum með meira en 7 þúsund líkamlega netþjóna, 11 þúsund gáma í skýinu okkar og 200 forrit, sem í ýmsum uppsetningum mynda 700 mismunandi klasa. Langflestir netþjónar keyra CentOS 7.
Þann 14. ágúst 2018 voru upplýsingar um FragmentSmack varnarleysið birtar
() og SegmentSmack (). Þetta eru veikleikar með netárásarvektor og nokkuð háa einkunn (7.5), sem ógnar afneitun á þjónustu (DoS) vegna auðlindaþreytu (CPU). Ekki var lögð til kjarnaleiðrétting fyrir FragmentSmack á þeim tíma; þar að auki kom hún út mun seinna en birting upplýsinga um varnarleysið. Til að útrýma SegmentSmack var lagt til að uppfæra kjarnann. Uppfærslupakkinn sjálfur var gefinn út sama dag, það eina sem var eftir var að setja hann upp.
Nei, við erum alls ekki á móti því að uppfæra kjarnann! Hins vegar eru blæbrigði ...
Hvernig við uppfærum kjarnann við framleiðslu
Almennt séð ekkert flókið:
- Sækja pakka;
- Settu þau upp á fjölda netþjóna (þar á meðal netþjóna sem hýsa skýið okkar);
- Gakktu úr skugga um að ekkert sé brotið;
- Gakktu úr skugga um að allar staðlaðar kjarnastillingar séu notaðar án villna;
- Bíddu í nokkra daga;
- Athugaðu frammistöðu netþjónsins;
- Skiptu um dreifingu nýrra netþjóna yfir í nýja kjarnann;
- Uppfærðu alla netþjóna eftir gagnaveri (ein gagnaver í einu til að lágmarka áhrif á notendur ef vandamál koma upp);
- Endurræstu alla netþjóna.
Endurtaktu fyrir allar greinar kjarna sem við höfum. Í augnablikinu er það:
- Stock CentOS 7 3.10 - fyrir flesta venjulega netþjóna;
- Vanilla 4.19 - fyrir okkar , vegna þess að við þurfum BFQ, BBR, osfrv.;
- Elrepo kjarna-ml 5.2 - fyrir , vegna þess að 4.19 hegðaði sér áður óstöðugt, en sömu eiginleika er þörf.
Eins og þú gætir hafa giskað á tekur langan tíma að endurræsa þúsundir netþjóna. Þar sem ekki allir veikleikar eru mikilvægir fyrir alla netþjóna, endurræsum við aðeins þá sem eru aðgengilegir beint af internetinu. Í skýinu, til að takmarka ekki sveigjanleika, bindum við ekki utanaðkomandi gáma við einstaka netþjóna með nýjum kjarna, heldur endurræsum alla véla án undantekninga. Sem betur fer er málsmeðferðin þar einfaldari en með venjulegum netþjónum. Til dæmis geta ríkisfangslausir gámar einfaldlega færst yfir á annan netþjón við endurræsingu.
Hins vegar er enn mikil vinna, og það getur tekið nokkrar vikur, og ef einhver vandamál eru með nýju útgáfuna, allt að nokkra mánuði. Árásarmenn skilja þetta mjög vel, svo þeir þurfa plan B.
FragmentSmack/SegmentSmack. Vinna í kringum
Sem betur fer, fyrir suma veikleika, er slík áætlun B til, og hún er kölluð lausn. Oftast er þetta breyting á kjarna/forritsstillingum sem geta lágmarkað hugsanleg áhrif eða alveg útrýmt hagnýtingu veikleika.
Í tilviki FragmentSmack/SegmentSmack þessi lausn:
«Þú getur breytt sjálfgefnum gildum 4MB og 3MB í net.ipv4.ipfrag_high_thresh og net.ipv4.ipfrag_low_thresh (og hliðstæða þeirra fyrir ipv6 net.ipv6.ipfrag_high_thresh og net.ipv6.ipfrag_low_thresh) í 256 kB eða 192 kB í sömu röð lægri. Próf sýna litla til verulega lækkun á örgjörvanotkun meðan á árás stendur, allt eftir vélbúnaði, stillingum og aðstæðum. Hins vegar gæti það verið einhver áhrif á frammistöðu vegna ipfrag_high_thresh=262144 bæta, þar sem aðeins tvö 64K brot geta passað inn í samsetningarröðina í einu. Til dæmis er hætta á að forrit sem vinna með stórum UDP pakka brotni'.
Færibreyturnar sjálfar lýst sem hér segir:
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.
Við höfum ekki stórar UDPs á framleiðsluþjónustu. Það er engin sundurleit umferð á staðarnetinu; það er sundurleit umferð á WAN, en ekki marktæk. Það eru engin merki - þú getur sett út lausn!
FragmentSmack/SegmentSmack. Fyrsta blóð
Fyrsta vandamálið sem við lentum í var að skýjagámar beittu nýju stillingunum stundum aðeins að hluta (aðeins ipfrag_low_thresh) og stundum alls ekki - þeir hrundu einfaldlega í byrjun. Það var ekki hægt að endurskapa vandamálið stöðugt (allar stillingar voru notaðar handvirkt án nokkurra erfiðleika). Að skilja hvers vegna gámurinn hrynur í byrjun er heldur ekki svo auðvelt: engar villur fundust. Eitt var víst: að snúa stillingunum til baka leysir vandamálið með gámahruni.
Af hverju er ekki nóg að nota Sysctl á gestgjafann? Gámurinn býr í sínu eigin sérstöku nafnarými, svo að minnsta kosti í ílátinu getur verið frábrugðið hýslinum.
Hvernig nákvæmlega er Sysctl stillingum beitt í ílátinu? Þar sem gámarnir okkar eru forréttindalausir muntu ekki geta breytt neinni Sysctl stillingu með því að fara inn í gáminn sjálfan - þú hefur einfaldlega ekki næg réttindi. Til að keyra gáma notaði skýið okkar á þeim tíma Docker (nú ). Færibreytur nýja gámsins voru sendar til Docker í gegnum API, þar á meðal nauðsynlegar Sysctl stillingar.
Þegar leitað var í gegnum útgáfurnar kom í ljós að Docker API skilaði ekki öllum villum (að minnsta kosti í útgáfu 1.10). Þegar við reyndum að ræsa gáminn með „docker run“ sáum við loksins að minnsta kosti eitthvað:
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.
Færugildið er ekki gilt. En afhverju? Og hvers vegna gildir það ekki bara stundum? Það kom í ljós að Docker ábyrgist ekki í hvaða röð Sysctl færibreytum er beitt (nýjasta prófuð útgáfan er 1.13.1), svo stundum reyndi að stilla ipfrag_high_thresh á 256K þegar ipfrag_low_thresh var enn 3M, það er að segja að efri mörkin voru lægri en neðri mörkin, sem leiddi til villunnar.
Á þeim tíma notuðum við nú þegar okkar eigin kerfi til að endurstilla ílátið eftir ræsingu (frysta ílátið eftir og framkvæma skipanir í nafnrými ílátsins í gegnum ), og við bættum líka ritstýringum Sysctl við þennan hluta. Vandamálið var leyst.
FragmentSmack/SegmentSmack. Fyrsta blóðið 2
Áður en við höfðum tíma til að skilja notkun Workaround í skýinu fóru fyrstu sjaldgæfu kvartanir frá notendum að berast. Á þeim tíma voru nokkrar vikur liðnar frá því að byrjað var að nota Workaround á fyrstu netþjónunum. Fyrstu rannsóknin leiddi í ljós að kvartanir bárust á hendur einstakri þjónustu og ekki öllum þjónum þessarar þjónustu. Vandinn er aftur orðinn afar óviss.
Fyrst og fremst reyndum við að sjálfsögðu að snúa Sysctl stillingunum til baka, en það hafði engin áhrif. Ýmsar meðhöndlun með netþjóninn og forritastillingar hjálpuðu ekki heldur. Endurræsa hjálpaði. Að endurræsa Linux er jafn óeðlilegt og það var eðlilegt fyrir Windows í gamla daga. Hins vegar hjálpaði það og við krítuðum það upp í „kjarnabilun“ þegar nýju stillingunum var beitt í Sysctl. Hversu fáránlegt það var...
Þremur vikum síðar kom vandamálið upp aftur. Uppsetning þessara netþjóna var frekar einföld: Nginx í proxy / jafnvægisstillingu. Ekki mikil umferð. Ný inngangsskýring: fjöldi 504 villna hjá viðskiptavinum eykst með hverjum deginum (). Grafið sýnir fjölda 504 villna á dag fyrir þessa þjónustu:
Allar villurnar eru um sama bakenda - um þann sem er í skýinu. Minnisnotkunargrafið fyrir pakkabrot á þessum bakenda leit svona út:
Þetta er ein augljósasta birtingarmynd vandamálsins í línuritum stýrikerfisins. Í skýinu, á sama tíma, var annað netvandamál með QoS (umferðarstjórnun) stillingum lagað. Á grafi yfir minnisnotkun fyrir pakkabrot leit það nákvæmlega eins út:
Forsendan var einföld: ef þau líta eins út á línuritunum, þá hafa þau sömu ástæðu. Þar að auki eru öll vandamál með þessa tegund af minni afar sjaldgæf.
Kjarninn í fasta vandamálinu var að við notuðum fq pakkaáætlunina með sjálfgefnum stillingum í QoS. Sjálfgefið, fyrir eina tengingu, gerir það þér kleift að bæta 100 pökkum við biðröðina, og sumar tengingar, í rásaskorti, fóru að stífla biðröðina. Í þessu tilviki falla pakkar niður. Í tc tölfræði (tc -s qdisc) má sjá þetta svona:
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“ er pakkarnir sem sleppt hafa verið vegna þess að farið er yfir biðröð einni tengingar, og „sleppt 464545“ er summa allra slepptu pakka þessa tímaáætlunarbúnaðar. Eftir að hafa lengt biðröðina í 1 þúsund og endurræst gámana hætti vandamálið að koma upp. Þú getur hallað þér aftur og drukkið smoothie.
FragmentSmack/SegmentSmack. Síðasta blóðið
Í fyrsta lagi, nokkrum mánuðum eftir að tilkynnt var um veikleika í kjarnanum, birtist loksins lagfæring fyrir FragmentSmack (mig minnir þig á að samhliða tilkynningunni í ágúst var lagfæring aðeins fyrir SegmentSmack gefin út), sem gaf okkur tækifæri til að yfirgefa Workaround, sem olli okkur töluverðum vandræðum. Á þessum tíma höfðum við þegar náð að flytja hluta af netþjónunum yfir á nýja kjarnann og nú þurftum við að byrja á byrjuninni. Af hverju uppfærðum við kjarnann án þess að bíða eftir FragmentSmack lagfæringunni? Staðreyndin er sú að ferlið við að vernda gegn þessum veikleikum féll saman (og sameinaðist) ferlinu við að uppfæra CentOS sjálft (sem tekur jafnvel lengri tíma en að uppfæra aðeins kjarnann). Að auki er SegmentSmack hættulegri varnarleysi og lagfæring fyrir það birtist strax, svo það var skynsamlegt samt. Hins vegar gátum við ekki einfaldlega uppfært kjarnann á CentOS vegna þess að FragmentSmack varnarleysið, sem birtist á CentOS 7.5, var aðeins lagað í útgáfu 7.6, þannig að við urðum að hætta uppfærslunni í 7.5 og byrja upp á nýtt með uppfærsluna í 7.6. Og þetta gerist líka.
Í öðru lagi hafa sjaldgæfar kvartanir notenda um vandamál komið aftur til okkar. Nú vitum við nú þegar með vissu að þær eru allar tengdar upphleðslu skráa frá viðskiptavinum á suma netþjóna okkar. Þar að auki fór mjög lítill fjöldi upphleðinga af heildarmassanum í gegnum þessa netþjóna.
Eins og við munum eftir sögunni hér að ofan hjálpaði það ekki að snúa Sysctl til baka. Endurræsa hjálpaði, en tímabundið.
Grunsemdir um Sysctl voru ekki fjarlægðar en að þessu sinni þurfti að safna eins miklum upplýsingum og hægt var. Það var líka mikill skortur á getu til að endurskapa upphleðsluvandamálið á viðskiptavininn til að rannsaka nánar hvað var að gerast.
Greining á allri tiltækri tölfræði og annálum færði okkur ekki nær því að skilja hvað var að gerast. Það var bráður skortur á getu til að endurskapa vandamálið til að "finna fyrir" ákveðinni tengingu. Að lokum tókst verktaki, með því að nota sérstaka útgáfu af forritinu, að ná stöðugri endurgerð vandamála á prófunartæki þegar það var tengt í gegnum Wi-Fi. Þetta var bylting í rannsókninni. Viðskiptavinurinn tengdist Nginx, sem var umboð til bakendans, sem var Java forritið okkar.
Samtalið um vandamál var svona (lagað á Nginx umboðshliðinni):
- Viðskiptavinur: beiðni um að fá upplýsingar um niðurhal á skrá.
- Java þjónn: svar.
- Viðskiptavinur: POST með skrá.
- Java þjónn: villa.
Jafnframt skrifar Java þjónninn í notendaskrána að 0 bæti af gögnum hafi borist frá biðlaranum og Nginx umboðið skrifar að beiðnin hafi tekið meira en 30 sekúndur (30 sekúndur er tímamörk biðlaraforritsins). Hvers vegna tímamörk og hvers vegna 0 bæti? Frá HTTP sjónarhorni virkar allt eins og það á að gera, en POST með skránni virðist hverfa af netinu. Þar að auki hverfur það á milli viðskiptavinarins og Nginx. Það er kominn tími til að vopna þig með Tcpdump! En fyrst þarftu að skilja netuppsetninguna. Nginx umboð er á bak við L3 jafnvægisbúnaðinn . Jarðgöng eru notuð til að afhenda pakka frá L3 jafnvægisbúnaðinum til netþjónsins, sem bætir hausum sínum við pakkana:
Í þessu tilviki kemur netið á þennan netþjón í formi Vlan-merktrar umferðar, sem bætir einnig eigin reitum við pakkana:
Og þessi umferð getur líka verið sundurleit (það sama litla hlutfall af komandi sundurleitri umferð og við ræddum um þegar áhætturnar af lausninni voru metnar), sem breytir einnig innihaldi hausanna:
Enn og aftur: pakkarnir eru hjúpaðir með Vlan-merki, hjúpaðir með göngum, sundraðir. Til að skilja betur hvernig þetta gerist skulum við rekja pakkaleiðina frá viðskiptavininum til Nginx umboðsins.
- Pakkinn nær L3 jafnvægisbúnaðinum. Til að beina réttri leið innan gagnaversins er pakkinn hjúpaður í göng og sendur á netkortið.
- Þar sem pakka + göng hausarnir passa ekki inn í MTU er pakkinn skorinn í brot og sendur á netið.
- Rofinn á eftir L3 jafnvægisbúnaðinum, þegar hann tekur á móti pakka, bætir Vlan tagi við hann og sendir hann áfram.
- Rofi fyrir framan Nginx proxy sér (byggt á tengistillingum) að þjónninn á von á Vlan-hjúpuðum pakka, svo hann sendir hann eins og hann er, án þess að fjarlægja Vlan-merkið.
- Linux tekur brot af einstökum pakka og sameinar þá í einn stóran pakka.
- Næst nær pakkinn Vlan viðmótinu, þar sem fyrsta lagið er fjarlægt úr honum - Vlan encapsulation.
- Linux sendir það síðan í Tunnel tengið, þar sem annað lag er fjarlægt úr því - Tunnel encapsulation.
Erfiðleikarnir eru að senda allt þetta sem breytur til tcpdump.
Byrjum á endanum: Eru til hreinir (án óþarfa hausa) IP-pakkar frá viðskiptavinum, með vlan og göngumhlíf fjarlægt?
tcpdump host <ip клиента>
Nei, það voru engir slíkir pakkar á þjóninum. Þannig að vandamálið hlýtur að vera fyrr. Eru einhverjir pakkar með aðeins Vlan-hjúpun fjarlægð?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx er IP-tala viðskiptavinarins á hex sniði.
32:4 — heimilisfang og lengd reitsins þar sem SCR IP er skrifað í Tunnel pakkann.
Velja þurfti netfangið með grófu valdi, þar sem á netinu skrifa þeir um 40, 44, 50, 54, en það var engin IP-tala þar. Þú getur líka skoðað einn af pakkanum í hex (-xx eða -XX færibreytan í tcpdump) og reiknað út IP töluna sem þú þekkir.
Eru pakkabrot án Vlan og Tunnel encapsulation fjarlægð?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Þessi galdur mun sýna okkur öll brotin, þar á meðal það síðasta. Sennilega er hægt að sía það sama eftir IP, en ég reyndi ekki, vegna þess að það eru ekki mjög margir slíkir pakkar og þeir sem ég þurfti fundust auðveldlega í almennu flæðinu. Hér eru þau:
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 ..............
Þetta eru tvö brot úr einum pakka (sama auðkenni 53652) með ljósmynd (orðið Exif sést í fyrsta pakkanum). Vegna þess að það eru pakkar á þessu stigi, en ekki í sameinuðu formi á sorphaugunum, er vandamálið greinilega með samsetningunni. Loksins eru til heimildargögn um þetta!
Pakkaafkóðarinn leiddi ekki í ljós nein vandamál sem kæmu í veg fyrir smíðina. Prófaði það hér: . Í fyrstu, þegar þú reynir að troða einhverju þar, líkar afkóðaranum ekki pakkasniðið. Það kom í ljós að það voru einhverjir auka tveir oktettar á milli Srcmac og Ethertype (ekki tengt við brotaupplýsingar). Eftir að hafa fjarlægt þau fór afkóðarinn að virka. Hins vegar sýndi það engin vandamál.
Hvað sem menn segja, þá fannst ekkert annað en þeir Sysctl. Allt sem var eftir var að finna leið til að bera kennsl á vandamálaþjóna til að skilja umfangið og ákveða frekari aðgerðir. Nauðsynlegur teljari fannst nógu fljótt:
netstat -s | grep "packet reassembles failed”
Það er líka í snmpd undir OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
„Fjöldi bilana sem greindist af reikniritinu fyrir endursamsetningu IP (af hvaða ástæðu sem er: rann út á tíma, villur osfrv.).“
Meðal netþjónahópsins sem vandamálið var rannsakað á, á tveimur jókst þessi teljari hraðar, á tveimur hægar og á tveimur til viðbótar jókst hann alls ekki. Samanburður á gangverki þessa teljara við gangverki HTTP villna á Java netþjóninum leiddi í ljós fylgni. Það er að segja að hægt væri að fylgjast með mælinum.
Að hafa áreiðanlega vísbendingu um vandamál er mjög mikilvægt svo að þú getir nákvæmlega ákvarðað hvort að afturkalla Sysctl hjálpar, þar sem frá fyrri sögu vitum við að þetta er ekki hægt að skilja strax af forritinu. Þessi vísir myndi gera okkur kleift að bera kennsl á öll vandamálasvæði í framleiðslu áður en notendur uppgötva það.
Eftir að Sysctl var snúið til baka hættu vöktunarvillurnar, þar með var orsök vandamálanna sönnuð, sem og sú staðreynd að afturköllunin hjálpar.
Við afturkölluðum sundurliðunarstillingarnar á öðrum netþjónum, þar sem nýtt eftirlit kom til sögunnar, og einhvers staðar úthlutaðum við enn meira minni fyrir brot en áður var sjálfgefið (þetta var UDP tölfræði, en tapið að hluta var ekki áberandi miðað við almennan bakgrunn) .
Mikilvægustu spurningarnar
Af hverju eru pakkar sundraðir á L3 jafnvægisbúnaðinum okkar? Flestir pakkarnir sem berast frá notendum til jafnvægisaðila eru SYN og ACK. Stærðir þessara pakka eru litlar. En þar sem hlutur slíkra pakka er mjög stór, gegn bakgrunni þeirra, tókum við ekki eftir tilvist stórra pakka sem fóru að sundrast.
Ástæðan var biluð uppsetningarforskrift á netþjónum með Vlan tengi (það voru mjög fáir netþjónar með merkta umferð í framleiðslu á þeim tíma). Advmss gerir okkur kleift að miðla til viðskiptavinarins þær upplýsingar að pakkar í áttina okkar ættu að vera minni í stærð svo að eftir að hafa fest gönghausa við þá þurfi þeir ekki að vera sundraðir.
Af hverju hjálpaði Sysctl afturköllun ekki, en endurræsa gerði það? Þegar Sysctl var snúið til baka breyttist magn af minni tiltækt til að sameina pakka. Á sama tíma virðist sú staðreynd að minni flæðir fyrir brot hafa leitt til hægfara á tengingum, sem leiddi til þess að brotin seinkuðust í langan tíma í biðröðinni. Það er að segja að ferlið fór í lotum.
Endurræsingin hreinsaði minnið og allt kom aftur í röð.
Var hægt að gera án lausnar? Já, en það er mikil hætta á að notendur skilji þjónustulausa ef árás verður. Að sjálfsögðu leiddi notkun Workaround til ýmissa vandamála, þar á meðal hægði á einni þjónustu fyrir notendur, en engu að síður teljum við að aðgerðirnar hafi verið réttlætanlegar.
Kærar þakkir til Andrey Timofeev () fyrir aðstoð við framkvæmd rannsóknarinnar, sem og Alexey Krenev () - fyrir títaníska vinnu við að uppfæra Centos og kjarna á netþjónum. Ferli sem í þessu tilviki þurfti að hefja nokkrum sinnum frá upphafi og þess vegna dróst það á langinn.
Heimild: www.habr.com