Sebagai situs yang sangat populer, stackoverflow.com mendapat banyak perhatian. Beberapa di antaranya bagus, seperti saat kami dinominasikan untuk Webby Award. Di lain waktu, perhatian itu jelas kurang baik, seperti ketika kita menjadi sasaran serangan penolakan layanan (DDoS) terdistribusi.
Selama beberapa bulan, kami telah menjadi target serangan DDoS yang sedang berlangsung. Serangan ini telah dibagi menjadi dua jenis serangan: API kami telah terkena serangan lapisan aplikasi sementara situs utama telah menjadi sasaran serangan berbasis volume. Kedua serangan ini memanfaatkan permukaan yang kami ekspos ke internet.
Kami masih mendapatkan hit secara teratur, tetapi berkat tim SRE dan DBRE kami, bersama dengan beberapa perubahan kode yang dibuat oleh Tim Platform Publik kami, kami dapat meminimalkan dampaknya terhadap pengalaman pengguna kami. Beberapa dari serangan ini sekarang hanya terlihat melalui log dan dasbor kami.
Kami ingin membagikan beberapa taktik umum yang telah kami gunakan untuk meredam efek serangan DDoS sehingga orang lain yang berada di bawah serangan yang sama dapat meminimalkannya.
Serangan botnet pada kueri SQL yang mahal
Di antara dua serangan lapisan aplikasi, penyerang memanfaatkan botnet yang sangat besar untuk memicu kueri yang sangat mahal. Beberapa server back end mencapai pemanfaatan CPU 100% selama serangan ini. Apa yang membuat tantangan ekstra ini adalah bahwa serangan itu didistribusikan melalui kumpulan besar alamat IP; beberapa IP hanya mengirim dua permintaan, jadi pembatasan tarif berdasarkan alamat IP tidak akan efektif.
Kami harus membuat filter yang memisahkan permintaan jahat dari yang sah sehingga kami dapat memblokir permintaan khusus tersebut. Awalnya, filternya agak terlalu bersemangat, tetapi seiring waktu, kami perlahan menyempurnakan filter untuk mengidentifikasi hanya permintaan jahat.
Setelah kami mengurangi serangan, mereka berkumpul kembali dan mencoba menargetkan halaman pengguna dengan meminta jumlah halaman yang sangat tinggi. Untuk menghindari deteksi atau larangan, mereka menambah nomor halaman yang diminta bot mereka. Ini menumbangkan kontrol kami sebelumnya dengan menyerang area berbeda dari situs web sambil tetap mengeksploitasi kerentanan yang sama. Sebagai tanggapan, kami memasang filter untuk mengidentifikasi dan memblokir lalu lintas berbahaya.
Rute API ini, seperti API apa pun yang menarik data dari database, diperlukan untuk fungsi Stack Overflow sehari-hari. Untuk melindungi rute seperti ini dari DDoS, inilah yang dapat Anda lakukan:
- Bersikeras agar setiap panggilan API diautentikasi. Ini akan membantu mengidentifikasi pengguna jahat. Jika hanya panggilan API yang diautentikasi tidak memungkinkan, tetapkan batas yang lebih ketat untuk lalu lintas anonim/tidak diautentikasi.
- Minimalkan jumlah data yang dapat dikembalikan oleh satu panggilan API. Saat kami membuat daftar pertanyaan halaman depan, kami tidak mengambil semua data untuk setiap pertanyaan. Kami membuat paginasi, malas memuat hanya data di viewport, dan hanya meminta data yang akan terlihat (yaitu, kami tidak meminta teks untuk setiap jawaban sampai memuat halaman pertanyaan itu sendiri).
- Batasi tarif semua panggilan API. Ini berjalan seiring dengan meminimalkan data per panggilan; untuk mendapatkan data dalam jumlah besar, penyerang perlu memanggil API beberapa kali. Tidak ada yang perlu memanggil API Anda seratus kali per detik.
- Filter lalu lintas berbahaya sebelum mencapai aplikasi Anda. Penyeimbang beban HAProxy berada di antara semua permintaan dan server kami untuk menyeimbangkan jumlah lalu lintas di seluruh server kami. Tapi itu tidak berarti semua lalu lintas harus pergi ke salah satu server tersebut. Terapkan log yang menyeluruh dan mudah ditanyakan sehingga permintaan berbahaya dapat dengan mudah diidentifikasi dan diblokir.
Mendera-a-mol pada IP berbahaya
Kami juga menjadi sasaran beberapa serangan berbasis volume. Botnet mengirimkan sejumlah besar permintaan `POST` ke `stackoverflow.com/questions/`. Yang ini mudah: karena kami tidak menggunakan garis miring di URL itu, kami memblokir semua lalu lintas di jalur khusus itu.
Penyerang mengetahuinya, menjatuhkan garis miring, dan kembali ke arah kami. Alih-alih hanya secara reaktif memblokir setiap rute yang diserang penyerang, kami mengumpulkan IP botnet dan memblokirnya melalui CDN kami, Fastly. Penyerang ini melakukan tiga pukulan pada kami: dua pukulan pertama menyebabkan kami kesulitan, tetapi begitu kami mengumpulkan IP dari serangan kedua, kami dapat memblokir serangan ketiga secara instan. Lalu lintas berbahaya bahkan tidak pernah sampai ke server kami.
Serangan berbasis volume baru—mungkin dari penyerang yang sama—mengambil pendekatan yang berbeda. Alih-alih melemparkan seluruh botnet kepada kami, mereka mengaktifkan bot yang cukup untuk mengganggu situs. Kami akan menempatkan IP tersebut di daftar blokir CDN kami, dan penyerang akan mengirimkan gelombang berikutnya kepada kami. Itu seperti permainan Whack-a-mole, kecuali tidak menyenangkan dan kami tidak memenangkan hadiah apa pun di akhir.
Alih-alih meminta tim insiden kami mengacak dan melarang IP saat mereka masuk, kami mengotomatiskannya seperti SRE kecil yang bagus. Kami membuat skrip yang akan memeriksa log lalu lintas kami untuk IP yang berperilaku dengan cara tertentu dan secara otomatis menambahkannya ke daftar larangan. Waktu respons kami meningkat pada setiap serangan. Penyerang terus berjalan sampai mereka bosan atau kehabisan IP untuk dilempar ke kami.
Serangan berbasis volume bisa lebih berbahaya. Mereka terlihat seperti lalu lintas biasa, hanya lebih dari itu. Bahkan jika botnet berfokus pada satu URL, Anda tidak dapat selalu memblokir URL begitu saja. Lalu lintas yang sah juga mengenai halaman itu. Berikut adalah beberapa takeaways dari upaya kami:
- Blokir URL aneh. Jika Anda mulai melihat garis miring di tempat Anda tidak menggunakannya, `POST` meminta jalur yang tidak valid, menandai dan memblokir permintaan tersebut. Jika Anda memiliki halaman catch-all lain dan mulai melihat URL aneh masuk, blokir mereka.
- Blokir IP berbahaya bahkan jika lalu lintas yang sah dapat berasal darinya. Ini memang menyebabkan beberapa kerusakan tambahan tetapi lebih baik untuk memblokir beberapa lalu lintas yang sah daripada turun untuk semua lalu lintas.
- Otomatiskan daftar blokir Anda. Masalah dengan memblokir botnet secara manual adalah kerja keras yang terlibat dengan mengidentifikasi bot dan mengirim IP ke daftar blokir Anda. Jika Anda dapat mengenali pola bot kemudian mengotomatiskan pemblokiran berdasarkan pola itu, waktu respons Anda akan turun dan waktu kerja Anda akan naik.
- Tar pitting adalah cara yang bagus untuk memperlambat botnet dan mengurangi serangan berbasis volume. Idenya adalah untuk mengurangi jumlah permintaan yang dikirim oleh botnet dengan meningkatkan waktu antar permintaan.
Hal lain yang kami pelajari
Dengan harus menghadapi banyak serangan DDoS secara berurutan, kami dapat mempelajari dan meningkatkan infrastruktur dan ketahanan kami secara keseluruhan. Kami tidak akan mengucapkan terima kasih kepada botnet, tetapi tidak ada yang lebih baik daripada krisis. Berikut adalah beberapa pelajaran besar secara keseluruhan yang kami pelajari.
Berinvestasi dalam pemantauan dan peringatan. Kami mengidentifikasi beberapa celah dalam protokol pemantauan kami yang dapat memperingatkan kami tentang serangan ini lebih cepat. Serangan lapisan aplikasi khususnya memiliki tanda-tanda yang dapat kami tambahkan ke portofolio pemantauan kami. Secara umum, meningkatkan perkakas kami secara keseluruhan telah membantu kami merespons dan mempertahankan waktu aktif situs.
Otomatiskan semua hal. Karena kami menghadapi beberapa serangan DDoS berturut-turut, kami dapat melihat pola dalam alur kerja kami dengan lebih baik. Saat SRE melihat sebuah pola, mereka mengotomatiskannya, persis seperti yang kami lakukan. Dengan membiarkan sistem kami menangani pekerjaan yang berulang, kami mengurangi waktu respons kami.
Tulis semuanya. Jika Anda tidak dapat mengotomatiskannya, rekam untuk petugas pemadam kebakaran di masa mendatang. Mungkin sulit untuk mundur selama krisis dan membuat catatan. Tapi kami berhasil meluangkan waktu dan membuat runbook untuk serangan di masa depan. Lain kali botnet membanjiri kita dengan lalu lintas, kita harus lebih dulu menanganinya.
Bicaralah dengan pengguna Anda. Node keluar Tor adalah sumber dari sejumlah besar lalu lintas selama salah satu serangan volume, jadi kami memblokirnya. Itu tidak cocok dengan pengguna sah yang kebetulan menggunakan IP yang sama. Pengguna memulai sedikit spekulasi liar, menyalahkan Komunis Tiongkok karena mencegah akses anonim ke situs (agar adil, itu setengah benar: Saya orang Tionghoa). Kami tidak berniat memblokir akses Tor secara permanen, tetapi mencegah pengguna lain mencapai situs, jadi kami menggunakan Meta untuk menjelaskan situasinya sebelum garpu rumput keluar secara massal. Kami sekarang menambahkan tugas dan alat komunikasi ke dalam runbook respons insiden kami sehingga kami bisa lebih proaktif dalam memberi tahu pengguna.
Serangan DDoS sering kali berhasil di internet. Kami telah mendapat banyak perhatian selama 12 tahun terakhir, dan beberapa di antaranya pasti negatif. Jika Anda menjadi penerima perhatian botnet, kami berharap pelajaran yang telah kami pelajari dapat membantu Anda juga.
Tags: DDoS, devops, keamanan