Variti ngembangkeun panyalindungan ngalawan bot sareng serangan DDoS, sareng ogé ngalaksanakeun tés setrés sareng beban. Dina konferensi HighLoad ++ 2018 urang ngobrol ngeunaan kumaha carana ngamankeun sumberdaya ti sagala rupa jenis serangan. Singketna: ngasingkeun bagian tina sistem, nganggo jasa awan sareng CDN, sareng ngapdet rutin. Tapi anjeun tetep moal tiasa nanganan panyalindungan tanpa perusahaan khusus :)
Sateuacan maca téks, anjeun tiasa maca abstrak pondok .
Sareng upami anjeun henteu resep maca atanapi ngan ukur hoyong ningali pidéo, ngarékam laporan kami aya di handap handapeun spoiler.
Rekaman video laporan
Seueur perusahaan parantos terang kumaha ngalakukeun tés beban, tapi henteu sadayana ngalakukeun tés setrés. Sababaraha palanggan urang nganggap yén situsna teu kaganggu kumargi aranjeunna gaduh sistem muatan anu luhur, sareng éta ngajagaan saé tina serangan. Kami nunjukkeun yén ieu sanés leres pisan.
Tangtosna, sateuacan ngalaksanakeun tés, kami nampi idin ti nasabah, ditandatanganan sareng dicap, sareng kalayan bantosan kami, serangan DDoS henteu tiasa dilakukeun ku saha waé. Uji coba dilaksanakeun dina waktos anu dipilih ku nasabah, nalika lalu lintas ka sumber dayana minimal, sareng masalah aksés moal mangaruhan klien. Salaku tambahan, kusabab aya anu tiasa salah nalika prosés tés, kami gaduh kontak konstan sareng palanggan. Hal ieu ngamungkinkeun anjeun henteu ngan ukur ngalaporkeun hasil anu dihontal, tapi ogé ngarobih hiji hal salami tés. Saatos tés parantos réngsé, kami sok ngadamel laporan dimana kami nunjukkeun kakurangan anu dideteksi sareng masihan saran pikeun ngaleungitkeun kalemahan situs.
Kumaha urang damel
Nalika nguji, urang emulate botnet a. Kusabab urang damel sareng klien anu henteu aya dina jaringan kami, pikeun mastikeun yén tés henteu réngsé dina menit kahiji kusabab watesan atanapi panyalindungan anu dipicu, kami nyayogikeun beban sanés tina hiji IP, tapi tina subnet urang sorangan. Tambih Deui, pikeun nyieun beban signifikan, urang boga server test urang sorangan cukup kuat.
Postulates
Loba teuing lain hartina alus
Beban pangsaeutikna anu urang tiasa nyangking sumber pikeun gagal, langkung saé. Upami anjeun tiasa ngajantenkeun situsna ngeureunkeun fungsina dina hiji pamundut per detik, atanapi bahkan hiji pamundut per menit, éta saé. Kusabab nurutkeun hukum meanness, pamaké atawa panyerang ngahaja bakal digolongkeun kana kerentanan husus ieu.
Gagal parsial langkung saé tibatan gagal lengkep
Kami salawasna mamatahan sangkan sistem hétérogén. Leuwih ti éta, éta patut misahkeun aranjeunna dina tingkat fisik, teu ngan ku containerization. Dina kasus separation fisik, sanajan hal gagal dina loka, aya kamungkinan luhur yén éta moal eureun digawé lengkep, sarta pamaké bakal neruskeun boga aksés ka sahenteuna bagian tina fungsionalitas nu.
Arsitéktur anu saé mangrupikeun dasar pikeun kelestarian
Toleransi kasalahan tina sumber daya sareng kamampuanna pikeun nahan serangan sareng beban kedah ditetepkeun dina tahap desain, kanyataanna, dina tahap ngagambar bagan alur munggaran dina notepad. Kusabab lamun kasalahan fatal creep di, kasebut nyaéta dimungkinkeun pikeun ngabenerkeun aranjeunna dina mangsa nu bakal datang, tapi hésé pisan.
Henteu ngan kode kudu alus, tapi ogé config
Seueur jalma nganggap yén tim pangembangan anu saé mangrupikeun jaminan jasa anu teu toleran. Tim pangembangan anu saé leres-leres diperyogikeun, tapi kedah aya ogé operasi anu saé, DevOps anu saé. Nyaéta, urang peryogi spesialis anu leres bakal ngonpigurasikeun Linux sareng jaringan, nyerat configs leres dina nginx, set wates, jsb. Upami teu kitu, sumberdaya bakal dianggo ogé ukur dina nguji, sarta di sawatara titik sagalana bakal megatkeun dina produksi.
Bedana antara beban sareng tés setrés
Uji beban ngamungkinkeun anjeun pikeun ngaidentipikasi wates fungsi sistem. Uji setrés ditujukeun pikeun mendakan kalemahan dina sistem sareng dianggo pikeun ngarobih sistem ieu sareng ningali kumaha éta bakal kalakuanana dina prosés gagalna sababaraha bagian. Dina hal ieu, sifat beban biasana tetep teu dipikanyaho ku palanggan sateuacan tés setrés dimimitian.
Fitur has tina serangan L7
Urang biasana ngabagi jinis beban kana beban dina tingkat L7 sareng L3&4. L7 mangrupikeun beban dina tingkat aplikasi, paling sering hartosna ngan ukur HTTP, tapi kami hartosna beban naon waé dina tingkat protokol TCP.
Serangan L7 gaduh ciri has anu tangtu. Anu mimiti, aranjeunna langsung sumping ka aplikasi, nyaéta, teu mungkin aranjeunna bakal ditingalikeun ku cara jaringan. Serangan sapertos kitu nganggo logika, sareng kusabab ieu, aranjeunna ngonsumsi CPU, mémori, disk, pangkalan data sareng sumber daya sanésna kalayan épisién pisan sareng sakedik lalulintas.
HTTP Banjir
Dina kasus serangan naon waé, beban langkung gampang didamel tibatan dicekel, sareng dina kasus L7 ieu ogé leres. Teu salawasna gampang ngabedakeun lalulintas serangan ti lalulintas sah, sarta paling sering ieu bisa dipigawé ku frékuénsi, tapi lamun sagalana geus rencanana leres, teras teu mungkin ngartos tina log dimana serangan jeung dimana requests sah.
Salaku conto kahiji, mertimbangkeun serangan HTTP Banjir. Grafik nunjukkeun yén serangan sapertos kitu biasana kuat pisan; dina conto di handap, jumlah puncak paménta ngaleuwihan 600 rébu per menit.
HTTP Banjir nyaéta cara panggampangna pikeun nyieun beban. Ilaharna, peryogi sababaraha jinis alat uji beban, sapertos ApacheBench, sareng nyetél pamundut sareng target. Kalayan pendekatan saderhana sapertos kitu, kamungkinan luhur pikeun ngajalankeun kana cache server, tapi gampang pikeun ngaliwat éta. Contona, nambahkeun string acak kana pamundut, nu bakal maksakeun server pikeun terus ngawula kaca seger.
Ogé, ulah poho ngeunaan pamaké-agén dina prosés nyieun beban. Seueur agén-agén alat panguji populér disaring ku pangurus sistem, sareng dina hal ieu beban tiasa waé henteu dugi ka tukang. Anjeun tiasa sacara signifikan ningkatkeun hasil ku nyelapkeun lulugu langkung atanapi kirang sah tina browser kana pamundut.
Sagampil serangan HTTP Banjir, aranjeunna ogé gaduh kalemahanana. Firstly, jumlah badag kakuatan diperlukeun pikeun nyieun beban. Bréh, serangan sapertos pisan gampang pikeun ngadeteksi, utamana lamun datang ti hiji alamat. Hasilna, pamundut langsung mimiti disaring ku pangurus sistem atanapi bahkan di tingkat panyadia.
Naon anu dipilarian
Pikeun ngirangan jumlah pamundut per detik tanpa kaleungitan efisiensi, anjeun kedah nunjukkeun imajinasi sakedik sareng ngajalajah situs. Ku kituna, anjeun bisa muka teu ukur saluran atawa server, tapi ogé bagian individu tina aplikasi, contona, database atawa sistem file. Anjeun ogé tiasa milarian tempat dina situs anu ngalakukeun itungan ageung: kalkulator, halaman pilihan produk, jsb. Tungtungna, sering kajadian yén situs éta ngagaduhan sababaraha jinis skrip PHP anu ngahasilkeun halaman sababaraha ratus rébu garis. Skrip sapertos kitu ogé ngamuat server sacara signifikan sareng tiasa janten target serangan.
Dimana milarian
Nalika urang nyeken sumberdaya sateuacan nguji, urang tingali heula, tangtosna, dina situs éta sorangan. Kami milarian sagala jinis widang input, file beurat - sacara umum, sadayana anu tiasa nyiptakeun masalah pikeun sumber daya sareng ngalambatkeun operasina. Alat pangembangan Banal di Google Chrome sareng Firefox ngabantosan di dieu, nunjukkeun waktos réspon halaman.
Urang ogé nyeken subdomains. Contona, aya hiji toko online tangtu, abc.com, sarta ngabogaan subdomain admin.abc.com. Paling dipikaresep, ieu mangrupa panel admin kalawan otorisasina, tapi lamun nempatkeun beban dina eta, éta bisa nyieun masalah pikeun sumber utama.
Situs tiasa gaduh subdomain api.abc.com. Paling dipikaresep, ieu téh sumberdaya pikeun aplikasi mobile. Aplikasina tiasa dipendakan di App Store atanapi Google Play, pasang titik aksés khusus, ngabedah API sareng ngadaptar akun uji. Masalahna nyaéta jalma sering mikir yén naon waé anu ditangtayungan ku otorisasina kebal tina panolakan serangan jasa. Sakuduna, otorisasina mangrupikeun CAPTCHA pangsaéna, tapi henteu. Gampang nyieun 10-20 rekening tés, tapi ku nyieun eta, urang meunang aksés ka fungsionalitas kompléks jeung undisguised.
Alami, urang nempo sajarah, di robots.txt na WebArchive, ViewDNS, sarta néangan versi heubeul tina sumberdaya. Kadang-kadang kajadian yén pamekar parantos ngagulung, sebutkeun, mail2.yandex.net, tapi versi lami, mail.yandex.net, tetep. mail.yandex.net ieu teu dirojong deui, sumberdaya ngembangkeun teu disadiakeun pikeun eta, tapi terus meakeun database. Sasuai, ngagunakeun versi heubeul, anjeun bisa éféktif ngagunakeun sumberdaya backend jeung sagalana nu aya di balik perenah nu. Tangtu, ieu teu salawasna kajadian, tapi urang masih sapatemon ieu rada mindeng.
Alami, urang nganalisis sadaya parameter pamundut sareng struktur cookie. Anjeun tiasa, sebutkeun, dump sababaraha nilai kana Asép Sunandar Sunarya JSON jero cookie a, nyieun loba nyarang sarta nyieun sumberdaya jalan pikeun waktu unreasonably lila.
Pilarian beban
Hal kahiji anu aya dina pikiran nalika nalungtik situs nyaéta ngamuat pangkalan data, sabab ampir sadayana gaduh pamilarian, sareng pikeun ampir sadayana, hanjakalna, éta kirang dijagi. Kanggo sababaraha alesan, pamekar teu nengetan cukup pikeun milarian. Tapi aya hiji rekomendasi di dieu - anjeun teu kudu nyieun requests tina tipe sarua, sabab bisa sapatemon cache, sakumaha dina kasus banjir HTTP.
Nyieun queries acak ka database oge teu salawasna éféktif. Hadé pisan mun éta nyieun daptar kecap konci nu relevan pikeun pilarian. Lamun urang balik deui ka conto hiji toko online: hayu urang nyebutkeun situs ngajual ban mobil tur ngidinan Anjeun pikeun ngeset radius tina ban, jenis mobil jeung parameter séjén. Sasuai, kombinasi kecap anu relevan bakal maksakeun pangkalan data pikeun dianggo dina kaayaan anu langkung kompleks.
Salaku tambahan, éta patut ngagunakeun pagination: langkung hese pikeun milarian pikeun ngabalikeun halaman penultimate tina hasil pamilarian tibatan anu munggaran. Nyaéta, kalayan bantuan pagination anjeun tiasa rada diversify beban.
Conto di handap nembongkeun beban pilarian. Ieu bisa ditempo yén ti detik pisan mimiti test dina laju sapuluh requests per detik, situs turun sarta teu ngabales.
Lamun teu aya pilarian?
Upami teu aya pamilarian, ieu sanés hartosna yén situs éta henteu ngandung widang input anu rentan anu sanés. Widang ieu tiasa janten otorisasi. Kiwari, pamekar resep nyieun hashes kompléks ngajaga database login tina serangan tabel katumbiri. Ieu alus, tapi hashes sapertos meakeun loba sumberdaya CPU. A aliran badag otorisasi palsu ngabalukarkeun gagalna prosésor, sarta salaku hasilna, situs eureun gawé.
Ayana dina situs sagala rupa bentuk pikeun koméntar sarta eupan balik mangrupa alesan pikeun ngirim téks kacida gedéna di dinya atawa ngan saukur nyieun caah masif. Kadang-kadang situs nampa file napel, kaasup dina format gzip. Dina hal ieu, urang nyandak file 1TB, niiskeun kana sababaraha bait atanapi kilobyte nganggo gzip sareng kirimkeun ka situs éta. Teras unzipped sareng pangaruh anu pikaresepeun pisan dicandak.
Sesa API
Abdi hoyong nengetan sakedik kana jasa populér sapertos Rest API. Ngamankeun API Istirahat langkung sesah tibatan situs wéb biasa. Malah métode trivial panyalindungan ngalawan gaya brute sandi sarta aktivitas haram lianna teu dianggo pikeun Rest API.
The Rest API pisan gampang megatkeun sabab ngakses database langsung. Dina waktos anu sami, gagalna jasa sapertos nyababkeun akibat anu serius pikeun bisnis. Kanyataanna nyaéta Rest API biasana dianggo henteu ngan ukur pikeun halaman wéb utama, tapi ogé pikeun aplikasi mobile sareng sababaraha sumber bisnis internal. Sareng upami sadaya ieu ragrag, maka pangaruhna langkung kuat tibatan dina kasus kagagalan halaman wéb anu sederhana.
Ngamuat eusi beurat
Upami kami ditawarkeun pikeun nguji sababaraha aplikasi halaman tunggal biasa, halaman badarat, atanapi halaman wéb kartu bisnis anu henteu ngagaduhan fungsionalitas anu rumit, urang milarian eusi anu beurat. Salaku conto, gambar ageung anu dikirimkeun ku server, file binér, dokuméntasi pdf - kami nyobian ngaunduh sadayana ieu. Tés sapertos ngamuat sistem file kalayan saé sareng macét saluran, sareng ku kituna efektif. Nyaéta, sanaos anjeun henteu nempatkeun pangladén, ngaunduh file ageung dina kecepatan rendah, anjeun ngan saukur bakal ngahambat saluran server target teras bakal aya panolakan jasa.
Conto tés sapertos nunjukkeun yén dina laju 30 RPS situs dieureunkeun ngaréspon atanapi ngahasilkeun kasalahan server 500th.
Ulah poho ngeunaan nyetel server. Anjeun mindeng bisa manggihan yén hiji jalma meuli mesin virtual, dipasang Apache dinya, ngonpigurasi sagalana sacara standar, masang aplikasi PHP, tur handap anjeun tiasa ningali hasilna.
Di dieu beban angkat ka akar sareng ngan ukur 10 RPS. Kami ngantosan 5 menit sareng server nabrak. Memang bener teu sagemblengna dipikawanoh naha anjeunna murag, tapi aya anggapan yén anjeunna ngan saukur boga teuing memori sahingga dieureunkeun ngabales.
Gelombang dumasar
Dina atawa dua taun ka tukang, serangan gelombang geus jadi cukup populér. Ieu disababkeun ku kanyataan yén seueur organisasi ngagaleuh sababaraha hardware pikeun panyalindungan DDoS, anu peryogi sababaraha waktos pikeun ngumpulkeun statistik pikeun ngamimitian nyaring serangan. Hartina, aranjeunna henteu nyaring serangan dina 30-40 detik munggaran, sabab ngumpulkeun data sareng diajar. Sasuai, dina 30-40 detik ieu anjeun tiasa ngaluncurkeun seueur pisan dina situs éta sumber dayana bakal lami-lami dugi ka sadaya pamundut diberesihan.
Dina kasus serangan di handap, aya interval 10 menit, nu satutasna bagian anyar, dirobah tina serangan anjog.
Hartina, pertahanan diajar, dimimitian nyaring, tapi bagian anyar, lengkep beda serangan anjog, sarta pertahanan mimiti diajar deui. Nyatana, nyaring lirén damel, panyalindungan janten teu efektif, sareng situsna henteu sayogi.
Serangan gelombang dicirikeun ku nilai anu luhur pisan di puncak, éta tiasa ngahontal saratus rébu atanapi sajuta pamundut per detik, dina kasus L7. Upami urang nyarioskeun L3&4, maka tiasa aya ratusan gigabit lalu lintas, atanapi, sasuai, ratusan mpps, upami anjeun ngitung dina pakét.
Masalah sareng serangan sapertos kitu nyaéta sinkronisasi. Seranganna asalna tina botnet sareng peryogi tingkat sinkronisasi anu luhur pikeun nyiptakeun spike hiji-waktos anu ageung pisan. Jeung koordinasi ieu teu salawasna jalan kaluar: kadang kaluaran mangrupa sababaraha jenis puncak parabolic, nu Sigana rada pathetic.
Henteu HTTP nyalira
Salian HTTP di L7, urang resep ngamangpaatkeun protokol séjén. Sakumaha aturan, situs wéb biasa, khususna hosting biasa, ngagaduhan protokol surat sareng MySQL nempel. Protokol surat anu poko keur beban kirang ti database, Tapi maranéhna ogé bisa dimuat rada éfisién tur mungkas nepi ka CPU overloaded on server.
Kami cukup suksés ngagunakeun kerentanan SSH 2016. Ayeuna kerentanan ieu parantos dibenerkeun pikeun ampir sadayana, tapi ieu sanés hartosna yén beban henteu tiasa dikintunkeun ka SSH. Tiasa. Aya ngan ukur beban otorisasi anu ageung, SSH ngahakan ampir sadayana CPU dina server, teras halaman wéb runtuh tina hiji atanapi dua pamundut per detik. Sasuai, ieu hiji atawa dua requests dumasar kana log teu bisa dibédakeun tina beban sah.
Seueur sambungan anu kami buka dina server ogé tetep relevan. Saméméhna, Apache kaliru ieu, ayeuna nginx sabenerna kaliru ngeunaan ieu, sabab mindeng ngonpigurasi sacara standar. Jumlah sambungan anu nginx tiasa tetep kabuka terbatas, janten urang muka jumlah sambungan ieu, nginx henteu nampi sambungan énggal, sareng akibatna situsna henteu jalan.
Kluster uji kami ngagaduhan CPU anu cekap pikeun nyerang sasalaman SSL. Sacara prinsip, sakumaha prakték nempokeun, botnets kadang resep ngalakukeun ieu teuing. Di hiji sisi, éta jelas yén anjeun moal bisa ngalakukeun tanpa SSL, sabab hasil Google, ranking, kaamanan. Di sisi anu sanésna, SSL hanjakalna gaduh masalah CPU.
L3&4
Lamun urang ngobrol ngeunaan serangan dina tingkat L3 & 4, urang biasana ngobrol ngeunaan serangan dina tingkat link. Beban sapertos ampir sok dibédakeun tina hiji sah, iwal éta serangan SYN-ngabahekeun. Masalah sareng serangan SYN-banjir pikeun alat kaamanan nyaeta volume badag maranéhanana. Nilai maksimum L3 & 4 éta 1,5-2 Tbit / s. Lalu lintas jenis ieu hésé pisan pikeun diolah bahkan pikeun perusahaan ageung, kalebet Oracle sareng Google.
SYN sareng SYN-ACK mangrupikeun pakét anu dianggo nalika ngadamel sambungan. Ku alatan éta, SYN-ngabahekeun hese ngabedakeun tina beban sah: teu jelas naha ieu SYN datang ka ngadegkeun sambungan, atawa bagian tina ngabahekeun.
UDP-ngabahekeun
Biasana, panyerang teu gaduh kamampuan anu urang gaduh, janten amplifikasi tiasa dianggo pikeun ngatur serangan. Nyaéta, panyerang nyeken Internét sareng mendakan server anu rentan atanapi henteu leres dikonpigurasikeun, contona, pikeun ngaréspon hiji pakét SYN, ngabales ku tilu SYN-ACK. Ku spoofing alamat sumber tina alamat tina server target, kasebut nyaéta dimungkinkeun pikeun ngaronjatkeun kakuatan ku, sebutkeun, tilu kali ku pakét tunggal jeung alihan lalulintas keur korban.
Masalah sareng amplifikasi nyaeta aranjeunna hese dideteksi. Conto panganyarna kalebet kasus sensasional tina memcached anu rentan. Tambih Deui, ayeuna aya seueur alat IoT, kaméra IP, anu ogé seueur dikonpigurasi sacara standar, sareng sacara standar aranjeunna dikonpigurasikeun sacara leres, naha éta panyerang sering nyerang serangan tina alat sapertos kitu.
Hésé SYN-ngabahekeun
SYN-ngabahekeun meureun tipe paling narik tina serangan ti sudut pandang pamekar. Masalahna nyaéta pangurus sistem sering nganggo pameungpeuk IP pikeun panyalindungan. Leuwih ti éta, meungpeuk IP mangaruhan teu ukur administrator sistem anu meta ngagunakeun Aksara, tapi ogé, hanjakalna, sababaraha sistem kaamanan nu dibeuli keur loba duit.
Metoda ieu tiasa janten musibah, sabab upami panyerang ngagentos alamat IP, perusahaan bakal ngablokir subnet sorangan. Nalika firewall meungpeuk klaster sorangan, kaluaran bakal gagal interaksi éksternal sarta sumberdaya bakal gagal.
Leuwih ti éta, teu hese meungpeuk jaringan sorangan. Upami kantor klien ngagaduhan jaringan Wi-Fi, atanapi upami kinerja sumberdaya diukur nganggo sababaraha sistem ngawaskeun, maka urang nyandak alamat IP tina sistem ngawaskeun ieu atanapi Wi-Fi kantor klien sareng nganggo salaku sumber. Tungtungna, sumberna sigana sayogi, tapi alamat IP target diblokir. Ku kituna, jaringan Wi-Fi tina konferensi HighLoad, dimana produk anyar parusahaan keur dibere, bisa jadi diblokir, sarta ieu merlukeun biaya bisnis jeung ékonomi tangtu.
Salila nguji, urang teu bisa make amplifikasi ngaliwatan memcached kalawan sagala sumberdaya éksternal, sabab aya pasatujuan pikeun ngirim lalulintas ngan ka alamat IP diwenangkeun. Sasuai, kami nganggo amplifikasi ngaliwatan SYN na SYN-ACK, nalika sistem responds ngirim hiji SYN dua atawa tilu SYN-ACK, sarta dina kaluaran serangan dikali dua atawa tilu kali.
instrumen
Salah sahiji alat utama anu kami anggo pikeun beban kerja L7 nyaéta Yandex-tank. Khususna, phantom dianggo salaku bedil, sareng aya sababaraha skrip pikeun ngahasilkeun kartrid sareng nganalisa hasilna.
Tcpdump dipaké pikeun nganalisis lalulintas jaringan, sarta Nmap dipaké pikeun nganalisis server. Pikeun nyiptakeun beban dina tingkat L3&4, OpenSSL sareng sakedik sihir urang sorangan sareng perpustakaan DPDK dianggo. DPDK mangrupikeun perpustakaan ti Intel anu ngamungkinkeun anjeun damel sareng antarmuka jaringan ngalangkungan tumpukan Linux, ku kituna ningkatkeun efisiensi. Alami, urang ngagunakeun DPDK teu ukur dina tingkat L3 & 4, tapi ogé dina tingkat L7, sabab ngamungkinkeun urang pikeun nyieun aliran beban pisan tinggi, dina rentang sababaraha juta requests per detik ti hiji mesin.
Urang ogé ngagunakeun generator lalulintas tangtu jeung alat husus nu urang nulis pikeun tés husus. Upami urang nginget kerentanan dina SSH, maka set di luhur teu tiasa dieksploitasi. Upami urang nyerang protokol surat, urang nyandak utilitas surat atanapi ngan saukur nyerat naskah dina éta.
papanggihan
Salaku kacindekan kuring hoyong nyarios:
- Salian tés beban klasik, perlu pikeun ngalaksanakeun tés setrés. Kami ngagaduhan conto nyata dimana subkontraktor pasangan ngan ukur ngalaksanakeun tés beban. Éta nunjukkeun yén sumberdaya tiasa nahan beban normal. Tapi lajeng hiji beban abnormal mucunghul, datang loka mimiti ngagunakeun sumberdaya nu rada béda, sarta salaku hasilna subcontractor nu iklas turun. Ku kituna, éta patut néangan vulnerabilities sanajan anjeun geus ditangtayungan tina serangan DDoS.
- Perlu ngasingkeun sababaraha bagian sistem ti anu sanés. Upami Anjeun gaduh pilarian a, Anjeun kudu mindahkeun ka mesin misah, nyaeta, moal malah ka Docker. Kusabab lamun pilarian atawa otorisasina gagal, sahenteuna hal baris nuluykeun jalan. Dina kasus toko online, pangguna bakal teras-terasan milarian produk dina katalog, angkat tina agrégator, mésér upami aranjeunna parantos otorisasi, atanapi otorisasi via OAuth2.
- Ulah ngalalaworakeun sagala jinis jasa awan.
- Anggo CDN henteu ngan ukur pikeun ngaoptimalkeun telat jaringan, tapi ogé minangka sarana panyalindungan ngalawan serangan dina kacapean saluran sareng ngan saukur banjir kana lalu lintas statik.
- Perlu ngagunakeun jasa panyalindungan khusus. Anjeun teu tiasa ngajaga diri tina serangan L3&4 dina tingkat saluran, sabab paling dipikaresep anjeun henteu gaduh saluran anu cekap. Anjeun oge saperti teu mirip ngalawan serangan L7, sabab bisa jadi kacida gedéna. Tambih Deui, milarian serangan leutik masih hak prerogative tina jasa husus, algoritma husus.
- Update rutin. Ieu lumaku teu ukur keur kernel, tapi ogé pikeun daemon SSH, utamana lamun anjeun boga aranjeunna kabuka ka luar. Sacara prinsip, sadayana kedah diropéa, sabab anjeun henteu mungkin tiasa ngalacak kerentanan anu tangtu ku anjeun nyalira.
sumber: www.habr.com