Variti, botlara ve DDoS saldırılarına karşı koruma geliştiriyor ve aynı zamanda stres ve yük testleri de gerçekleştiriyor. HighLoad++ 2018 konferansında kaynakların çeşitli saldırı türlerine karşı nasıl korunacağından bahsettik. Kısacası: sistemin bazı kısımlarını izole edin, bulut hizmetlerini ve CDN'leri kullanın ve düzenli olarak güncelleyin. Ancak yine de uzman şirketler olmadan korumayı başaramazsınız :)
Metni okumadan önce kısa özetleri okuyabilirsiniz .
Eğer okumayı sevmiyorsanız ya da sadece videoyu izlemek istiyorsanız raporumuzun kaydını aşağıda spoiler altında bulabilirsiniz.
Raporun video kaydı
Birçok şirket zaten yük testinin nasıl yapılacağını biliyor ancak hepsi stres testi yapmıyor. Müşterilerimizden bazıları, sitelerinin yüksek yük sistemine sahip olması ve saldırılara karşı iyi koruma sağlaması nedeniyle zarar görmez olduğunu düşünüyor. Bunun tamamen doğru olmadığını gösteriyoruz.
Elbette testleri yapmadan önce müşteriden imzalı ve kaşeli izin alıyoruz ve bizim yardımımızla kimseye DDoS saldırısı yapılamaz. Test, müşteri tarafından seçilen, kaynağına gelen trafiğin minimum düzeyde olduğu ve erişim sorunlarının istemcileri etkilemeyeceği bir zamanda gerçekleştirilir. Ayrıca test sürecinde her zaman bir şeyler ters gidebileceği için müşteriyle sürekli iletişim halinde oluyoruz. Bu, yalnızca elde edilen sonuçları raporlamanıza değil, aynı zamanda test sırasında bir şeyi değiştirmenize de olanak tanır. Testin tamamlanmasının ardından her zaman tespit edilen eksiklikleri belirttiğimiz ve sitenin zayıf yönlerinin giderilmesine yönelik önerilerde bulunduğumuz bir rapor hazırlarız.
nasıl çalışıyoruz
Test ederken bir botnet taklit ediyoruz. Ağlarımızda bulunmayan clientlarla çalıştığımız için, limitlerin veya korumanın tetiklenmesi nedeniyle testin ilk dakikada bitmemesini sağlamak için yükü tek bir IP'den değil, kendi alt ağımızdan sağlıyoruz. Ayrıca, önemli bir yük oluşturmak için oldukça güçlü bir test sunucumuz var.
Varsayımlar
Çok fazlası iyi anlamına gelmez
Bir kaynağın başarısız olmasına ne kadar az yük getirebilirsek o kadar iyidir. Saniyede bir istekle, hatta dakikada bir istekle sitenin çalışmasını durdurabilirseniz, bu harika. Çünkü kötü niyet kanununa göre, kullanıcılar veya saldırganlar yanlışlıkla bu güvenlik açığına düşeceklerdir.
Kısmi başarısızlık, tam başarısızlıktan daha iyidir
Her zaman sistemlerin heterojen olmasını öneriyoruz. Üstelik bunları yalnızca konteynerleştirme yoluyla değil, fiziksel düzeyde de ayırmaya değer. Fiziksel ayırma durumunda, sitede bir şey arızalansa bile, tamamen çalışmayı durdurmama olasılığı yüksektir ve kullanıcılar, işlevselliğin en azından bir kısmına erişmeye devam edecektir.
İyi mimari sürdürülebilirliğin temelidir
Bir kaynağın hata toleransı ve saldırılara ve yüklere dayanma yeteneği, tasarım aşamasında, aslında ilk akış şemalarının bir not defterinde çizilmesi aşamasında ortaya konmalıdır. Çünkü ölümcül hatalar ortaya çıkarsa bunları ileride düzeltmek mümkün ama çok zordur.
Yalnızca kod değil, aynı zamanda yapılandırma da iyi olmalıdır
Birçok kişi iyi bir geliştirme ekibinin hataya dayanıklı hizmetin garantisi olduğunu düşünüyor. İyi bir geliştirme ekibi gerçekten gerekli ama aynı zamanda iyi operasyonlar ve iyi DevOps da olmalı. Yani Linux'u ve ağı doğru şekilde yapılandıracak, nginx'te yapılandırmaları doğru yazacak, sınırları belirleyecek vb. uzmanlara ihtiyacımız var. Aksi takdirde, kaynak yalnızca test sırasında iyi çalışacak ve bir noktada üretimde her şey bozulacaktır.
Yük ve stres testi arasındaki farklar
Yük testi, sistem işleyişinin sınırlarını belirlemenize olanak tanır. Stres testi, bir sistemdeki zayıflıkları bulmayı amaçlar ve bu sistemi kırmak ve belirli parçaların arızalanması sürecinde nasıl davranacağını görmek için kullanılır. Bu durumda yükün niteliği genellikle stres testi başlamadan önce müşteri tarafından bilinmez.
L7 saldırılarının ayırt edici özellikleri
Genellikle yük türlerini L7 ve L3&4 seviyelerindeki yüklere ayırırız. L7, uygulama düzeyindeki bir yüktür, çoğunlukla yalnızca HTTP anlamına gelir, ancak TCP protokol düzeyindeki herhangi bir yükü kastediyoruz.
L7 saldırılarının belirli ayırt edici özellikleri vardır. Öncelikle doğrudan uygulamaya geliyorlar, yani ağ yoluyla yansımaları pek mümkün değil. Bu tür saldırılar mantık kullanır ve bu nedenle CPU, bellek, disk, veritabanı ve diğer kaynakları çok verimli ve az trafikle tüketirler.
HTTP Taşkını
Herhangi bir saldırı durumunda yükü oluşturmak, idare etmekten daha kolaydır ve L7 durumunda da bu geçerlidir. Saldırı trafiğini meşru trafikten ayırmak her zaman kolay değildir ve çoğu zaman bu frekansa göre yapılabilir ancak her şey doğru planlanırsa o zaman saldırının nerede olduğunu ve meşru isteklerin nerede olduğunu loglardan anlamak imkansızdır.
İlk örnek olarak bir HTTP Flood saldırısını düşünün. Grafikte bu tür saldırıların genellikle çok güçlü olduğu görülüyor; aşağıdaki örnekte en yüksek istek sayısı dakikada 600 bini aştı.
HTTP Flood, yük oluşturmanın en kolay yoludur. Tipik olarak ApacheBench gibi bir tür yük test aracını alır ve bir istek ve hedef belirler. Bu kadar basit bir yaklaşımla, sunucu önbelleğiyle karşılaşma olasılığı yüksektir, ancak bunu atlatmak kolaydır. Örneğin, isteğe rastgele dizeler eklemek, bu, sunucuyu sürekli olarak yeni bir sayfa sunmaya zorlayacaktır.
Ayrıca, yük oluşturma sürecinde kullanıcı aracısını da unutmayın. Popüler test araçlarının birçok kullanıcı aracısı sistem yöneticileri tarafından filtrelenir ve bu durumda yük arka uca ulaşmayabilir. İsteğe tarayıcıdan az çok geçerli bir başlık ekleyerek sonucu önemli ölçüde iyileştirebilirsiniz.
HTTP Flood saldırıları ne kadar basit olsa da dezavantajları da var. Öncelikle yükü oluşturmak için büyük miktarda güce ihtiyaç vardır. İkincisi, bu tür saldırıların tespit edilmesi, özellikle de tek bir adresten geliyorsa, çok kolaydır. Sonuç olarak, istekler sistem yöneticileri tarafından ve hatta sağlayıcı düzeyinde anında filtrelenmeye başlar.
Bakılacak şey
Verimliliği kaybetmeden saniyedeki istek sayısını azaltmak için biraz hayal gücü göstermeniz ve siteyi keşfetmeniz gerekir. Böylece yalnızca kanalı veya sunucuyu değil aynı zamanda uygulamanın veritabanları veya dosya sistemleri gibi tek tek bölümlerini de yükleyebilirsiniz. Ayrıca sitede büyük hesaplamalar yapan yerleri de arayabilirsiniz: hesap makineleri, ürün seçim sayfaları vb. Son olarak, genellikle sitenin birkaç yüz bin satırlık bir sayfa oluşturan bir tür PHP betiğine sahip olduğu görülür. Böyle bir komut dosyası aynı zamanda sunucuyu önemli ölçüde yükler ve bir saldırının hedefi haline gelebilir.
Nereye bakmalı
Test etmeden önce bir kaynağı taradığımızda, elbette ilk olarak sitenin kendisine bakarız. Her türlü giriş alanını, ağır dosyaları - genel olarak kaynak için sorun yaratabilecek ve çalışmasını yavaşlatabilecek her şeyi arıyoruz. Google Chrome ve Firefox'taki banal geliştirme araçları, sayfa yanıt sürelerini göstererek bu konuda yardımcı olur.
Ayrıca alt alan adlarını da tarıyoruz. Örneğin, abc.com adında belirli bir çevrimiçi mağaza var ve admin.abc.com alt alan adına sahip. Büyük ihtimalle bu yetkilendirilmiş bir yönetici panelidir ancak üzerine yük koyarsanız ana kaynak için sorun yaratabilir.
Sitenin api.abc.com alt alan adı olabilir. Büyük olasılıkla, bu mobil uygulamalar için bir kaynaktır. Uygulama App Store veya Google Play'de bulunabilir, özel bir erişim noktası kurabilir, API'yi inceleyebilir ve test hesaplarını kaydedebilir. Sorun şu ki, insanlar genellikle yetkilendirmeyle korunan herhangi bir şeyin hizmet reddi saldırılarına karşı bağışık olduğunu düşünüyor. Güya, yetkilendirme en iyi CAPTCHA'dır, ancak değildir. 10-20 test hesabı oluşturmak kolaydır, ancak bunları oluşturarak karmaşık ve sade işlevselliğe erişim elde ederiz.
Doğal olarak robots.txt ve WebArchive, ViewDNS'deki geçmişe bakıyoruz ve kaynağın eski sürümlerini arıyoruz. Bazen geliştiricilerin örneğin mail2.yandex.net'i kullanıma sunduğu, ancak eski sürüm olan mail.yandex.net'in kaldığı görülür. Bu mail.yandex.net artık desteklenmiyor, geliştirme kaynakları ona tahsis edilmiyor, ancak veritabanını tüketmeye devam ediyor. Buna göre eski sürümü kullanarak arka uç kaynaklarını ve düzenin arkasında olan her şeyi etkili bir şekilde kullanabilirsiniz. Elbette bu her zaman olmuyor ama yine de bu durumla oldukça sık karşılaşıyoruz.
Doğal olarak tüm istek parametrelerini ve çerez yapısını analiz ediyoruz. Örneğin, bir çerezin içindeki bir JSON dizisine bir miktar değer aktarabilir, çok sayıda iç içe yerleştirme oluşturabilir ve kaynağın makul olmayan bir süre boyunca çalışmasını sağlayabilirsiniz.
Arama yükü
Bir siteyi araştırırken akla gelen ilk şey veritabanını yüklemektir, çünkü hemen hemen herkesin bir araması vardır ve neredeyse herkes için ne yazık ki yeterince korunmamaktadır. Bazı nedenlerden dolayı geliştiriciler aramaya yeterince dikkat etmiyor. Ancak burada bir öneri var; aynı türde isteklerde bulunmamalısınız çünkü HTTP Flood'da olduğu gibi önbelleğe almayla karşılaşabilirsiniz.
Veritabanına rastgele sorgular yapmak da her zaman etkili değildir. Aramayla alakalı anahtar kelimelerin bir listesini oluşturmak çok daha iyidir. Çevrimiçi mağaza örneğine dönersek: Diyelim ki site araba lastikleri satıyor ve lastiklerin yarıçapını, araba tipini ve diğer parametreleri ayarlamanıza izin veriyor. Buna göre ilgili kelimelerin kombinasyonları veri tabanını çok daha karmaşık koşullarda çalışmaya zorlayacaktır.
Ek olarak, sayfalandırmayı kullanmaya değer: bir aramanın, arama sonuçlarının sondan bir önceki sayfasını döndürmesi, ilkinden çok daha zordur. Yani sayfalandırmanın yardımıyla yükü biraz çeşitlendirebilirsiniz.
Aşağıdaki örnek arama yükünü göstermektedir. Testin ilk saniyesinden itibaren saniyede on istek hızında sitenin kapandığı ve yanıt vermediği görülüyor.
Arama yoksa?
Arama yoksa bu, sitenin başka güvenlik açığı bulunan giriş alanları içermediği anlamına gelmez. Bu alan yetkilendirme olabilir. Günümüzde geliştiriciler, oturum açma veritabanını gökkuşağı tablo saldırısından korumak için karmaşık karmalar yapmayı seviyor. Bu iyidir, ancak bu tür karmalar çok fazla CPU kaynağı tüketir. Çok sayıda yanlış yetkilendirme akışı işlemci arızasına yol açar ve bunun sonucunda site çalışmayı durdurur.
Sitede yorum ve geri bildirim için her türlü formun varlığı, oraya çok büyük metinler göndermenin veya sadece büyük bir sel yaratmanın bir nedenidir. Bazen siteler gzip formatı da dahil olmak üzere ekli dosyaları kabul eder. Bu durumda 1 TB'lık bir dosya alıp gzip kullanarak birkaç bayta veya kilobayta sıkıştırıp siteye gönderiyoruz. Daha sonra fermuarı açılır ve çok ilginç bir etki elde edilir.
Dinlenme API
Rest API gibi popüler hizmetlere biraz dikkat etmek istiyorum. Rest API'sinin güvenliğini sağlamak normal bir web sitesinden çok daha zordur. Parolanın kaba kuvvetine ve diğer yasa dışı faaliyetlere karşı önemsiz koruma yöntemleri bile Rest API'sinde işe yaramaz.
Rest API'sinin kırılması çok kolaydır çünkü doğrudan veritabanına erişir. Aynı zamanda böyle bir hizmetin başarısızlığı iş dünyası için oldukça ciddi sonuçlar doğurmaktadır. Gerçek şu ki, Rest API'si genellikle yalnızca ana web sitesi için değil, aynı zamanda mobil uygulama ve bazı dahili iş kaynakları için de kullanılıyor. Ve eğer tüm bunlar düşerse, o zaman etki, basit bir web sitesi arızasından çok daha güçlüdür.
Ağır içerik yükleniyor
Karmaşık işlevlere sahip olmayan sıradan tek sayfalık bir uygulamayı, açılış sayfasını veya kartvizit web sitesini test etmemiz teklif edilirse, ağır içerik ararız. Örneğin, sunucunun gönderdiği büyük resimler, ikili dosyalar, pdf belgeleri - tüm bunları indirmeye çalışıyoruz. Bu tür testler dosya sistemini iyi yükler ve kanalları tıkar ve bu nedenle etkilidir. Yani, sunucuyu kapatmasanız bile, büyük bir dosyayı düşük hızlarda indirerek, hedef sunucunun kanalını tıkarsınız ve ardından hizmet reddi meydana gelir.
Böyle bir test örneği, 30 RPS hızında sitenin yanıt vermeyi bıraktığını veya 500. sunucu hataları ürettiğini gösterir.
Sunucuları kurmayı unutmayın. Bir kişinin sanal bir makine satın aldığını, Apache'yi oraya yüklediğini, her şeyi varsayılan olarak yapılandırdığını, bir PHP uygulaması yüklediğini ve sonucu aşağıda görebilirsiniz.
Burada yük köke gitti ve yalnızca 10 RPS'ye ulaştı. 5 dakika bekledik ve sunucu çöktü. Neden düştüğü tam olarak bilinmese de hafızasının çok fazla olduğu ve bu nedenle yanıt vermediği yönünde bir varsayım var.
Dalga bazlı
Son bir veya iki yılda dalga saldırıları oldukça popüler hale geldi. Bunun nedeni, birçok kuruluşun DDoS koruması için belirli donanım parçaları satın almasıdır; bu donanımlar, saldırıyı filtrelemeye başlamak için istatistik toplamak için belirli bir süre gerektirir. Yani ilk 30-40 saniyede saldırıyı filtrelemiyorlar çünkü veri biriktiriyorlar ve öğreniyorlar. Buna göre, bu 30-40 saniye içinde sitede o kadar çok şey başlatabilirsiniz ki, tüm istekler giderilene kadar kaynak uzun süre yatacaktır.
Aşağıdaki saldırı durumunda 10 dakikalık bir ara vardı ve ardından saldırının yeni, değiştirilmiş bir kısmı geldi.
Yani savunma öğrendi, filtrelemeye başladı ama saldırının yeni, tamamen farklı bir kısmı geldi ve savunma yeniden öğrenmeye başladı. Aslında filtreleme çalışmayı durdurur, koruma etkisiz hale gelir ve site kullanılamaz hale gelir.
Dalga saldırıları zirvede çok yüksek değerlerle karakterize edilir; L7 durumunda saniyede yüz bin veya bir milyon isteğe ulaşabilir. L3&4 hakkında konuşursak, paketleri sayarsanız yüzlerce gigabit trafik veya buna göre yüzlerce mpps olabilir.
Bu tür saldırılardaki sorun senkronizasyondur. Saldırılar bir botnet'ten geliyor ve tek seferlik çok büyük bir artış yaratmak için yüksek düzeyde senkronizasyon gerekiyor. Ve bu koordinasyon her zaman işe yaramıyor: bazen çıktı bir tür parabolik zirve oluyor ve bu oldukça acıklı görünüyor.
Yalnızca HTTP değil
L7'deki HTTP'ye ek olarak diğer protokollerden de yararlanmayı seviyoruz. Kural olarak, normal bir web sitesinde, özellikle de normal bir barındırmada, posta protokolleri ve MySQL öne çıkar. Posta protokolleri veritabanlarına göre daha az yüke tabidir, ancak aynı zamanda oldukça verimli bir şekilde yüklenebilirler ve sunucuda aşırı yüklenmiş bir CPU ile sonuçlanabilirler.
2016 SSH güvenlik açığı konusunda oldukça gerçekçi bir başarı elde ettik. Artık bu güvenlik açığı neredeyse herkes için giderildi ancak bu, SSH'ye yük gönderilemeyeceği anlamına gelmiyor. Olabilmek. Çok fazla yetkilendirme var, SSH sunucudaki CPU'nun neredeyse tamamını tüketiyor ve ardından web sitesi saniyede bir veya iki istek nedeniyle çöküyor. Buna göre loglara dayalı bu bir veya iki isteğin meşru bir yüklemeden ayırt edilmesi mümkün değildir.
Sunucularda açtığımız birçok bağlantı da geçerliliğini koruyor. Daha önce Apache bundan suçluydu, şimdi ise genellikle varsayılan olarak yapılandırıldığı için nginx aslında bundan suçlu. Nginx'in açık tutabileceği bağlantı sayısı sınırlıdır, dolayısıyla bu sayıda bağlantıyı açıyoruz, nginx artık yeni bağlantı kabul etmiyor ve bunun sonucunda site çalışmıyor.
Test kümemizde SSL anlaşmasına saldırmak için yeterli CPU var. Prensip olarak, uygulamanın gösterdiği gibi, botnet'ler de bazen bunu yapmaktan hoşlanır. Bir yandan SSL olmadan yapamayacağınız açık çünkü Google sonuçları, sıralaması, güvenliği. Öte yandan SSL'de ne yazık ki CPU sorunu var.
L3&4
L3&4 düzeyindeki bir saldırıdan bahsettiğimizde genellikle bağlantı düzeyindeki bir saldırıdan bahsediyoruz. Böyle bir yük, bir SYN-flood saldırısı olmadığı sürece neredeyse her zaman yasal olandan ayırt edilebilir. Güvenlik araçlarına yönelik SYN-flood saldırılarının sorunu büyük hacimli olmalarıdır. Maksimum L3&4 değeri 1,5-2 Tbit/s idi. Bu tür trafiğin işlenmesi Oracle ve Google dahil büyük şirketler için bile oldukça zordur.
SYN ve SYN-ACK, bağlantı kurulurken kullanılan paketlerdir. Bu nedenle SYN-flood'u yasal bir yükten ayırt etmek zordur: Bunun bağlantı kurmaya gelen bir SYN mi yoksa bir selin parçası mı olduğu açık değildir.
UDP-sel
Tipik olarak saldırganlar bizim sahip olduğumuz yeteneklere sahip değildir, dolayısıyla saldırıları organize etmek için güçlendirme kullanılabilir. Yani, saldırgan İnternet'i tarar ve savunmasız veya yanlış yapılandırılmış, örneğin bir SYN paketine yanıt olarak üç SYN-ACK ile yanıt veren sunucular bulur. Kaynak adresi hedef sunucunun adresinden taklit ederek, tek bir paketle gücü örneğin üç kat artırmak ve trafiği kurbana yönlendirmek mümkündür.
Amplifikasyonlarla ilgili sorun, tespit edilmelerinin zor olmasıdır. Son örnekler arasında hassas memcached'in sansasyonel durumu yer alıyor. Ayrıca, artık çoğunlukla varsayılan olarak yapılandırılmış ve varsayılan olarak yanlış yapılandırılmış çok sayıda IoT cihazı, IP kamera var, bu nedenle saldırganlar en sık bu tür cihazlar aracılığıyla saldırı yapıyor.
Zor SYN taşması
SYN-flood, geliştirici açısından muhtemelen en ilginç saldırı türüdür. Sorun, sistem yöneticilerinin koruma için sıklıkla IP engellemeyi kullanmasıdır. Üstelik IP engelleme, yalnızca komut dosyaları kullanarak hareket eden sistem yöneticilerini değil aynı zamanda maalesef büyük paralara satın alınan bazı güvenlik sistemlerini de etkiliyor.
Bu yöntem bir felakete dönüşebilir çünkü saldırganlar IP adreslerini değiştirirse şirket kendi alt ağını engelleyecektir. Güvenlik Duvarı kendi kümesini engellediğinde, çıktı harici etkileşimlerde başarısız olur ve kaynak başarısız olur.
Üstelik kendi ağınızı engellemek hiç de zor değil. Müşterinin ofisinde bir Wi-Fi ağı varsa veya kaynakların performansı çeşitli izleme sistemleri kullanılarak ölçülüyorsa, bu izleme sisteminin veya müşterinin ofis Wi-Fi'sinin IP adresini alıp kaynak olarak kullanırız. Sonunda kaynak kullanılabilir görünüyor ancak hedef IP adresleri engelleniyor. Böylelikle firmanın yeni ürününün tanıtılacağı HighLoad konferansının Wi-Fi ağı bloke edilebiliyor ve bu da bazı ticari ve ekonomik maliyetleri beraberinde getiriyor.
Test sırasında, trafiği yalnızca izin verilen IP adreslerine göndermeye yönelik anlaşmalar olduğundan, herhangi bir harici kaynakla memcached aracılığıyla yükseltmeyi kullanamayız. Buna göre, sistem bir SYN göndermeye iki veya üç SYN-ACK ile yanıt verdiğinde ve çıkışta saldırı iki veya üç kez çarpıldığında SYN ve SYN-ACK aracılığıyla güçlendirme kullanıyoruz.
Araçlar
L7 iş yükü için kullandığımız ana araçlardan biri Yandex-tank'tır. Özellikle, silah olarak bir fantom kullanılır, ayrıca kartuş oluşturmak ve sonuçları analiz etmek için çeşitli komut dosyaları vardır.
Tcpdump ağ trafiğini analiz etmek için kullanılır ve Nmap sunucuyu analiz etmek için kullanılır. Yükü L3&4 seviyesinde oluşturmak için OpenSSL ve biraz da DPDK kütüphanesi ile kendi büyümüzden yararlanılır. DPDK, Intel'in Linux yığınını atlayarak ağ arayüzüyle çalışmanıza olanak tanıyan ve böylece verimliliği artıran bir kitaplığıdır. Doğal olarak, DPDK'yı yalnızca L3&4 düzeyinde değil, aynı zamanda L7 düzeyinde de kullanıyoruz çünkü bu, bir makineden saniyede birkaç milyon istek aralığında çok yüksek bir yük akışı oluşturmamıza olanak tanıyor.
Ayrıca belirli testler için yazdığımız belirli trafik oluşturucuları ve özel araçları da kullanıyoruz. SSH kapsamındaki zafiyeti hatırlarsak yukarıdaki setten yararlanılamaz. Posta protokolüne saldırırsak, posta yardımcı programlarını alırız veya bunlara yalnızca komut dosyaları yazarız.
Bulgular
Sonuç olarak şunu söylemek isterim:
- Klasik yük testinin yanı sıra stres testinin de yapılması gerekmektedir. Bir ortağın taşeronunun yalnızca yük testi yaptığı gerçek bir örneğimiz var. Kaynağın normal yüke dayanabileceğini gösterdi. Ancak daha sonra anormal bir yük ortaya çıktı, site ziyaretçileri kaynağı biraz farklı kullanmaya başladı ve bunun sonucunda taşeron uzandı. Bu nedenle, DDoS saldırılarına karşı zaten korunuyor olsanız bile güvenlik açıklarını aramaya değer.
- Sistemin bazı kısımlarını diğerlerinden izole etmek gerekir. Eğer bir aramanız varsa bunu Docker’a bile değil, ayrı makinelere taşımanız gerekiyor. Çünkü arama veya yetkilendirme başarısız olursa en azından bir şeyler çalışmaya devam edecektir. Çevrimiçi mağaza söz konusu olduğunda, kullanıcılar ürünleri katalogda bulmaya, toplayıcıya gitmeye, zaten yetkiliyse satın almaya veya OAuth2 aracılığıyla yetkilendirmeye devam edecek.
- Her türlü bulut hizmetini ihmal etmeyin.
- CDN'yi yalnızca ağ gecikmelerini optimize etmek için değil, aynı zamanda kanalın tükenmesine ve statik trafiğe taşmaya yönelik saldırılara karşı koruma aracı olarak da kullanın.
- Özel koruma hizmetlerinin kullanılması gereklidir. Kanal düzeyinde L3&4 saldırılarına karşı kendinizi koruyamazsınız çünkü büyük ihtimalle yeterli kanalınız yoktur. Ayrıca çok büyük olabildikleri için L7 saldırılarına karşı koymanız da pek mümkün değildir. Ayrıca, küçük saldırıların araştırılması hâlâ özel hizmetlerin, özel algoritmaların ayrıcalığıdır.
- Düzenli olarak güncelleyin. Bu sadece çekirdek için değil aynı zamanda SSH arka plan programı için de geçerlidir, özellikle de dışarıya açıksa. Prensip olarak her şeyin güncellenmesi gerekiyor çünkü belirli güvenlik açıklarını kendi başınıza takip etmeniz pek mümkün değil.
Kaynak: habr.com