Sziasztok! A nevem Dmitry Samsonov, vezető rendszergazdaként dolgozom az Odnoklassnikinél. Több mint 7 ezer fizikai szerverünk, felhőnkben 11 ezer konténerünk és 200 alkalmazásunk van, amelyek különböző konfigurációkban 700 különböző klasztert alkotnak. A szerverek túlnyomó többsége CentOS 7-et futtat.
14. augusztus 2018-én közzétették a FragmentSmack biztonsági réssel kapcsolatos információkat
() és SegmentSmack (). Ezek hálózati támadási vektorral és meglehetősen magas pontszámmal (7.5) rendelkező sebezhetőségek, amelyek az erőforrások kimerülése (CPU) miatti szolgáltatásmegtagadást (DoS) fenyegetik. A FragmentSmack rendszermag-javítását akkor még nem javasolták, ráadásul jóval később jelent meg, mint a sérülékenységről szóló információ. A SegmentSmack kiküszöbölése érdekében javasolták a kernel frissítését. Maga a frissítőcsomag még aznap megjelent, már csak a telepítés volt hátra.
Nem, egyáltalán nem ellenezzük a kernel frissítését! Vannak azonban árnyalatok...
Hogyan frissítjük a kernelt éles környezetben
Általában semmi bonyolult:
- Csomagok letöltése;
- Telepítse őket számos szerverre (beleértve a felhőnket kiszolgáló szervereket is);
- Győződjön meg arról, hogy semmi sem törött;
- Győződjön meg arról, hogy az összes szabványos kernelbeállítást hiba nélkül alkalmazza;
- Várjon néhány napot;
- Ellenőrizze a szerver teljesítményét;
- Az új szerverek telepítésének átállítása az új kernelre;
- Frissítse az összes kiszolgálót adatközpont szerint (egyszerre egy adatközpont, hogy probléma esetén minimálisra csökkentse a felhasználókra gyakorolt hatást);
- Indítsa újra az összes szervert.
Ismételje meg a rendszermagunk összes ágára. Jelenleg ez:
- Stock CentOS 7 3.10 - a legtöbb normál szerverhez;
- Vanília 4.19 - a miénk , mert szükségünk van BFQ, BBR stb.;
- Elrepo kernel-ml 5.2 - for , mert a 4.19 korábban instabilan viselkedett, de ugyanazokra a funkciókra van szükség.
Ahogy azt sejteni lehetett, több ezer szerver újraindítása tart a leghosszabb ideig. Mivel nem minden sérülékenység kritikus minden szerver esetében, csak azokat indítjuk újra, amelyek közvetlenül elérhetők az internetről. A felhőben a rugalmasság korlátozása érdekében nem a külsőleg elérhető konténereket kötjük az egyes szerverekhez új kernellel, hanem kivétel nélkül újraindítjuk az összes gazdagépet. Szerencsére ott az eljárás egyszerűbb, mint a hagyományos szervereknél. Például az állapot nélküli tárolók egyszerűen átkerülhetnek egy másik kiszolgálóra az újraindítás során.
A munka azonban még mindig sok, és több hétig is eltarthat, ha pedig probléma adódik az új verzióval, akár több hónapig is. A támadók ezt nagyon jól megértik, ezért szükségük van egy B-tervre.
FragmentSmack/SegmentSmack. Kerülő megoldás
Szerencsére bizonyos sebezhetőségek esetében létezik egy ilyen B-terv, amelynek neve Megkerülő. Leggyakrabban ez a kernel/alkalmazás beállításainak megváltoztatása, amely minimalizálhatja a lehetséges hatást, vagy teljesen kiküszöbölheti a sebezhetőségek kihasználását.
FragmentSmack/SegmentSmack esetén ez a megoldás:
«Módosíthatja a net.ipv4.ipfrag_high_thresh és net.ipv3.ipfrag_low_thresh (és az ipv4 net.ipv4.ipfrag_high_thresh és net.ipv6.ipfrag_low_thresh megfelelői) alapértelmezett 6 MB és 6 MB értékét 256 vagy 192 kB-re, illetve kB-re. Alsó. A tesztek a hardvertől, a beállításoktól és a körülményektől függően kismértékű vagy jelentős csökkenést mutatnak a CPU-használatban támadás során. Az ipfrag_high_thresh=262144 bájt azonban hatással lehet a teljesítményre, mivel egyszerre csak két 64K-os töredék fér bele az összeállítási sorba. Fennáll például annak a veszélye, hogy a nagy UDP-csomagokkal működő alkalmazások megszakadnak".
Maguk a paraméterek az alábbiak szerint írják le:
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.
Nincsenek nagy UDP-ink a termelési szolgáltatásokban. A LAN-on nincs töredezett forgalom, a WAN-on töredezett a forgalom, de nem jelentős. Nincsenek jelek – kidolgozhatja a megoldást!
FragmentSmack/SegmentSmack. Első vér
Az első probléma, amellyel találkoztunk, az volt, hogy a felhőkonténerek néha csak részben alkalmazták az új beállításokat (csak az ipfrag_low_thresh), néha pedig egyáltalán nem alkalmazták őket – egyszerűen az elején összeomlottak. A problémát nem lehetett stabilan reprodukálni (minden beállítást manuálisan, minden nehézség nélkül alkalmaztak). Nem is olyan egyszerű megérteni, hogy a konténer miért omlik össze az elején: nem találtunk hibát. Egy dolog biztos volt: a beállítások visszaállítása megoldja a konténerösszeomlás problémáját.
Miért nem elég a Sysctl alkalmazása a gazdagépen? A tároló saját dedikált hálózatának névterében él, így legalább a tárolóban eltérhet a gazdagéptől.
Pontosan hogyan alkalmazzák a Sysctl beállításokat a tárolóban? Mivel tárolóink nem jogosultak, nem tudja megváltoztatni a Sysctl-beállításokat magába a tárolóba való belépéssel – egyszerűen nincs elegendő jogosultsága. A konténerek futtatásához felhőnk akkoriban a Dockert használta (most ). Az új konténer paraméterei az API-n keresztül átadásra kerültek a Dockernek, beleértve a szükséges Sysctl beállításokat is.
A verziók közötti keresés során kiderült, hogy a Docker API nem adott vissza minden hibát (legalábbis az 1.10-es verzióban). Amikor megpróbáltuk elindítani a konténert a „docker run” segítségével, végre láttunk legalább valamit:
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.
A paraméter értéke nem érvényes. De miért? És miért nem csak néha érvényes? Kiderült, hogy a Docker nem garantálja a Sysctl paraméterek alkalmazási sorrendjét (a legfrissebb tesztelt verzió 1.13.1), ezért az ipfrag_high_thresh néha 256K-ra próbálta állítani, amikor az ipfrag_low_thresh még 3M volt, vagyis a felső határ alacsonyabb volt. mint az alsó határ, ami a hibához vezetett.
Akkoriban már saját mechanizmust használtunk a konténer indítás utáni újrakonfigurálására (a konténer lefagyasztása után és parancsok végrehajtása a tároló névterében keresztül ), és ehhez a részhez hozzáadtuk a Sysctl paraméterek írását is. A probléma megoldódott.
FragmentSmack/SegmentSmack. First Blood 2
Mielőtt még volt időnk megérteni a megoldás felhőben való használatát, megérkeztek az első ritka panaszok a felhasználóktól. Ekkor több hét telt el a Workaround használatának kezdete óta az első szervereken. A kezdeti vizsgálat kimutatta, hogy egyes szolgáltatások ellen érkeztek panaszok, és nem ezeknek a szolgáltatásoknak az összes szerverére. A probléma ismét rendkívül bizonytalanná vált.
Először természetesen megpróbáltuk visszaállítani a Sysctl beállításait, de ennek semmi hatása nem volt. A szerverrel és az alkalmazás beállításaival végzett különféle manipulációk sem segítettek. Az újraindítás segített. A Linux újraindítása ugyanolyan természetellenes, mint a régi időkben a Windows esetében. Ez azonban segített, és a Sysctl új beállításainak alkalmazásakor „kernelhibát” okoztunk. Milyen komolytalan volt...
Három héttel később a probléma megismétlődött. Ezeknek a szervereknek a konfigurációja meglehetősen egyszerű volt: Nginx proxy/balancer módban. Nem nagy forgalom. Új bevezető megjegyzés: az 504-es hibák száma az ügyfeleknél napról napra növekszik (). A grafikon a szolgáltatás napi 504 hibájának számát mutatja:
Az összes hiba ugyanarról a háttérről szól – a felhőben lévőről. A csomagtöredékek memóriafelhasználási grafikonja ezen a háttéren így nézett ki:
Ez a probléma egyik legnyilvánvalóbb megnyilvánulása az operációs rendszer grafikonjaiban. A felhőben ezzel egy időben egy másik hálózati probléma is kijavított a QoS (Traffic Control) beállításokkal. A csomagtöredékek memóriafelhasználásának grafikonján pontosan ugyanúgy nézett ki:
A feltevés egyszerű volt: ha ugyanúgy néznek ki a grafikonokon, akkor ugyanaz az oka. Ráadásul az ilyen típusú memóriával kapcsolatos bármilyen probléma rendkívül ritka.
A javított probléma lényege az volt, hogy a QoS-ben alapértelmezett beállításokkal az fq csomagütemezőt használtuk. Alapértelmezés szerint egy kapcsolathoz 100 csomag hozzáadását teszi lehetővé a sorhoz, és egyes kapcsolatok csatornahiányos helyzetekben elkezdték eltömíteni a sort a kapacitással. Ebben az esetben a csomagokat eldobják. A tc statisztikákban (tc -s qdisc) ez így látható:
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
A „464545 flows_plimit” az egyik kapcsolat sorkorlátjának túllépése miatt elvetett csomagok, a „dropped 464545” pedig az ütemező összes eldobott csomagjának összege. A várakozási sor hosszának 1 ezerre növelése és a tárolók újraindítása után a probléma megszűnt. Dőlhetsz hátra és ihatsz egy turmixot.
FragmentSmack/SegmentSmack. Utolsó vér
Először is, több hónappal a kernel sebezhetőségeinek bejelentése után végre megjelent a FragmentSmack javítása (hadd emlékeztessem önöket arra, hogy az augusztusi bejelentéssel együtt egy csak a SegmentSmackhez készült javítás is megjelent), ami lehetőséget adott a megoldás elhagyására. ami elég sok gondot okozott nekünk. Ezalatt a szerverek egy részét már sikerült átvinnünk az új kernelre, most pedig elölről kellett kezdenünk. Miért frissítettük a kernelt anélkül, hogy megvártuk volna a FragmentSmack javítást? A tény az, hogy az e sebezhetőségek elleni védelem folyamata egybeesett (és egyesült) magának a CentOS frissítésének folyamatával (ami még több időt vesz igénybe, mint csak a kernel frissítése). Ráadásul a SegmentSmack egy veszélyesebb sebezhetőség, amelyre azonnal megjelent a javítás, így mindenesetre volt értelme. A kernelt azonban egyszerűen nem tudtuk frissíteni CentOS-en, mert a CentOS 7.5 alatt megjelent FragmentSmack sebezhetőséget csak a 7.6-os verzióban javították ki, így le kellett állítani a 7.5-ös frissítést, és elölről kezdeni a 7.6-os frissítéssel. És ez is megtörténik.
Másodszor, a problémákkal kapcsolatos ritka felhasználói panaszok visszatértek hozzánk. Most már biztosan tudjuk, hogy ezek mind a kliensek állományainak egyes szervereinkre való feltöltéséhez kapcsolódnak. Ráadásul a teljes tömegből nagyon kis számú feltöltés ment át ezeken a szervereken.
Ahogy a fenti történetből emlékszünk, a Sysctl visszagörgetése nem segített. Az újraindítás segített, de átmenetileg.
A Sysctl-lel kapcsolatos gyanút nem szüntették meg, de ezúttal a lehető legtöbb információt kellett összegyűjteni. Szintén nagyon hiányos volt a feltöltési probléma reprodukálása a kliensen, hogy pontosabban tanulmányozhassa, mi történik.
Az összes rendelkezésre álló statisztika és napló elemzése nem vitt közelebb ahhoz, hogy megértsük, mi történik. Akut hiányosság volt a probléma reprodukálása ahhoz, hogy „érezzen” egy konkrét kapcsolatot. Végül a fejlesztőknek az alkalmazás speciális verziójával sikerült stabilan reprodukálniuk a problémákat egy teszteszközön, amikor Wi-Fi-n keresztül csatlakoztak. Ez áttörést jelentett a nyomozásban. A kliens az Nginx-hez csatlakozott, amely proxyzott a háttérrendszerhez, amely a Java alkalmazásunk volt.
A problémák párbeszéde a következő volt (javítva az Nginx proxy oldalán):
- Kliens: egy fájl letöltésével kapcsolatos információ kérése.
- Java szerver: válasz.
- Kliens: POST fájllal.
- Java szerver: hiba.
Ugyanakkor a Java szerver azt írja a naplóba, hogy 0 bájt adat érkezett a klienstől, az Nginx proxy pedig azt, hogy a kérés több mint 30 másodpercig tartott (30 másodperc a kliens alkalmazás időtúllépése). Miért az időtúllépés és miért 0 bájt? HTTP szemszögből nézve minden úgy működik, ahogy kell, de úgy tűnik, hogy a fájlt tartalmazó POST eltűnik a hálózatról. Sőt, eltűnik az ügyfél és az Nginx között. Ideje felvértezned magad a Tcpdump-pal! De először meg kell értenie a hálózati konfigurációt. Az Nginx proxy az L3 kiegyensúlyozó mögött található . Az alagútkezelés a csomagok L3-as kiegyenlítőtől a kiszolgálóhoz való eljuttatására szolgál, amely fejléceit adja hozzá a csomagokhoz:
Ebben az esetben a hálózat Vlan-címkézett forgalom formájában érkezik ehhez a szerverhez, amely saját mezőket is hozzáad a csomagokhoz:
És ez a forgalom töredezett is lehet (a bejövő töredezett forgalom ugyanaz a kis százaléka, amelyről a megoldás kockázatainak felmérésekor beszéltünk), ami szintén megváltoztatja a fejlécek tartalmát:
Még egyszer: a csomagokat Vlan címkével kapszulázzák, alagútba zárják, töredezettek. Hogy jobban megértsük, hogyan történik ez, kövessük nyomon a csomag útvonalát az ügyféltől az Nginx proxyig.
- A csomag eléri az L3 egyensúlyozót. Az adatközponton belüli helyes útválasztás érdekében a csomagot egy alagútba zárják, és elküldik a hálózati kártyára.
- Mivel a csomag + alagút fejlécek nem férnek bele az MTU-ba, a csomagot töredékekre vágják és elküldik a hálózatnak.
- Az L3 balancer utáni kapcsoló csomag fogadásakor Vlan tag-et ad hozzá és továbbküldi.
- Az Nginx proxy előtti kapcsoló azt látja (a portbeállítások alapján), hogy a szerver Vlan-beágyazott csomagot vár, tehát úgy küldi el, ahogy van, a Vlan tag eltávolítása nélkül.
- A Linux az egyes csomagok töredékeit veszi, és egy nagy csomagba egyesíti.
- Ezután a csomag eléri a Vlan interfészt, ahol eltávolítják róla az első réteget - Vlan tokozást.
- A Linux ezután elküldi az Tunnel interfészre, ahol egy másik réteget távolítanak el róla - Tunnel encapsulation.
A nehézséget az jelenti, hogy mindezt paraméterként adjuk át a tcpdump-nak.
Kezdjük a végéről: vannak tiszta (felesleges fejlécek nélküli) IP-csomagok a kliensektől, a vlan és alagút beágyazás eltávolításával?
tcpdump host <ip клиента>
Nem, nem voltak ilyen csomagok a szerveren. Tehát a probléma korábban ott kell hogy legyen. Vannak olyan csomagok, amelyekből csak Vlan-beágyazás van eltávolítva?
tcpdump ip[32:4]=0xx390x2xx
A 0xx390x2xx az ügyfél IP-címe hexadecimális formátumban.
32:4 - annak a mezőnek a címe és hossza, amelybe az SCR IP be van írva az Tunnel csomagban.
A mezőcímet nyers erővel kellett kiválasztani, mivel az interneten 40, 44, 50, 54-ről írnak, de ott nem volt IP cím. Megnézheti az egyik csomagot hexadecimális formában (a tcpdump -xx vagy -XX paramétere), és kiszámíthatja az Ön által ismert IP-címet.
Vannak olyan csomagtöredékek, amelyek nem tartalmazzák a Vlan és Tunnel tokozását?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Ez a varázslat megmutatja nekünk az összes töredéket, beleértve az utolsót is. Valószínűleg ugyanezt lehet szűrni IP alapján, de nem próbáltam, mert nem nagyon van ilyen csomag, és amikre szükségem volt, azokat könnyen megtaláltam az általános áramlásban. Itt vannak:
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 ..............
Ez egy csomag két töredéke (azonos azonosító 53652), egy fényképpel (az Exif szó látható az első csomagban). Tekintettel arra, hogy ezen a szinten vannak csomagok, de nem összevont formában a tárolókban, a probléma egyértelműen az összeállítással van. Végre erre is van okirati bizonyíték!
A csomagdekódoló nem tárt fel olyan problémát, amely megakadályozná az összeállítást. Itt próbálták ki: . Először, amikor megpróbálsz berakni valamit, a dekóder nem szereti a csomagformátumot. Kiderült, hogy van néhány extra két oktett az Srcmac és az Ethertype között (nem kapcsolódik a töredékinformációkhoz). Ezek eltávolítása után a dekóder működni kezdett. Ez azonban nem mutatott problémát.
Bármit is mondjunk, semmi mást nem találtunk, csak a Sysctl-eket. Nem maradt más hátra, mint megtalálni a módját a problémás szerverek azonosításának, hogy megértsük a léptéket és döntsünk a további lépésekről. A kívánt számlálót elég gyorsan megtalálták:
netstat -s | grep "packet reassembles failed”
Az snmpd-ben is megtalálható az OID=1.3.6.1.2.1.4.31.1.1.16.1 alatt ().
"Az IP-újraszerelési algoritmus által észlelt hibák száma (bármilyen okból: időtúllépés, hibák stb.)."
Azon szervercsoportok közül, amelyeken a problémát vizsgálták, kettőnél gyorsabban, kettőnél lassabban nőtt ez a számláló, kettőnél pedig egyáltalán nem. Ennek a számlálónak a dinamikájának összehasonlítása a Java szerver HTTP-hibáinak dinamikájával összefüggést mutatott ki. Vagyis a mérőt lehetett figyelni.
A problémák megbízható jelzése nagyon fontos, hogy pontosan meg lehessen állapítani, hogy a Sysctl visszagörgetése segít-e, mivel az előző történetből tudjuk, hogy ezt nem lehet azonnal megérteni az alkalmazásból. Ez a mutató lehetővé teszi számunkra, hogy azonosítsuk a termelés összes problémás területét, mielőtt a felhasználók felfedeznék azt.
A Sysctl visszagörgetése után a felügyeleti hibák megszűntek, így bebizonyosodott a problémák oka, valamint az, hogy a visszagörgetés segít.
Más szervereken visszaforgattuk a töredezettségi beállításokat, ahol új figyelés lép életbe, és valahol még több memóriát foglaltunk le a töredékekhez, mint az eddig alapértelmezett volt (ez UDP statisztika volt, aminek a részleges elvesztése az általános háttér mellett nem volt észrevehető) .
A legfontosabb kérdések
Miért töredezettek a csomagok az L3 kiegyensúlyozónkon? A felhasználóktól az egyensúlyozókhoz érkező csomagok többsége SYN és ACK. Ezeknek a csomagoknak a mérete kicsi. De mivel az ilyen csomagok aránya nagyon nagy, hátterükben nem vettük észre a nagy csomagok jelenlétét, amelyek töredezni kezdtek.
Az ok egy hibás konfigurációs szkript volt Vlan interfésszel rendelkező szervereken (akkor nagyon kevés címkézett forgalommal rendelkező szerver volt élesben). Az Advmss lehetővé teszi, hogy a kliens felé továbbítsuk azt az információt, hogy az irányunkba érkező csomagoknak kisebb méretűnek kell lenniük, hogy alagútfejlécek rögzítése után ne kelljen széttöredezni.
Miért nem segített a Sysctl visszaállítása, de az újraindítás igen? A Sysctl visszagörgetése megváltoztatta a csomagok egyesítéséhez rendelkezésre álló memória mennyiségét. Ugyanakkor nyilvánvalóan a töredékek memóriatúlcsordulása a kapcsolatok lelassulásához vezetett, ami a töredékek hosszú ideig tartó késleltetéséhez vezetett a sorban. Vagyis ciklusokban ment a folyamat.
Az újraindítás törölte a memóriát, és minden helyreállt.
Megoldható volt a megoldás nélkül? Igen ám, de nagy a kockázata annak, hogy támadás esetén a felhasználók szolgáltatás nélkül maradnak. Természetesen a Workaround használata különféle problémákat okozott, többek között az egyik szolgáltatás lelassulását a felhasználók számára, de ennek ellenére úgy gondoljuk, hogy a lépések indokoltak voltak.
Nagyon köszönöm Andrey Timofejevnek () a nyomozás lefolytatásában nyújtott segítségért, valamint Alekszej Krenev () - a Centos és a szervereken lévő kernelek frissítésével kapcsolatos titáni munkához. Egy folyamat, amit ebben az esetben többször is elölről kellett kezdeni, ezért is húzódott hosszú hónapokig.
Forrás: will.com