Hai semua! Nama saya Dmitry Samsonov, saya bekerja sebagai pentadbir sistem terkemuka di Odnoklassniki. Kami mempunyai lebih daripada 7 ribu pelayan fizikal, 11 ribu kontena dalam awan kami dan 200 aplikasi, yang dalam pelbagai konfigurasi membentuk 700 kelompok berbeza. Sebilangan besar pelayan menjalankan CentOS 7.
Pada 14 Ogos 2018, maklumat tentang kerentanan FragmentSmack telah diterbitkan
() dan SegmentSmack (). Ini adalah kelemahan dengan vektor serangan rangkaian dan skor yang agak tinggi (7.5), yang mengancam penafian perkhidmatan (DoS) akibat kehabisan sumber (CPU). Pembetulan kernel untuk FragmentSmack tidak dicadangkan pada masa itu; lebih-lebih lagi, ia keluar lebih lewat daripada penerbitan maklumat tentang kelemahan. Untuk menghapuskan SegmentSmack, dicadangkan untuk mengemas kini kernel. Pakej kemas kini itu sendiri dikeluarkan pada hari yang sama, yang tinggal hanyalah memasangnya.
Tidak, kami sama sekali tidak menentang mengemas kini kernel! Walau bagaimanapun, terdapat nuansa ...
Cara kami mengemas kini kernel pada pengeluaran
Secara umum, tiada yang rumit:
- Muat turun pakej;
- Pasangnya pada beberapa pelayan (termasuk pelayan yang mengehos awan kami);
- Pastikan tiada yang rosak;
- Pastikan semua tetapan kernel standard digunakan tanpa ralat;
- Tunggu beberapa hari;
- Semak prestasi pelayan;
- Tukar penggunaan pelayan baharu kepada kernel baharu;
- Kemas kini semua pelayan mengikut pusat data (satu pusat data pada satu masa untuk meminimumkan kesan ke atas pengguna sekiranya berlaku masalah);
- But semula semua pelayan.
Ulang untuk semua cabang biji yang kita ada. Pada masa ini ia adalah:
- Stock CentOS 7 3.10 - untuk kebanyakan pelayan biasa;
- Vanila 4.19 - untuk kami , kerana kita memerlukan BFQ, BBR, dll.;
- Elrepo kernel-ml 5.2 - untuk , kerana 4.19 digunakan untuk berkelakuan tidak stabil, tetapi ciri yang sama diperlukan.
Seperti yang anda duga, but semula beribu-ribu pelayan mengambil masa yang paling lama. Memandangkan bukan semua kelemahan adalah kritikal untuk semua pelayan, kami hanya but semula yang boleh diakses secara langsung daripada Internet. Dalam awan, untuk tidak mengehadkan fleksibiliti, kami tidak mengikat bekas yang boleh diakses secara luaran kepada pelayan individu dengan kernel baharu, tetapi but semula semua hos tanpa pengecualian. Nasib baik, prosedur di sana lebih mudah daripada dengan pelayan biasa. Sebagai contoh, bekas tanpa kewarganegaraan hanya boleh berpindah ke pelayan lain semasa but semula.
Walau bagaimanapun, masih terdapat banyak kerja, dan ia boleh mengambil masa beberapa minggu, dan jika terdapat sebarang masalah dengan versi baharu, sehingga beberapa bulan. Penyerang memahami perkara ini dengan baik, jadi mereka memerlukan pelan B.
FragmentSmack/SegmentSmack. Penyelesaian
Nasib baik, untuk beberapa kelemahan pelan B seperti itu wujud, dan ia dipanggil Penyelesaian. Selalunya, ini ialah perubahan dalam tetapan kernel/aplikasi yang boleh meminimumkan kesan yang mungkin atau menghapuskan sepenuhnya eksploitasi kelemahan.
Dalam kes FragmentSmack/SegmentSmack Penyelesaian ini:
Β«Anda boleh menukar nilai lalai 4MB dan 3MB dalam net.ipv4.ipfrag_high_thresh dan net.ipv4.ipfrag_low_thresh (dan rakan sejawatannya untuk ipv6 net.ipv6.ipfrag_high_thresh dan net.ipv6.ipfrag_low_thresh) masing-masing kepada 256 kB dan 192 kB lebih rendah. Ujian menunjukkan penurunan kecil hingga ketara dalam penggunaan CPU semasa serangan bergantung pada perkakasan, tetapan dan keadaan. Walau bagaimanapun, mungkin terdapat beberapa kesan prestasi disebabkan oleh ipfrag_high_thresh=262144 bait, kerana hanya dua serpihan 64K boleh dimuatkan ke dalam baris gilir pemasangan semula pada satu masa. Sebagai contoh, terdapat risiko bahawa aplikasi yang berfungsi dengan paket UDP yang besar akan rosak'.
Parameter itu sendiri diterangkan seperti berikut:
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.
Kami tidak mempunyai UDP yang besar pada perkhidmatan pengeluaran. Tiada trafik berpecah-belah pada LAN; terdapat trafik berpecah-belah pada WAN, tetapi tidak penting. Tiada tanda - anda boleh melancarkan Penyelesaian!
FragmentSmack/SegmentSmack. Darah pertama
Masalah pertama yang kami hadapi ialah bekas awan kadangkala menggunakan tetapan baharu hanya sebahagiannya (hanya ipfrag_low_thresh), dan kadangkala tidak menggunakannya sama sekali - ia hanya ranap pada mulanya. Tidak mungkin untuk menghasilkan semula masalah secara stabil (semua tetapan digunakan secara manual tanpa sebarang kesulitan). Memahami sebab kontena ranap pada permulaan juga tidak begitu mudah: tiada ralat ditemui. Satu perkara yang pasti: melancarkan semula tetapan menyelesaikan masalah dengan ranap kontena.
Mengapa tidak cukup untuk menggunakan Sysctl pada hos? Bekas itu tinggal dalam Ruang Nama rangkaian khususnya sendiri, jadi sekurang-kurangnya dalam bekas mungkin berbeza daripada hos.
Sejauh manakah tetapan Sysctl digunakan dalam bekas? Memandangkan bekas kami tidak mempunyai keistimewaan, anda tidak akan dapat menukar sebarang tetapan Sysctl dengan masuk ke dalam bekas itu sendiri - anda tidak mempunyai hak yang mencukupi. Untuk menjalankan kontena, awan kami pada masa itu menggunakan Docker (sekarang ). Parameter bekas baharu telah dihantar kepada Docker melalui API, termasuk tetapan Sysctl yang diperlukan.
Semasa mencari melalui versi, ternyata API Docker tidak mengembalikan semua ralat (sekurang-kurangnya dalam versi 1.10). Apabila kami cuba memulakan bekas melalui "larian docker", kami akhirnya melihat sekurang-kurangnya sesuatu:
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 tidak sah. Tapi kenapa? Dan mengapa ia tidak sah hanya kadang-kadang? Ternyata Docker tidak menjamin susunan parameter Sysctl digunakan (versi terbaharu yang diuji ialah 1.13.1), jadi kadangkala ipfrag_high_thresh cuba ditetapkan kepada 256K apabila ipfrag_low_thresh masih 3M, iaitu had atas lebih rendah daripada had yang lebih rendah, yang membawa kepada ralat.
Pada masa itu, kami telah menggunakan mekanisme kami sendiri untuk mengkonfigurasi semula bekas selepas permulaan (membekukan bekas selepas dan melaksanakan arahan dalam ruang nama bekas melalui ), dan kami juga menambah menulis parameter Sysctl ke bahagian ini. Masalah telah diselesaikan.
FragmentSmack/SegmentSmack. Darah Pertama 2
Sebelum kami mempunyai masa untuk memahami penggunaan Penyelesaian dalam awan, aduan pertama yang jarang berlaku daripada pengguna mula tiba. Pada masa itu, beberapa minggu telah berlalu sejak mula menggunakan Penyelesaian pada pelayan pertama. Siasatan awal menunjukkan bahawa aduan diterima terhadap perkhidmatan individu, dan bukan semua pelayan perkhidmatan ini. Masalahnya sekali lagi menjadi sangat tidak menentu.
Pertama sekali, kami, sudah tentu, cuba melancarkan tetapan Sysctl, tetapi ini tidak mempunyai sebarang kesan. Pelbagai manipulasi dengan tetapan pelayan dan aplikasi juga tidak membantu. But semula telah membantu. Mengebut semula Linux adalah luar biasa seperti biasa untuk Windows pada zaman dahulu. Walau bagaimanapun, ia membantu, dan kami mengaitkannya kepada "kernel glitch" apabila menggunakan tetapan baharu dalam Sysctl. Betapa remehnya...
Tiga minggu kemudian masalah itu berulang. Konfigurasi pelayan ini agak mudah: Nginx dalam mod proksi/pengimbang. Tidak banyak lalu lintas. Nota pengenalan baharu: bilangan 504 ralat pada pelanggan semakin meningkat setiap hari (). Graf menunjukkan bilangan 504 ralat setiap hari untuk perkhidmatan ini:
Semua ralat adalah kira-kira bahagian belakang yang sama - tentang ralat yang ada di awan. Graf penggunaan memori untuk serpihan pakej pada bahagian belakang ini kelihatan seperti ini:
Ini adalah salah satu manifestasi paling jelas masalah dalam graf sistem pengendalian. Dalam awan, pada masa yang sama, satu lagi masalah rangkaian dengan tetapan QoS (Kawalan Trafik) telah dibetulkan. Pada graf penggunaan memori untuk serpihan paket, ia kelihatan betul-betul sama:
Andaian adalah mudah: jika ia kelihatan sama pada graf, maka ia mempunyai sebab yang sama. Lebih-lebih lagi, sebarang masalah dengan memori jenis ini sangat jarang berlaku.
Intipati masalah tetap ialah kami menggunakan penjadual paket fq dengan tetapan lalai dalam QoS. Secara lalai, untuk satu sambungan, ia membolehkan anda menambah 100 paket ke baris gilir, dan beberapa sambungan, dalam situasi kekurangan saluran, mula menyumbat baris gilir ke kapasiti. Dalam kes ini, paket digugurkan. Dalam statistik tc (tc -s qdisc) ia boleh dilihat seperti ini:
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" ialah paket yang digugurkan kerana melebihi had baris gilir satu sambungan dan "tercicir 464545" ialah jumlah semua paket yang digugurkan bagi penjadual ini. Selepas menambah panjang baris gilir kepada 1 ribu dan memulakan semula bekas, masalah itu berhenti berlaku. Anda boleh duduk dan minum smoothie.
FragmentSmack/SegmentSmack. Darah Terakhir
Pertama, beberapa bulan selepas pengumuman kelemahan dalam kernel, pembetulan untuk FragmentSmack akhirnya muncul (biar saya ingatkan anda bahawa bersama-sama dengan pengumuman pada bulan Ogos, pembetulan hanya untuk SegmentSmack telah dikeluarkan), yang memberi kami peluang untuk meninggalkan Penyelesaian, yang menyebabkan kami banyak masalah. Pada masa ini, kami telah berjaya memindahkan beberapa pelayan ke kernel baharu, dan kini kami perlu bermula dari awal. Mengapa kami mengemas kini kernel tanpa menunggu pembetulan FragmentSmack? Hakikatnya ialah proses melindungi daripada kelemahan ini bertepatan (dan digabungkan) dengan proses mengemas kini CentOS itu sendiri (yang memerlukan lebih banyak masa daripada mengemas kini kernel sahaja). Selain itu, SegmentSmack ialah kerentanan yang lebih berbahaya, dan pembetulan untuknya muncul serta-merta, jadi ia tetap masuk akal. Walau bagaimanapun, kami tidak boleh hanya mengemas kini kernel pada CentOS kerana kerentanan FragmentSmack, yang muncul semasa CentOS 7.5, hanya diperbaiki dalam versi 7.6, jadi kami terpaksa menghentikan kemas kini kepada 7.5 dan mula semula dengan kemas kini kepada 7.6. Dan ini juga berlaku.
Kedua, aduan pengguna yang jarang berlaku tentang masalah telah kembali kepada kami. Kini kami sudah mengetahui dengan pasti bahawa semuanya berkaitan dengan muat naik fail daripada pelanggan ke beberapa pelayan kami. Selain itu, sejumlah kecil muat naik daripada jumlah jisim telah melalui pelayan ini.
Seperti yang kita ingat dari cerita di atas, melancarkan Sysctl tidak membantu. But semula membantu, tetapi buat sementara waktu.
Kecurigaan mengenai Sysctl tidak dialih keluar, tetapi kali ini adalah perlu untuk mengumpul maklumat sebanyak mungkin. Terdapat juga kekurangan besar keupayaan untuk menghasilkan semula masalah muat naik pada pelanggan untuk mengkaji dengan lebih tepat apa yang berlaku.
Analisis semua statistik dan log yang tersedia tidak membawa kami lebih dekat untuk memahami perkara yang berlaku. Terdapat kekurangan akut keupayaan untuk menghasilkan semula masalah untuk "merasakan" sambungan tertentu. Akhirnya, pembangun, menggunakan versi khas aplikasi, berjaya mencapai pengeluaran semula masalah yang stabil pada peranti ujian apabila disambungkan melalui Wi-Fi. Ini adalah satu kejayaan dalam penyiasatan. Pelanggan disambungkan ke Nginx, yang diproksi ke bahagian belakang, yang merupakan aplikasi Java kami.
Dialog untuk masalah adalah seperti ini (ditetapkan pada bahagian proksi Nginx):
- Klien: meminta untuk menerima maklumat tentang memuat turun fail.
- Pelayan Java: respons.
- Klien: POST dengan fail.
- Pelayan Java: ralat.
Pada masa yang sama, pelayan Java menulis pada log bahawa 0 bait data telah diterima daripada klien, dan proksi Nginx menulis bahawa permintaan mengambil masa lebih daripada 30 saat (30 saat ialah tamat masa aplikasi klien). Mengapa tamat masa dan mengapa 0 bait? Dari perspektif HTTP, semuanya berfungsi sebagaimana mestinya, tetapi POST dengan fail nampaknya hilang dari rangkaian. Selain itu, ia hilang antara pelanggan dan Nginx. Sudah tiba masanya untuk mempersenjatai diri anda dengan Tcpdump! Tetapi pertama-tama anda perlu memahami konfigurasi rangkaian. Proksi Nginx berada di belakang pengimbang L3 . Terowong digunakan untuk menghantar paket dari pengimbang L3 ke pelayan, yang menambahkan pengepalanya pada paket:
Dalam kes ini, rangkaian datang ke pelayan ini dalam bentuk trafik berteg Vlan, yang juga menambah medannya sendiri pada paket:
Dan trafik ini juga boleh dipecah-pecahkan (peratusan kecil yang sama bagi trafik berpecah-belah yang sama yang kita bincangkan semasa menilai risiko daripada Penyelesaian), yang turut mengubah kandungan pengepala:
Sekali lagi: paket dikapsulkan dengan tag Vlan, dikapsulkan dengan terowong, berpecah-belah. Untuk lebih memahami bagaimana ini berlaku, mari kita jejak laluan paket dari klien ke proksi Nginx.
- Paket mencapai pengimbang L3. Untuk penghalaan yang betul dalam pusat data, paket dikapsulkan dalam terowong dan dihantar ke kad rangkaian.
- Oleh kerana pengepala paket + terowong tidak sesuai dengan MTU, paket itu dipotong menjadi serpihan dan dihantar ke rangkaian.
- Suis selepas pengimbang L3, apabila menerima paket, menambah teg Vlan padanya dan menghantarnya.
- Suis di hadapan proksi Nginx melihat (berdasarkan tetapan port) bahawa pelayan menjangkakan paket berkapsul Vlan, jadi ia menghantarnya sebagaimana adanya, tanpa mengalih keluar tag Vlan.
- Linux mengambil serpihan pakej individu dan menggabungkannya menjadi satu pakej besar.
- Seterusnya, paket mencapai antara muka Vlan, di mana lapisan pertama dikeluarkan daripadanya - pengkapsulan Vlan.
- Linux kemudian menghantarnya ke antara muka Terowong, di mana lapisan lain dikeluarkan daripadanya - Enkapsulasi Terowong.
Kesukarannya adalah untuk lulus semua ini sebagai parameter kepada tcpdump.
Mari kita mulakan dari akhir: adakah terdapat paket IP bersih (tanpa pengepala yang tidak diperlukan) daripada pelanggan, dengan enkapsulasi vlan dan terowong dialih keluar?
tcpdump host <ip ΠΊΠ»ΠΈΠ΅Π½ΡΠ°>
Tidak, tiada pakej sedemikian pada pelayan. Jadi masalah itu mesti ada lebih awal. Adakah terdapat sebarang paket dengan enkapsulasi Vlan sahaja yang dialih keluar?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx ialah alamat IP pelanggan dalam format hex.
32:4 β alamat dan panjang medan di mana IP SCR ditulis dalam paket Terowong.
Alamat medan harus dipilih dengan kekerasan, kerana di Internet mereka menulis kira-kira 40, 44, 50, 54, tetapi tidak ada alamat IP di sana. Anda juga boleh melihat salah satu paket dalam hex (parameter -xx atau -XX dalam tcpdump) dan mengira alamat IP yang anda tahu.
Adakah terdapat serpihan paket tanpa enkapsulasi Vlan dan Terowong dialih keluar?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Sihir ini akan menunjukkan kepada kita semua serpihan, termasuk yang terakhir. Mungkin, perkara yang sama boleh ditapis oleh IP, tetapi saya tidak mencuba, kerana tidak terdapat banyak paket sedemikian, dan yang saya perlukan mudah ditemui dalam aliran umum. Di sini mereka:
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 ..............
Ini adalah dua serpihan satu pakej (ID yang sama 53652) dengan gambar (perkataan Exif boleh dilihat dalam pakej pertama). Disebabkan fakta bahawa terdapat pakej pada tahap ini, tetapi tidak dalam bentuk gabungan di tempat pembuangan, masalahnya jelas dengan pemasangan. Akhirnya terdapat bukti dokumentari ini!
Penyahkod paket tidak mendedahkan sebarang masalah yang akan menghalang pembinaan. Cuba di sini: . Pada mulanya, apabila anda cuba memasukkan sesuatu di sana, penyahkod tidak menyukai format paket. Ternyata terdapat beberapa tambahan dua oktet antara Srcmac dan Ethertype (tidak berkaitan dengan maklumat serpihan). Selepas mengeluarkannya, penyahkod mula berfungsi. Bagaimanapun, ia tidak menunjukkan sebarang masalah.
Walau apa pun yang boleh dikatakan, tiada apa-apa lagi yang ditemui kecuali Sysctl tersebut. Yang tinggal hanyalah mencari jalan untuk mengenal pasti pelayan masalah untuk memahami skala dan memutuskan tindakan selanjutnya. Kaunter yang diperlukan ditemui dengan cukup cepat:
netstat -s | grep "packet reassembles failedβ
Ia juga dalam snmpd di bawah OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"Bilangan kegagalan yang dikesan oleh algoritma pemasangan semula IP (atas apa jua sebab: tamat masa, ralat, dll.)."
Di antara kumpulan pelayan di mana masalah itu dikaji, pada dua kaunter ini meningkat lebih cepat, pada dua lebih perlahan, dan pada dua lagi ia tidak meningkat sama sekali. Membandingkan dinamik kaunter ini dengan dinamik ralat HTTP pada pelayan Java mendedahkan korelasi. Iaitu, meter boleh dipantau.
Mempunyai penunjuk masalah yang boleh dipercayai adalah sangat penting supaya anda boleh menentukan dengan tepat sama ada melancarkan Sysctl membantu, kerana dari cerita sebelumnya kita tahu bahawa ini tidak dapat difahami dengan segera daripada aplikasi. Penunjuk ini membolehkan kami mengenal pasti semua kawasan masalah dalam pengeluaran sebelum pengguna menemuinya.
Selepas melancarkan Sysctl, ralat pemantauan dihentikan, oleh itu punca masalah telah terbukti, serta fakta bahawa rollback membantu.
Kami melancarkan semula tetapan pemecahan pada pelayan lain, di mana pemantauan baharu mula dimainkan, dan di suatu tempat kami memperuntukkan lebih banyak memori untuk serpihan daripada sebelumnya yang lalai (ini adalah statistik UDP, kehilangan separa yang tidak ketara terhadap latar belakang umum) .
Soalan yang paling penting
Mengapa paket berpecah-belah pada pengimbang L3 kami? Kebanyakan paket yang tiba daripada pengguna kepada pengimbang adalah SYN dan ACK. Saiz pakej ini adalah kecil. Tetapi oleh kerana bahagian paket sedemikian adalah sangat besar, dengan latar belakang mereka kami tidak menyedari kehadiran paket besar yang mula berpecah.
Sebabnya ialah skrip konfigurasi yang rosak pada pelayan dengan antara muka Vlan (terdapat sangat sedikit pelayan dengan trafik berteg dalam pengeluaran pada masa itu). Advmss membolehkan kami menyampaikan kepada pelanggan maklumat bahawa paket ke arah kami harus bersaiz lebih kecil supaya selepas melampirkan pengepala terowong kepada mereka ia tidak perlu dipecahkan.
Mengapa Sysctl rollback tidak membantu, tetapi but reboot berjaya? Menggulung semula Sysctl menukar jumlah memori yang tersedia untuk penggabungan pakej. Pada masa yang sama, nampaknya fakta limpahan memori untuk serpihan membawa kepada kelembapan sambungan, yang menyebabkan serpihan ditangguhkan untuk masa yang lama dalam baris gilir. Iaitu, proses itu berjalan dalam kitaran.
But semula itu mengosongkan ingatan dan semuanya kembali kepada pesanan.
Adakah boleh dilakukan tanpa Penyelesaian? Ya, tetapi terdapat risiko tinggi untuk meninggalkan pengguna tanpa perkhidmatan sekiranya berlaku serangan. Sudah tentu, penggunaan Penyelesaian mengakibatkan pelbagai masalah, termasuk kelembapan salah satu perkhidmatan untuk pengguna, tetapi kami percaya bahawa tindakan itu wajar.
Terima kasih banyak kepada Andrey Timofeev () untuk bantuan dalam menjalankan siasatan, serta Alexey Krenev () - untuk kerja besar mengemas kini Centos dan kernel pada pelayan. Satu proses yang dalam kes ini terpaksa dimulakan dari awal beberapa kali, itulah sebabnya ia berlarutan selama beberapa bulan.
Sumber: www.habr.com