Dag Allemaal! Mijn naam is Dmitry Samsonov, ik werk als een leidende systeembeheerder bij Odnoklassniki. We hebben ruim 7 duizend fysieke servers, 11 duizend containers in onze cloud en 200 applicaties, die in verschillende configuraties 700 verschillende clusters vormen. De overgrote meerderheid van de servers draait CentOS 7.
Op 14 augustus 2018 werd informatie over de FragmentSmack-kwetsbaarheid gepubliceerd
() en SegmentSmack (). Dit zijn kwetsbaarheden met een netwerkaanvalvector en een vrij hoge score (7.5), waardoor Denial of Service (DoS) dreigt vanwege uitputting van bronnen (CPU). Een kernelfix voor FragmentSmack werd destijds niet voorgesteld; bovendien kwam deze veel later uit dan de publicatie van informatie over de kwetsbaarheid. Om SegmentSmack te elimineren, werd voorgesteld om de kernel bij te werken. Het updatepakket zelf werd op dezelfde dag uitgebracht, het enige dat nog restte was het installeren ervan.
Nee, wij zijn helemaal niet tegen het updaten van de kernel! Er zijn echter nuances...
Hoe we de kernel bijwerken tijdens productie
Over het algemeen niets ingewikkelds:
- Pakketten downloaden;
- Installeer ze op een aantal servers (inclusief servers die onze cloud hosten);
- Zorg ervoor dat er niets kapot is;
- Zorg ervoor dat alle standaard kernelinstellingen zonder fouten worden toegepast;
- Wacht een paar dagen;
- Controleer de serverprestaties;
- Schakel de implementatie van nieuwe servers over naar de nieuwe kernel;
- Update alle servers per datacenter (één datacenter tegelijk om het effect op gebruikers te minimaliseren in geval van problemen);
- Start alle servers opnieuw op.
Herhaal dit voor alle takken van de kernels die we hebben. Op dit moment is het:
- Stock CentOS 7 3.10 - voor de meeste reguliere servers;
- Vanille 4.19 - voor de onze , omdat we BFQ, BBR, enz. nodig hebben;
- Elrepo kernel-ml 5.2 - voor , omdat 4.19 zich onstabiel gedroeg, maar dezelfde functies nodig zijn.
Zoals je misschien al geraden hebt, duurt het herstarten van duizenden servers het langst. Omdat niet alle kwetsbaarheden voor alle servers kritiek zijn, herstarten we alleen de servers die direct toegankelijk zijn vanaf internet. Om de flexibiliteit niet te beperken, koppelen we in de cloud geen extern toegankelijke containers aan individuele servers met een nieuwe kernel, maar herstarten we alle hosts zonder uitzondering. Gelukkig is de procedure daar eenvoudiger dan bij reguliere servers. Stateless containers kunnen bijvoorbeeld tijdens een herstart eenvoudig naar een andere server worden verplaatst.
Er is echter nog veel werk, en het kan enkele weken duren, en als er problemen zijn met de nieuwe versie, tot enkele maanden. Aanvallers begrijpen dit heel goed, dus ze hebben een plan B nodig.
FragmentSmack/SegmentSmack. tijdelijke oplossing
Gelukkig bestaat er voor sommige kwetsbaarheden zo’n plan B, genaamd Workaround. Meestal is dit een wijziging in de kernel-/applicatie-instellingen die het mogelijke effect kan minimaliseren of de exploitatie van kwetsbaarheden volledig kan elimineren.
In het geval van FragmentSmack/SegmentSmack deze oplossing:
«U kunt de standaardwaarden van 4MB en 3MB in net.ipv4.ipfrag_high_thresh en net.ipv4.ipfrag_low_thresh (en hun tegenhangers voor ipv6 net.ipv6.ipfrag_high_thresh en net.ipv6.ipfrag_low_thresh) wijzigen in respectievelijk 256 kB en 192 kB of lager. Tests tonen kleine tot aanzienlijke dalingen in het CPU-gebruik tijdens een aanval aan, afhankelijk van de hardware, instellingen en omstandigheden. Er kan echter enige prestatie-impact zijn als gevolg van ipfrag_high_thresh=262144 bytes, aangezien er slechts twee 64K-fragmenten tegelijk in de wachtrij voor opnieuw samenstellen kunnen passen. Zo bestaat het risico dat applicaties die met grote UDP-pakketten werken kapot gaan.
De parameters zelf als volgt beschreven:
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.
We hebben geen grote UDP's voor productieservices. Er is geen gefragmenteerd verkeer op het LAN; er is gefragmenteerd verkeer op het WAN, maar niet significant. Er zijn geen tekenen: u kunt een tijdelijke oplossing uitrollen!
FragmentSmack/SegmentSmack. Eerste bloed
Het eerste probleem dat we tegenkwamen was dat cloudcontainers de nieuwe instellingen soms slechts gedeeltelijk toepasten (alleen ipfrag_low_thresh), en soms helemaal niet - ze crashten simpelweg bij het opstarten. Het was niet mogelijk om het probleem stabiel te reproduceren (alle instellingen werden zonder problemen handmatig toegepast). Begrijpen waarom de container bij de start crasht, is ook niet zo eenvoudig: er zijn geen fouten gevonden. Eén ding was zeker: het terugdraaien van de instellingen lost het probleem met containercrashes op.
Waarom is het niet voldoende om Sysctl op de host toe te passen? De container leeft in zijn eigen speciale netwerknaamruimte, dus tenminste in de container kan verschillen van de host.
Hoe worden Sysctl-instellingen precies toegepast in de container? Omdat onze containers geen rechten hebben, kunt u geen enkele Sysctl-instelling wijzigen door naar de container zelf te gaan - u heeft eenvoudigweg niet voldoende rechten. Om containers uit te voeren, gebruikte onze cloud destijds Docker (nu ). Via de API werden de parameters van de nieuwe container doorgegeven aan Docker, inclusief de benodigde Sysctl-instellingen.
Bij het doorzoeken van de versies bleek dat de Docker API niet alle fouten retourneerde (althans in versie 1.10). Toen we de container via “docker run” probeerden te starten, zagen we uiteindelijk in ieder geval iets:
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 parameterwaarde is niet geldig. Maar waarom? En waarom is het niet slechts af en toe geldig? Het bleek dat Docker de volgorde waarin Sysctl-parameters worden toegepast niet garandeert (de laatst geteste versie is 1.13.1), dus soms probeerde ipfrag_high_thresh op 256K te worden ingesteld terwijl ipfrag_low_thresh nog 3M was, dat wil zeggen dat de bovengrens lager was dan de ondergrens, die tot de fout leidde.
Destijds gebruikten we al ons eigen mechanisme voor het opnieuw configureren van de container na het starten (het bevriezen van de container na het starten). en het uitvoeren van opdrachten in de naamruimte van de container via ), en we hebben ook het schrijven van Sysctl-parameters aan dit deel toegevoegd. Het probleem is opgelost.
FragmentSmack/SegmentSmack. Eerste Bloed 2
Voordat we tijd hadden om het gebruik van Workaround in de cloud te begrijpen, begonnen de eerste zeldzame klachten van gebruikers binnen te komen. Op dat moment waren er enkele weken verstreken sinds de start van het gebruik van Workaround op de eerste servers. Uit het eerste onderzoek bleek dat er klachten waren binnengekomen tegen individuele diensten, en niet tegen alle servers van deze diensten. Het probleem is opnieuw uiterst onzeker geworden.
Allereerst hebben we uiteraard geprobeerd de Sysctl-instellingen terug te draaien, maar dit had geen enkel effect. Ook diverse manipulaties met de server- en applicatie-instellingen hielpen niet. Opnieuw opstarten hielp. Het opnieuw opstarten van Linux is net zo onnatuurlijk als vroeger normaal was voor Windows. Het hielp echter, en we schreven het toe aan een “kernelglitch” bij het toepassen van de nieuwe instellingen in Sysctl. Hoe frivool was het...
Drie weken later herhaalde het probleem zich. De configuratie van deze servers was vrij eenvoudig: Nginx in proxy/balancer-modus. Niet veel verkeer. Nieuwe inleidende opmerking: het aantal 504-fouten op clients neemt elke dag toe (). De grafiek toont het aantal 504 fouten per dag voor deze service:
Alle fouten gaan over dezelfde backend - over degene die zich in de cloud bevindt. De geheugenverbruikgrafiek voor pakketfragmenten op deze backend zag er als volgt uit:
Dit is een van de meest voor de hand liggende manifestaties van het probleem in grafieken van besturingssystemen. In de cloud werd tegelijkertijd een ander netwerkprobleem met QoS-instellingen (Traffic Control) opgelost. Op de grafiek van het geheugengebruik voor pakketfragmenten zag het er precies hetzelfde uit:
De veronderstelling was simpel: als ze er in de grafieken hetzelfde uitzien, hebben ze dezelfde reden. Bovendien zijn problemen met dit type geheugen uiterst zeldzaam.
De essentie van het opgeloste probleem was dat we de fq-pakketplanner gebruikten met standaardinstellingen in QoS. Standaard kunt u voor één verbinding 100 pakketten aan de wachtrij toevoegen, en sommige verbindingen begonnen, in situaties van kanaaltekort, de wachtrij tot aan de capaciteit te verstoppen. In dit geval worden pakketten verwijderd. In tc-statistieken (tc -s qdisc) kan het als volgt worden gezien:
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
“464545flows_plimit” zijn de pakketten die zijn verwijderd vanwege het overschrijden van de wachtrijlimiet van één verbinding, en “dropped 464545” is de som van alle verwijderde pakketten van deze planner. Nadat de wachtrijlengte was vergroot tot duizend en de containers opnieuw waren opgestart, trad het probleem niet meer op. Je kunt achterover leunen en een smoothie drinken.
FragmentSmack/SegmentSmack. Laatste bloed
Ten eerste verscheen er enkele maanden na de aankondiging van kwetsbaarheden in de kernel eindelijk een oplossing voor FragmentSmack (laat me je eraan herinneren dat samen met de aankondiging in augustus ook een oplossing alleen voor SegmentSmack werd uitgebracht), wat ons de kans gaf om Workaround te verlaten. wat ons heel wat problemen bezorgde. Gedurende deze tijd waren we er al in geslaagd een aantal servers over te zetten naar de nieuwe kernel, en nu moesten we vanaf het begin beginnen. Waarom hebben we de kernel bijgewerkt zonder op de FragmentSmack-fix te wachten? Feit is dat het proces van bescherming tegen deze kwetsbaarheden samenviel (en samensmolt) met het proces van het updaten van CentOS zelf (wat zelfs meer tijd kost dan het updaten van alleen de kernel). Bovendien is SegmentSmack een gevaarlijkere kwetsbaarheid, en er verscheen onmiddellijk een oplossing voor, dus het was hoe dan ook logisch. We konden de kernel op CentOS echter niet zomaar updaten omdat de FragmentSmack-kwetsbaarheid, die verscheen tijdens CentOS 7.5, pas in versie 7.6 was opgelost, dus moesten we de update naar 7.5 stoppen en helemaal opnieuw beginnen met de update naar 7.6. En dit gebeurt ook.
Ten tweede zijn er zeldzame klachten van gebruikers over problemen bij ons teruggekomen. Nu weten we al zeker dat ze allemaal verband houden met het uploaden van bestanden van clients naar sommige van onze servers. Bovendien ging een zeer klein aantal uploads van de totale massa via deze servers.
Zoals we ons uit het bovenstaande verhaal herinneren, hielp het terugdraaien van Sysctl niet. Opnieuw opstarten hielp, maar tijdelijk.
Vermoedens ten aanzien van Sysctl werden niet weggenomen, maar deze keer was het nodig om zoveel mogelijk informatie te verzamelen. Er was ook een groot gebrek aan de mogelijkheid om het uploadprobleem op de client te reproduceren om nauwkeuriger te kunnen bestuderen wat er gebeurde.
Analyse van alle beschikbare statistieken en logboeken bracht ons niet dichter bij het begrijpen van wat er gebeurde. Er was een acuut gebrek aan vermogen om het probleem te reproduceren om een specifiek verband te ‘voelen’. Ten slotte zijn de ontwikkelaars erin geslaagd om met behulp van een speciale versie van de applicatie een stabiele weergave van problemen op een testapparaat te bereiken wanneer deze via Wi-Fi is verbonden. Dit was een doorbraak in het onderzoek. De client maakte verbinding met Nginx, die via een proxy verbinding maakte met de backend, onze Java-applicatie.
De dialoog voor problemen was als volgt (opgelost aan de Nginx-proxykant):
- Klant: verzoek om informatie te ontvangen over het downloaden van een bestand.
- Java-server: antwoord.
- Klant: POST met bestand.
- Java-server: fout.
Tegelijkertijd schrijft de Java-server naar het logboek dat er 0 bytes aan gegevens zijn ontvangen van de client, en de Nginx-proxy schrijft dat het verzoek meer dan 30 seconden duurde (30 seconden is de time-out van de clienttoepassing). Waarom de time-out en waarom 0 bytes? Vanuit HTTP-perspectief werkt alles zoals het hoort, maar de POST met het bestand lijkt uit het netwerk te verdwijnen. Bovendien verdwijnt het tussen de client en Nginx. Het is tijd om jezelf te bewapenen met Tcpdump! Maar eerst moet u de netwerkconfiguratie begrijpen. Nginx-proxy bevindt zich achter de L3-balancer . Tunneling wordt gebruikt om pakketten van de L3-balancer naar de server te leveren, die de headers aan de pakketten toevoegt:
In dit geval komt het netwerk naar deze server in de vorm van Vlan-tagged verkeer, dat ook zijn eigen velden aan de pakketten toevoegt:
En dit verkeer kan ook gefragmenteerd zijn (datzelfde kleine percentage van het binnenkomende gefragmenteerde verkeer waar we het over hadden bij het beoordelen van de risico's van Workaround), waardoor ook de inhoud van de headers verandert:
Nogmaals: pakketten worden ingekapseld met een Vlan-tag, ingekapseld met een tunnel, gefragmenteerd. Om beter te begrijpen hoe dit gebeurt, gaan we de pakketroute van de client naar de Nginx-proxy traceren.
- Het pakket bereikt de L3-balancer. Voor een correcte routering binnen het datacenter wordt het pakket in een tunnel ingekapseld en naar de netwerkkaart gestuurd.
- Omdat de pakket- en tunnelheaders niet in de MTU passen, wordt het pakket in fragmenten geknipt en naar het netwerk gestuurd.
- De switch achter de L3-balancer voegt bij ontvangst van een pakket een Vlan-tag eraan toe en verzendt het door.
- De schakelaar voor de Nginx-proxy ziet (op basis van de poortinstellingen) dat de server een in Vlan ingekapseld pakket verwacht, dus verzendt het zoals het is, zonder de Vlan-tag te verwijderen.
- Linux neemt fragmenten van individuele pakketten en voegt deze samen tot één groot pakket.
- Vervolgens bereikt het pakket de Vlan-interface, waar de eerste laag ervan wordt verwijderd: Vlan-inkapseling.
- Linux stuurt het vervolgens naar de Tunnel-interface, waar een andere laag eruit wordt verwijderd: Tunnel-inkapseling.
De moeilijkheid is om dit allemaal als parameters door te geven aan tcpdump.
Laten we bij het einde beginnen: zijn er schone (zonder onnodige headers) IP-pakketten van clients, waarbij vlan- en tunnelinkapseling zijn verwijderd?
tcpdump host <ip клиента>
Nee, dergelijke pakketten stonden niet op de server. Het probleem moet er dus eerder zijn. Zijn er pakketten waarbij alleen de Vlan-inkapseling is verwijderd?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx is het client-IP-adres in hex-formaat.
32:4 — adres en lengte van het veld waarin het SCR IP in het Tunnelpakket wordt geschreven.
Het veldadres moest met brute kracht worden geselecteerd, aangezien ze op internet ongeveer 40, 44, 50, 54 schrijven, maar daar was geen IP-adres. Je kunt ook naar een van de pakketten in hex kijken (de parameter -xx of -XX in tcpdump) en het IP-adres berekenen dat je kent.
Zijn er pakketfragmenten zonder verwijderde Vlan- en Tunnel-inkapseling?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Deze magie zal ons alle fragmenten laten zien, inclusief de laatste. Waarschijnlijk kan hetzelfde op IP worden gefilterd, maar ik heb het niet geprobeerd, omdat er niet veel van dergelijke pakketten zijn, en de pakketten die ik nodig had, waren gemakkelijk te vinden in de algemene stroom. Daar zijn ze:
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 zijn twee fragmenten van één pakket (dezelfde ID 53652) met een foto (in het eerste pakket is het woord Exif zichtbaar). Vanwege het feit dat er pakketten op dit niveau zijn, maar niet in de samengevoegde vorm in de dumps, ligt het probleem duidelijk bij de assemblage. Eindelijk is daar bewijsmateriaal van!
De pakketdecoder bracht geen problemen aan het licht die de bouw zouden verhinderen. Ik heb het hier geprobeerd: . In eerste instantie, als je daar iets probeert te proppen, houdt de decoder niet van het pakketformaat. Het bleek dat er twee extra octetten waren tussen Srcmac en Ethertype (niet gerelateerd aan fragmentinformatie). Na het verwijderen ervan begon de decoder te werken. Het vertoonde echter geen problemen.
Wat je ook zegt, er is niets anders gevonden dan die Sysctl. Het enige dat overbleef was het vinden van een manier om probleemservers te identificeren om de omvang te begrijpen en te beslissen over verdere acties. De benodigde teller werd snel genoeg gevonden:
netstat -s | grep "packet reassembles failed”
Het staat ook in snmpd onder OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
“Het aantal fouten dat is gedetecteerd door het algoritme voor het opnieuw samenstellen van het IP-adres (om welke reden dan ook: time-out, fouten, enz.).”
Onder de groep servers waarop het probleem werd bestudeerd, steeg deze teller op twee sneller, op twee langzamer en op nog twee helemaal niet. Het vergelijken van de dynamiek van deze teller met de dynamiek van HTTP-fouten op de Java-server bracht een correlatie aan het licht. Dat wil zeggen, de meter zou kunnen worden gecontroleerd.
Het hebben van een betrouwbare indicator van problemen is erg belangrijk, zodat je nauwkeurig kunt bepalen of het terugdraaien van Sysctl helpt, aangezien we uit het vorige verhaal weten dat dit niet direct vanuit de applicatie te begrijpen is. Deze indicator zou ons in staat stellen alle probleemgebieden in de productie te identificeren voordat gebruikers deze ontdekken.
Na het terugdraaien van Sysctl stopten de monitoringfouten, waardoor de oorzaak van de problemen werd bewezen, evenals het feit dat het terugdraaien helpt.
We hebben de fragmentatie-instellingen op andere servers teruggedraaid, waar nieuwe monitoring een rol speelde, en ergens hebben we zelfs meer geheugen voor fragmenten toegewezen dan voorheen de standaard was (dit waren UDP-statistieken, waarvan het gedeeltelijke verlies niet merkbaar was tegen de algemene achtergrond) .
De belangrijkste vragen
Waarom zijn pakketten gefragmenteerd op onze L3-balancer? De meeste pakketten die van gebruikers naar balancers komen, zijn SYN en ACK. De afmetingen van deze pakketten zijn klein. Maar aangezien het aandeel van dergelijke pakketten erg groot is, merkten we tegen hun achtergrond niet de aanwezigheid op van grote pakketten die begonnen te fragmenteren.
De reden was een defect configuratiescript op servers met Vlan-interfaces (er waren op dat moment maar heel weinig servers met getagd verkeer in productie). Met Advmss kunnen we aan de klant de informatie overbrengen dat pakketten in onze richting kleiner van formaat moeten zijn, zodat ze na het koppelen van tunnelheaders niet gefragmenteerd hoeven te worden.
Waarom hielp het terugdraaien van Sysctl niet, maar het opnieuw opstarten wel? Het terugdraaien van Sysctl veranderde de hoeveelheid geheugen die beschikbaar was voor het samenvoegen van pakketten. Tegelijkertijd leidde blijkbaar juist het feit van de geheugenoverloop voor fragmenten tot een vertraging van verbindingen, wat ertoe leidde dat fragmenten lange tijd in de wachtrij bleven staan. Dat wil zeggen, het proces verliep in cycli.
Door het opnieuw opstarten werd het geheugen gewist en alles keerde terug naar de orde.
Was het mogelijk om dit zonder tijdelijke oplossing te doen? Ja, maar er is een groot risico dat gebruikers bij een aanval zonder service blijven. Natuurlijk heeft het gebruik van Workaround tot verschillende problemen geleid, waaronder de vertraging van een van de diensten voor gebruikers, maar toch zijn wij van mening dat de acties gerechtvaardigd waren.
Veel dank aan Andrej Timofejev () voor hulp bij het uitvoeren van het onderzoek, evenals Alexey Krenev () - voor het gigantische werk van het updaten van Centos en kernels op servers. Een proces dat in dit geval meerdere malen vanaf het begin moest worden gestart en daarom vele maanden heeft geduurd.
Bron: www.habr.com