Herkese selam! Adım Dmitry Samsonov, Odnoklassniki'de lider sistem yöneticisi olarak çalışıyorum. 7 binin üzerinde fiziksel sunucumuz, bulutumuzda 11 bin konteyner ve çeşitli konfigürasyonlarda 200 farklı küme oluşturan 700 uygulamamız var. Sunucuların büyük çoğunluğu CentOS 7'yi çalıştırıyor.
14 Ağustos 2018'de FragmentSmack güvenlik açığı hakkında bilgi yayımlandı
() ve SegmentSmack (). Bunlar, ağ saldırı vektörüne sahip ve kaynak tükenmesi (CPU) nedeniyle hizmet reddini (DoS) tehdit eden oldukça yüksek puana (7.5) sahip güvenlik açıklarıdır. O zamanlar FragmentSmack için bir çekirdek düzeltmesi önerilmemişti; üstelik, güvenlik açığıyla ilgili bilgilerin yayınlanmasından çok daha sonra ortaya çıktı. SegmentSmack'i ortadan kaldırmak için çekirdeğin güncellenmesi önerildi. Güncelleme paketi aynı gün yayınlandı, geriye sadece onu yüklemek kaldı.
Hayır, çekirdeğin güncellenmesine kesinlikle karşı değiliz! Ancak nüanslar var...
Çekirdeği üretimde nasıl güncelleriz?
Genel olarak karmaşık bir şey yok:
- Paketleri indirin;
- Bunları bir dizi sunucuya yükleyin (bulutumuzu barındıran sunucular dahil);
- Hiçbir şeyin kırılmadığından emin olun;
- Tüm standart çekirdek ayarlarının hatasız olarak uygulandığından emin olun;
- Birkaç gün bekleyin;
- Sunucu performansını kontrol edin;
- Yeni sunucuların dağıtımını yeni çekirdeğe geçirin;
- Tüm sunucuları veri merkezine göre güncelleyin (sorun olması durumunda kullanıcılar üzerindeki etkiyi en aza indirmek için tek seferde bir veri merkezi);
- Tüm sunucuları yeniden başlatın.
Elimizdeki çekirdeklerin tüm dalları için tekrarlayın. Şu anda durum şöyle:
- Stok CentOS 7 3.10 - çoğu normal sunucu için;
- Vanilya 4.19 - bizim için , çünkü BFQ, BBR vb.'ye ihtiyacımız var;
- Elrepo çekirdek-ml 5.2 - için çünkü 4.19 kararsız davranıyordu ama aynı özelliklere ihtiyaç vardı.
Tahmin edebileceğiniz gibi binlerce sunucunun yeniden başlatılması en uzun süreyi alır. Tüm güvenlik açıkları tüm sunucular için kritik olmadığından, yalnızca İnternet'ten doğrudan erişilebilenleri yeniden başlatıyoruz. Bulutta, esnekliği sınırlamamak için, dışarıdan erişilebilen konteynerleri yeni bir çekirdeğe sahip bireysel sunuculara bağlamayız, ancak istisnasız tüm ana bilgisayarları yeniden başlatırız. Neyse ki buradaki prosedür normal sunuculara göre daha basittir. Örneğin, durum bilgisi olmayan konteynerler, yeniden başlatma sırasında kolayca başka bir sunucuya taşınabilir.
Ancak hala çok iş var ve bu birkaç hafta sürebilir ve yeni sürümde herhangi bir sorun olması durumunda birkaç aya kadar sürebilir. Saldırganlar bunu çok iyi anlıyor ve bir B planına ihtiyaçları var.
FragmentSmack/SegmentSmack. Geçici çözüm
Neyse ki bazı güvenlik açıkları için böyle bir B planı mevcut ve buna Geçici Çözüm deniyor. Çoğu zaman bu, çekirdek/uygulama ayarlarında olası etkiyi en aza indirebilecek veya güvenlik açıklarından yararlanmayı tamamen ortadan kaldırabilecek bir değişikliktir.
FragmentSmack/SegmentSmack durumunda Bunun gibi geçici çözüm:
«net.ipv4.ipfrag_high_thresh ve net.ipv3.ipfrag_low_thresh'teki 4MB ve 4MB varsayılan değerlerini (ve bunların ipv6 net.ipv6.ipfrag_high_thresh ve net.ipv6.ipfrag_low_thresh için karşılıkları) sırasıyla 256 kB ve 192 kB olarak değiştirebilirsiniz veya daha düşük. Testler, donanıma, ayarlara ve koşullara bağlı olarak bir saldırı sırasında CPU kullanımında küçük ila önemli düşüşler göstermektedir. Ancak ipfrag_high_thresh=262144 bayt nedeniyle performansta bir miktar etki olabilir, çünkü yeniden birleştirme sırasına aynı anda yalnızca iki adet 64K parça sığabilir. Örneğin büyük UDP paketleriyle çalışan uygulamaların bozulması riski vardır.'.
Parametrelerin kendileri şu şekilde anlatılmıştır:
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.
Üretim hizmetlerinde büyük UDP'lerimiz yok. LAN'da parçalanmış trafik yok; WAN'da parçalanmış trafik var, ancak önemli değil. Hiçbir işaret yok; Geçici Çözümü kullanıma sunabilirsiniz!
FragmentSmack/SegmentSmack. İlk kan
Karşılaştığımız ilk sorun, bulut konteynerlerinin bazen yeni ayarları yalnızca kısmen uygulaması (yalnızca ipfrag_low_thresh), bazen de hiç uygulamamasıydı; başlangıçta çöktüler. Sorunu istikrarlı bir şekilde yeniden oluşturmak mümkün olmadı (tüm ayarlar herhangi bir zorluk olmadan manuel olarak uygulandı). Konteynerin başlangıçta neden çöktüğünü anlamak da o kadar kolay değil: hiçbir hata bulunamadı. Kesin olan bir şey vardı: Ayarları geri almak, konteyner çökmeleriyle ilgili sorunu çözüyordu.
Ana makineye Sysctl uygulamak neden yeterli değil? Konteyner kendi özel ağ Ad Alanında yaşar, yani en azından kaptaki ana bilgisayardan farklı olabilir.
Sysctl ayarları kapsayıcıda tam olarak nasıl uygulanır? Konteynerlerimiz ayrıcalıklı olmadığından, konteynerin içine girerek herhangi bir Sysctl ayarını değiştiremezsiniz; sadece yeterli haklara sahip değilsiniz. Konteynerleri çalıştırmak için o zamanki bulutumuz Docker'ı kullanıyordu (şimdi ). Yeni konteynerin parametreleri, gerekli Sysctl ayarları da dahil olmak üzere API aracılığıyla Docker'a aktarıldı.
Sürümler arasında arama yaparken Docker API'nin tüm hataları döndürmediği ortaya çıktı (en azından sürüm 1.10'da). Konteyneri "docker run" ile başlatmaya çalıştığımızda sonunda en azından bir şey gördük:
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.
Parametre değeri geçerli değil. Ama neden? Ve neden sadece bazen geçerli değil? Docker'ın Sysctl parametrelerinin uygulanma sırasını garanti etmediği ortaya çıktı (en son test edilen sürüm 1.13.1), bu nedenle bazen ipfrag_low_thresh hala 256M iken, yani üst limit daha düşükken ipfrag_high_thresh 3K'ya ayarlanmaya çalışıldı. hataya yol açan alt sınırdan daha fazla.
O zamanlar, başlangıçtan sonra konteyneri yeniden yapılandırmak için zaten kendi mekanizmamızı kullanıyorduk (konteynerin ve konteynerin ad alanındaki komutların çalıştırılması ) ve bu kısma Sysctl parametrelerinin yazılmasını da ekledik. Problem çözüldü.
FragmentSmack/SegmentSmack. İlk Kan 2
Bulutta Geçici Çözümün kullanımını anlamaya zaman bulamadan, kullanıcılardan ilk nadir şikayetler gelmeye başladı. O zamanlar, Geçici Çözümün ilk sunucularda kullanılmaya başlamasının üzerinden birkaç hafta geçmişti. İlk soruşturma, şikayetlerin bu hizmetlerin tüm sunucularına değil, bireysel hizmetlere karşı alındığını gösterdi. Sorun yine son derece belirsiz hale geldi.
Öncelikle elbette Sysctl ayarlarını geri almaya çalıştık ama bunun bir etkisi olmadı. Sunucu ve uygulama ayarlarında yapılan çeşitli manipülasyonlar da işe yaramadı. Yeniden başlatma yardımcı oldu. Linux'un yeniden başlatılması, eski günlerde Windows için normal olduğu kadar doğal değil. Ancak yardımcı oldu ve Sysctl'de yeni ayarları uygularken bunu bir "çekirdek hatası" olarak değerlendirdik. Ne kadar anlamsızdı...
Üç hafta sonra sorun tekrarladı. Bu sunucuların yapılandırması oldukça basitti: Proxy/dengeleyici modunda Nginx. Çok fazla trafik yok. Yeni tanıtım notu: İstemcilerdeki 504 hata sayısı her geçen gün artıyor (). Grafik, bu hizmet için günlük 504 hatanın sayısını göstermektedir:
Tüm hatalar aynı arka uçla ilgilidir - buluttakiyle ilgili. Bu arka uçtaki paket parçalarına ilişkin bellek tüketimi grafiği şöyle görünüyordu:
Bu, işletim sistemi grafiklerinde sorunun en belirgin göstergelerinden biridir. Bulutta aynı anda QoS (Trafik Kontrolü) ayarlarındaki bir başka ağ sorunu da giderildi. Paket parçaları için bellek tüketimi grafiğinde tamamen aynı görünüyordu:
Varsayım basitti: Eğer grafiklerde aynı görünüyorlarsa, o zaman aynı sebepleri var demektir. Üstelik bu tür hafızayla ilgili herhangi bir sorun son derece nadirdir.
Düzeltilen sorunun özü, QoS'de fq paket zamanlayıcısını varsayılan ayarlarla kullanmamızdı. Varsayılan olarak, bir bağlantı için kuyruğa 100 paket eklemenize izin verir ve kanal sıkıntısı durumunda bazı bağlantılar kuyruğu kapasiteye kadar tıkamaya başlar. Bu durumda paketler bırakılır. tc istatistiklerinde (tc -s qdisc) şu şekilde görülebilir:
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 flow_plimit", bir bağlantının kuyruk limitinin aşılması nedeniyle bırakılan paketlerdir ve "düşürülmüş 464545", bu zamanlayıcının bırakılan tüm paketlerinin toplamıdır. Kuyruk uzunluğunu 1 bine çıkardıktan ve konteynerleri yeniden başlattıktan sonra sorunun oluşması durdu. Arkanıza yaslanıp bir smoothie içebilirsiniz.
FragmentSmack/SegmentSmack. Son Kan
İlk olarak, çekirdekteki güvenlik açıklarının duyurulmasından birkaç ay sonra, sonunda FragmentSmack için bir düzeltme ortaya çıktı (Ağustos'taki duyuruyla birlikte yalnızca SegmentSmack için bir düzeltmenin yayınlandığını hatırlatmama izin verin), bu da bize Geçici Çözümden vazgeçme şansı verdi, bu da bize büyük sıkıntı yaşattı. Bu süre zarfında bazı sunucuları yeni çekirdeğe aktarmayı zaten başarmıştık ve artık en baştan başlamamız gerekiyordu. Neden FragmentSmack düzeltmesini beklemeden çekirdeği güncelledik? Gerçek şu ki, bu güvenlik açıklarına karşı koruma süreci, CentOS'un kendisini güncelleme süreciyle çakıştı (ve birleşti) (bu, yalnızca çekirdeğin güncellenmesinden daha fazla zaman alır). Ayrıca SegmentSmack daha tehlikeli bir güvenlik açığı ve bunun için bir düzeltme hemen ortaya çıktı, bu yüzden yine de mantıklıydı. Ancak CentOS 7.5 sırasında ortaya çıkan FragmentSmack güvenlik açığı yalnızca 7.6 sürümünde düzeltildiği için çekirdeği CentOS'ta güncelleyemedik, bu nedenle 7.5 güncellemesini durdurup 7.6 güncellemesiyle her şeye yeniden başlamak zorunda kaldık. Ve bu da oluyor.
İkincisi, sorunlarla ilgili nadir kullanıcı şikayetleri bize geri döndü. Artık bunların hepsinin istemcilerden bazı sunucularımıza dosya yüklenmesiyle ilgili olduğundan eminiz. Üstelik toplam kütlenin çok az sayıda yüklemesi bu sunucular üzerinden gerçekleşti.
Yukarıdaki hikayeden hatırladığımız gibi Sysctl'i geri almanın bir faydası olmadı. Yeniden başlatma yardımcı oldu, ancak geçici olarak.
Sysctl ile ilgili şüpheler ortadan kalkmadı ancak bu sefer mümkün olduğu kadar çok bilgi toplamak gerekiyordu. Ayrıca, neler olup bittiğini daha doğru bir şekilde incelemek için yükleme sorununu istemcide yeniden oluşturma becerisinde de büyük bir eksiklik vardı.
Mevcut tüm istatistiklerin ve kayıtların analizi, bizi neler olduğunu anlamaya daha fazla yaklaştırmadı. Belirli bir bağlantıyı “hissetmek” için sorunu yeniden üretme yeteneğinde ciddi bir eksiklik vardı. Son olarak, uygulamanın özel bir sürümünü kullanan geliştiriciler, Wi-Fi ile bağlandığında bir test cihazında sorunların kararlı bir şekilde yeniden üretilmesini sağlamayı başardılar. Bu, soruşturmada bir dönüm noktasıydı. İstemci, Java uygulamamız olan arka uca proxy yapan Nginx'e bağlandı.
Sorunlara ilişkin diyalog şu şekildeydi (Nginx proxy tarafında düzeltildi):
- İstemci: Bir dosyanın indirilmesiyle ilgili bilgi alma isteği.
- Java sunucusu: yanıt.
- İstemci: Dosyayla birlikte POST.
- Java sunucusu: hata.
Aynı zamanda, Java sunucusu günlüğe istemciden 0 bayt veri alındığını yazar ve Nginx proxy'si isteğin 30 saniyeden fazla sürdüğünü yazar (30 saniye, istemci uygulamasının zaman aşımıdır). Neden zaman aşımı ve neden 0 bayt? HTTP açısından bakıldığında her şey olması gerektiği gibi çalışıyor ancak dosyanın bulunduğu POST ağdan kayboluyor gibi görünüyor. Üstelik istemci ile Nginx arasında kayboluyor. Kendinizi Tcpdump ile silahlandırmanın zamanı geldi! Ancak önce ağ yapılandırmasını anlamanız gerekir. Nginx proxy, L3 dengeleyicinin arkasındadır . Tünel oluşturma, paketleri L3 dengeleyiciden sunucuya iletmek için kullanılır; sunucu, başlıklarını paketlere ekler:
Bu durumda ağ, bu sunucuya, paketlere kendi alanlarını da ekleyen Vlan etiketli trafik biçiminde gelir:
Ve bu trafik aynı zamanda parçalanmış da olabilir (Geçici Çözümden gelen riskleri değerlendirirken bahsettiğimiz, gelen parçalanmış trafiğin aynı küçük yüzdesi), bu da başlıkların içeriğini de değiştirir:
Bir kez daha: paketler bir Vlan etiketiyle kapsülleniyor, bir tünelle kapsülleniyor ve parçalanıyor. Bunun nasıl olduğunu daha iyi anlamak için istemciden Nginx proxy'ye giden paket yolunu izleyelim.
- Paket L3 dengeleyiciye ulaşır. Veri merkezi içinde doğru yönlendirme için paket bir tünel içinde kapsüllenir ve ağ kartına gönderilir.
- Paket + tünel başlıkları MTU'ya sığmadığı için paket parçalara ayrılarak ağa gönderilir.
- L3 dengeleyiciden sonraki anahtar, bir paket alırken ona bir Vlan etiketi ekler ve onu gönderir.
- Nginx proxy'sinin önündeki anahtar (bağlantı noktası ayarlarına bağlı olarak) sunucunun Vlan kapsüllü bir paket beklediğini görür ve bu nedenle onu Vlan etiketini kaldırmadan olduğu gibi gönderir.
- Linux bireysel paketlerin parçalarını alır ve bunları büyük bir pakette birleştirir.
- Daha sonra paket, ilk katmanın (Vlan kapsülleme) kaldırıldığı Vlan arayüzüne ulaşır.
- Linux daha sonra onu Tünel arayüzüne gönderir ve burada başka bir katman - Tünel kapsülleme - kaldırılır.
Zorluk tüm bunları parametre olarak tcpdump'a iletmektir.
Sondan başlayalım: istemcilerden gelen, vlan ve tünel kapsüllemesi kaldırılmış temiz (gereksiz başlıklar olmadan) IP paketleri var mı?
tcpdump host <ip клиента>
Hayır, sunucuda böyle bir paket yoktu. Yani sorun daha önceden orada olmalı. Yalnızca Vlan kapsüllemesinin kaldırıldığı paketler var mı?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx, onaltılık formattaki istemci IP adresidir.
32:4 — Tünel paketinde SCR IP'sinin yazıldığı alanın adresi ve uzunluğu.
İnternette yaklaşık 40, 44, 50, 54 yazdıkları için alan adresinin kaba kuvvetle seçilmesi gerekiyordu, ancak orada IP adresi yoktu. Ayrıca hex'teki paketlerden birine (tcpdump'taki -xx veya -XX parametresi) bakıp bildiğiniz IP adresini hesaplayabilirsiniz.
Vlan ve Tünel kapsüllemesi kaldırılmamış paket parçaları var mı?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Bu sihir bize sonuncusu dahil tüm parçaları gösterecek. Muhtemelen aynı şey IP'ye göre filtrelenebilir, ancak denemedim çünkü bu tür çok fazla paket yok ve ihtiyacım olanlar genel akışta kolayca bulundu. İşte buradalar:
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 ..............
Bunlar bir fotoğraflı (ilk pakette Exif kelimesi görünür) bir paketin (aynı ID 53652) iki parçasıdır. Bu seviyede paketlerin olması ancak dökümlerde birleştirilmiş formda olmaması nedeniyle sorun açıkça montajdadır. Sonunda bunun belgesel kanıtı var!
Paket kod çözücü, derlemeyi engelleyecek herhangi bir sorun ortaya çıkarmadı. Burada denedim: . İlk başta oraya bir şey doldurmaya çalıştığınızda kod çözücü paket formatını beğenmiyor. Srcmac ve Ethertype arasında fazladan iki sekizlinin olduğu ortaya çıktı (parça bilgisiyle ilgili değil). Bunları çıkardıktan sonra kod çözücü çalışmaya başladı. Ancak herhangi bir sorun göstermedi.
Ne derse desin, Sysctl dışında başka hiçbir şey bulunamadı. Geriye kalan tek şey, ölçeği anlamak ve sonraki eylemlere karar vermek için sorunlu sunucuları tanımlamanın bir yolunu bulmaktı. Gerekli sayaç yeterince hızlı bir şekilde bulundu:
netstat -s | grep "packet reassembles failed”
Ayrıca OID=1.3.6.1.2.1.4.31.1.1.16.1 altında snmpd'dedir ().
"IP yeniden birleştirme algoritması tarafından tespit edilen hataların sayısı (hangi nedenle olursa olsun: zaman aşımına uğradı, hatalar vb.)."
Sorunun incelendiği sunucu gruplarından ikisinde bu sayaç daha hızlı arttı, ikisinde daha yavaş arttı ve diğer ikisinde ise hiç artmadı. Bu sayacın dinamiklerini Java sunucusundaki HTTP hatalarının dinamikleriyle karşılaştırmak bir korelasyon ortaya çıkardı. Yani sayaç izlenebilir.
Sorunların güvenilir bir göstergesine sahip olmak çok önemlidir, böylece Sysctl'i geri almanın işe yarayıp yaramayacağını doğru bir şekilde belirleyebilirsiniz, çünkü önceki hikayeden bunun uygulamadan hemen anlaşılamayacağını biliyoruz. Bu gösterge, kullanıcılar keşfetmeden önce üretimdeki tüm sorunlu alanları belirlememize olanak tanıyacaktır.
Sysctl'i geri aldıktan sonra izleme hataları durduruldu, böylece sorunların nedeni ve geri almanın yardımcı olduğu kanıtlandı.
Yeni izlemenin devreye girdiği diğer sunuculardaki parçalanma ayarlarını geri aldık ve bir yerlerde parçalar için önceden varsayılandan daha fazla bellek ayırdık (bu, genel arka planda kısmi kaybı fark edilmeyen UDP istatistikleriydi) .
en önemli sorular
Paketler neden L3 dengeleyicimizde parçalanmış durumda? Kullanıcılardan dengeleyicilere gelen paketlerin çoğu SYN ve ACK'dır. Bu paketlerin boyutları küçüktür. Ancak bu tür paketlerin payı çok büyük olduğundan, arka planlarına karşı parçalanmaya başlayan büyük paketlerin varlığını fark etmedik.
Bunun nedeni bozuk bir yapılandırma komut dosyasıydı Vlan arayüzlerine sahip sunucularda (o zamanlar üretimde etiketli trafiğe sahip çok az sayıda sunucu vardı). Advmss, istemciye bizim yönümüzdeki paketlerin boyutunun daha küçük olması gerektiği bilgisini aktarmamıza olanak tanır, böylece onlara tünel başlıklarını ekledikten sonra parçalanmaları gerekmez.
Sysctl'i geri alma neden işe yaramadı ama yeniden başlatma işe yaradı? Sysctl'in geri alınması, paketlerin birleştirilmesi için kullanılabilir bellek miktarını değiştirdi. Aynı zamanda, görünüşe göre parçalar için hafıza taşması gerçeği, bağlantıların yavaşlamasına yol açtı ve bu da parçaların kuyrukta uzun süre gecikmesine neden oldu. Yani süreç döngüler halinde ilerledi.
Yeniden başlatma hafızayı temizledi ve her şey yoluna girdi.
Geçici Çözüm olmadan bunu yapmak mümkün müydü? Evet, ancak bir saldırı durumunda kullanıcıların hizmetsiz kalma riski yüksektir. Elbette, Geçici Çözümün kullanımı, kullanıcılar için hizmetlerden birinin yavaşlaması da dahil olmak üzere çeşitli sorunlara yol açtı, ancak yine de eylemlerin haklı olduğuna inanıyoruz.
Andrey Timofeev'e çok teşekkürler () ve Alexey Krenev'in yanı sıra soruşturmanın yürütülmesinde yardım için () - Centos'u ve sunuculardaki çekirdekleri güncellemeye yönelik devasa çalışma için. Bu durumda birkaç kez baştan başlatılması gereken bir süreç, bu yüzden aylarca sürdü.
Kaynak: habr.com