Hoi allegearre! Myn namme is Dmitry Samsonov, ik wurkje as in liedende systeembehearder by Odnoklassniki. Wy hawwe mear as 7 tûzen fysike tsjinners, 11 tûzen konteners yn ús wolk en 200 applikaasjes, dy't yn ferskate konfiguraasjes 700 ferskillende klusters foarmje. De grutte mearderheid fan servers rint CentOS 7.
Op 14 augustus 2018 waard ynformaasje publisearre oer de kwetsberens fan FragmentSmack
() en SegmentSmack (). Dit binne kwetsberens mei in netwurk oanfal vector en in frij hege skoare (7.5), dy't bedrige ûntkenning fan tsjinst (DoS) fanwege resource útputting (CPU). In kernelfix foar FragmentSmack waard op dat stuit net foarsteld; boppedat kaam it folle letter út as de publikaasje fan ynformaasje oer de kwetsberens. Om SegmentSmack te eliminearjen, waard foarsteld om de kernel te aktualisearjen. It updatepakket sels waard deselde dei frijlitten, alles wat oerbleau wie it te ynstallearjen.
Nee, wy binne hielendal net tsjin it bywurkjen fan de kernel! D'r binne lykwols nuânses ...
Hoe't wy de kernel bywurkje by produksje
Yn it algemien, neat yngewikkeld:
- Download pakketten;
- Ynstallearje se op in oantal servers (ynklusyf servers dy't ús wolk hostje);
- Soargje derfoar dat neat brutsen is;
- Soargje derfoar dat alle standert kernel ynstellings wurde tapast sûnder flaters;
- Wachtsje in pear dagen;
- Kontrolearje tsjinner prestaasjes;
- Skeakelje ynset fan nije tsjinners nei de nije kernel;
- Update alle servers troch datasintrum (ien datasintrum tagelyk om it effekt op brûkers yn gefal fan problemen te minimalisearjen);
- Reboot alle tsjinners.
Werhelje foar alle tûken fan 'e kernels dy't wy hawwe. Op it stuit is it:
- Stock CentOS 7 3.10 - foar de measte reguliere tsjinners;
- Vanilla 4.19 - foar ús , om't wy BFQ, BBR, ensfh.
- Elrepo kernel-ml 5.2 - foar , om't 4.19 eartiids ynstabyl gedrage, mar deselde funksjes binne nedich.
Lykas jo miskien hawwe rieden, nimt it opstarten fan tûzenen servers de langste tiid. Om't net alle kwetsberens kritysk binne foar alle servers, starte wy allinich dejingen dy't direkt tagonklik binne fan it ynternet op 'e nij. Yn 'e wolk, om de fleksibiliteit net te beheinen, bine wy gjin eksterne tagonklike konteners oan yndividuele servers mei in nije kernel, mar opnij alle hosts sûnder útsûndering. Gelokkich is de proseduere dêr ienfâldiger dan mei gewoane servers. Bygelyks, steatleaze konteners kinne gewoanwei ferpleatse nei in oare server by in trochstart.
Lykwols, der is noch in soad wurk, en it kin nimme ferskate wiken, en as der gjin problemen mei de nije ferzje, oant ferskate moannen. Oanfallers begripe dit hiel goed, dus se hawwe in plan B nedich.
FragmentSmack/SegmentSmack. Oplossing
Gelokkich, foar guon kwetsberens bestiet sa'n plan B, en it hjit Workaround. Meastentiids is dit in feroaring yn kernel / applikaasje-ynstellingen dy't it mooglike effekt minimalisearje kinne of de eksploitaasje fan kwetsberens folslein eliminearje.
Yn it gefal fan FragmentSmack/SegmentSmack dizze oplossing:
«Jo kinne de standertwearden fan 4MB en 3MB feroarje yn net.ipv4.ipfrag_high_thresh en net.ipv4.ipfrag_low_thresh (en har tsjinhingers foar ipv6 net.ipv6.ipfrag_high_thresh en net.ipv6.ipfrag_low_thresh) nei respektivelik 256 kB of 192 kB of respektivelik leger. Tests litte lytse oant signifikante drippen sjen yn CPU-gebrûk by in oanfal ôfhinklik fan hardware, ynstellings en betingsten. D'r kin lykwols wat ynfloed op prestaasjes wêze troch ipfrag_high_thresh=262144 bytes, om't mar twa 64K-fragminten tagelyk yn 'e weryndielingswachtrige kinne passe. D'r is bygelyks in risiko dat applikaasjes dy't wurkje mei grutte UDP-pakketten brekke".
De parameters sels beskreaun as folget:
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.
Wy hawwe gjin grutte UDP's op produksjetsjinsten. D'r is gjin fragminteare ferkear op it LAN; d'r is fragminteare ferkear op it WAN, mar net signifikant. D'r binne gjin tekens - jo kinne Workaround útrolje!
FragmentSmack/SegmentSmack. Earste bloed
It earste probleem dat wy tsjinkamen wie dat wolkcontainers de nije ynstellings soms mar foar in part tapasten (allinich ipfrag_low_thresh), en soms hielendal net tapasten - se ferûngelokke gewoan by it begjin. It wie net mooglik om it probleem stabyl te reprodusearjen (alle ynstellings waarden sûnder swierrichheden mei de hân tapast). Begripe wêrom't de kontener by de start crasht is ek net sa maklik: der binne gjin flaters fûn. Ien ding wie wis: it weromrôljen fan de ynstellingen lost it probleem op mei kontenerûngelok.
Wêrom is it net genôch om Sysctl oan te passen op 'e host? De kontener libbet yn in eigen tawijd netwurk Namespace, dus teminsten yn 'e kontener kin ferskille fan' e host.
Hoe krekt wurde Sysctl-ynstellingen tapast yn 'e kontener? Om't ús konteners unprivileged binne, kinne jo gjin Sysctl-ynstelling feroarje troch yn 'e kontener sels te gean - jo hawwe gewoan net genôch rjochten. Om konteners út te fieren, brûkte ús wolk op dat stuit Docker (no ). De parameters fan 'e nije kontener waarden trochjûn oan Docker fia de API, ynklusyf de nedige Sysctl-ynstellingen.
By it sykjen troch de ferzjes die bliken dat de Docker API net alle flaters weromkaam (op syn minst yn ferzje 1.10). Doe't wy besochten om de kontener te starten fia "docker run", seagen wy úteinlik op syn minst wat:
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.
De parameterwearde is net jildich. Wêrom? En wêrom is it net allinich soms jildich? It die bliken dat Docker de folchoarder net garandearret wêryn't Sysctl-parameters wurde tapast (de lêste testen ferzje is 1.13.1), dus soms besocht ipfrag_high_thresh te setten op 256K doe't ipfrag_low_thresh noch 3M wie, dat is, de boppegrins wie leger dan de legere limyt, wat late ta de flater.
Op dat stuit hawwe wy al ús eigen meganisme brûkt om de kontener nei it begjin te konfigurearjen (de kontener nei it befriezen en it útfieren fan kommando's yn 'e nammeromte fan' e kontener fia ), en wy hawwe ek skriuwen Sysctl parameters tafoege oan dit diel. It probleem waard oplost.
FragmentSmack/SegmentSmack. Earste bloed 2
Foardat wy tiid hiene om it gebrûk fan Workaround yn 'e wolk te begripen, begon de earste seldsume klachten fan brûkers te kommen. Op dat stuit wiene ferskate wiken ferrûn sûnt it begjin fan it brûken fan Workaround op 'e earste servers. It earste ûndersyk die bliken dat klachten waarden ûntfongen tsjin yndividuele tsjinsten, en net alle servers fan dizze tsjinsten. It probleem is wer tige ûnwis wurden.
As earste hawwe wy fansels besocht de Sysctl-ynstellingen werom te rôljen, mar dit hie gjin effekt. Ferskate manipulaasjes mei de server- en applikaasjeynstellingen holpen ek net. Reboot holp. Linux opnij opstarte is sa ûnnatuerlik as it normaal wie foar Windows yn 'e âlde dagen. It holp lykwols, en wy kamen it oant in "kernel glitch" by it tapassen fan de nije ynstellings yn Sysctl. Wat wie it nuver...
Trije wiken letter kaam it probleem werom. De konfiguraasje fan dizze tsjinners wie frij simpel: Nginx yn proxy / balancer modus. Net folle ferkear. Nije ynliedende notysje: it oantal 504 flaters op kliïnten nimt elke dei ta (). De grafyk toant it oantal 504 flaters per dei foar dizze tsjinst:
Alle flaters binne oer deselde backend - oer dejinge dy't yn 'e wolk is. De grafyk foar ûnthâldferbrûk foar pakketfragminten op dizze backend seach der sa út:
Dit is ien fan de meast foar de hân lizzende manifestaasjes fan it probleem yn bestjoeringssysteem grafiken. Yn 'e wolk, krekt tagelyk, waard in oar netwurkprobleem mei QoS (Traffic Control) ynstellings repareare. Op 'e grafyk fan ûnthâldferbrûk foar pakketfragminten seach it krekt itselde út:
De oanname wie ienfâldich: as se op 'e grafiken itselde sjogge, dan hawwe se deselde reden. Boppedat binne alle problemen mei dit soarte ûnthâld ekstreem seldsum.
De essinsje fan it fêste probleem wie dat wy de fq-pakketplanner brûkten mei standertynstellingen yn QoS. Standert, foar ien ferbining, kinne jo 100 pakketten tafoegje oan 'e wachtrige, en guon ferbiningen, yn situaasjes fan kanaaltekoart, begûnen de wachtrige te ferstoppe. Yn dit gefal wurde pakketten fallen. Yn tc-statistiken (tc -s qdisc) kin it sa sjoen wurde:
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 de pakketten dy't falle binne fanwege it oersjen fan de wachtrige limyt fan ien ferbining, en "fallen 464545" is de som fan alle sakke pakketten fan dizze planner. Nei it fergrutsjen fan de wachtrige lingte nei 1 tûzen en de konteners opnij starte, stoppe it probleem mei foarkommen. Jo kinne efteroer sitte en in smoothie drinke.
FragmentSmack/SegmentSmack. Lêste Bloed
As earste, ferskate moannen nei de oankundiging fan kwetsberens yn 'e kernel, ferskynde einlings in fix foar FragmentSmack (lit my jo herinnerje dat tegearre mei de oankundiging yn augustus, in fix allinich foar SegmentSmack waard frijlitten), wat ús in kâns joech om Workaround te ferlitten, wat ús nochal in soad muoite soarge. Yn dizze tiid hienen wy al slagge om guon fan 'e servers oer te setten nei de nije kernel, en no moasten wy fan it begjin ôf begjinne. Wêrom hawwe wy de kernel bywurke sûnder te wachtsjen op de FragmentSmack-fix? It feit is dat it proses fan beskerming tsjin dizze kwetsberens gearfoel (en gearfoege) mei it proses fan it bywurkjen fan CentOS sels (wat noch mear tiid nimt dan it bywurkjen fan allinich de kernel). Derneist, SegmentSmack is in gefaarliker kwetsberens, en in fix foar it ferskynde fuortendaliks, dus it makke yn elts gefal sin. Wy koenen lykwols net gewoan de kernel op CentOS bywurkje, om't de kwetsberens fan FragmentSmack, dy't ferskynde tidens CentOS 7.5, allinich yn ferzje 7.6 reparearre waard, sadat wy de fernijing nei 7.5 stopje moasten en opnij begjinne mei de fernijing nei 7.6. En dit bart ek.
Twads binne seldsume brûkersklachten oer problemen by ús weromkommen. No witte wy al wis dat se allegear relatearre binne oan it uploaden fan bestannen fan kliïnten nei guon fan ús servers. Boppedat gie in heul lyts oantal uploads fan 'e totale massa troch dizze servers.
As wy ús ûnthâlde fan it hjirboppe ferhaal, holp it weromrollen fan Sysctl net. Reboot holp, mar tydlik.
Fertochten oangeande Sysctl binne net fuorthelle, mar dizze kear wie it nedich om safolle mooglik ynformaasje te sammeljen. D'r wie ek in grut gebrek oan fermogen om it uploadprobleem op 'e kliïnt te reprodusearjen om krekter te studearjen wat der barde.
Analyse fan alle beskikbere statistiken en logs brocht ús net tichter by it begripen fan wat der barde. D'r wie in akuut gebrek oan fermogen om it probleem te reprodusearjen om in spesifike ferbining te "fielen". Uteinlik slaggen de ûntwikkelders, mei help fan in spesjale ferzje fan 'e applikaasje, in stabile reproduksje fan problemen op in testapparaat by ferbûn fia Wi-Fi. Dit wie in trochbraak yn it ûndersyk. De kliïnt ferbûn mei Nginx, dy't proxyed oan 'e efterkant, dat wie ús Java-applikaasje.
It dialooch foar problemen wie sa (fêststeld op 'e Nginx proxy side):
- Klant: fersyk om ynformaasje te ûntfangen oer it downloaden fan in bestân.
- Java tsjinner: antwurd.
- Klant: POST mei triem.
- Java-tsjinner: flater.
Tagelyk skriuwt de Java-tsjinner nei it log dat 0 bytes fan gegevens waarden ûntfongen fan 'e kliïnt, en de Nginx-proxy skriuwt dat it fersyk mear as 30 sekonden naam (30 sekonden is de time-out fan' e kliïntapplikaasje). Wêrom de timeout en wêrom 0 bytes? Fanút in HTTP-perspektyf wurket alles sa't it moat, mar de POST mei it bestân liket te ferdwinen út it netwurk. Boppedat ferdwynt it tusken de kliïnt en Nginx. It is tiid om josels te bewapenjen mei Tcpdump! Mar earst moatte jo de netwurkkonfiguraasje begripe. Nginx proxy is efter de L3 balancer . Tunneling wurdt brûkt om pakketten te leverjen fan 'e L3-balancer nei de tsjinner, dy't syn kopteksten tafoegje oan' e pakketten:
Yn dit gefal komt it netwurk nei dizze tsjinner yn 'e foarm fan Vlan-tagged ferkear, dy't ek syn eigen fjilden tafoegje oan' e pakketten:
En dit ferkear kin ek fragminteare wurde (datselde lytse persintaazje fan ynkommend fragmintearre ferkear dat wy prate oer by it beoardieljen fan de risiko's fan Workaround), wat ek de ynhâld fan 'e kopteksten feroaret:
Noch ien kear: pakketten wurde ynkapsele mei in Vlan tag, ynkapsele mei in tunnel, fersnippere. Om better te begripen hoe't dit bart, litte wy de pakketrûte fan 'e kliïnt nei de Nginx-proxy trace.
- It pakket berikt de L3 balancer. Foar juste routing binnen it datasintrum wurdt it pakket yn in tunnel ynkapsele en nei de netwurkkaart stjoerd.
- Sûnt de kopteksten fan pakket + tunnel net passe yn 'e MTU, wurdt it pakket yn fragminten ôfsnien en nei it netwurk stjoerd.
- De switch nei de L3 balancer, by ûntfangst fan in pakket, foeget in Vlan tag oan it en stjoert it op.
- De skeakel foar de Nginx-proxy sjocht (basearre op 'e havenynstellingen) dat de tsjinner in Vlan-ynkapsele pakket ferwachtet, sadat it it stjoert sa't it is, sûnder de Vlan-tag te ferwiderjen.
- Linux nimt fragminten fan yndividuele pakketten en fusearret se yn ien grut pakket.
- Folgjende, it pakket berikt de Vlan ynterface, dêr't de earste laach wurdt fuorthelle út it - Vlan encapsulation.
- Linux stjoert it dan nei de Tunnel-ynterface, wêr't in oare laach derfan wurdt fuortsmiten - Tunnel-ynkapseling.
De muoite is dit alles troch te jaan as parameters nei tcpdump.
Litte wy begjinne fan 'e ein: binne d'r skjinne (sûnder ûnnedige kopteksten) IP-pakketten fan kliïnten, mei vlan en tunnel-ynkapseling fuortsmiten?
tcpdump host <ip клиента>
Nee, d'r wiene gjin sokke pakketten op 'e tsjinner. It probleem moat der dus earder wêze. Binne der pakketten mei allinnich Vlan ynkapseling fuorthelle?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx is it client-IP-adres yn hex-formaat.
32: 4 - adres en lingte fan it fjild wêryn de SCR IP is skreaun yn it Tunnelpakket.
It fjildadres moast mei brute krêft selektearre wurde, om't se op it ynternet oer 40, 44, 50, 54 skriuwe, mar d'r wie gjin IP-adres dêr. Jo kinne ek sjen nei ien fan de pakketten yn hex (de -xx of -XX parameter yn tcpdump) en berekkenje it IP-adres dat jo witte.
Binne der pakket fragminten sûnder Vlan en Tunnel ynkapseling fuortsmiten?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Dizze magy sil ús alle fragminten sjen litte, ynklusyf de lêste. Wierskynlik kin itselde ding wurde filtere troch IP, mar ik haw it net besocht, om't d'r net folle sokke pakketten binne, en dejingen dy't ik nedich wiene, wiene maklik te finen yn 'e algemiene stream. Hjir binne se:
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 binne twa fragminten fan ien pakket (deselde ID 53652) mei in foto (it wurd Exif is sichtber yn it earste pakket). Troch it feit dat der pakketten op dit nivo binne, mar net yn 'e gearfoege foarm yn' e stoarten, sit it probleem dúdlik by de gearstalling. Uteinlik is der dokumintêre bewiis fan dit!
De pakketdekoder liet gjin problemen sjen dy't de bou foarkomme. Hjir besocht: . As jo earst besykje wat dêr te stopjen, hâldt de dekoder it pakketformaat net. It die bliken dat der wat ekstra twa oktetten wiene tusken Srcmac en Ethertype (net relatearre oan fragmintynformaasje). Nei it fuortheljen fan se begon de dekoder te wurkjen. It liet lykwols gjin problemen sjen.
Wat men ek sizze mei, der is neat oars fûn as dy Sysctl. Alles wat oerbleau wie in manier te finen om probleemservers te identifisearjen om de skaal te begripen en te besluten oer fierdere aksjes. De fereaske teller waard fluch genôch fûn:
netstat -s | grep "packet reassembles failed”
It is ek yn snmpd ûnder OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"It oantal flaters ûntdutsen troch it algoritme foar opnij gearstalling fan IP (om hokker reden dan ek: time-out, flaters, ensfh.)."
Under de groep servers dêr't it probleem waard bestudearre, op twa ferhege dizze teller flugger, op twa stadiger, en op twa mear net tanommen hielendal. It fergelykjen fan de dynamyk fan dizze teller mei de dynamyk fan HTTP-flaters op 'e Java-tsjinner liet in korrelaasje sjen. Dat is, de meter koe wurde kontrolearre.
It hawwen fan in betroubere yndikator fan problemen is heul wichtich, sadat jo sekuer kinne bepale oft it weromrollen fan Sysctl helpt, om't út it foarige ferhaal witte wy dat dit net direkt kin wurde begrepen fan 'e applikaasje. Dizze yndikator soe ús tastean om alle probleemgebieten yn produksje te identifisearjen foardat brûkers it ûntdekke.
Nei it weromdraaien fan Sysctl stopten de monitoaringsfouten, dus waard de oarsaak fan 'e problemen bewiisd, en ek it feit dat it weromdraaien helpt.
Wy rôle de fragmintaasje-ynstellingen werom op oare servers, wêr't nije tafersjoch yn it spul kaam, en earne hawwe wy noch mear ûnthâld foar fragminten tawiisd as earder de standert wie (dit wie UDP-statistiken, wêrfan it foar in part ferlies net te merken wie tsjin de algemiene eftergrûn) .
De wichtichste fragen
Wêrom binne pakketten fersnippere op ús L3 balancer? De measte pakketten dy't komme fan brûkers nei balancers binne SYN en ACK. De maten fan dizze pakketten binne lyts. Mar om't it oandiel fan sokke pakketten heul grut is, hawwe wy tsjin har eftergrûn de oanwêzigens fan grutte pakketten net opmurken dy't begon te fragmintearjen.
De reden wie in brutsen konfiguraasjeskript op servers mei Vlan-ynterfaces (d'r wiene op dat stuit heul pear servers mei tagged ferkear yn produksje). Advmss lit ús de ynformaasje oerbringe oan 'e kliïnt dat pakketten yn ús rjochting lytser moatte wêze, sadat se nei it heakjen fan tunnelkoppen oan har net fersnippere hoege te wurden.
Wêrom hat Sysctl rollback net holpen, mar opnij opstarte? Sysctl weromrôlje feroare de hoemannichte ûnthâld beskikber foar it gearfoegjen fan pakketten. Tagelyk hat blykber it feit fan ûnthâld oerstreaming foar fragminten late ta fertraging fan ferbinings, wat late ta fragminten wurde fertrage foar in lange tiid yn 'e wachtrige. Dat is, it proses gie yn syklusen.
De herstart wist it ûnthâld en alles kaam werom yn oarder.
Wie it mooglik te dwaan sûnder Workaround? Ja, mar d'r is in heech risiko om brûkers sûnder tsjinst te litten yn gefal fan in oanfal. Fansels resultearre it gebrûk fan Workaround yn ferskate problemen, ynklusyf it fertrage fan ien fan 'e tsjinsten foar brûkers, mar wy leauwe lykwols dat de aksjes terjochte wiene.
Tige tank oan Andrey Timofeev () foar help by it útfieren fan it ûndersyk, lykas Alexey Krenev () - foar it titanyske wurk fan it bywurkjen fan Centos en kernels op servers. In proses dat yn dit gefal ferskate kearen fan it begjin ôf begûn wurde moast, dêrom slepe it in protte moannen.
Boarne: www.habr.com