Solusi 1:
DDOS (atau bahkan DOS), pada intinya, adalah kehabisan sumber daya. Anda tidak akan pernah bisa menghilangkan kemacetan, karena Anda hanya bisa mendorongnya lebih jauh.
Di AWS, Anda beruntung karena komponen jaringannya sangat kuat - akan sangat mengejutkan mengetahui bahwa tautan upstream sudah jenuh. Namun, CPU, serta I/O disk, jauh lebih mudah dibanjiri.
Tindakan terbaik adalah dengan memulai beberapa pemantauan (lokal seperti SAR, jarak jauh dengan Nagios dan/atau ScoutApp) dan beberapa fasilitas logging jarak jauh (Syslog-ng). Dengan penyiapan seperti itu, Anda akan dapat mengidentifikasi sumber daya mana yang menjadi jenuh (soket jaringan karena banjir Syn; CPU karena kueri atau perayap SQL yang buruk; ram karena ...). Jangan lupa untuk memiliki partisi log Anda (jika Anda tidak mengaktifkan logging jarak jauh) pada volume EBS (untuk mempelajari log nanti).
Jika serangan datang melalui halaman web, log akses (atau yang setara) bisa sangat berguna.
Solusi 2:
Anda juga dapat lebih mengisolasi instans EC2 dengan menempatkannya di belakang Elastic Load Balancer dan hanya menerima lalu lintas dari instans ELB. Ini memberi lebih banyak tanggung jawab pada Amazon untuk mengelola serangan DDOS.
Saya berasumsi bahwa Anda masih memiliki SSH terbuka untuk semua, jadi kemungkinan Anda masih akan melihat lalu lintas nakal masuk ke sana, kecuali Anda dapat mengunci port itu ke beberapa IP statis. Anda dapat mengubah port SSHd menjadi sesuatu yang lebih tidak jelas (yaitu, selain 22) untuk lebih mengurangi serangan DDOS (kebanyakan bot hanya memeriksa port yang dikenal).
Saya juga akan menyebutkan fail2ban, yang dapat memantau log dan untuk sementara memodifikasi tabel ip Anda untuk memblokir IP tertentu (misalnya, jika ada 6 upaya gagal untuk SSH ke host Anda dari satu alamat IP, itu dapat memblokir IP tersebut selama 30 menit atau lebih). Perlu diingat bahwa (seperti yang dikomentari oleh Jordan dengan cerdas) fail2ban mungkin tidak sesuai untuk memblokir lalu lintas yang diproksikan (mis., dari ELB) karena akan memblokir IP proksi, belum tentu IP jarak jauh yang asli.
Saya belum pernah menggunakannya, tetapi Apache mod_evasive mungkin juga perlu diselidiki; namun, ini mungkin memiliki kelemahan yang sama dengan fail2ban dalam hal pemblokiran berbasis IP.
Solusi 3:
Jika Anda menggunakan Apache, saya sarankan menggunakan mod_security. Dikemas oleh sebagian besar vendor, kumpulan aturan inti melakukan pekerjaan yang luar biasa.
Langkah pengerasan lainnya adalah membatasi permintaan di tingkat server web. Nginx., Apache dapat membatasi dan membatasi permintaan yang masuk.
Solusi 4:
Solusi yang saya gunakan untuk memblokir IP aktivitas buruk waktu nyata yang keluar dari AWS dan lainnya adalah ini ... Di CSF Firewall saya di konfigurasi untuk LFD Blocklists saya menggunakan daftar yang ditemukan di sini - http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Real-time
Unduh Daftar Hitam untuk CSF Firewall » http://myip.ms/files/blacklist/csf/latest_blacklist.txt
Tidak ada lagi lalu lintas AWS yang sangat menjengkelkan.
Solusi 5:
Saya bias, karena saya bekerja untuk jaringan pengiriman konten sebagai insinyur Presales keamanan.
Namun, memanfaatkan solusi mitigasi Ddos pada jaringan pengiriman konten memastikan bahwa Anda tidak pernah kehabisan sumber daya sejak awal. Ini mirip dengan meletakkan penyeimbang muatan F5 di depan situs Anda, tetapi menyebar ke ribuan lokasi di seluruh dunia.
CDN yang baik akan memungkinkan Anda untuk menyelubungi asal dengan daftar putih yang Anda pasang di firewall aws. Jadi ketika penyerang melakukan pengintaian mereka di Amazon, alamat IP Anda akan kosong karena semuanya akan diblokir.
Jadi serangan Ddos diblokir saat lalu lintas mengenai node sedekat mungkin dengan penyerang. Ini memastikan Anda mengurangi serangan Ddos sejauh mungkin dari aset yang Anda coba lindungi.
CDN yang baik juga dapat melakukan pemeriksaan kesehatan dan lalu lintas failover ke lokasi lain misalnya ego lain di pantat, Azure, ruang rak, lapisan lunak, dc fisik dll. Itu juga harus memiliki WAF untuk memastikan Anda dapat memblokir serangan kelelahan lapisan aplikasi seperti RUDY, slowpost, slowloris serta sql, xss, rfi, lfi dll.
Secara default cdn juga memblokir serangan lapisan jaringan seperti tetesan air mata, serangan icmp, synfloods dll. Sebuah cdn dapat mengurangi serangan Ddos karena trey memiliki kapasitas yang sangat besar untuk menerima permintaan, menyaring lalu lintas yang buruk dan meneruskan lalu lintas yang baik. Jadi memperkuat serangan seperti serangan volumetrik ntp, DNS, ssdp, chargen dan snmp dapat diblokir.
Serangan terbesar yang pernah saya lihat hingga saat ini adalah 321gbps pada Juli 2014. Selama serangan ini, ada juga serangan protokol DNS pada 20gbps. Jadi, Anda perlu memastikan infrastruktur DNS Anda juga tangguh untuk menahan sejumlah besar permintaan.
Dari deskripsi yang Anda berikan, sepertinya Anda terkena serangan kelelahan, di mana penyerang membuka banyak utas sehingga semua utas digunakan di server web, server aplikasi, atau firewall. Ini mirip dengan sesuatu seperti slowpost, slowloris atau RUDY.
Untuk memblokir serangan kelelahan lapisan aplikasi, Anda perlu mendapatkan firewall aplikasi web (WAF). Firewall jaringan tipikal (termasuk firewall amazon dan firewall generasi berikutnya) tidak akan dapat memblokirnya. Mengirim firewall kerja hari ini hanya dapat memblokir sekitar 30% dari semua serangan hari ini (Nov 2014).