🥇Jihadhari na udhaifu unaoleta raundi za kazi. Sehemu ya 1: FragmentSmack/SegmentSmack

Salaam wote! Jina langu ni Dmitry Samsonov, ninafanya kazi kama msimamizi mkuu wa mfumo huko Odnoklassniki. Tuna zaidi ya seva za kimwili elfu 7, vyombo elfu 11 kwenye wingu letu na programu 200, ambazo katika usanidi mbalimbali huunda makundi 700 tofauti. Idadi kubwa ya seva zinaendesha CentOS 7.
Tarehe 14 Agosti 2018, maelezo kuhusu uwezekano wa kuathiriwa na FragmentSmack yalichapishwa.
(CVE-2018-5391) na SegmentSmack (CVE-2018-5390) Hizi ni udhaifu na vekta ya mashambulizi ya mtandao na alama ya juu kabisa (7.5), ambayo inatishia kunyimwa huduma (DoS) kutokana na kumalizika kwa rasilimali (CPU). Marekebisho ya kernel ya FragmentSmack hayakupendekezwa wakati huo; zaidi ya hayo, yalitoka baadaye sana kuliko kuchapishwa kwa habari kuhusu athari. Ili kuondoa SegmentSmack, ilipendekezwa kusasisha kernel. Kifurushi cha sasisho chenyewe kilitolewa siku hiyo hiyo, kilichobaki ni kukisakinisha.
Hapana, hatupingani na kusasisha kernel hata kidogo! Walakini, kuna nuances ...

Jinsi tunavyosasisha kernel kwenye uzalishaji

Kwa ujumla, hakuna kitu ngumu:

Pakua vifurushi;
Zisakinishe kwenye seva kadhaa (pamoja na seva zinazosimamia wingu letu);
Hakikisha hakuna kitu kilichovunjika;
Hakikisha kuwa mipangilio yote ya kernel ya kawaida inatumika bila makosa;
Subiri siku chache;
Angalia utendaji wa seva;
Badilisha utumaji wa seva mpya kwa kernel mpya;
Sasisha seva zote kwa kituo cha data (kituo kimoja cha data kwa wakati mmoja ili kupunguza athari kwa watumiaji ikiwa kuna shida);
Washa upya seva zote.

Rudia kwa matawi yote ya kokwa tuliyo nayo. Kwa sasa ni:

Stock CentOS 7 3.10 - kwa seva nyingi za kawaida;
Vanilla 4.19 - kwa ajili yetu mawingu ya wingu moja, потому что нам нужен BFQ, BBR и т.д.;
Elrepo kernel-ml 5.2 - kwa wasambazaji wenye kubeba sana, kwa sababu 4.19 ilitumika kutokuwa thabiti, lakini vipengele sawa vinahitajika.

Kama unavyoweza kukisia, kuwasha tena maelfu ya seva huchukua muda mrefu zaidi. Kwa kuwa si udhaifu wote ambao ni muhimu kwa seva zote, tunawasha upya zile zinazoweza kufikiwa moja kwa moja kutoka kwa Mtandao pekee. Katika wingu, ili tusizuie kunyumbulika, hatufungi vyombo vinavyoweza kufikiwa nje na seva mahususi zilizo na kerneli mpya, lakini washa upya seva pangishi zote bila ubaguzi. Kwa bahati nzuri, utaratibu huko ni rahisi zaidi kuliko kwa seva za kawaida. Kwa mfano, vyombo visivyo na uraia vinaweza tu kuhamia kwenye seva nyingine wakati wa kuwasha upya.

Hata hivyo, bado kuna kazi nyingi, na inaweza kuchukua wiki kadhaa, na ikiwa kuna matatizo yoyote na toleo jipya, hadi miezi kadhaa. Wavamizi wanaelewa hili vizuri, kwa hivyo wanahitaji mpango B.

FragmentSmack/SegmentSmack. Suluhu

Kwa bahati nzuri, kwa udhaifu fulani mpango kama huo B upo, na unaitwa Workaround. Mara nyingi, haya ni mabadiliko katika mipangilio ya kernel/programu ambayo inaweza kupunguza athari iwezekanayo au kuondoa kabisa unyonyaji wa udhaifu.

Kwa upande wa FragmentSmack/SegmentSmack ilipendekezwa Suluhu hii:

«Unaweza kubadilisha thamani chaguomsingi za 4MB na 3MB katika net.ipv4.ipfrag_high_thresh na net.ipv4.ipfrag_low_thresh (na wenzao wa ipv6 net.ipv6.ipfrag_high_thresh na net.ipv6.ipv256.ipfrag_low_thresh) hadi 192kB262144 au kB64 kwa heshima_XNUMXkBXNUMX chini. Majaribio huonyesha matone madogo hadi makubwa katika matumizi ya CPU wakati wa shambulio kulingana na maunzi, mipangilio na hali. Hata hivyo, kunaweza kuwa na athari fulani ya utendakazi kutokana na ipfrag_high_thresh=XNUMX byte, kwani ni vipande viwili tu vya XNUMXK vinaweza kutoshea kwenye foleni ya kuunganisha tena kwa wakati mmoja. Kwa mfano, kuna hatari kwamba programu zinazofanya kazi na pakiti kubwa za UDP zitavunjika'.

Vigezo vyenyewe katika nyaraka za kernel imeelezwa kama ifuatavyo:

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.

Hatuna UDP kubwa kwenye huduma za uzalishaji. Hakuna trafiki iliyogawanyika kwenye LAN; kuna trafiki iliyogawanyika kwenye WAN, lakini sio muhimu. Hakuna dalili - unaweza kuzindua Workaround!

FragmentSmack/SegmentSmack. Damu ya kwanza

Shida ya kwanza tuliyokumbana nayo ni kwamba vyombo vya wingu wakati mwingine vilitumia mipangilio mipya kwa sehemu tu (ipfrag_low_thresh), na wakati mwingine havikuzitumia kabisa - zilianguka mwanzoni. Haikuwezekana kuzalisha tatizo kwa utulivu (mipangilio yote ilitumiwa kwa mikono bila matatizo yoyote). Kuelewa kwa nini kontena huanguka mwanzoni pia sio rahisi sana: hakuna makosa yaliyopatikana. Jambo moja lilikuwa hakika: kurudisha nyuma mipangilio hutatua tatizo na ajali za kontena.

Kwa nini haitoshi kutumia Sysctl kwa mwenyeji? Chombo kinaishi katika nafasi yake ya mtandao iliyojitolea, kwa hivyo angalau sehemu ya vigezo vya mtandao wa Sysctl kwenye chombo kinaweza kutofautiana na mwenyeji.

Mipangilio ya Sysctl inatumika vipi kwenye chombo? Kwa kuwa makontena yetu hayana haki, hutaweza kubadilisha mpangilio wowote wa Sysctl kwa kuingia kwenye chombo chenyewe - huna haki za kutosha. Ili kuendesha vyombo, wingu letu wakati huo lilitumia Docker (sasa podman) Vigezo vya kontena mpya vilipitishwa kwa Docker kupitia API, pamoja na mipangilio muhimu ya Sysctl.
Wakati wa kutafuta matoleo, iliibuka kuwa API ya Docker haikurudisha makosa yote (angalau katika toleo la 1.10). Tulipojaribu kuanza chombo kupitia "docker run", hatimaye tuliona angalau kitu:

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.

Thamani ya kigezo si sahihi. Lakini kwa nini? Na kwa nini sio halali wakati mwingine tu? Ilibainika kuwa Docker haitoi hakikisho la mpangilio ambao vigezo vya Sysctl vinatumika (toleo la hivi punde lililojaribiwa ni 1.13.1), kwa hivyo wakati mwingine ipfrag_high_thresh ilijaribu kuweka 256K wakati ipfrag_low_thresh bado ilikuwa 3M, yaani, kikomo cha juu kilikuwa cha chini. kuliko kikomo cha chini, ambacho kilisababisha kosa.

Wakati huo, tayari tulitumia utaratibu wetu wa kusanidi tena kontena baada ya kuanza (kufungia chombo baada ya friji ya kikundi na kutekeleza maagizo katika nafasi ya jina ya kontena kupitia ip neti), na pia tuliongeza uandishi wa vigezo vya Sysctl kwa sehemu hii. Tatizo lilitatuliwa.

FragmentSmack/SegmentSmack. Damu ya kwanza 2

Kabla hatujapata wakati wa kuelewa matumizi ya Workaround katika wingu, malalamiko ya kwanza nadra kutoka kwa watumiaji yalianza kuwasili. Wakati huo, wiki kadhaa zilikuwa zimepita tangu kuanza kwa kutumia Workaround kwenye seva za kwanza. Uchunguzi wa awali ulionyesha kuwa malalamiko yalipokelewa dhidi ya huduma za kibinafsi, na sio seva zote za huduma hizi. Tatizo limekuwa tena lisilo na uhakika.

Kwanza kabisa, sisi, kwa kweli, tulijaribu kurudisha mipangilio ya Sysctl, lakini hii haikuwa na athari yoyote. Udanganyifu mbalimbali na seva na mipangilio ya programu haukusaidia pia. Imesaidia kuwasha upya. Kuanzisha upya Linux sio kawaida kama ilivyokuwa kawaida kwa Windows katika siku za zamani. Hata hivyo, ilisaidia, na tuliiweka chaki hadi "kernel glitch" wakati wa kutumia mipangilio mipya katika Sysctl. Ilikuwa ni ujinga kiasi gani...

Wiki tatu baadaye tatizo lilijirudia. Usanidi wa seva hizi ulikuwa rahisi sana: Nginx katika hali ya proksi/sawazisha. Sio trafiki nyingi. Ujumbe mpya wa utangulizi: idadi ya makosa 504 kwa wateja inaongezeka kila siku (Muda wa Kuisha wa Lango) Grafu inaonyesha idadi ya makosa 504 kwa siku kwa huduma hii:

Makosa yote ni kuhusu backend sawa - kuhusu moja ambayo ni katika wingu. Grafu ya utumiaji wa kumbukumbu ya vipande vya kifurushi kwenye sehemu hii ya nyuma ilionekana kama hii:

Hii ni mojawapo ya maonyesho ya wazi zaidi ya tatizo katika grafu za mfumo wa uendeshaji. Katika wingu, wakati huo huo, shida nyingine ya mtandao na mipangilio ya QoS (Udhibiti wa Trafiki) iliwekwa. Kwenye grafu ya utumiaji wa kumbukumbu kwa vipande vya pakiti, ilionekana sawa:

Dhana ilikuwa rahisi: ikiwa wanaonekana sawa kwenye grafu, basi wana sababu sawa. Aidha, matatizo yoyote na aina hii ya kumbukumbu ni nadra sana.

Kiini cha tatizo lililowekwa ni kwamba tulitumia kipanga ratiba cha pakiti ya fq na mipangilio chaguo-msingi katika QoS. Kwa chaguo-msingi, kwa uunganisho mmoja, inakuwezesha kuongeza pakiti 100 kwenye foleni, na baadhi ya viunganisho, katika hali ya uhaba wa kituo, walianza kuziba foleni kwa uwezo. Katika kesi hii, pakiti zimeshuka. Katika takwimu za tc (tc -s qdisc) inaweza kuonekana kama hii:

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" ni pakiti zilizodondoshwa kwa sababu ya kuzidi kikomo cha foleni cha muunganisho mmoja, na "imeshuka 464545" ni jumla ya pakiti zote zilizodondoshwa za kipanga ratiba hiki. Baada ya kuongeza urefu wa foleni hadi elfu 1 na kuanzisha tena vyombo, shida iliacha kutokea. Unaweza kukaa nyuma na kunywa smoothie.

FragmentSmack/SegmentSmack. Damu ya Mwisho

Kwanza, miezi kadhaa baada ya kutangazwa kwa udhaifu kwenye kernel, marekebisho ya FragmentSmack hatimaye yalionekana (wacha nikukumbushe kwamba pamoja na tangazo la Agosti, marekebisho ya SegmentSmack pekee yalitolewa), ambayo yalitupa nafasi ya kuachana na Workaround, ambayo ilituletea shida sana. Wakati huu, tayari tumeweza kuhamisha baadhi ya seva kwenye kernel mpya, na sasa tulipaswa kuanza tangu mwanzo. Kwa nini tulisasisha kernel bila kungoja urekebishaji wa FragmentSmack? Ukweli ni kwamba mchakato wa kulinda dhidi ya udhaifu huu uliambatana (na kuunganishwa) na mchakato wa kusasisha CentOS yenyewe (ambayo inachukua muda zaidi kuliko kusasisha kernel tu). Kwa kuongeza, SegmentSmack ni hatari zaidi, na marekebisho yake yalionekana mara moja, kwa hivyo ilikuwa na maana hata hivyo. Walakini, hatukuweza kusasisha kernel kwenye CentOS kwa sababu hatari ya FragmentSmack, ambayo ilionekana wakati wa CentOS 7.5, ilirekebishwa tu katika toleo la 7.6, kwa hivyo ilitubidi kusimamisha sasisho hadi 7.5 na kuanza tena na sasisho hadi 7.6. Na hii pia hutokea.

Pili, malalamiko ya nadra ya watumiaji kuhusu shida yamerudi kwetu. Sasa tayari tunajua kwa hakika kwamba zote zinahusiana na upakiaji wa faili kutoka kwa wateja hadi kwa baadhi ya seva zetu. Zaidi ya hayo, idadi ndogo sana ya upakiaji kutoka kwa wingi wa jumla ilipitia seva hizi.

Kama tunavyokumbuka kutoka kwa hadithi hapo juu, kurudisha nyuma Sysctl hakujasaidia. Reboot imesaidia, lakini kwa muda.
Tuhuma kuhusu Sysctl hazikuondolewa, lakini wakati huu ilikuwa ni lazima kukusanya taarifa nyingi iwezekanavyo. Pia kulikuwa na ukosefu mkubwa wa uwezo wa kuzalisha tena tatizo la upakiaji kwa mteja ili kusoma kwa usahihi zaidi kile kilichokuwa kikifanyika.

Uchambuzi wa takwimu na kumbukumbu zote zinazopatikana haukutuletea karibu kuelewa kinachoendelea. Kulikuwa na ukosefu mkubwa wa uwezo wa kuzalisha tatizo ili "kuhisi" uhusiano maalum. Hatimaye, watengenezaji, kwa kutumia toleo maalum la programu, waliweza kufikia uzazi thabiti wa matatizo kwenye kifaa cha mtihani wakati wa kushikamana kupitia Wi-Fi. Hii ilikuwa mafanikio katika uchunguzi. Mteja aliunganishwa kwa Nginx, ambayo ilitumika kwa upande wa nyuma, ambayo ilikuwa programu yetu ya Java.

Mazungumzo ya shida yalikuwa kama haya (yaliyowekwa kwa upande wa wakala wa Nginx):

Mteja: ombi la kupokea habari kuhusu kupakua faili.
Seva ya Java: majibu.
Mteja: POST na faili.
Seva ya Java: hitilafu.

Wakati huo huo, seva ya Java inaandika kwa logi kwamba ka 0 za data zilipokelewa kutoka kwa mteja, na wakala wa Nginx anaandika kwamba ombi lilichukua zaidi ya sekunde 30 (sekunde 30 ni muda wa maombi ya mteja). Kwa nini muda umeisha na kwa nini baiti 0? Kwa mtazamo wa HTTP, kila kitu hufanya kazi kama inavyopaswa, lakini POST iliyo na faili inaonekana kutoweka kutoka kwa mtandao. Kwa kuongezea, inatoweka kati ya mteja na Nginx. Ni wakati wa kujizatiti na Tcpdump! Lakini kwanza unahitaji kuelewa usanidi wa mtandao. Seva mbadala ya Nginx iko nyuma ya kisawazishi cha L3 NFware. Uwekaji tunnel hutumika kupeana pakiti kutoka kwa kisawazishaji cha L3 hadi kwa seva, ambayo huongeza vichwa vyake kwenye pakiti:

Katika kesi hii, mtandao unakuja kwa seva hii kwa namna ya trafiki yenye lebo ya Vlan, ambayo pia inaongeza uwanja wake kwenye pakiti:

Na trafiki hii pia inaweza kugawanywa (asilimia hiyo hiyo ndogo ya trafiki iliyogawanyika inayoingia ambayo tulizungumza juu yake wakati wa kutathmini hatari kutoka kwa Workaround), ambayo pia hubadilisha yaliyomo kwenye vichwa:

Mara nyingine tena: pakiti zimefungwa na lebo ya Vlan, iliyoingizwa na handaki, imegawanyika. Ili kuelewa vyema jinsi hii inatokea, hebu tufuate njia ya pakiti kutoka kwa mteja hadi kwa seva mbadala ya Nginx.

Pakiti hufikia usawa wa L3. Kwa uelekezaji sahihi ndani ya kituo cha data, pakiti imefungwa kwenye handaki na kutumwa kwa kadi ya mtandao.
Kwa kuwa pakiti + vichwa vya handaki haviingii kwenye MTU, pakiti hukatwa vipande vipande na kutumwa kwenye mtandao.
Kubadili baada ya kusawazisha L3, wakati wa kupokea pakiti, huongeza lebo ya Vlan kwake na kuituma.
Swichi iliyo mbele ya proksi ya Nginx inaona (kulingana na mipangilio ya bandari) kwamba seva inatarajia pakiti iliyofunikwa na Vlan, kwa hivyo huituma kama ilivyo, bila kuondoa lebo ya Vlan.
Linux huchukua vipande vya vifurushi vya mtu binafsi na kuviunganisha kwenye kifurushi kimoja kikubwa.
Ifuatayo, pakiti hufikia kiolesura cha Vlan, ambapo safu ya kwanza imeondolewa kutoka kwayo - encapsulation ya Vlan.
Linux kisha huituma kwa kiolesura cha Tunnel, ambapo safu nyingine huondolewa kutoka kwayo - Ufungaji wa Tunnel.

Ugumu ni kupitisha haya yote kama vigezo kwa tcpdump.
Wacha tuanze kutoka mwisho: je, kuna pakiti za IP safi (bila vichwa vya lazima) kutoka kwa wateja, na uwekaji wa vlan na handaki umeondolewa?

tcpdump host <ip клиента>

Hapana, hapakuwa na vifurushi kama hivyo kwenye seva. Kwa hivyo shida lazima iwe hapo awali. Je, kuna pakiti zilizo na usimbaji wa Vlan pekee zimeondolewa?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx ni anwani ya IP ya mteja katika umbizo la hex.
32:4 - anwani na urefu wa shamba ambalo SCR IP imeandikwa kwenye pakiti ya Tunnel.

Anwani ya shamba ilipaswa kuchaguliwa kwa nguvu ya kikatili, kwani kwenye mtandao wanaandika kuhusu 40, 44, 50, 54, lakini hapakuwa na anwani ya IP huko. Unaweza pia kuangalia moja ya pakiti katika hex (parameta -xx au -XX katika tcpdump) na kuhesabu anwani ya IP unayojua.

Kuna vipande vya pakiti bila Vlan na Tunnel encapsulation kuondolewa?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Uchawi huu utatuonyesha vipande vyote, ikiwa ni pamoja na moja ya mwisho. Pengine, kitu kimoja kinaweza kuchujwa na IP, lakini sikujaribu, kwa sababu hakuna pakiti nyingi kama hizo, na zile nilizohitaji zilipatikana kwa urahisi katika mtiririko wa jumla. Hizi hapa:

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 ..............

Hizi ni vipande viwili vya kifurushi kimoja (kitambulisho sawa 53652) na picha (neno Exif linaonekana kwenye kifurushi cha kwanza). Kutokana na ukweli kwamba kuna vifurushi katika ngazi hii, lakini si katika fomu iliyounganishwa katika utupaji, tatizo ni wazi na mkusanyiko. Hatimaye kuna ushahidi wa maandishi wa hili!

Decoder ya pakiti haikufunua shida zozote ambazo zingezuia ujenzi. Ilijaribu hapa: hpd.gasmi.net. Mara ya kwanza, unapojaribu kuweka kitu hapo, avkodare haipendi umbizo la pakiti. Ilibainika kuwa kulikuwa na pweza mbili za ziada kati ya Srcmac na Ethertype (hazihusiani na maelezo ya vipande). Baada ya kuwaondoa, avkodare ilianza kufanya kazi. Walakini, haikuonyesha shida.
Chochote mtu anaweza kusema, hakuna kitu kingine kilichopatikana isipokuwa hizo Sysctl. Iliyobaki ni kutafuta njia ya kutambua seva za shida ili kuelewa kiwango na kuamua juu ya hatua zaidi. Kaunta inayohitajika ilipatikana haraka vya kutosha:

netstat -s | grep "packet reassembles failed”

Pia iko katika snmpd chini ya OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"Idadi ya mapungufu yaliyogunduliwa na algorithm ya kukusanya tena IP (kwa sababu yoyote: imepitwa na wakati, makosa, n.k.)."

Kati ya kikundi cha seva ambazo shida ilisomwa, kwa mbili counter hii iliongezeka kwa kasi, kwa mbili polepole zaidi, na kwa mbili zaidi haikuongezeka hata kidogo. Kulinganisha mienendo ya kaunta hii na mienendo ya hitilafu za HTTP kwenye seva ya Java ilidhihirisha uwiano. Hiyo ni, mita inaweza kufuatiliwa.

Kuwa na kiashiria cha kuaminika cha shida ni muhimu sana ili uweze kuamua kwa usahihi ikiwa kurudisha nyuma Sysctl husaidia, kwani kutoka kwa hadithi iliyopita tunajua kuwa hii haiwezi kueleweka mara moja kutoka kwa programu. Kiashiria hiki kinaweza kuturuhusu kutambua maeneo yote ya matatizo katika uzalishaji kabla ya watumiaji kugundua.
Baada ya kurudisha nyuma Sysctl, makosa ya ufuatiliaji yalisimama, kwa hivyo sababu ya shida ilithibitishwa, na ukweli kwamba kurudi nyuma husaidia.

Tulirudisha mipangilio ya kugawanyika kwenye seva zingine, ambapo ufuatiliaji mpya ulianza kutumika, na mahali pengine tulitenga kumbukumbu zaidi ya vipande kuliko ilivyokuwa chaguo-msingi (hii ilikuwa takwimu za UDP, upotezaji wa sehemu ambayo haukuonekana dhidi ya msingi wa jumla) .

Maswali muhimu zaidi

Kwa nini pakiti zimegawanywa kwenye mizani yetu ya L3? Pakiti nyingi zinazofika kutoka kwa watumiaji hadi kwa visawazishaji ni SYN na ACK. Ukubwa wa vifurushi hivi ni ndogo. Lakini kwa kuwa sehemu ya pakiti hizo ni kubwa sana, dhidi ya historia yao hatukuona kuwepo kwa pakiti kubwa ambazo zilianza kugawanyika.

Sababu ilikuwa hati ya usanidi iliyovunjika advmss kwenye seva zilizo na miingiliano ya Vlan (kulikuwa na seva chache sana zilizo na trafiki yenye lebo katika uzalishaji wakati huo). Advmss huturuhusu kuwasilisha kwa mteja habari kwamba pakiti katika mwelekeo wetu zinapaswa kuwa ndogo kwa ukubwa ili baada ya kuambatanisha vichwa vya handaki kwao sio lazima kugawanyika.

Kwa nini urejeshaji wa Sysctl haukusaidia, lakini kuwasha tena? Kurudisha nyuma Sysctl ilibadilisha kiwango cha kumbukumbu kinachopatikana cha kuunganisha vifurushi. Wakati huo huo, inaonekana ukweli halisi wa kufurika kwa kumbukumbu kwa vipande ulisababisha kupungua kwa miunganisho, ambayo ilisababisha vipande kucheleweshwa kwa muda mrefu kwenye foleni. Hiyo ni, mchakato ulikwenda kwa mzunguko.
Kuwasha upya kulifuta kumbukumbu na kila kitu kilirudi kwa mpangilio.

Iliwezekana kufanya bila Workaround? Ndiyo, lakini kuna hatari kubwa ya kuacha watumiaji bila huduma katika tukio la mashambulizi. Bila shaka, matumizi ya Workaround yalisababisha matatizo mbalimbali, ikiwa ni pamoja na kupungua kwa moja ya huduma kwa watumiaji, lakini hata hivyo tunaamini kwamba vitendo vilihesabiwa haki.

Asante sana kwa Andrey Timofeev (atimofeyev) kwa msaada katika kufanya uchunguzi, na vile vile Alexey Krenev (kifaax) - kwa kazi ya titanic ya kusasisha Centos na kernels kwenye seva. Mchakato ambao katika kesi hii ulipaswa kuanza tangu mwanzo mara kadhaa, ndiyo sababu ulivuta kwa miezi mingi.

Chanzo: mapenzi.com

Jihadharini na udhaifu unaoleta raundi za kazi. Sehemu ya 1: FragmentSmack/SegmentSmack