Variti membangunkan perlindungan terhadap bot dan serangan DDoS, dan juga menjalankan ujian tekanan dan beban. Pada persidangan HighLoad++ 2018 kami bercakap tentang cara untuk mendapatkan sumber daripada pelbagai jenis serangan. Ringkasnya: asingkan bahagian sistem, gunakan perkhidmatan awan dan CDN, dan kemas kini dengan kerap. Tetapi anda masih tidak akan dapat mengendalikan perlindungan tanpa syarikat khusus :)
Sebelum membaca teks, anda boleh membaca abstrak pendek .
Dan jika anda tidak suka membaca atau hanya mahu menonton video, rakaman laporan kami adalah di bawah spoiler.
Rakaman video laporan
Banyak syarikat sudah tahu cara melakukan ujian beban, tetapi tidak semua melakukan ujian tekanan. Sesetengah pelanggan kami berpendapat bahawa tapak mereka kebal kerana mereka mempunyai sistem muatan tinggi dan ia melindungi dengan baik daripada serangan. Kami menunjukkan bahawa ini tidak sepenuhnya benar.
Sudah tentu, sebelum menjalankan ujian, kami mendapatkan kebenaran daripada pelanggan, ditandatangani dan dicop, dan dengan bantuan kami serangan DDoS tidak boleh dilakukan ke atas sesiapa. Ujian dijalankan pada masa yang dipilih oleh pelanggan, apabila trafik ke sumbernya adalah minimum, dan masalah akses tidak akan menjejaskan pelanggan. Di samping itu, memandangkan sesuatu selalu boleh berlaku semasa proses ujian, kami sentiasa berhubung dengan pelanggan. Ini membolehkan anda bukan sahaja melaporkan hasil yang dicapai, tetapi juga untuk mengubah sesuatu semasa ujian. Setelah selesai ujian, kami sentiasa membuat laporan di mana kami menunjukkan kelemahan yang dikesan dan memberikan cadangan untuk menghapuskan kelemahan tapak.
Bagaimana kita berusaha
Apabila menguji, kami mencontohi botnet. Memandangkan kami bekerja dengan pelanggan yang tidak berada di rangkaian kami, untuk memastikan ujian tidak berakhir pada minit pertama disebabkan had atau perlindungan yang dicetuskan, kami membekalkan beban bukan dari satu IP, tetapi daripada subnet kami sendiri. Selain itu, untuk mencipta beban yang ketara, kami mempunyai pelayan ujian kami sendiri yang cukup berkuasa.
Postulat
Terlalu banyak tidak bermakna baik
Lebih sedikit beban yang boleh kita bawa sumber kepada kegagalan, lebih baik. Jika anda boleh membuat tapak berhenti berfungsi pada satu permintaan sesaat, atau bahkan satu permintaan seminit, itu bagus. Kerana mengikut undang-undang kekejaman, pengguna atau penyerang secara tidak sengaja akan jatuh ke dalam kelemahan tertentu ini.
Kegagalan separa adalah lebih baik daripada kegagalan sepenuhnya
Kami sentiasa menasihati menjadikan sistem heterogen. Lebih-lebih lagi, adalah wajar memisahkannya pada tahap fizikal, dan bukan hanya dengan kontena. Dalam kes pemisahan fizikal, walaupun sesuatu gagal di tapak, terdapat kebarangkalian tinggi bahawa ia tidak akan berhenti berfungsi sepenuhnya, dan pengguna akan terus mendapat akses kepada sekurang-kurangnya sebahagian daripada fungsi tersebut.
Seni bina yang baik adalah asas untuk kemampanan
Toleransi kesalahan sumber dan keupayaannya untuk menahan serangan dan beban harus ditetapkan pada peringkat reka bentuk, sebenarnya, pada peringkat melukis carta alir pertama dalam buku nota. Kerana jika kesilapan maut merayap masuk, adalah mungkin untuk membetulkannya pada masa akan datang, tetapi ia sangat sukar.
Bukan sahaja kod harus bagus, tetapi juga konfigurasi
Ramai orang berpendapat bahawa pasukan pembangunan yang baik adalah jaminan perkhidmatan yang tahan terhadap kesalahan. Pasukan pembangunan yang baik sangat diperlukan, tetapi juga mesti ada operasi yang baik, DevOps yang baik. Iaitu, kami memerlukan pakar yang akan mengkonfigurasi Linux dan rangkaian dengan betul, menulis konfigurasi dengan betul dalam nginx, menetapkan had, dll. Jika tidak, sumber akan berfungsi dengan baik hanya dalam ujian, dan pada satu ketika semuanya akan pecah dalam pengeluaran.
Perbezaan antara ujian beban dan tekanan
Ujian beban membolehkan anda mengenal pasti had fungsi sistem. Ujian tekanan adalah bertujuan untuk mencari kelemahan dalam sistem dan digunakan untuk memecahkan sistem ini dan melihat bagaimana ia akan bertindak dalam proses kegagalan bahagian tertentu. Dalam kes ini, sifat beban biasanya tidak diketahui oleh pelanggan sebelum ujian tekanan bermula.
Ciri-ciri tersendiri serangan L7
Kami biasanya membahagikan jenis beban kepada beban pada tahap L7 dan L3&4. L7 ialah beban pada peringkat aplikasi, selalunya ia hanya bermaksud HTTP, tetapi kami maksudkan sebarang beban pada tahap protokol TCP.
Serangan L7 mempunyai ciri tersendiri tertentu. Pertama, mereka datang terus ke aplikasi, iaitu, tidak mungkin ia akan ditunjukkan melalui cara rangkaian. Serangan sedemikian menggunakan logik, dan disebabkan ini, ia menggunakan CPU, memori, cakera, pangkalan data dan sumber lain dengan sangat cekap dan dengan trafik yang sedikit.
Banjir HTTP
Dalam kes sebarang serangan, beban lebih mudah dibuat daripada dikendalikan, dan dalam kes L7 ini juga benar. Tidak selalu mudah untuk membezakan trafik serangan daripada trafik yang sah, dan selalunya ini boleh dilakukan mengikut kekerapan, tetapi jika semuanya dirancang dengan betul, maka mustahil untuk memahami dari log di mana serangan itu dan di mana permintaan yang sah berada.
Sebagai contoh pertama, pertimbangkan serangan Banjir HTTP. Graf menunjukkan bahawa serangan sedemikian biasanya sangat kuat; dalam contoh di bawah, bilangan puncak permintaan melebihi 600 ribu seminit.
HTTP Flood ialah cara paling mudah untuk membuat beban. Biasanya, ia memerlukan beberapa jenis alat ujian beban, seperti ApacheBench, dan menetapkan permintaan dan sasaran. Dengan pendekatan yang begitu mudah, terdapat kebarangkalian yang tinggi untuk memasuki cache pelayan, tetapi mudah untuk memintasnya. Contohnya, menambahkan rentetan rawak pada permintaan, yang akan memaksa pelayan untuk sentiasa menyediakan halaman baharu.
Juga, jangan lupa tentang ejen pengguna dalam proses membuat beban. Banyak ejen pengguna alat ujian popular ditapis oleh pentadbir sistem, dan dalam kes ini beban mungkin tidak sampai ke bahagian belakang. Anda boleh meningkatkan hasil dengan ketara dengan memasukkan pengepala yang lebih kurang sah daripada penyemak imbas ke dalam permintaan.
Semudah serangan HTTP Flood, ia juga mempunyai kelemahannya. Pertama, sejumlah besar kuasa diperlukan untuk mencipta beban. Kedua, serangan sedemikian sangat mudah untuk dikesan, terutamanya jika ia datang dari satu alamat. Akibatnya, permintaan serta-merta mula ditapis sama ada oleh pentadbir sistem atau bahkan di peringkat pembekal.
Apa yang hendak dicari
Untuk mengurangkan bilangan permintaan sesaat tanpa kehilangan kecekapan, anda perlu menunjukkan sedikit imaginasi dan meneroka tapak. Oleh itu, anda boleh memuatkan bukan sahaja saluran atau pelayan, tetapi juga bahagian individu aplikasi, contohnya, pangkalan data atau sistem fail. Anda juga boleh mencari tempat di tapak yang melakukan pengiraan besar: kalkulator, halaman pemilihan produk, dsb. Akhirnya, ia sering berlaku bahawa laman web ini mempunyai beberapa jenis skrip PHP yang menghasilkan halaman beberapa ratus ribu baris. Skrip sedemikian juga memuatkan pelayan dengan ketara dan boleh menjadi sasaran untuk serangan.
Mana nak cari
Apabila kami mengimbas sumber sebelum menguji, kami mula-mula melihat, sudah tentu, pada tapak itu sendiri. Kami sedang mencari semua jenis medan input, fail berat - secara umum, segala-galanya yang boleh menimbulkan masalah untuk sumber dan melambatkan operasinya. Alat pembangunan banal dalam Google Chrome dan Firefox membantu di sini, menunjukkan masa respons halaman.
Kami juga mengimbas subdomain. Sebagai contoh, terdapat kedai dalam talian tertentu, abc.com, dan ia mempunyai subdomain admin.abc.com. Kemungkinan besar, ini adalah panel pentadbir dengan kebenaran, tetapi jika anda meletakkan beban padanya, ia boleh menimbulkan masalah untuk sumber utama.
Tapak ini mungkin mempunyai subdomain api.abc.com. Kemungkinan besar, ini adalah sumber untuk aplikasi mudah alih. Aplikasi ini boleh didapati di App Store atau Google Play, memasang titik akses khas, membedah API dan mendaftar akaun ujian. Masalahnya ialah orang sering berfikir bahawa apa-apa yang dilindungi oleh kebenaran adalah kebal terhadap serangan penafian perkhidmatan. Kononnya, kebenaran adalah CAPTCHA terbaik, tetapi tidak. Mudah untuk membuat 10-20 akaun ujian, tetapi dengan menciptanya, kami mendapat akses kepada fungsi yang kompleks dan tidak terselindung.
Sememangnya, kami melihat sejarah, di robots.txt dan WebArchive, ViewDNS, dan mencari versi lama sumber tersebut. Kadang-kadang ia berlaku bahawa pemaju telah melancarkan, katakan, mail2.yandex.net, tetapi versi lama, mail.yandex.net, kekal. mail.yandex.net ini tidak lagi disokong, sumber pembangunan tidak diperuntukkan kepadanya, tetapi ia terus menggunakan pangkalan data. Sehubungan itu, menggunakan versi lama, anda boleh menggunakan sumber bahagian belakang dan semua yang ada di belakang reka letak dengan berkesan. Sudah tentu, ini tidak selalu berlaku, tetapi kami masih menghadapi ini agak kerap.
Sememangnya, kami menganalisis semua parameter permintaan dan struktur kuki. Anda boleh, katakan, membuang beberapa nilai ke dalam tatasusunan JSON di dalam kuki, mencipta banyak sarang dan membuat sumber berfungsi untuk jangka masa yang tidak munasabah.
Muatan carian
Perkara pertama yang terlintas di fikiran semasa menyelidik tapak ialah memuatkan pangkalan data, kerana hampir semua orang mempunyai carian, dan untuk hampir semua orang, malangnya, ia kurang dilindungi. Atas sebab tertentu, pembangun tidak memberikan perhatian yang cukup untuk mencari. Tetapi terdapat satu cadangan di sini - anda tidak seharusnya membuat permintaan daripada jenis yang sama, kerana anda mungkin menghadapi caching, seperti yang berlaku dengan banjir HTTP.
Membuat pertanyaan rawak ke pangkalan data juga tidak selalu berkesan. Adalah lebih baik untuk membuat senarai kata kunci yang berkaitan dengan carian. Jika kita kembali kepada contoh kedai dalam talian: katakan tapak itu menjual tayar kereta dan membolehkan anda menetapkan jejari tayar, jenis kereta dan parameter lain. Sehubungan itu, gabungan perkataan yang berkaitan akan memaksa pangkalan data berfungsi dalam keadaan yang lebih kompleks.
Di samping itu, adalah berbaloi menggunakan penomboran: adalah lebih sukar untuk carian untuk mengembalikan halaman kedua terakhir hasil carian daripada yang pertama. Iaitu, dengan bantuan penomboran anda boleh mempelbagaikan sedikit beban.
Contoh di bawah menunjukkan beban carian. Ia dapat dilihat bahawa dari saat pertama ujian pada kelajuan sepuluh permintaan sesaat, laman web itu turun dan tidak bertindak balas.
Jika tiada carian?
Jika tiada carian, ini tidak bermakna tapak tersebut tidak mengandungi medan input lain yang terdedah. Medan ini mungkin kebenaran. Pada masa kini, pembangun suka membuat cincang kompleks untuk melindungi pangkalan data log masuk daripada serangan jadual pelangi. Ini bagus, tetapi cincang sedemikian menggunakan banyak sumber CPU. Aliran besar kebenaran palsu membawa kepada kegagalan pemproses, dan akibatnya, tapak berhenti berfungsi.
Kehadiran di tapak semua jenis borang untuk komen dan maklum balas adalah sebab untuk menghantar teks yang sangat besar ke sana atau hanya mencipta banjir besar. Kadangkala tapak menerima fail yang dilampirkan, termasuk dalam format gzip. Dalam kes ini, kami mengambil fail 1TB, memampatkannya kepada beberapa bait atau kilobait menggunakan gzip dan menghantarnya ke tapak. Kemudian ia dibuka zip dan kesan yang sangat menarik diperolehi.
API Rehat
Saya ingin memberi sedikit perhatian kepada perkhidmatan popular seperti Rest API. Menjaga API Rehat adalah lebih sukar daripada tapak web biasa. Malah kaedah perlindungan yang remeh terhadap kekerasan kata laluan dan aktiviti tidak sah lain tidak berfungsi untuk Rest API.
API Rehat sangat mudah dipecahkan kerana ia mengakses pangkalan data secara langsung. Pada masa yang sama, kegagalan perkhidmatan sedemikian memerlukan akibat yang agak serius untuk perniagaan. Hakikatnya ialah Rest API biasanya digunakan bukan sahaja untuk laman web utama, tetapi juga untuk aplikasi mudah alih dan beberapa sumber perniagaan dalaman. Dan jika semua ini jatuh, maka kesannya jauh lebih kuat daripada dalam kes kegagalan laman web yang mudah.
Memuatkan kandungan berat
Jika kami ditawarkan untuk menguji beberapa aplikasi satu halaman biasa, halaman pendaratan atau tapak web kad perniagaan yang tidak mempunyai fungsi yang rumit, kami mencari kandungan yang berat. Sebagai contoh, imej besar yang dihantar pelayan, fail binari, dokumentasi pdf - kami cuba memuat turun semua ini. Ujian sedemikian memuatkan sistem fail dengan baik dan menyumbat saluran, dan oleh itu berkesan. Iaitu, walaupun anda tidak meletakkan pelayan ke bawah, memuat turun fail besar pada kelajuan rendah, anda hanya akan menyumbat saluran pelayan sasaran dan kemudian penafian perkhidmatan akan berlaku.
Contoh ujian sedemikian menunjukkan bahawa pada kelajuan 30 RPS tapak berhenti bertindak balas atau menghasilkan ralat pelayan ke-500.
Jangan lupa tentang menyediakan pelayan. Anda sering dapati bahawa seseorang membeli mesin maya, memasang Apache di sana, mengkonfigurasi segala-galanya secara lalai, memasang aplikasi PHP, dan di bawah anda boleh melihat hasilnya.
Di sini beban pergi ke akar dan berjumlah hanya 10 RPS. Kami menunggu 5 minit dan pelayan ranap. Memang benar bahawa ia tidak diketahui sepenuhnya mengapa dia jatuh, tetapi terdapat andaian bahawa dia mempunyai terlalu banyak ingatan dan oleh itu berhenti bertindak balas.
berasaskan gelombang
Dalam satu atau dua tahun lepas, serangan gelombang telah menjadi agak popular. Ini disebabkan oleh fakta bahawa banyak organisasi membeli perkakasan tertentu untuk perlindungan DDoS, yang memerlukan masa tertentu untuk mengumpul statistik untuk mula menapis serangan. Iaitu, mereka tidak menapis serangan dalam 30-40 saat pertama, kerana mereka mengumpul data dan belajar. Sehubungan itu, dalam 30-40 saat ini, anda boleh melancarkan begitu banyak di tapak sehingga sumber itu akan berbohong untuk masa yang lama sehingga semua permintaan dibersihkan.
Dalam kes serangan di bawah, terdapat selang 10 minit, selepas itu bahagian serangan baharu yang diubah suai tiba.
Iaitu, pertahanan belajar, mula menapis, tetapi bahagian serangan baru yang sama sekali berbeza tiba, dan pertahanan mula belajar semula. Malah, penapisan berhenti berfungsi, perlindungan menjadi tidak berkesan, dan tapak tidak tersedia.
Serangan gelombang dicirikan oleh nilai yang sangat tinggi di puncak, ia boleh mencapai seratus ribu atau sejuta permintaan sesaat, dalam kes L7. Jika kita bercakap tentang L3&4, maka terdapat ratusan gigabit trafik, atau, oleh itu, ratusan mpps, jika anda mengira dalam paket.
Masalah dengan serangan sedemikian ialah penyegerakan. Serangan datang daripada botnet dan memerlukan tahap penyegerakan yang tinggi untuk mencipta lonjakan satu kali yang sangat besar. Dan penyelarasan ini tidak selalu berjaya: kadangkala outputnya adalah sejenis puncak parabola, yang kelihatan agak menyedihkan.
Bukan HTTP sahaja
Selain HTTP di L7, kami suka mengeksploitasi protokol lain. Sebagai peraturan, laman web biasa, terutamanya pengehosan biasa, mempunyai protokol mel dan MySQL menonjol. Protokol mel tertakluk kepada beban yang kurang daripada pangkalan data, tetapi ia juga boleh dimuatkan dengan agak cekap dan berakhir dengan CPU yang terlebih beban pada pelayan.
Kami agak berjaya menggunakan kelemahan SSH 2016. Sekarang kelemahan ini telah diperbaiki untuk hampir semua orang, tetapi ini tidak bermakna bahawa beban tidak boleh diserahkan kepada SSH. boleh. Terdapat beban kebenaran yang besar, SSH memakan hampir keseluruhan CPU pada pelayan, dan kemudian laman web itu runtuh daripada satu atau dua permintaan sesaat. Sehubungan itu, satu atau dua permintaan berdasarkan log ini tidak boleh dibezakan daripada beban yang sah.
Banyak sambungan yang kami buka dalam pelayan juga kekal relevan. Sebelum ini, Apache bersalah dalam hal ini, kini nginx sebenarnya bersalah atas perkara ini, kerana ia sering dikonfigurasikan secara lalai. Bilangan sambungan yang boleh terus dibuka nginx adalah terhad, jadi kami membuka bilangan sambungan ini, nginx tidak lagi menerima sambungan baharu, dan akibatnya tapak tidak berfungsi.
Kelompok ujian kami mempunyai CPU yang mencukupi untuk menyerang jabat tangan SSL. Pada dasarnya, seperti yang ditunjukkan oleh amalan, botnet kadangkala suka melakukan ini juga. Di satu pihak, jelas bahawa anda tidak boleh melakukannya tanpa SSL, kerana hasil Google, kedudukan, keselamatan. Sebaliknya, SSL malangnya mempunyai masalah CPU.
L3&4
Apabila kita bercakap tentang serangan di peringkat L3&4, kita biasanya bercakap tentang serangan di peringkat pautan. Beban sedemikian hampir selalu boleh dibezakan daripada beban yang sah, melainkan ia adalah serangan banjir SYN. Masalah dengan serangan banjir SYN untuk alat keselamatan ialah jumlahnya yang besar. Nilai L3&4 maksimum ialah 1,5-2 Tbit/s. Trafik jenis ini sangat sukar untuk diproses walaupun untuk syarikat besar, termasuk Oracle dan Google.
SYN dan SYN-ACK ialah paket yang digunakan semasa membuat sambungan. Oleh itu, SYN-banjir sukar untuk dibezakan daripada beban yang sah: tidak jelas sama ada ini SYN yang datang untuk mewujudkan sambungan, atau sebahagian daripada banjir.
UDP-banjir
Biasanya, penyerang tidak mempunyai keupayaan seperti yang kita miliki, jadi penguatan boleh digunakan untuk mengatur serangan. Iaitu, penyerang mengimbas Internet dan mencari sama ada pelayan yang terdedah atau dikonfigurasikan secara salah yang, sebagai contoh, sebagai tindak balas kepada satu paket SYN, bertindak balas dengan tiga SYN-ACK. Dengan memalsukan alamat sumber daripada alamat pelayan sasaran, adalah mungkin untuk meningkatkan kuasa dengan, katakan, tiga kali dengan satu paket dan mengalihkan trafik kepada mangsa.
Masalah dengan amplifikasi adalah sukar untuk dikesan. Contoh terkini termasuk kes sensasi memcached yang terdedah. Selain itu, kini terdapat banyak peranti IoT, kamera IP, yang juga kebanyakannya dikonfigurasikan secara lalai, dan secara lalai ia dikonfigurasikan secara tidak betul, itulah sebabnya penyerang paling kerap membuat serangan melalui peranti sedemikian.
Banjir SYN yang sukar
SYN-flood mungkin merupakan jenis serangan yang paling menarik dari sudut pandangan pembangun. Masalahnya ialah pentadbir sistem sering menggunakan penyekatan IP untuk perlindungan. Selain itu, penyekatan IP bukan sahaja menjejaskan pentadbir sistem yang bertindak menggunakan skrip, tetapi juga, malangnya, beberapa sistem keselamatan yang dibeli dengan banyak wang.
Kaedah ini boleh berubah menjadi bencana, kerana jika penyerang menggantikan alamat IP, syarikat akan menyekat subnetnya sendiri. Apabila Firewall menyekat kelompoknya sendiri, output akan gagal interaksi luaran dan sumber akan gagal.
Lebih-lebih lagi, tidak sukar untuk menyekat rangkaian anda sendiri. Jika pejabat pelanggan mempunyai rangkaian Wi-Fi, atau jika prestasi sumber diukur menggunakan pelbagai sistem pemantauan, maka kami mengambil alamat IP sistem pemantauan ini atau Wi-Fi pejabat pelanggan dan menggunakannya sebagai sumber. Pada akhirnya, sumber itu nampaknya tersedia, tetapi alamat IP sasaran disekat. Oleh itu, rangkaian Wi-Fi persidangan HighLoad, di mana produk baharu syarikat sedang dibentangkan, mungkin disekat, dan ini melibatkan kos perniagaan dan ekonomi tertentu.
Semasa ujian, kami tidak boleh menggunakan amplifikasi melalui memcached dengan mana-mana sumber luaran, kerana terdapat perjanjian untuk menghantar trafik hanya ke alamat IP yang dibenarkan. Sehubungan itu, kami menggunakan penguatan melalui SYN dan SYN-ACK, apabila sistem bertindak balas untuk menghantar satu SYN dengan dua atau tiga SYN-ACK, dan pada output serangan didarab dengan dua atau tiga kali.
Tools
Salah satu alatan utama yang kami gunakan untuk beban kerja L7 ialah Yandex-tank. Khususnya, hantu digunakan sebagai pistol, serta terdapat beberapa skrip untuk menjana kartrij dan untuk menganalisis hasilnya.
Tcpdump digunakan untuk menganalisis trafik rangkaian, dan Nmap digunakan untuk menganalisis pelayan. Untuk mencipta beban pada tahap L3&4, OpenSSL dan sedikit keajaiban kami sendiri dengan perpustakaan DPDK digunakan. DPDK ialah perpustakaan daripada Intel yang membolehkan anda bekerja dengan antara muka rangkaian memintas timbunan Linux, dengan itu meningkatkan kecekapan. Sememangnya, kami menggunakan DPDK bukan sahaja pada tahap L3&4, tetapi juga pada tahap L7, kerana ia membolehkan kami mencipta aliran beban yang sangat tinggi, dalam julat beberapa juta permintaan sesaat daripada satu mesin.
Kami juga menggunakan penjana trafik tertentu dan alat khas yang kami tulis untuk ujian tertentu. Jika kita mengingati kelemahan di bawah SSH, maka set di atas tidak boleh dieksploitasi. Jika kami menyerang protokol mel, kami mengambil utiliti mel atau hanya menulis skrip padanya.
Penemuan
Sebagai kesimpulan saya ingin mengatakan:
- Sebagai tambahan kepada ujian beban klasik, adalah perlu untuk menjalankan ujian tekanan. Kami mempunyai contoh sebenar di mana subkontraktor rakan kongsi hanya menjalankan ujian beban. Ia menunjukkan bahawa sumber itu boleh menahan beban biasa. Tetapi kemudian beban yang tidak normal muncul, pelawat tapak mula menggunakan sumber itu sedikit berbeza, dan akibatnya subkontraktor itu berbaring. Oleh itu, adalah wajar mencari kelemahan walaupun anda sudah dilindungi daripada serangan DDoS.
- Ia adalah perlu untuk mengasingkan beberapa bahagian sistem daripada yang lain. Jika anda mempunyai carian, anda perlu mengalihkannya ke mesin yang berasingan, iaitu, bukan juga ke Docker. Kerana jika carian atau kebenaran gagal, sekurang-kurangnya sesuatu akan terus berfungsi. Dalam kes kedai dalam talian, pengguna akan terus mencari produk dalam katalog, pergi dari agregator, membeli jika mereka sudah dibenarkan atau memberi kebenaran melalui OAuth2.
- Jangan abaikan semua jenis perkhidmatan awan.
- Gunakan CDN bukan sahaja untuk mengoptimumkan kelewatan rangkaian, tetapi juga sebagai cara perlindungan terhadap serangan terhadap keletihan saluran dan hanya membanjiri trafik statik.
- Ia perlu menggunakan perkhidmatan perlindungan khusus. Anda tidak boleh melindungi diri anda daripada serangan L3&4 di peringkat saluran, kerana kemungkinan besar anda tidak mempunyai saluran yang mencukupi. Anda juga tidak mungkin melawan serangan L7, kerana ia boleh menjadi sangat besar. Selain itu, pencarian untuk serangan kecil masih menjadi prerogatif perkhidmatan khas, algoritma khas.
- Kemas kini dengan kerap. Ini terpakai bukan sahaja pada kernel, tetapi juga untuk daemon SSH, terutamanya jika anda membukanya ke luar. Pada dasarnya, segala-galanya perlu dikemas kini, kerana anda tidak mungkin dapat menjejaki kelemahan tertentu sendiri.
Sumber: www.habr.com