Variti ngembangake proteksi marang bot lan serangan DDoS, lan uga nganakake tes stres lan beban. Ing konferensi HighLoad ++ 2018 kita ngomong babagan carane ngamanake sumber daya saka macem-macem jinis serangan. Singkat: isolasi bagean sistem, gunakake layanan awan lan CDN, lan nganyari kanthi rutin. Nanging sampeyan isih ora bisa nangani proteksi tanpa perusahaan khusus :)
Sadurunge maca teks, sampeyan bisa maca abstrak singkat .
Lan yen sampeyan ora seneng maca utawa mung pengin nonton video, rekaman laporan kita ana ing ngisor spoiler.
Rekaman video saka laporan
Akeh perusahaan sing wis ngerti carane nindakake tes beban, nanging ora kabeh nindakake tes stres. Sawetara pelanggan ngira yen situs kasebut ora bisa dikalahake amarga duwe sistem muatan dhuwur, lan nglindhungi kanthi apik saka serangan. Kita nuduhake yen iki ora sakabehe bener.
Mesthi, sadurunge nganakake tes, kita entuk ijin saka pelanggan, ditandatangani lan dicap, lan kanthi bantuan serangan DDoS ora bisa ditindakake sapa wae. Pengujian ditindakake ing wektu sing dipilih dening pelanggan, nalika lalu lintas menyang sumber daya minimal, lan masalah akses ora bakal mengaruhi klien. Kajaba iku, amarga ana sing bisa salah sajrone proses tes, kita kudu terus kontak karo pelanggan. Iki ngidini sampeyan ora mung nglaporake asil sing diraih, nanging uga ngganti soko sajrone tes. Sawise rampung tes, kita mesthi nggawe laporan sing nuduhake kekurangan sing dideteksi lan menehi rekomendasi kanggo ngilangi kelemahane situs kasebut.
Carane kita makarya
Nalika nguji, kita niru botnet. Amarga kita kerja karo klien sing ora ana ing jaringan kita, kanggo mesthekake yen tes ora rampung ing menit pisanan amarga watesan utawa proteksi sing dipicu, kita nyuplai muatan ora saka siji IP, nanging saka subnet kita dhewe. Kajaba iku, kanggo nggawe beban sing signifikan, kita duwe server tes sing cukup kuat.
Postulate
Kakehan ora ateges apik
Kurang beban sing bisa nggawa sumber kanggo gagal, luwih apik. Yen sampeyan bisa nggawe situs mandheg ing siji panjalukan saben detik, utawa malah siji panjalukan saben menit, iku apik. Amarga miturut hukum meanness, pangguna utawa panyerang bakal tiba ing kerentanan tartamtu iki.
Gagal parsial luwih apik tinimbang gagal lengkap
Kita tansah menehi saran supaya sistem heterogen. Kajaba iku, kudu dipisahake ing tingkat fisik, lan ora mung kanthi wadah. Ing kasus pamisahan fisik, sanajan ana sing gagal ing situs kasebut, ana kemungkinan sing ora bakal mandheg rampung, lan pangguna bakal entuk akses menyang paling ora bagean saka fungsi kasebut.
Arsitektur sing apik minangka dhasar kanggo kelestarian
Toleransi kesalahan sumber daya lan kemampuan kanggo nahan serangan lan beban kudu dilebokake ing tahap desain, nyatane, ing tahap nggambar flowchart pisanan ing notepad. Amarga yen kesalahan fatal creep ing, iku bisa kanggo mbenerake ing mangsa, nanging angel banget.
Ora mung kode kudu apik, nanging uga config
Akeh wong sing nganggep manawa tim pangembangan sing apik minangka jaminan layanan sing tahan kesalahan. Tim pangembangan sing apik pancen perlu, nanging uga kudu ana operasi sing apik, DevOps sing apik. Yaiku, kita butuh spesialis sing bakal ngatur Linux lan jaringan kanthi bener, nulis konfigurasi kanthi bener ing nginx, nyetel watesan, lsp. Yen ora, sumber daya bakal bisa digunakake mung ing testing, lan ing sawetara titik kabeh bakal break ing produksi.
Bedane antarane tes beban lan stres
Pengujian beban ngidini sampeyan ngenali watesan fungsi sistem. Pengujian stres ditujokake kanggo nemokake kelemahane sistem lan digunakake kanggo ngrusak sistem iki lan ndeleng kepiye tumindak ing proses kegagalan bagean tartamtu. Ing kasus iki, sifat beban biasane ora dingerteni pelanggan sadurunge tes stres diwiwiti.
Fitur khas saka serangan L7
Biasane kita mbagi jinis beban dadi beban ing tingkat L7 lan L3&4. L7 minangka beban ing tingkat aplikasi, paling asring tegese mung HTTP, nanging tegese beban apa wae ing tingkat protokol TCP.
Serangan L7 duwe fitur khas tartamtu. Kaping pisanan, dheweke langsung menyang aplikasi kasebut, yaiku, ora mungkin bakal dibayangke liwat sarana jaringan. Serangan kasebut nggunakake logika, lan amarga iki, nggunakake CPU, memori, disk, database lan sumber daya liyane kanthi efisien lan kanthi lalu lintas sithik.
HTTP Banjir
Ing cilik saka serangan sembarang, mbukak luwih gampang kanggo nggawe saka kanggo nangani, lan ing cilik saka L7 iki uga bener. Ora mesthi gampang kanggo mbedakake lalu lintas serangan saka lalu lintas sing sah, lan paling asring iki bisa ditindakake kanthi frekuensi, nanging yen kabeh wis direncanakake kanthi bener, mula ora bisa dingerteni saka log ing ngendi serangan kasebut lan ing ngendi panjaluk sing sah.
Minangka conto pisanan, nimbang serangan HTTP Banjir. Grafik kasebut nuduhake manawa serangan kasebut biasane kuat banget; ing conto ing ngisor iki, jumlah panyuwunan puncak ngluwihi 600 ewu saben menit.
HTTP Flood minangka cara paling gampang kanggo nggawe beban. Biasane, butuh sawetara alat uji beban, kayata ApacheBench, lan nyetel panjaluk lan target. Kanthi pendekatan sing prasaja, ana kemungkinan gedhe kanggo mbukak cache server, nanging gampang dilewati. Contone, nambah strings acak kanggo request, kang bakal meksa server kanggo terus-terusan ngawula kaca seger.
Uga, aja lali babagan pangguna-agen ing proses nggawe beban. Akeh pangguna-agen alat tes populer disaring dening administrator sistem, lan ing kasus iki, beban kasebut bisa uga ora tekan mburi. Sampeyan bisa nambah asil kanthi nyata kanthi nglebokake header sing luwih bener saka browser menyang panyuwunan.
Minangka prasaja minangka serangan HTTP Banjir, padha uga duwe drawbacks. Kaping pisanan, akeh daya dibutuhake kanggo nggawe beban. Kapindho, serangan kasebut gampang banget dideteksi, utamane yen asale saka siji alamat. Akibaté, panjalukan langsung wiwit disaring dening administrator sistem utawa malah ing tingkat panyedhiya.
Apa sing kudu digoleki
Kanggo nyuda jumlah panjalukan saben detik tanpa kelangan efisiensi, sampeyan kudu nuduhake imajinasi sethithik lan njelajah situs kasebut. Mangkono, sampeyan bisa mbukak ora mung saluran utawa server, nanging uga bagean individu saka aplikasi, contone, database utawa sistem file. Sampeyan uga bisa nggoleki panggonan ing situs sing nggawe petungan gedhe: kalkulator, kaca pilihan produk, lsp. Pungkasan, asring kedadeyan situs kasebut duwe sawetara jinis skrip PHP sing ngasilake kaca pirang-pirang atus ewu baris. Skrip kasebut uga ngemot server kanthi signifikan lan bisa dadi target serangan.
Golek endi
Nalika kita mindhai sumber sadurunge testing, kita pisanan katon, mesthi, ing situs dhewe. We are looking for kabeh jinis kolom input, file abot - ing umum, kabeh sing bisa nggawe masalah kanggo sumber lan alon mudhun operasi. Piranti pangembangan Banal ing bantuan Google Chrome lan Firefox ing kene, nuduhake wektu nanggepi kaca.
Kita uga mindai subdomain. Contone, ana toko online tartamtu, abc.com, lan duwe subdomain admin.abc.com. Paling kamungkinan, iki minangka panel admin kanthi wewenang, nanging yen sampeyan mbukak, bisa nggawe masalah kanggo sumber utama.
Situs kasebut bisa uga duwe subdomain api.abc.com. Paling kamungkinan, iki minangka sumber daya kanggo aplikasi seluler. Aplikasi kasebut bisa ditemokake ing App Store utawa Google Play, nginstal jalur akses khusus, mbedah API lan ndhaptar akun tes. Masalahe yaiku wong asring mikir yen apa wae sing dilindhungi dening wewenang iku kebal marang serangan penolakan layanan. Mesthine, wewenang minangka CAPTCHA sing paling apik, nanging ora. Gampang nggawe 10-20 akun test, nanging kanthi nggawe, kita entuk akses menyang fungsionalitas sing rumit lan ora jelas.
Alamiah, kita ndeleng sajarah, ing robots.txt lan WebArchive, ViewDNS, lan goleki versi lawas saka sumber. Kadhangkala kedadeyan sing pangembang wis diluncurake, ucapake, mail2.yandex.net, nanging versi lawas, mail.yandex.net, tetep. Mail.yandex.net iki ora didhukung maneh, sumber daya pembangunan ora dialokasikan, nanging terus nganggo basis data. Dadi, nggunakake versi lawas, sampeyan bisa nggunakake sumber daya backend lan kabeh sing ana ing mburi tata letak. Mesthine, iki ora mesthi kedadeyan, nanging kita isih kerep nemoni iki.
Alami, kita nganalisa kabeh parameter panyuwunan lan struktur cookie. Sampeyan bisa, umpamane, mbuwang sawetara nilai menyang array JSON ing cookie, nggawe akeh nesting lan nggawe sumber daya bisa digunakake kanggo wektu sing ora wajar.
Nggoleki beban
Babagan pisanan sing dipikirake nalika nliti situs yaiku mbukak database, amarga meh kabeh wong duwe telusuran, lan kanggo meh kabeh wong, sayangé, ora dilindhungi. Kanggo sawetara alasan, pangembang ora menehi perhatian sing cukup kanggo nggoleki. Nanging ana siji rekomendasi ing kene - sampeyan ora kudu njaluk panjaluk saka jinis sing padha, amarga sampeyan bisa nemokake caching, kayadene banjir HTTP.
Nggawe pitakon acak menyang database uga ora tansah efektif. Luwih becik nggawe dhaptar tembung kunci sing cocog karo telusuran. Yen kita bali menyang conto toko online: ayo ngomong situs adol ban mobil lan ngidini sampeyan nyetel radius ban, jinis mobil lan paramèter liyane. Dadi, kombinasi tembung sing cocog bakal meksa database bisa digunakake ing kahanan sing luwih rumit.
Kajaba iku, iku worth nggunakake pagination: iku luwih angel kanggo nggoleki kanggo bali kaca penultimate saka asil panelusuran saka pisanan. Yaiku, kanthi bantuan pagination sampeyan bisa rada macem-macem beban.
Conto ing ngisor iki nuduhake beban telusuran. Bisa dideleng yen saka detik pisanan tes kanthi kacepetan sepuluh panjaluk per detik, situs kasebut mudhun lan ora nanggapi.
Yen ora ana telusuran?
Yen ora ana telusuran, iki ora ateges situs kasebut ora ngemot kolom input liyane sing rentan. Lapangan iki bisa dadi wewenang. Saiki, pangembang seneng nggawe hash rumit kanggo nglindhungi database login saka serangan tabel pelangi. Iki apik, nanging hash kasebut nggunakake akeh sumber daya CPU. A aliran gedhe saka wewenang palsu ndadékaké kanggo Gagal prosesor, lan minangka asil, situs mandheg digunakake.
Ngarsane ing situs kabeh jinis formulir kanggo komentar lan umpan balik minangka alesan kanggo ngirim teks sing gedhe banget ing kana utawa mung nggawe banjir gedhe. Kadhangkala situs nampa file sing dilampirake, kalebu ing format gzip. Ing kasus iki, kita njupuk file 1TB, compress menyang sawetara bita utawa kilobyte nggunakake gzip lan ngirim menyang situs. Banjur dibukak lan efek sing menarik banget.
Gunakake API
Aku kaya kanggo mbayar manungsa waé sethitik kanggo layanan populer kayata Rest API. Ngamanake API Istirahat luwih angel tinimbang situs web biasa. Malah cara proteksi sing ora pati penting marang kekuwatan sandi lan kegiatan sing ora sah liyane ora bisa digunakake kanggo Rest API.
The Rest API gampang banget kanggo break amarga ngakses database langsung. Ing wektu sing padha, kegagalan layanan kasebut nyebabake akibat sing cukup serius kanggo bisnis. Kasunyatane yaiku API Rest biasane digunakake ora mung kanggo situs web utama, nanging uga kanggo aplikasi seluler lan sawetara sumber daya bisnis internal. Lan yen kabeh iki tiba, mula efek kasebut luwih kuat tinimbang kasus kegagalan situs web sing prasaja.
Loading konten abot
Yen kita ditawani nyoba sawetara aplikasi siji-halaman biasa, kaca kebangkrutan, utawa situs web kertu bisnis sing ora nduweni fungsi sing rumit, kita nggoleki konten sing abot. Contone, gambar gedhe sing dikirim server, file binar, dokumentasi pdf - kita nyoba ndownload kabeh iki. Tes kasebut ngemot sistem file kanthi apik lan macet saluran, mula efektif. Yaiku, sanajan sampeyan ora nyelehake server, ndownload file gedhe kanthi kacepetan sing sithik, sampeyan mung bakal macet saluran server target lan banjur penolakan layanan bakal kedadeyan.
Conto tes kasebut nuduhake yen ing kacepetan 30 RPS situs kasebut mandheg nanggapi utawa ngasilake kesalahan server kaping 500.
Aja lali babagan nyetel server. Sampeyan kerep bisa nemokake manawa ana wong sing tuku mesin virtual, nginstal Apache ing kana, ngatur kabeh kanthi standar, nginstal aplikasi PHP, lan ing ngisor iki sampeyan bisa ndeleng asile.
Kene mbukak menyang ROOT lan gunggungipun mung 10 RPS. We ngenteni 5 menit lan server tabrakan. Pancen ora dingerteni sebabe dheweke tiba, nanging ana anggepan yen dheweke mung duwe memori sing akeh lan mula mandheg nanggapi.
adhedhasar gelombang
Ing taun utawa rong taun kepungkur, serangan gelombang wis dadi populer. Iki amarga kasunyatan manawa akeh organisasi tuku piranti keras tartamtu kanggo proteksi DDoS, sing mbutuhake wektu tartamtu kanggo nglumpukake statistik kanggo miwiti nyaring serangan kasebut. Yaiku, dheweke ora nyaring serangan ing 30-40 detik pisanan, amarga padha nglumpukake data lan sinau. Mulane, ing 30-40 detik iki sampeyan bisa mbukak akeh ing situs sing sumber daya bakal ngapusi kanggo dangu nganti kabeh panjalukan wis dibusak.
Ing kasus serangan ing ngisor iki, ana interval 10 menit, sawise sing anyar, bagean serangan sing diowahi teka.
Yaiku, pertahanan sinau, wiwit nyaring, nanging bagean serangan anyar sing beda-beda teka, lan pertahanan wiwit sinau maneh. Nyatane, nyaring mandheg, proteksi dadi ora efektif, lan situs kasebut ora kasedhiya.
Serangan gelombang ditondoi kanthi nilai sing dhuwur banget ing puncak, bisa tekan satus ewu utawa yuta panjalukan per detik, ing kasus L7. Yen kita ngomong babagan L3&4, bisa uga ana atusan gigabit lalu lintas, utawa, kanthi mangkono, atusan mpps, yen sampeyan ngetung ing paket.
Masalah karo serangan kasebut yaiku sinkronisasi. Serangan kasebut asale saka botnet lan mbutuhake sinkronisasi tingkat dhuwur kanggo nggawe lonjakan siji-wektu sing gedhe banget. Lan koordinasi iki ora tansah bisa metu: kadhangkala output sawetara jenis puncak parabolic, kang katon rada pathetic.
Ora mung HTTP
Saliyane HTTP ing L7, kita seneng ngeksploitasi protokol liyane. Minangka aturan, situs web biasa, utamane hosting reguler, duwe protokol email lan MySQL tetep metu. Protokol mail tundhuk beban kurang saka database, nanging uga bisa dimuat cukup irit lan mungkasi munggah karo CPU overloaded ing server.
Kita cukup realistis sukses karo kerentanan SSH 2016. Saiki kerentanan iki wis didandani kanggo meh kabeh wong, nanging iki ora ateges beban ora bisa dikirim menyang SSH. Saget. Ana mung akeh wewenang, SSH mangan meh kabeh CPU ing server, banjur situs web ambruk saka siji utawa loro panjalukan saben detik. Patut, siji utawa loro panjalukan iki adhedhasar log ora bisa dibedakake saka beban sing sah.
Akeh sambungan sing dibukak ing server uga tetep relevan. Sadurunge, Apache guilty iki, saiki nginx bener guilty iki, amarga asring diatur minangka standar. Jumlah sambungan sing nginx bisa tetep mbukak diwatesi, mula kita mbukak jumlah sambungan iki, nginx ora nampa sambungan anyar maneh, lan minangka asil situs kasebut ora bisa digunakake.
Kluster uji kita duwe CPU sing cukup kanggo nyerang jabat tangan SSL. Ing asas, minangka laku nuduhake, botnets kadhangkala seneng nindakake iki uga. Ing tangan siji, jelas yen sampeyan ora bisa nindakake tanpa SSL, amarga asil Google, peringkat, keamanan. Ing tangan liyane, SSL sayangé duwe masalah CPU.
L3&4
Nalika kita ngomong babagan serangan ing tingkat L3&4, kita biasane ngomong babagan serangan ing level link. Beban kuwi meh tansah dibedakake saka sah, kajaba iku serangan SYN-banjir. Masalah karo serangan SYN-banjir kanggo piranti keamanan iku volume gedhe. Nilai L3 & 4 maksimal yaiku 1,5-2 Tbit / s. Lalu lintas jenis iki angel banget diproses sanajan kanggo perusahaan gedhe, kalebu Oracle lan Google.
SYN lan SYN-ACK minangka paket sing digunakake nalika nggawe sambungan. Mulane, SYN-banjir angel kanggo mbedakake saka mbukak sah: iku ora cetha apa iki SYN teka kanggo netepake sambungan, utawa bagéan saka banjir.
UDP-banjir
Biasane, panyerang ora duwe kemampuan sing kita duwe, mula amplifikasi bisa digunakake kanggo ngatur serangan. Yaiku, panyerang mindai Internet lan nemokake server sing rawan utawa ora dikonfigurasi kanthi bener, contone, kanggo nanggepi siji paket SYN, nanggapi nganggo telung SYN-ACK. Kanthi spoofing alamat sumber saka alamat server target, iku bisa kanggo nambah daya dening, ngomong, kaping telu karo paket siji lan pangalihan lalu lintas kanggo korban.
Masalah karo amplifikasi yaiku angel dideteksi. Conto paling anyar kalebu kasus sensasional saka memcached sing rentan. Kajaba iku, saiki ana akeh piranti IoT, kamera IP, sing uga biasane dikonfigurasi kanthi standar, lan kanthi standar ora dikonfigurasi kanthi bener, mula para panyerang asring nyerang liwat piranti kasebut.
SYN-banjir angel
SYN-banjir mbokmenawa jinis paling menarik saka serangan saka titik pangembang tampilan. Masalahe yaiku administrator sistem asring nggunakake pamblokiran IP kanggo proteksi. Kajaba iku, pamblokiran IP ora mung mengaruhi administrator sistem sing tumindak nggunakake skrip, nanging uga, sayangé, sawetara sistem keamanan sing dituku kanthi dhuwit akeh.
Cara iki bisa dadi bencana, amarga yen panyerang ngganti alamat IP, perusahaan bakal mblokir subnet dhewe. Nalika Firewall mblokir kluster dhewe, output bakal gagal interaksi eksternal lan sumber daya bakal gagal.
Kajaba iku, ora angel mblokir jaringan sampeyan dhewe. Yen kantor klien duwe jaringan Wi-Fi, utawa yen kinerja sumber daya diukur nggunakake macem-macem sistem ngawasi, banjur njupuk alamat IP sistem pemantauan iki utawa Wi-Fi kantor klien lan digunakake minangka sumber. Ing pungkasan, sumber daya katon kasedhiya, nanging alamat IP target diblokir. Mangkono, jaringan Wi-Fi konferensi HighLoad, ing ngendi produk anyar perusahaan ditampilake, bisa diblokir, lan iki mbutuhake biaya bisnis lan ekonomi tartamtu.
Sajrone testing, kita ora bisa nggunakake amplifikasi liwat memcached karo sembarang sumber eksternal, amarga ana persetujuan kanggo ngirim lalu lintas mung kanggo alamat IP diijini. Patut, kita nggunakake amplifikasi liwat SYN lan SYN-ACK, nalika sistem nanggapi kanggo ngirim siji SYN karo loro utawa telu SYN-ACK, lan ing output serangan wis pingan dening loro utawa telu.
Piranti
Salah sawijining alat utama sing digunakake kanggo beban kerja L7 yaiku Yandex-tank. Utamane, phantom digunakake minangka bedhil, lan ana sawetara skrip kanggo ngasilake cartridges lan kanggo nganalisa asil.
Tcpdump digunakake kanggo nganalisa lalu lintas jaringan, lan Nmap digunakake kanggo nganalisa server. Kanggo nggawe beban ing tingkat L3&4, OpenSSL lan sawetara sihir kita dhewe karo perpustakaan DPDK digunakake. DPDK minangka perpustakaan saka Intel sing ngidini sampeyan nggarap antarmuka jaringan sing ngliwati tumpukan Linux, saéngga nambah efisiensi. Alami, kita nggunakake DPDK ora mung ing tingkat L3 & 4, nanging uga ing tingkat L7, amarga ngidini kita kanggo nggawe aliran mbukak dhuwur banget, ing sawetara yuta panjalukan saben detik saka siji mesin.
Kita uga nggunakake generator lalu lintas tartamtu lan alat khusus sing kita tulis kanggo tes tartamtu. Yen kita ngelingi kerentanan ing SSH, mula set ing ndhuwur ora bisa dimanfaatake. Yen kita nyerang protokol mail, kita njupuk keperluan mail utawa mung nulis skrip ing wong.
temonan
Minangka kesimpulan, aku arep ngomong:
- Saliyane tes beban klasik, perlu kanggo nganakake tes stres. Kita duwe conto nyata ing ngendi subkontraktor mitra mung nindakake tes beban. Iki nuduhake manawa sumber daya bisa tahan beban normal. Nanging banjur ana beban sing ora normal, pengunjung situs wiwit nggunakake sumber daya kanthi beda, lan minangka asil subkontraktor kasebut mudhun. Mangkono, sampeyan kudu nggoleki kerentanan sanajan sampeyan wis dilindhungi saka serangan DDoS.
- Sampeyan perlu kanggo ngisolasi sawetara bagéan saka sistem saka liyane. Yen sampeyan duwe telusuran, sampeyan kudu mindhah menyang mesin sing kapisah, yaiku, ora menyang Docker. Amarga yen telusuran utawa wewenang gagal, paling ora ana sing bakal ditindakake. Ing kasus toko online, pangguna bakal terus nemokake produk ing katalog, pindhah saka aggregator, tuku yen wis sah, utawa menehi wewenang liwat OAuth2.
- Aja nglirwakake kabeh jinis layanan awan.
- Gunakake CDN ora mung kanggo ngoptimalake wektu tundha jaringan, nanging uga minangka sarana pangayoman marang serangan ing saluran kekeselen lan mung banjir menyang lalu lintas statis.
- Sampeyan perlu nggunakake layanan perlindungan khusus. Sampeyan ora bisa nglindhungi dhewe saka serangan L3&4 ing tingkat saluran, amarga sampeyan ora duwe saluran sing cukup. Sampeyan uga ora bisa nglawan serangan L7, amarga bisa dadi gedhe banget. Kajaba iku, telusuran serangan cilik isih dadi prerogatif layanan khusus, algoritma khusus.
- Nganyari kanthi rutin. Iki ditrapake ora mung kanggo kernel, nanging uga kanggo daemon SSH, utamane yen sampeyan mbukak menyang njaba. Prinsip, kabeh kudu dianyari, amarga sampeyan ora bisa nglacak kerentanan tartamtu dhewe.
Source: www.habr.com