Sebelum merilis layanan baru, alangkah baiknya untuk memastikan bahwa ia bekerja sesuai dengan harapan kami dan tersedia terlepas dari berapa banyak pelanggan yang menggunakannya pada saat yang sama.
Dan bagaimana layanan ini akan bereaksi jika serangan DoS terdistribusi diatur terhadapnya? Apakah sumber daya dilindungi dari penyerang potensial?
Untuk menilai risiko yang mungkin terjadi dan meningkatkan keamanan, masuk akal untuk secara mandiri melakukan tindakan yang mensimulasikan serangan DDoS, sementara sumber daya belum diluncurkan untuk penggunaan massal.
Pada artikel ini, kita akan berbicara tentang pengalaman mengatur pengujian beban untuk layanan DNS dan HTTP.
Persiapan
Untuk memprovokasi generasi lalu lintas jaringan dalam jumlah besar pada sumber daya yang dipantau, Anda perlu menggunakan banyak mesin virtual, yang masing-masing akan mengirimkan jumlah maksimum permintaan ke layanan. Jika Anda tidak memiliki pusat data yang kuat, masuk akal untuk sementara menyewa mesin virtual di cloud. Gagasan ini memiliki satu fitur: Anda perlu memastikan bahwa cloud tidak merangkak, mengambil aktivitas Anda untuk tindakan penyerang.
Membandingkan kebijakan berbagai layanan cloud (seseorang dengan kejam melarang akun yang, mungkin, diambil tindakan yang menyebabkan kegagalan sumber daya) terkait pengujian beban menggunakan fungsionalitasnya, kami memutuskan untuk berhenti di Amazon Web Services (AWS). Dokumen mereka menunjukkan bahwa AWS memungkinkan pengujian muatan, tetapi meminta persetujuan dengan mengirim email ke alamat tertentu.
Harmonisasi pengujian stres
Kami mengirim pesan di mana kami secara singkat berbicara tentang niat kami, dan kami mendapatkan formulir yang harus diisi:
Customer ID: Customer Name: Email Address: AWS Account ID load test will be performed from: Does the customer have an NDA? Target Data EC2 Resources: Cloudfront Distribution: API Gateway / Lambda ID: ELB Names: Non-AWS Target: Region (please list all regions in scope for testing): Source Data: IP Addresses: Source Account ID: Regions involved: Testing Parameters: How much traffic do you plan to generate by region during testing? What is your expected peak load from source by region? (ie xx Gbps) What is your expected peak load at destination? (ie xx Gbps) Are you testing traffic outbound from EC2, inbound into EC2, or both? Are you testing traffic outbound (egress) from EC2, inbound (ingress) into EC2, or both: Egress. What is your expected peak load from source by region? (ie xx Gbps) Ingress. What is your expected peak load from source by region? (ie xx Gbps) Start Date: End Date: Finite testing details including timeline of testing: Summary of Test: Testing Timelines by phase including rps, pps, and Gbps: Peak bandwidth for each source IP: Tools Used for each phase of test: Types of testing to be performed for each phase of the request: What criteria/metrics will you monitor to ensure the success of this test? Who is performing the Load Test? (Please provide contact details): Does the tester have an NDA? Testing Security Do you have a way to monitor the data traffic for the duration of the test to verify bandwidth limits do not exceed approved rates? Do you have a way to immediately stop the traffic if we/you discover any issue? 2 Emergency contact names and phone numbers:
Ada beberapa nuansa:
Mereka bertanya kepada kami siapa yang akan kami "tan". Apakah kita punya hak untuk ini? Kami mengatakan bahwa ini adalah sumber daya kami (tampaknya, tidak ada yang memeriksa apakah ini benar) dan bahwa pengujian sepenuhnya konsisten.
Kita perlu menentukan berapa banyak traffic yang akan kita buat di masing-masing daerah. Selama korespondensi, kami menemukan bahwa masing-masing daerah memiliki batas sendiri pada jumlah lalu lintas jaringan. Secara total, mereka diizinkan untuk meminta 645 Gb / s. Kami mempertimbangkan berapa banyak yang dibutuhkan untuk serangan itu, dan kami memilih daerah sedemikian rupa untuk mendapatkan nilai yang diperlukan.
Diperlukan untuk menggambarkan kapan serangan itu akan dilakukan, berapa lama itu akan berlangsung dan bagaimana kekuatannya akan tumbuh. Dalam bentuk bebas, tetapi dalam detail yang cukup kita berbicara tentang rencana kita. Serangan itu dilakukan dengan peningkatan kekuatan secara bertahap, jadi kami mengecat tahap pengujian apa yang akan dilakukan dan kekuatan maksimum apa yang diharapkan dari masing-masing. Tanggal serangan dapat dihilangkan hingga satu hari, dimungkinkan untuk menunjukkan rentang dua hingga tiga minggu.
Dan tanpa gagal, kami melakukan yang terbaik untuk memastikan bahwa kami akan berperilaku baik, dengan cermat memantau kemajuan pengujian dan menghentikannya pada permintaan pertama jika perlu.
Kemungkinan besar, dalam menanggapi formulir yang telah diisi mereka akan meminta klarifikasi, jadi kami berkorespondensi dan menjawab pertanyaan sampai kami mendapat izin untuk menguji.
Dibutuhkan sekitar tiga hari kerja untuk menyelesaikan proses persetujuan jika dijawab segera.
Persiapan infrastruktur
Setelah persetujuan, kami dihadapkan dengan kebutuhan untuk mempersiapkan infrastruktur untuk pengujian. Faktanya adalah bahwa selama pemeriksaan kita perlu segera:
• menyertakan sebuah instance;
• meluncurkan serangan uji;
• mengumpulkan statistik tentang kemajuan;
• hentikan serangan uji coba;
• mengubah alamat IP;
• matikan mesin virtual.
Buat Gambar Instance
Pilih Jenis Instance
Pertama, mari kita membangun gambar AWS yang akan berisi alat dan skrip yang diperlukan untuk manajemen. Langkah pertama adalah memilih contoh yang akan disewa. Kami mempelajari karakteristik berbagai jenis instance: kami melihat harga, jumlah lalu lintas maksimum, daya CPU (yang terakhir penting, karena lalu lintas dibuat oleh kapasitas prosesor setelah semua), kemudian kami menguji kinerja nyata dan jumlah permintaan maksimum. Menurut perkiraan kami, contoh kecil adalah yang paling nyaman untuk pengujian, tetapi di sini semua orang memilih seleranya.
Karakteristik contoh dapat ditemukan di sini . Anda juga dapat memilih dan membandingkan contoh di sini .
Batasi permintaan
Anda harus berpikir terlebih dahulu tentang berapa banyak contoh yang akan berpartisipasi dalam pengujian. Faktanya adalah bahwa Amazon memberikan batasan masing-masing daerah pada jumlah daerah. Jika Anda merasa bahwa Anda akan membutuhkan lebih banyak instance daripada yang tersedia secara default, maka Anda harus meminta peningkatan batas sedini mungkin. Untuk melakukan ini, pergi ke bagian Dukungan , buat panggilan tipe peningkatan batas Layanan. Waktu pemrosesan untuk permintaan bisa berbeda: seseorang menjawab keesokan harinya, memberikan sebanyak entitas seperti yang diminta, seseorang mengatakan bahwa ia tidak akan membiarkan lebih dari N instance dijalankan. Ada daerah yang menanggapi permintaan selama sekitar satu bulan.
Penyesuaian kinerja
Selanjutnya, Anda perlu membuat gambar instan yang akan diluncurkan selama pengujian. Untuk melakukan ini, kita menghidupkan instance dari jenis yang dipilih, membuat semua pengaturan di atasnya, lalu menyimpan apa yang terjadi sebagai gambar (dalam menu Tindakan, di mana Anda dapat mengaktifkan instance, serta fungsi untuk membuat Gambar Buat Gambar).
Kita perlu mendapatkan lalu lintas keluar maksimum dari setiap instance, jadi pertama-tama kita mengoptimalkan pengaturan jaringan dan memori untuk tugas kita pada instance.
Untuk melakukan ini, buat pengaturan di file /etc/sysctl.conf :
• Tingkatkan kisaran port lokal dan kurangi waktu yang dihabiskan oleh soket dalam status FIN_WAIT:
net.ipv4.ip_local_port_range = 1024-65535 ( : 32768-61000) net.ipv4.tcp_fin_timeout = 10 ( : 60)
Rentang port lokal menentukan jumlah maksimum soket keluar yang dapat dibuat oleh host dari IP tertentu.
Dengan pengaturan default (61.000–32.768), 28.233 soket diperoleh. Dengan pengaturan baru - 64 500.
Fin_timeout menentukan waktu minimum soket yang keluar bisa dalam status FIN_WAIT.
Jika nilai standar ditentukan, sistem dapat menyediakan tidak lebih dari (61.000–32.768) / 60 = 470 soket per detik.
Dengan meningkatkan port_range dan mengurangi fin_timeout, kita dapat memengaruhi kemampuan sistem untuk menghasilkan lebih banyak koneksi keluar.
• Mari kita gunakan kembali soket dalam keadaan TIME_WAIT saat yang gratis berakhir:
net.ipv4.tcp_tw_reuse = 1
Mengatur opsi di atas (yang dinonaktifkan secara default) membantu meminimalkan hilangnya "idle" koneksi yang sudah terpenuhi.
Sangat detail tentang TIME_WAIT dijelaskan dalam artikel ini.
• Aktifkan opsi tcp_timestamps agar opsi tcp_tw_reuse di atas berfungsi:
net.ipv4.tcp_timestamps = 1 – `tcp_timestamps` tcp_tw_reuse
• Opsi lain:
net.ipv4.tcp_max_tw_buckets = 720000 – TIME_WAIT net.ipv4.tcp_keepalive_time = 600 – - keepalive- net.ipv4.tcp_keepalive_probes = 3 – keepalive- net.ipv4.tcp_keepalive_intvl = 10 – keepalive- net.ipv4.tcp_window_scaling = 1 – TCP- net.ipv4.tcp_mem = 8192 131072 196304 – TCP- net.ipv4.udp_mem = 8192 131072 196304 – udp- net.ipv4.tcp_slow_start_after_idle=0 – Slow-Start Restart net.core.wmem_default = 31457280 – net.core.wmem_max = 33554432 – net.core.somaxconn = 65535 – net.core.netdev_max_backlog = 65535 – vm.swappiness = 30 – vm.dirty_ratio = 50 – 50 % vm.pagecache = 90 –
Uji skrip serangan
1. Serangan DNS
Salah satu tugas utama pengujian adalah untuk mengevaluasi kinerja server DNS. Yaitu, server DNS dapat menjadi penghambat toleransi kesalahan suatu situs, karena meskipun layanan paling stabil tidak tersedia jika ada masalah dengan DNS. Untuk membuat beban pada server DNS, kami akan menghasilkan banyak permintaan DNS yang berbeda. Permintaan harus valid dan membutuhkan respons terbesar dan terlama dari server DNS.
Utilitas DNSPerf cocok untuk menghasilkan lalu lintas tersebut.
DNSPerf adalah alat pengujian kinerja DNS sederhana, fleksibel, dan gratis. Ini terutama dirancang untuk server DNS otoritatif, tetapi juga dapat digunakan untuk mengukur kinerja server caching.
Dalam kasus kami, server DNS otoritatif dimuat yang melayani satu zona - example.com.
Untuk DNSPerf, pertama-tama kami menyiapkan file dengan permintaan dns_queries.txt (terutama APA SAJA untuk meningkatkan waktu dan ukuran respons dari server DNS):
#dns_queries.txt example.com ANY www.example.com ANY test.example.com ANY static.example.com ANY example.com www.example.com test.example.com MX
Contoh menjalankan utilitas:
dnsperf -s TARGET_IP -d dns_queries.txt -c 100 -n 100 -s = IP- -d = . – stdin -c = . -n = «» .
2. Menyerang ICMP
Tahap pengujian berikutnya adalah menilai resistansi terhadap sejumlah besar lalu lintas ICMP. Karena, karena alasan teknis, server sering harus dapat menanggapi permintaan ping, ada kemungkinan serangan DDoS menggunakan permintaan ping. Selain menentukan pengaturan yang mengecualikan kemungkinan ping-to-death , Anda perlu memastikan bahwa server tahan terhadap beban ICMP puncak. Untuk membuat beban seperti itu, lebih baik menggunakan utilitas hping3 yang terkenal, yang memungkinkan Anda untuk menyesuaikan jumlah permintaan, interval antar pengiriman, serta ukuran paket.
Contoh menjalankan utilitas:
hping3 -i u1000 -d 1500 -c 100000 -1 TARGET_IP -i u100 = (uX for X microseconds) -d 1500 = -c 1000000 = -1 = ICMP
3. Serangan HTTP
Sekarang kami memeriksa ketahanan terhadap stres fungsi utama dari layanan - memproses lalu lintas HTTP (S). Salah satu alat yang paling fleksibel dan termudah untuk menghasilkan lalu lintas HTTP adalah pengepungan . Siege adalah utilitas multi-utas sumber terbuka yang dirancang untuk menguji kinerja sumber daya web.
Seperti DNSPerf, pengepungan memungkinkan Anda memuat server dengan permintaan dari sejumlah pengguna virtual (emulasi pengguna dilakukan menggunakan port terpisah), serta menggunakan serangkaian permintaan yang telah ditentukan. Ini sangat mudah, karena Anda dapat memasukkan pertanyaan paling banyak sumber daya dalam pengujian.
Contoh menjalankan utilitas:
siege -b -c 100 -f test_urls.txt -b = ( benchmark) -c = . -f =
Format konten test_urls.txt :
http://example.com/site/login POST login=username&password=test http://example.com/site/client POST useragent=Mozilla&version=123&date=24May http://example.com/site/order POST user=username&company=ooo&phone=812345678
Seperti yang Anda lihat, tes dilakukan menggunakan permintaan POST terutama yang membutuhkan pemrosesan di sisi server dan menempati jumlah sumber daya terbesar dibandingkan dengan jenis permintaan lainnya.
Tidak ada opsi yang menggunakan spoofing IP, karena Amazon tidak mengizinkan ini. Apa pun src_IP yang ditentukan dalam paket, itu akan diubah ke yang benar saat keluar dari instance.
Semua permintaan yang dihasilkan harus sah - tidak ada gelombang lalu lintas keluar yang tidak dijawab - karena kebijakan DDoS Amazon cukup ketat. Bahkan stress test yang terkoordinasi membutuhkan waktu minimal beberapa hari untuk berkomunikasi dengan dukungan teknis, dan pada tindakan "jahat" pertama kami mendapatkan larangan pelabuhan dari mana lalu lintas keluar, dan persyaratan untuk segera menjelaskan.
Skrip untuk meluncurkan serangan
Untuk manajemen pengujian jarak jauh, kami akan menyiapkan skrip bash (dns.sh, ping.sh, http.sh) yang meluncurkan jenis serangan yang diinginkan, dan file dengan muatan (test_urls.txt, valid_dns_queries.txt).
Saat kami mengunggah semua ini ke gambar AWS (dari mana semua instance akan dibuat), setiap pengujian dapat dijalankan dari jarak jauh menggunakan perintah dari format berikut:
ssh instance-amazon 'sudo <stress-script>.sh start <params> &>>stress.log &'
Script dari tipe yang diperlukan ditentukan sebagai stress-script.sh, dan params adalah parameter yang sesuai. Dalam file stress.log, kami akan melacak output dari utilitas yang berjalan. Untuk kenyamanan, kami akan menggunakan log yang berbeda untuk utilitas yang berbeda: dns.log, ping.log, http.log.
Contoh skrip dns.sh :
Seperti dapat dilihat dari kode, skrip dapat dimulai dan dihentikan, serta memeriksa statusnya (berjalan / tidak berjalan).
Skrip untuk tes ICMP dan HTTP dibuat dengan cara yang sama, mulai hping3 dan pengepungan, masing-masing, dengan parameter string melewati argumen.
Contoh perintah:
ssh instance-amazon 'sudo dns.sh start -s TARGET_IP -d valid_dns_queries.txt -c 1 -n 100 &>>dns.log &' ssh instance-amazon 'sudo ping.sh start -i u1000 -d 1500 -c 100000 -1 TARGET_IP &>>ping.log &' ssh instance-amazon 'sudo http.sh start -b -c 100 -f test_urls.txt &>> http.log &'
Skrip pemantauan
Untuk mengevaluasi lalu lintas keluar dan keadaan infrastruktur pengujian, kami membutuhkan alat pemantauan. Untuk alasan kesederhanaan dan penghematan sumber daya, kami menggunakan iptables. Untuk melakukan ini, kami akan menulis skrip yang menghitung jumlah MB yang dikirim, dan meletakkannya di gambar AWS:
#iptables.sh sudo iptables -N TRAFFIC_OUT sudo iptables -A TRAFFIC_OUT -p tcp sudo iptables -A TRAFFIC_OUT -p udp sudo iptables -A TRAFFIC_OUT -p icmp sudo iptables -A OUTPUT -j TRAFFIC_OUT sudo iptables-save
Script menciptakan rantai TRAFFIC_OUT baru dan menambahkan filter untuk itu untuk protokol yang diperlukan: tcp, udp, icmp.
Penerusan paket ke TRAFFIC_OUT ditambahkan ke rantai OUTPUT.
Jumlah data yang ditransfer dapat ditemukan oleh perintah:
# iptables -L TRAFFIC_OUT -v -n -x | tail -n 3 | awk '{print $2/1024/1024,"Mb\t\t\t",$3}' : 2.2 Mb tcp 4.4 Mb udp 3.2 Mb icmp
Instal skrip sebagai layanan. Untuk melakukan ini, buat file monitoring.service dan pindahkan ke /etc/systemd/system image kita:
# /etc/systemd/system/monitoring.service [Unit] After=network.target [Service] ExecStart=/usr/local/bin/monitoring.sh [Install] WantedBy=default.target
Sekarang Anda dapat menambahkan layanan ke startup:
systemctl enable monitoring.service systemctl start monitoring.service
Manajemen instance
Sekarang mari kita berurusan dengan manajemen instance jarak jauh (seotomatis mungkin).
Untuk tujuan ini, Anda dapat menggunakan mekanisme AWS CLI - manajemen konsol.
Buat Kunci Rahasia ( Kunci akses (ID kunci akses dan kunci akses rahasia)) dan konfigurasikan konsol.
Sekarang kami memiliki akses ke semua fitur akun.
Keunikan bekerja dengan AWS adalah bahwa semua tindakan dilakukan untuk wilayah tertentu dan harus diulang jika beberapa daerah terlibat.
Untuk membuat instance baru dari gambar yang kami buat di atas (kami berasumsi bahwa ada ami-ID publik yang kami gunakan dalam skrip), kami akan melakukan hal berikut:
- buat kunci SSH dan tambahkan ke AWS:
yes n |ssh-keygen -q -t rsa -f $KEYNAME -m pem -N "" > /dev/null chmod 400 $KEYNAME aws ec2 import-key-pair --region $REGION --key-name $KEYNAME --public-key-material file:///$(pwd)/$KEYNAME.pub
- buat grup keamanan yang memungkinkan akses ke mesin melalui SSH. Jika tidak, koneksi SSH yang masuk akan ditolak:
SECURITY="ssh-group" aws ec2 create-security-group --region $REGION --group-name $SECURITY --description "Just ssh. Nothing more" IP_RANGE="0.0.0.0/24" aws ec2 authorize-security-group-ingress --region $REGION --group-name $SECURITY --protocol tcp --port 22 --cidr $IP_RANGE
- buat instance dengan kunci yang dibuat sebelumnya dan grup keamanan dan tentukan ID gambar. Jumlah instance yang dibuat pada satu waktu dapat berubah-ubah:
IMG='ami-0d0eaed20348a3389' NUM=1 aws ec2 run-instances --region $REGION --image-id $IMG --count $NUM --instance-type t2.micro --key-name $KEYNAME --security-groups default $SECURITY > instances.json
- tunggu sampai mesin diinisialisasi. Ini membutuhkan waktu: pertama kita mendapatkan respons sukses (instances.json), tetapi pada saat itu mesin baru saja dibuat tetapi belum dimulai (misalnya, belum ditetapkan alamat IP). Hal ini diperlukan untuk menunggu peluncuran selesai (biasanya satu menit sudah cukup untuk ini).
Maka Anda dapat terhubung melalui SSH jika kami tahu alamat IP. Cukup minta daftar mesin yang sedang berjalan. Di antara parameter mereka, kami menemukan PublicDnsName atau PublicIpAddress.
aws ec2 describe-instances --region
Selanjutnya, kami menjalankan perintah SSH, menunjukkan kunci SSH yang dibuat di atas:
ssh -I $KEYNAME -oStrictHostKeyChecking=no ubuntu''+ins_dns echo''O''
Perintah SSH memungkinkan Anda untuk mengontrol serangan dan mendapatkan semua informasi tentang keadaan serangan, karena kami telah memberikan contoh dengan semua skrip dan alat yang diperlukan.
Anda perlu memahami bahwa sebagian besar pertahanan terhadap serangan penolakan layanan memblokir alamat IP dari mana banyak permintaan diterima secara anomali. Oleh karena itu, alamat IP mesin virtual harus terus berubah untuk mempertahankan kekuatan serangan.
AWS memberikan alamat IP baru setiap kali mesin mulai. Oleh karena itu, untuk mengubah IP, Anda harus mematikan dan menghidupkan mesin lagi (tidak perlu menghapusnya!).
Perbedaan antara mematikan dan menghapus adalah kami mengirim sinyal yang berbeda. Berhenti - untuk mematikan, mengakhiri - untuk mematikan dan menghapus segera.
Untuk memantau lalu lintas masuk dari instance, kami menggunakan perintah berikut dengan instance ID: ketika pengukuran lalu lintas dimulai, ketika itu berakhir, untuk periode berapa nilai-nilai dijumlahkan:
aws cloudwatch get-metric-statistics --region REGION --namespace AWS/EC2 \ --statistics Sum --metric-name NetworkIn --start-time $STARTTIME --end-time $FINISHTIME --period $PERIOD --dimensions Name=InstanceId,Value=$INCTANCEID
Pemantauan Ketersediaan Layanan
Selain itu, untuk melakukan serangan, Anda perlu mengamati apakah layanan yang kami uji masih hidup.
Kami membuat dan menjalankan skrip "ping" paling sederhana yang memantau ketersediaan port target (53 dan 80 dalam kasus kami).
Contoh kode Python yang mengotomatiskan pemeriksaan ketersediaan:
def http(url): cmd = ['curl', '-w', '"%{time_total}"', '-o', '/dev/null', '-s', url] result = check_output(cmd).decode('utf-8') result = float(json.loads(result)) return result * 1000000 def dns(ip, domain): cmd = ['dig', 'any', '@'+ip, domain ] result = check_output(cmd).decode('utf-8') result = int(result.split('Query time:')[1].split('msec')[0]) return result
Informasi yang diterima disimpan dalam file log, atas dasar itu, berdasarkan pada hasil serangan, akan mungkin untuk membuat grafik ketersediaan sumber daya.
Selama pengujian, perlu untuk selalu memeriksa log "ping" agar tidak mematikan sumber daya sepenuhnya dan tidak dapat dibatalkan. Segera setelah degradasi yang signifikan muncul dan respons terhadap permintaan terlalu banyak waktu, serangan harus dihentikan.
Jika perlambatan tidak signifikan, dan kekuatan serangan telah mencapai maksimum yang ditetapkan, maka masuk akal untuk menunggu satu atau dua menit, dan jika layanan terus bekerja tanpa gangguan, maka pemeriksaan dianggap berhasil.
Masalah keuangan
Perlu membahas masalah lain yang terkait dengan organisasi pengujian - biaya seluruh acara ini.
Amazon memberikan informasi harga yang terperinci, tetapi Anda harus memahami bahwa Anda harus membayar hampir semua hal. Namun demikian, banyak perhitungan dapat diabaikan. Pertama-tama, ada baiknya menghitung biaya lalu lintas (tergantung pada wilayah dan pada seberapa banyak jumlah total informasi yang akan ditransmisikan) dan biaya penyewaan contoh (pembayaran per menit). Barang-barang ini membentuk sekitar 99% dari biaya seluruh serangan.
Oleh karena itu, biaya serangan dihitung dalam setiap kasus secara terpisah, tergantung pada kekuatan serangan maksimum [skala permusuhan] dan jumlah peluncuran yang direncanakan.
Dari sudut pandang penyederhanaan perhitungan, lebih baik menggunakan akun Amazon, yang terdaftar tidak lebih dari setahun yang lalu. Maka bagian dari operasi akan bebas. Baca lebih lanjut tentang batasan penggunaan gratis di sini .
Untuk mengilustrasikan perhitungan biaya melakukan pengujian beban, katakanlah kita ingin memeriksa stabilitas server DNS ke beban 10 Gb / s.
Kita tahu bahwa alat yang digunakan dan kemampuan instance t3.small diluncurkan di Mumbai memungkinkan Anda untuk mengeluarkan 500 Mb / s dari satu instance yang sedang berjalan. Harga untuk menyewa suatu entitas adalah $ 0,0224 per jam, untuk lalu lintas - $ 0,01093 untuk 1 GB. Artinya, puncak serangan berarti operasi simultan dari 20 entitas.
Kami akan meningkatkan kekuatan serangan secara bertahap, untuk ini pertama-tama kami meluncurkan satu entitas, kemudian menambahkan yang lain setiap 60 detik.
Rumus untuk menghitung biaya berupa:
60 * ( ) + 60 * 0,5 /c * ( ) = 60 . 1 * ( ) + 2 * ( ) + ... + 20 * ( ) =
Ternyata biaya satu serangan dengan kapasitas 10 Gb / s ke server DNS adalah sekitar $ 70. Perhatikan bahwa ini adalah perkiraan kasar, karena volume lalu lintas tidak dapat diprediksi secara akurat. . , – , .
. .