Waspada tina kerentanan anu nyababkeun babak damel. Bagian 1: FragmentSmack/SegmentSmack

Halo sadayana! Nami abdi Dmitry Samsonov, abdi damel salaku administrator sistem terkemuka di Odnoklassniki. Kami ngagaduhan langkung ti 7 rébu server fisik, 11 rébu wadah dina awan kami sareng 200 aplikasi, anu dina sababaraha konfigurasi ngabentuk 700 klaster anu béda. Seuseueurna server ngajalankeun CentOS 7.
Dina 14 Agustus 2018, inpormasi ngeunaan kerentanan FragmentSmack diterbitkeun
(CVE-2018-5391) jeung SegmentSmack (CVE-2018-5390). Ieu mangrupikeun kerentanan kalayan vektor serangan jaringan sareng skor anu cukup luhur (7.5), anu ngancam panolakan jasa (DoS) kusabab kakurangan sumber daya (CPU). Perbaikan kernel pikeun FragmentSmack henteu diusulkeun dina waktos éta; komo deui, éta kaluar langkung lami tibatan publikasi inpormasi ngeunaan kerentanan éta. Pikeun ngaleungitkeun SegmentSmack, disarankeun pikeun ngapdet kernel. Paket update sorangan dileupaskeun dina dinten anu sami, anu tinggaleun nyaéta masangna.
Henteu, kami henteu ngalawan ngamutahirkeun kernel pisan! Sanajan kitu, aya nuances ...

Kumaha urang ngamutahirkeun kernel on produksi

Sacara umum, teu aya anu rumit:

1. Ngundeur pakét;
2. Pasang aranjeunna dina sajumlah pangladén (kalebet pangladén anu nyayogikeun awan kami);
3. Pastikeun teu aya anu pegat;
4. Pastikeun yén sadaya setélan kernel standar diterapkeun tanpa kasalahan;
5. Antosan sababaraha dinten;
6. Pariksa kinerja server;
7. Pindahkeun panyebaran server énggal ka kernel énggal;
8. Apdet sadaya server ku pusat data (hiji pusat data dina hiji waktos pikeun ngaleutikan pangaruh kana pangguna upami aya masalah);
9. Reboot sadaya server.

Ngulang pikeun sakabéh cabang tina kernels kami boga. Dina momen éta:

• Stock CentOS 7 3.10 - pikeun kalolobaan server biasa;
• Vanili 4.19 - pikeun urang awan hiji-awan, sabab urang kudu BFQ, BBR, jsb;
• Elrepo kernel-ml 5.2 - pikeun distributor kacida dimuat, sabab 4.19 dipaké pikeun kalakuanana teu stabil, tapi fitur anu sarua diperlukeun.

Sakumaha anjeun tiasa duga, rebooting rébuan server peryogi waktos anu paling lami. Kusabab henteu sadayana kerentanan penting pikeun sadaya server, kami ngan ukur reboot anu tiasa diaksés langsung tina Internét. Dina awan, dina urutan teu ngawatesan kalenturan, urang teu dasi peti diaksés externally ka server individu kalawan kernel anyar, tapi reboot sadayana host tanpa iwal. Untungna, prosedur aya leuwih basajan ti jeung server biasa. Contona, wadah stateless saukur bisa mindahkeun ka server sejen salila reboot a.

Sanajan kitu, aya kénéh loba karya, sarta eta tiasa nyandak sababaraha minggu, sarta lamun aya wae masalah jeung versi anyar, nepi ka sababaraha bulan. Panyerang ngartos pisan ieu, janten aranjeunna peryogi rencana B.

FragmentSmack/SegmentSmack. Solusina

Untungna, pikeun sababaraha kerentanan sapertos rencana B aya, sareng éta disebut Workaround. Seringna, ieu mangrupikeun parobihan dina setélan kernel/aplikasi anu tiasa ngaminimalkeun pangaruh anu mungkin atanapi ngaleungitkeun lengkep eksploitasi kerentanan.

Dina kasus FragmentSmack/SegmentSmack diusulkeun Workaround sapertos kieu:

«Anjeun tiasa ngarobih nilai standar 4MB sareng 3MB dina net.ipv4.ipfrag_high_thresh sareng net.ipv4.ipfrag_low_thresh (sareng pasanganna pikeun ipv6 net.ipv6.ipfrag_high_thresh sareng net.ipv6.ipfrag_low_thresh) janten masing-masing 256 kB atanapi 192 kB handap. Tés nunjukkeun tetes leutik dugi ka signifikan dina pamakean CPU salami serangan gumantung kana hardware, setélan, sareng kaayaan. Sanajan kitu, meureun aya sababaraha dampak kinerja alatan ipfrag_high_thresh = 262144 bait, sabab ngan dua fragmen 64K bisa pas kana antrian reassembly dina hiji waktu. Salaku conto, aya résiko yén aplikasi anu tiasa dianggo sareng pakét UDP ageung bakal rusak".

Parameter sorangan dina dokuméntasi kernel digambarkeun saperti kieu:

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.

Urang teu boga UDPs badag dina jasa produksi. Henteu aya lalu lintas anu fragméntasi dina LAN; aya lalu lintas anu fragméntasi dina WAN, tapi henteu signifikan. Henteu aya tanda-tanda - anjeun tiasa ngaluncurkeun Workaround!

FragmentSmack/SegmentSmack. Getih munggaran

Masalah kahiji anu kami tepang nyaéta wadah awan kadang-kadang nerapkeun setélan énggal ngan ukur sawaréh (ngan ipfrag_low_thresh), sareng sakapeung henteu nerapkeunana pisan - aranjeunna ngan saukur nabrak di mimiti. Henteu mungkin pikeun ngahasilkeun deui masalah sacara stabil (sadayana setélan diterapkeun sacara manual tanpa aya kasusah). Ngartos naha wadahna ngadat di mimiti ogé henteu gampang: teu aya kasalahan anu kapendak. Hiji hal anu pasti: gulung deui setélan ngarengsekeun masalah sareng kacilakaan wadahna.

Naha éta henteu cekap pikeun nerapkeun Sysctl dina host? Wadahna hirup dina Namespace jaringan dedicated sorangan, jadi sahenteuna bagian tina parameter jaringan Sysctl dina wadahna bisa béda ti host.

Kumaha persisna setélan Sysctl diterapkeun dina wadahna? Kusabab wadahna kami henteu ngagaduhan hak istimewa, anjeun moal tiasa ngarobih setélan Sysctl ku lebet kana wadahna nyalira - anjeun ngan saukur teu gaduh hak anu cekap. Pikeun ngajalankeun peti, awan kami dina waktos éta nganggo Docker (ayeuna podman). Parameter wadahna anyar disalurkeun ka Docker via API, kalebet setélan Sysctl anu diperyogikeun.
Nalika milarian versi, tétéla yén Docker API henteu mulangkeun sadaya kasalahan (sahenteuna dina versi 1.10). Nalika kami nyobian ngamimitian wadahna ku "docker run", kami tungtungna ningali sahenteuna hiji hal:

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.

Nilai parameter henteu valid. Tapi naha? Jeung naha teu valid ngan kadang? Tétéla yén Docker henteu ngajamin urutan dimana parameter Sysctl diterapkeun (versi anu diuji panganyarna nyaéta 1.13.1), ku kituna sakapeung ipfrag_high_thresh nyobian disetel ka 256K nalika ipfrag_low_thresh masih 3M, nyaéta, wates luhur langkung handap. ti wates handap, nu ngarah ka kasalahan.

Dina waktos éta, kami parantos nganggo mékanisme sorangan pikeun ngonfigurasi ulang wadahna saatos ngamimitian (tirisan wadahna saatos freezer grup sarta executing paréntah dina namespasi wadahna via ip jaring), sarta kami ogé ditambahkeun nulis parameter Sysctl kana bagian ieu. Masalahna direngsekeun.

FragmentSmack/SegmentSmack. Getih munggaran 2

Sateuacan urang gaduh waktos ngartos pamakean Workaround dina awan, keluhan langka munggaran ti pangguna mimiti sumping. Dina waktu éta, sababaraha minggu geus kaliwat ti mimiti ngagunakeun Workaround dina server munggaran. Panaliti awal nunjukkeun yén keluhan ditampi ngalawan jasa individu, sareng henteu sadayana server jasa ieu. Masalahna deui janten teu pasti.

Anu mimiti, tangtosna, urang nyobian ngagulung deui setélan Sysctl, tapi ieu henteu ngagaduhan pangaruh. Rupa-rupa manipulasi sareng pangladén sareng setélan aplikasi ogé henteu ngabantosan. Reboot mantuan. Rebooting Linux henteu wajar sapertos biasa pikeun Windows dina jaman baheula. Sanajan kitu, éta mantuan, sarta kami chalked eta nepi ka "kernel glitch" nalika nerapkeun setélan anyar dina Sysctl. Kumaha sembrono éta ...

Tilu minggu ti harita masalahna kaulang deui. Konfigurasi server ieu cukup basajan: Nginx dina modeu proxy / balancer. Teu loba lalulintas. Catetan bubuka anyar: jumlah 504 kasalahan dina klien ningkat unggal dinten (Waktu Laju Gerbang). Grafik nunjukkeun jumlah kasalahan 504 per dinten pikeun layanan ieu:

Sadayana kasalahan ngeunaan backend anu sami - ngeunaan anu aya dina méga. Grafik konsumsi mémori pikeun fragmen pakét dina backend ieu katingali sapertos kieu:

Ieu salah sahiji manifestasi paling atra tina masalah dina grafik sistem operasi. Dina awan, dina waktos anu sami, masalah jaringan sanés sareng setélan QoS (Traffic Control) parantos dibenerkeun. Dina grafik konsumsi mémori pikeun fragmen pakét, éta katingalina sami:

Anggapan éta saderhana: upami aranjeunna katingali sami dina grafik, maka aranjeunna gaduh alesan anu sami. Sumawona, masalah naon waé sareng jinis mémori ieu jarang pisan.

Intina masalah tetep éta urang dipaké fq packet scheduler kalawan setélan standar di QoS. Sacara standar, pikeun hiji sambungan, éta ngidinan Anjeun pikeun nambahkeun 100 pakét kana antrian, sarta sababaraha sambungan, dina kaayaan kakurangan channel, mimiti bakiak antrian ka kapasitas. Dina hal ieu, pakét turun. Dina statistik tc (tc -s qdisc) tiasa katingali sapertos kieu:

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" nyaeta pakét turun alatan ngaleuwihan wates antrian hiji sambungan, sarta "turun 464545" nyaeta jumlah sadaya pakét turun tina scheduler ieu. Saatos ningkatkeun panjang antrian ka 1 sarébu sareng ngamimitian deui wadahna, masalahna eureun. Anjeun tiasa calik sareng nginum smoothie.

FragmentSmack/SegmentSmack. Getih Panungtungan

Anu mimiti, sababaraha bulan saatos pengumuman kerentanan dina kernel, perbaikan pikeun FragmentSmack tungtungna muncul (hayu kuring ngingetan yén babarengan sareng pengumuman dina bulan Agustus, perbaikan ngan pikeun SegmentSmack dileupaskeun), anu masihan kami kasempetan pikeun ngantunkeun Workaround, nu ngabalukarkeun urang rada loba gangguan. Salila ieu, urang parantos junun nransferkeun sababaraha server kana kernel énggal, sareng ayeuna urang kedah ngamimitian ti mimiti. Naha urang ngamutahirkeun kernel tanpa ngantosan ngalereskeun FragmentSmack? Kanyataanna nyaéta prosés ngajagi tina kerentanan ieu kabeneran (sareng dihijikeun) sareng prosés ngapdet CentOS sorangan (anu nyandak waktos langkung seueur tibatan ngan ukur kernel). Salaku tambahan, SegmentSmack mangrupikeun kerentanan anu langkung bahaya, sareng perbaikan pikeun éta langsung muncul, janten waé waé. Najan kitu, urang teu bisa ngan saukur ngamutahirkeun kernel on CentOS sabab kerentanan FragmentSmack, nu mucunghul dina mangsa CentOS 7.5, ieu ngan dibereskeun dina versi 7.6, jadi urang kudu eureun apdet pikeun 7.5 tur mimitian sakabeh deui ku update ka 7.6. Sarta ieu ogé kajadian.

Bréh, keluhan pamaké langka ngeunaan masalah geus balik ka kami. Ayeuna kami parantos terang yén aranjeunna sadayana aya hubunganana sareng unggah file ti klien ka sababaraha server kami. Leuwih ti éta, sajumlah leutik pisan unggah tina total massa ngaliwatan server ieu.

Sakumaha urang émut tina carita di luhur, ngagulung deui Sysctl henteu ngabantosan. Reboot mantuan, tapi samentara.
Kacurigaan ngeunaan Sysctl teu dipiceun, tapi waktos ieu diperlukeun pikeun ngumpulkeun saloba mungkin informasi. Aya ogé kakurangan ageung kamampuan pikeun ngahasilkeun deui masalah unggah dina klien pikeun diajar langkung tepat naon anu kajantenan.

Analisis sadaya statistik sareng log anu sayogi henteu ngajantenkeun urang langkung caket kana ngartos naon anu kajantenan. Aya kakurangan akut kamampuan pikeun ngahasilkeun deui masalah pikeun "ngarasa" sambungan anu khusus. Tungtungna, pamekar, ngagunakeun versi husus tina aplikasi, junun ngahontal réproduksi stabil tina masalah dina alat test nalika disambungkeun via Wi-Fi. Ieu narabas dina panalungtikan. Klién nyambung ka Nginx, anu diproksi kana backend, anu mangrupikeun aplikasi Java kami.

Dialog pikeun masalah sapertos kieu (dibereskeun dina sisi proxy Nginx):

1. Klién: nyuhunkeun nampi inpormasi ngeunaan ngaunduh file.
2. server Java: respon.
3. Klién: POST sareng file.
4. server Java: kasalahan.

Dina waktos anu sami, server Java nyerat kana log yén 0 bait data ditampi ti klien, sareng proxy Nginx nyerat yén pamundutna nyandak langkung ti 30 detik (30 detik mangrupikeun waktosna tina aplikasi klien). Naha waktosna sareng kunaon 0 bait? Ti hiji sudut pandang HTTP, sagalana jalan sakumaha sakuduna, tapi POST kalawan file sigana ngaleungit tina jaringan. Sumawona, éta ngaleungit antara klien sareng Nginx. Waktosna pikeun panangan diri sareng Tcpdump! Tapi mimitina anjeun kedah ngartos konfigurasi jaringan. Proksi Nginx aya di tukangeun kasaimbangan L3 NFware. Tunneling dipaké pikeun nganteurkeun pakét ti balancer L3 ka server, nu nambahkeun headers na kana pakét:

Dina hal ieu, jaringan datang ka server ieu dina bentuk lalulintas Vlan-tagged, nu ogé nambahkeun widang sorangan kana pakét:

Sareng patalimarga ieu ogé tiasa fragméntasi (éta perséntase leutik anu sami tina lalu lintas fragméntasi anu asup anu urang bahas nalika ngira-ngira résiko tina Workaround), anu ogé ngarobih eusi header:

Sakali deui: pakét anu encapsulated kalawan tag Vlan, encapsulated kalawan torowongan a, fragmented. Pikeun langkung ngartos kumaha ieu kajadian, hayu urang lacak jalur pakét ti klien ka proxy Nginx.

1. pakét ngahontal kasaimbangan L3. Pikeun routing bener dina puseur data, pakét ieu encapsulated dina torowongan sarta dikirim ka kartu jaringan.
2. Kusabab header pakét + torowongan henteu pas kana MTU, pakét dipotong kana fragmen sareng dikirim ka jaringan.
3. The switch sanggeus L3 balancer, nalika narima pakét a, nambahkeun tag Vlan ka dinya sarta ngirimkeunana dina.
4. Saklar di hareup proxy Nginx nilik (dumasar kana setélan port) yén server ieu expecting pakét Vlan-encapsulated, jadi ngirimkeunana sakumaha anu kasebut, tanpa nyoplokkeun tag Vlan.
5. Linux nyandak fragmen pakét individu sareng ngahijikeun kana hiji pakét ageung.
6. Salajengna, pakét ngahontal antarmuka Vlan, dimana lapisan munggaran dipiceun tina éta - enkapsulasi Vlan.
7. Linux Ubuntu lajeng ngirimkeunana ka panganteur Torowongan, dimana lapisan séjén dipiceun tina eta - Tunnel encapsulation.

Kasusahna nyaéta lulus sadayana ieu salaku parameter pikeun tcpdump.
Hayu urang mimitian ti tungtungna: aya bersih (tanpa headers perlu) pakét IP ti klien, kalawan vlan na torowongan encapsulation dihapus?

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

Henteu, henteu aya bungkusan sapertos kitu dina server. Jadi masalahna kudu aya saméméhna. Naha aya pakét anu ngan ukur enkapsulasi Vlan dihapus?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx mangrupikeun alamat IP klien dina format hex.
32:4 — alamat sareng panjang lapangan dimana SCR IP ditulis dina pakét Torowongan.

Alamat lapangan kedah dipilih ku gaya kasar, sabab dina Internét aranjeunna nyerat ngeunaan 40, 44, 50, 54, tapi teu aya alamat IP di dinya. Anjeun oge bisa nempo salah sahiji pakét dina hex (parameter -xx atanapi -XX di tcpdump) jeung ngitung alamat IP anjeun terang.

Aya fragmen pakét tanpa Vlan sareng Tunnel encapsulation dihapus?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

Sihir ieu bakal nunjukkeun ka urang sadaya fragmen, kalebet anu terakhir. Panginten, hal anu sami tiasa disaring ku IP, tapi kuring henteu nyobian, sabab henteu seueur pakét sapertos kitu, sareng anu kuring peryogikeun gampang dipendakan dina aliran umum. Ieu aranjeunna:

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

Ieu mangrupikeun dua fragmen tina hiji pakét (ID sami 53652) sareng poto (kecap Exif katingali dina pakét munggaran). Alatan kanyataan yén aya bungkusan dina tingkat ieu, tapi teu dina formulir ngahiji dina dumps, masalahna jelas jeung assembly nu. Tungtungna aya bukti dokumenter ieu!

Dekoder pakét henteu ngungkabkeun masalah anu bakal nyegah pangwangunan. Dicobian di dieu: hpd.gasmi.net. Mimitina, nalika anjeun nyobian barang-barang di dinya, dekoder henteu resep kana format pakét. Tétéla aya sababaraha tambahan dua oktét antara Srcmac na Ethertype (teu patali jeung informasi fragmen). Saatos miceun aranjeunna, decoder mimiti jalan. Sanajan kitu, éta némbongkeun euweuh masalah.
Naon waé anu dicarioskeun, teu aya anu sanés kapendak kecuali Sysctl. Sadaya anu tetep nyaéta milarian cara pikeun ngaidentipikasi server masalah pikeun ngartos skala sareng mutuskeun tindakan salajengna. The counter diperlukeun kapanggih cukup gancang:

netstat -s | grep "packet reassembles failed”

Éta ogé aya dina snmpd handapeun OID = 1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"Jumlah kagagalan dideteksi ku algoritma assembling ulang IP (kanggo alesan naon: timed out, kasalahan, jsb)."

Di antara grup server anu masalahna ditaliti, dina dua counter ieu ningkat langkung gancang, dina dua langkung laun, sareng dina dua deui henteu ningkat pisan. Ngabandingkeun dinamika counter ieu jeung dinamika kasalahan HTTP dina server Java wangsit korelasi a. Hartina, méter bisa diawaskeun.

Ngabogaan indikator dipercaya tina masalah penting pisan ku kituna anjeun bisa akurat nangtukeun naha rolling deui Sysctl mantuan, saprak carita saméméhna urang terang yen ieu teu bisa langsung dipikaharti tina aplikasi. Indikator ieu ngamungkinkeun urang pikeun ngaidentipikasi sadaya masalah dina produksi sateuacan pangguna mendakanana.
Saatos ngagulung deui Sysctl, kasalahan ngawaskeun lirén, ku kituna panyabab masalahna dibuktikeun, ogé kanyataan yén balikan deui ngabantosan.

Kami ngagulung deui setélan fragméntasi dina server anu sanés, dimana ngawaskeun énggal dimaénkeun, sareng dimana waé kami nyayogikeun langkung seueur mémori pikeun fragmen tibatan standar standar (ieu statistik UDP, leungitna parsial anu henteu katingali ngalawan latar umum). .

Patarosan anu paling penting

Naha pakét fragméntasi dina balancer L3 kami? Seuseueurna pakét anu sumping ti pangguna ka pangimbang nyaéta SYN sareng ACK. Ukuran bungkusan ieu leutik. Tapi kumargi pangsa pakét sapertos kitu ageung pisan, ngalawan latar tukangna kami henteu perhatikeun ayana pakét ageung anu mimiti sempalan.

Alesanana nyaéta skrip konfigurasi rusak advmss dina server kalawan interfaces Vlan (aya saeutik pisan server kalawan lalulintas di tag dina produksi dina waktu éta). Advmss ngamungkinkeun urang pikeun nepikeun ka klien informasi yén pakét arah urang kedah ukuranana leuwih leutik ku kituna sanggeus ngalampirkeun headers torowongan maranéhna teu kudu fragmented.

Naha Sysctl rollback teu mantuan, tapi reboot tuh? Ngagulung deui Sysctl ngarobih jumlah mémori anu sayogi pikeun ngahijikeun bungkusan. Dina waktu nu sarua, tétéla pisan kanyataan ngabahekeun memori pikeun fragmen ngarah ka slowdown sambungan, nu ngarah ka fragmen nu nyangsang pikeun lila dina antrian. Hartina, prosés lumangsung dina siklus.
Reboot ngabersihan mémori sareng sadayana dipulangkeun kana tatanan.

Naha éta tiasa dilakukeun tanpa Workaround? Leres, tapi aya résiko anu luhur pikeun ngantepkeun pangguna tanpa jasa upami aya serangan. Tangtosna, panggunaan Workaround nyababkeun sagala rupa masalah, kalebet ngalambatkeun salah sahiji jasa pikeun pangguna, tapi kami yakin yén tindakan éta leres.

Hatur nuhun pisan ka Andrey Timofeev (atimofeyev) pikeun bantuan dina ngalaksanakeun panalungtikan, kitu ogé Alexey Krenev (alat x) - pikeun karya titanic ngamutahirkeun Centos na kernels on server. Prosés anu dina hal ieu kedah dimimitian ti mimiti sababaraha kali, naha éta nyeret salami sababaraha bulan.

sumber: www.habr.com