Variti mengembangkan perlindungan terhadap serangan bot dan DDoS, dan juga melakukan pengujian tegangan dan beban. Pada konferensi HighLoad ++ 2018, kami berbicara tentang cara mengamankan sumber daya dari berbagai jenis serangan. Singkatnya: mengisolasi bagian-bagian sistem, menggunakan layanan cloud dan CDN dan memperbarui secara teratur. Tetapi tanpa perusahaan khusus, perlindungan Anda masih tidak bisa :)Sebelum membaca teks, Anda dapat membiasakan diri dengan abstrak singkat
di situs web konferensi .
Dan jika Anda tidak suka membaca atau hanya ingin menonton video, rekaman laporan kami berada di bawah spoiler.
Banyak perusahaan sudah tahu bagaimana melakukan stress testing, tetapi tidak semua melakukan stress testing. Beberapa pelanggan kami berpikir bahwa situs mereka kebal karena mereka memiliki sistem beban tinggi dan melindungi terhadap serangan. Kami menunjukkan bahwa ini tidak sepenuhnya benar.
Tentu saja, sebelum melakukan tes, kami mendapatkan izin dari pelanggan, ditandatangani dan dicap, dan dengan bantuan kami, kami tidak dapat melakukan serangan DDoS pada siapa pun. Pengujian dilakukan pada waktu yang dipilih oleh pelanggan, ketika kehadiran sumber dayanya minimal, dan masalah akses tidak akan mempengaruhi pelanggan. Selain itu, karena sesuatu selalu dapat salah selama proses pengujian, kami memiliki kontak yang konstan dengan pelanggan. Hal ini memungkinkan tidak hanya untuk melaporkan hasil yang dicapai, tetapi juga untuk mengubah sesuatu selama pengujian. Pada akhir pengujian, kami selalu menyusun laporan di mana kami menunjukkan kelemahan yang ditemukan dan memberikan rekomendasi untuk menghilangkan kelemahan situs.
Bagaimana kita bekerja
Selama pengujian, kami meniru botnet. Karena kami bekerja dengan klien yang tidak berada di jaringan kami, sehingga pengujian tidak berakhir pada menit pertama karena memicu batas atau perlindungan, kami memuat beban bukan dari satu IP, tetapi dari subnet kami sendiri. Plus, untuk membuat beban yang signifikan, kami memiliki server uji kami sendiri yang agak kuat.
Postulat
Banyak yang tidak baik
Semakin sedikit beban yang dapat kami bawa ke sumber daya gagal, semakin baik. Jika Anda berhasil membuat situs berhenti berfungsi dari satu permintaan per detik, atau bahkan dari satu permintaan per menit, itu tidak masalah. Karena menurut hukum kekejaman, pengguna atau penyerang tidak sengaja jatuh ke dalam kerentanan ini.
Kegagalan sebagian lebih baik daripada kegagalan total
Kami selalu menyarankan agar sistem menjadi heterogen. Selain itu, ada baiknya memisahkan mereka di tingkat fisik, dan bukan hanya kemasukan. Dalam hal pemisahan fisik, bahkan jika sesuatu gagal di situs, kemungkinan itu tidak akan berhenti berfungsi sepenuhnya, dan pengguna masih akan memiliki akses ke setidaknya sebagian dari fungsi tersebut.
Arsitektur yang tepat adalah fondasi keberlanjutan
Toleransi kesalahan sumber daya dan kemampuannya untuk menahan serangan dan beban harus diletakkan pada tahap desain, pada kenyataannya, pada tahap menggambar diagram blok pertama dalam buku catatan. Karena jika kesalahan fatal muncul, Anda dapat memperbaikinya di masa mendatang, tetapi ini sangat sulit.
Tidak hanya kode yang baik, tetapi juga konfigurasi
Banyak orang berpikir bahwa tim pengembangan yang baik adalah jaminan ketahanan layanan. Tim pengembangan yang baik benar-benar diperlukan, tetapi harus juga ada operasi yang baik, DevOps yang baik. Artinya, kami membutuhkan spesialis yang mengkonfigurasi Linux dan jaringan dengan benar, menulis konfigurasi dengan benar di nginx, mengkonfigurasi batas, dan lainnya. Jika tidak, sumber daya hanya akan berfungsi dengan baik pada pengujian, dan dalam produksi pada titik tertentu semuanya akan rusak.
Perbedaan antara stress dan stress testing
Pengujian beban memungkinkan Anda mengidentifikasi batasan sistem. Stress testing bertujuan untuk menemukan kelemahan sistem dan digunakan untuk memecah sistem ini dan melihat bagaimana ia akan berperilaku dalam proses kegagalan bagian-bagian tertentu. Pada saat yang sama, sifat beban biasanya tetap tidak diketahui pelanggan sampai dimulainya pengujian tegangan.
Fitur khas dari serangan L7
Kami biasanya membagi jenis beban menjadi beban pada level L7 dan L3 & 4. L7 adalah beban pada level aplikasi, paling sering dipahami hanya sebagai HTTP, tetapi yang kami maksud adalah setiap beban pada level protokol TCP.
Serangan L7 memiliki fitur pembeda tertentu. Pertama, mereka datang langsung ke aplikasi, yaitu, tidak mungkin bahwa mereka dapat tercermin melalui jaringan. Serangan semacam itu menggunakan logika, dan karena ini mereka mengkonsumsi CPU, memori, disk, basis data dan sumber daya lainnya dengan sangat efisien dan dengan sedikit lalu lintas.
HTTP Flood
Dalam kasus serangan apa pun, beban lebih mudah dibuat daripada ditangani, dan dalam kasus L7 ini juga benar. Lalu lintas serangan tidak selalu mudah dibedakan dari yang sah, dan paling sering dapat dilakukan berdasarkan frekuensi, tetapi jika semuanya direncanakan dengan benar, maka tidak mungkin untuk memahami di mana serangan itu dan di mana permintaan yang sah berasal dari log.
Sebagai contoh pertama, pertimbangkan serangan HTTP Flood. Grafik menunjukkan bahwa biasanya serangan seperti itu sangat kuat, dalam contoh di bawah jumlah permintaan puncak melebihi 600 ribu per menit.
HTTP Flood adalah cara termudah untuk membuat beban. Biasanya, beberapa jenis alat pengujian beban diambil untuknya, misalnya, ApacheBench, dan permintaan serta tujuannya ditetapkan. Dengan pendekatan sederhana seperti itu, kemungkinan akan mengalami caching server, tetapi mudah untuk disiasati. Misalnya, menambahkan garis acak ke kueri, yang memaksa server untuk selalu memberikan halaman baru.
Juga, jangan lupa tentang agen-pengguna dalam proses pembuatan suatu beban. Banyak agen pengguna alat pengujian populer difilter oleh administrator sistem, dan dalam hal ini, beban mungkin tidak mencapai backend. Anda dapat secara signifikan meningkatkan hasilnya dengan memasukkan header yang kurang lebih valid dari browser ke dalam permintaan.
Untuk semua kesederhanaannya, serangan HTTP Flood memiliki kelemahan. Pertama, kapasitas besar diperlukan untuk membuat beban. Kedua, serangan seperti itu sangat mudah dideteksi, terutama jika berasal dari alamat yang sama. Akibatnya, permintaan segera mulai difilter baik oleh administrator sistem, atau bahkan di tingkat penyedia.
Apa yang harus dicari
Untuk mengurangi jumlah permintaan per detik dan tetap tidak kehilangan efisiensi, Anda perlu menunjukkan sedikit imajinasi dan menjelajahi situs. Jadi, Anda tidak hanya dapat memuat saluran atau server, tetapi juga setiap bagian aplikasi, misalnya, basis data atau sistem file. Anda juga dapat mencari tempat di situs yang melakukan perhitungan besar: kalkulator, halaman pemilihan produk, dan banyak lagi. Akhirnya, sering terjadi bahwa ada skrip php di situs yang menghasilkan halaman beberapa ratus ribu baris. Skrip seperti itu juga memuat server secara berat dan dapat menjadi target serangan.
Di mana mencarinya
Ketika kita memindai sumber daya sebelum pengujian, pertama-tama kita melihat, tentu saja, di situs itu sendiri. Kami mencari semua jenis bidang input, file berat - secara umum, semua yang dapat membuat masalah untuk sumber daya dan memperlambat operasinya. Di sini, alat pengembangan biasa di Google Chrome dan Firefox membantu menunjukkan waktu respons halaman.
Kami juga memindai subdomain. Misalnya, ada toko online tertentu, abc.com, dan memiliki subdomain admin.abc.com. Kemungkinan besar, ini adalah panel admin dengan otorisasi, tetapi jika Anda memasukkan beban ke dalamnya, maka hal itu dapat menimbulkan masalah bagi sumber daya utama.
Situs ini mungkin memiliki subdomain api.abc.com. Kemungkinan besar, ini adalah sumber daya untuk aplikasi seluler. Aplikasi ini dapat ditemukan di App Store atau Google Play, meletakkan titik akses khusus, membedah API dan mendaftarkan akun pengujian. Masalahnya adalah bahwa sering orang berpikir bahwa segala sesuatu yang dilindungi oleh otorisasi kebal terhadap penolakan serangan layanan. Diduga, otorisasi adalah CAPTCHA terbaik, tetapi tidak. Membuat 10-20 akun pengujian itu mudah, dan dengan membuatnya, kami mendapatkan akses ke fungsionalitas yang kompleks dan tidak disembunyikan.
Secara alami, kita melihat sejarah, di robots.txt dan WebArchive, ViewDNS, kami mencari versi lama dari sumber. Kadang-kadang terjadi bahwa pengembang meluncurkan, katakanlah, mail2.yandex.net, tetapi versi lama, mail.yandex.net, tetap ada. Mail.yandex.net ini tidak lagi didukung, sumber daya pengembangan tidak dialokasikan untuk itu, tetapi terus mengkonsumsi database. Dengan demikian, menggunakan versi lama, Anda dapat secara efektif menggunakan sumber daya backend dan segala sesuatu yang ada di balik tata letak. Tentu saja, ini tidak selalu terjadi, tetapi kita masih sering menghadapi hal seperti ini.
Secara alami, kami membedah semua parameter permintaan, struktur cookie. Anda dapat, katakanlah, mendorong beberapa nilai ke dalam array JSON di dalam cookie, membuat lebih banyak sarang dan membuat sumber daya bekerja terlalu lama.
Cari beban
Hal pertama yang terlintas dalam pikiran ketika meneliti sebuah situs adalah memuat basis data, karena hampir setiap orang memiliki pencarian, dan hampir setiap orang memilikinya, sayangnya, tidak terlindungi dengan baik. Untuk beberapa alasan, para pengembang tidak cukup memperhatikan pencarian. Tetapi ada satu rekomendasi - jangan membuat jenis permintaan yang sama, karena Anda mungkin mengalami caching, seperti halnya dengan HTTP float.
Membuat kueri acak ke dalam basis data juga tidak selalu efisien. Jauh lebih baik untuk membuat daftar kata kunci yang relevan dengan pencarian. Jika Anda kembali ke contoh toko online: misalkan situs menjual ban mobil dan memungkinkan Anda untuk mengatur jari-jari ban, jenis mobil dan parameter lainnya. Dengan demikian, kombinasi kata-kata yang relevan akan membuat database bekerja dalam kondisi yang jauh lebih kompleks.
Selain itu, layak menggunakan pagination: jauh lebih sulit bagi pencarian untuk mengembalikan halaman kedua dari masalah daripada yang pertama. Artinya, dengan bantuan pagination, Anda dapat melakukan diversifikasi sedikit.
Dalam contoh di bawah ini, kami menunjukkan beban dalam pencarian. Dapat dilihat bahwa dari detik pertama pengujian dengan kecepatan sepuluh permintaan per detik, situs turun dan tidak merespons.
Jika tidak ada pencarian?
Jika tidak ada pencarian, ini tidak berarti bahwa situs tersebut tidak mengandung bidang input rentan lainnya. Bidang ini mungkin otorisasi. Sekarang pengembang suka membuat hash yang kompleks untuk melindungi basis data masuk dari serangan pada tabel pelangi. Ini bagus, tetapi hash seperti itu menghabiskan sumber daya CPU yang besar. Aliran besar otorisasi palsu menyebabkan kegagalan prosesor, dan sebagai hasilnya, situs berhenti bekerja pada output.
Kehadiran di situs semua jenis formulir untuk komentar dan umpan balik adalah kesempatan untuk mengirim teks yang sangat besar di sana atau hanya membuat banjir besar. Terkadang situs menerima lampiran file, termasuk dalam format gzip. Dalam hal ini, kami mengambil file 1TB, menggunakan gzip, kami mengompresnya menjadi beberapa byte atau kilobyte dan mengirimkannya ke situs. Kemudian dibuka ritsleting dan efek yang sangat menarik diperoleh.
API sisanya
Saya ingin sedikit memperhatikan layanan populer seperti API Istirahat. Melindungi API Istirahat jauh lebih sulit daripada situs biasa. Untuk API Istirahat, bahkan metode perlindungan sepele terhadap pemecahan kata sandi dan aktivitas tidak sah lainnya tidak berfungsi.
API Istirahat sangat mudah dipecahkan karena mengakses database secara langsung. Pada saat yang sama, kegagalan layanan semacam itu membawa konsekuensi yang cukup serius bagi bisnis. Faktanya adalah bahwa API Istirahat biasanya tidak hanya melibatkan situs utama, tetapi juga aplikasi seluler, beberapa sumber daya bisnis internal. Dan jika semua ini jatuh, maka efeknya jauh lebih kuat daripada dalam kasus kegagalan situs sederhana.
Beban Konten Berat
Jika kami ditawari untuk menguji beberapa aplikasi satu halaman biasa, halaman arahan, situs web kartu nama, yang tidak memiliki fungsi yang kompleks, kami sedang mencari konten yang berat. Misalnya, gambar besar yang diberikan server, file biner, dokumentasi pdf - kami mencoba untuk memompa semuanya. Tes semacam itu memuat sistem file dengan baik dan menyumbat saluran, dan karenanya efektif. Artinya, bahkan jika Anda tidak meletakkan server, mengunduh file besar dengan kecepatan rendah, Anda hanya akan menyumbat saluran server target dan kemudian penolakan layanan akan terjadi.
Contoh pengujian semacam itu menunjukkan bahwa pada kecepatan 30 RPS situs berhenti merespons, atau menghasilkan 500 kesalahan server.
Jangan lupa tentang pengaturan server. Anda sering dapat menemukan bahwa seseorang membeli mesin virtual, menginstal Apache di sana, mengkonfigurasi semuanya secara default, menemukan aplikasi php, dan di bawah ini Anda dapat melihat hasilnya.
Di sini bebannya pergi ke root dan hanya berjumlah 10 RPS. Kami menunggu 5 menit dan server macet. Sampai akhir, bagaimanapun, tidak diketahui mengapa dia jatuh, tetapi ada asumsi bahwa dia hanya penuh dengan ingatan, dan karena itu berhenti merespons.
Berbasis gelombang
Dalam satu atau dua tahun terakhir, serangan gelombang telah menjadi sangat populer. Ini disebabkan oleh kenyataan bahwa banyak organisasi membeli perangkat keras tertentu untuk perlindungan terhadap DDoS, yang memerlukan sejumlah statistik tertentu untuk mulai menyaring serangan. Artinya, mereka tidak menyaring serangan dalam 30-40 detik pertama, karena mereka mengumpulkan data dan belajar. Oleh karena itu, dalam 30-40 detik ini, Anda dapat meluncurkan begitu banyak sehingga sumber daya akan berbohong untuk waktu yang lama sampai semua permintaan dihapus.
Dalam kasus serangan, ada interval 10 menit di bawah, setelah itu bagian serangan baru yang dimodifikasi tiba.
Yaitu, pertahanan dilatih, mulai menyaring, tetapi bagian baru, serangan yang sama sekali berbeda tiba, dan pertahanan mulai berlatih lagi. Bahkan, penyaringan berhenti berfungsi, perlindungan menjadi tidak efektif, dan situs tidak dapat diakses.
Serangan gelombang dicirikan oleh nilai yang sangat tinggi di puncaknya, dapat mencapai seratus ribu atau sejuta permintaan per detik, dalam kasus L7. Jika kita berbicara tentang L3 & 4, maka mungkin ada ratusan gigabit lalu lintas, atau, karenanya, ratusan mpps, jika Anda menghitung dalam paket.
Masalah dengan serangan tersebut adalah sinkronisasi. Serangan datang dari botnet, dan untuk menciptakan puncak satu kali yang sangat besar, diperlukan sinkronisasi tingkat tinggi. Dan koordinasi ini tidak selalu berhasil: kadang-kadang outputnya adalah semacam puncak parabola, yang terlihat agak menyedihkan.
Bukan HTTP Unified
Selain HTTP pada level L7, kami senang mengeksploitasi protokol lain. Sebagai aturan, sebuah situs web biasa, terutama hosting biasa, memiliki protokol surat dan MySQL mencuat. Protokol mail tidak terlalu terpengaruh daripada database, tetapi mereka juga dapat dimuat dengan cukup efisien dan mendapatkan CPU yang kelebihan beban di server pada output.
Dengan bantuan kerentanan SSH 2016, kami cukup sukses. Sekarang kerentanan ini telah diperbaiki untuk hampir semua orang, tetapi ini tidak berarti bahwa SSH tidak dapat dimuat. Kamu bisa. Hanya banyak otorisasi yang dilayani, SSH memakan hampir seluruh CPU di server, dan kemudian situs web sudah terdiri dari satu atau dua permintaan per detik.
Karenanya, satu atau dua kueri log ini tidak dapat dibedakan dari muatan yang sah.
Banyak koneksi yang kami buka di server tetap relevan. Sebelumnya, Apache berdosa, sekarang nginx sebenarnya berdosa, karena sering dikonfigurasi secara default. Jumlah koneksi yang nginx dapat tetap terbuka terbatas, jadi kami membuka jumlah koneksi ini, koneksi nginx baru tidak lagi menerima, dan situs tidak berfungsi pada output.
Cluster pengujian kami memiliki cukup CPU untuk menyerang jabat tangan SSL. Pada prinsipnya, seperti yang ditunjukkan oleh latihan, botnet juga terkadang suka melakukan ini. Di satu sisi, jelas bahwa Anda tidak dapat melakukannya tanpa SSL, karena Google menerbitkan, memberi peringkat, dan keamanan. SSL, di sisi lain, sayangnya memiliki masalah CPU.
L3 & 4
Ketika kita berbicara tentang serangan di level L3 & 4, kita biasanya berbicara tentang serangan di level saluran. Beban seperti itu hampir selalu dapat dibedakan dari yang sah jika itu bukan serangan banjir SYN. Masalah serangan banjir SYN untuk fitur keamanan besar. Nilai maksimum L3 & 4 adalah 1,5-2 Tb / s. Lalu lintas seperti itu sangat sulit ditangani bahkan untuk perusahaan besar, termasuk Oracle dan Google.
SYN dan SYN-ACK adalah paket yang digunakan untuk membangun koneksi. Oleh karena itu, sulit untuk membedakan SYN-banjir dari beban yang sah: tidak jelas apakah ini SYN, yang datang untuk membuat sambungan, atau bagian dari banjir.
Banjir UDP
Biasanya, penyerang tidak memiliki kemampuan yang kita miliki, sehingga amplifikasi dapat digunakan untuk mengatur serangan. Yaitu, seorang penyerang memindai Internet dan menemukan server yang rentan atau tidak dikonfigurasi dengan benar, yang, misalnya, sebagai tanggapan terhadap satu paket SYN, merespons dengan tiga SYN-ACK. Dengan memalsukan alamat sumber dari alamat server target, Anda dapat menggunakan satu paket untuk meningkatkan kapasitas, katakanlah, tiga kali, dan mengarahkan lalu lintas ke korban.
Masalah dengan amplifikasi adalah pendeteksiannya yang kompleks. Dari contoh-contoh terbaru kita dapat mengutip kasus sensasional dengan memcached yang rentan. Plus, sekarang ada banyak perangkat IoT, kamera IP, yang sebagian besar juga dikonfigurasi secara default, dan secara default mereka dikonfigurasi secara tidak benar, oleh karena itu, melalui perangkat tersebut, penyerang paling sering melakukan serangan.
SYN-flood yang sulit
SYN-flood mungkin adalah tampilan paling menarik dari semua serangan dari sudut pandang pengembang. Masalahnya adalah bahwa administrator sistem sering menggunakan pemblokiran IP untuk perlindungan. Selain itu, pemblokiran IP mempengaruhi tidak hanya sysadmin yang beroperasi sesuai dengan skrip, tetapi, sayangnya, beberapa sistem keamanan yang dibeli dengan banyak uang.
Metode ini dapat berubah menjadi malapetaka, karena jika penyerang mengubah alamat IP mereka, perusahaan akan memblokir subnetnya sendiri. Ketika Firewall memblokir klusternya sendiri, interaksi eksternal akan macet di output, dan sumber daya akan rusak.
Dan untuk mencapai pemblokiran jaringan Anda sendiri itu mudah. Jika kantor klien memiliki jaringan Wi-Fi, atau jika kesehatan sumber daya diukur menggunakan berbagai pemantauan, maka kami mengambil alamat IP dari sistem pemantauan ini atau kantor klien Wi-Fi, dan menggunakannya sebagai sumber. Pada output, sumber daya tampaknya tersedia, tetapi alamat IP target diblokir. Jadi, jaringan Wi-Fi pada konferensi HighLoad, tempat produk baru perusahaan disajikan, dapat diblokir, dan ini memerlukan biaya bisnis dan ekonomi tertentu.
Selama pengujian, kami tidak dapat menggunakan amplifikasi melalui memcached oleh beberapa sumber daya eksternal, karena ada perjanjian untuk memasok lalu lintas hanya ke alamat IP yang diizinkan. Dengan demikian, kami menggunakan amplifikasi melalui SYN dan SYN-ACK, ketika sistem merespons dengan mengirim dua atau tiga SYN-ACK untuk mengirim satu SYN, dan hasilnya dikalikan dua hingga tiga kali.
Alat-alatnya
Salah satu alat utama yang kami gunakan untuk memuat di level L7 adalah Yandex-tank. Secara khusus, hantu digunakan sebagai senjata, ditambah ada beberapa skrip untuk menghasilkan kartrid dan untuk menganalisis hasilnya.
Tcpdump digunakan untuk menganalisis lalu lintas jaringan, dan Nmap digunakan untuk menganalisis lalu lintas server. Untuk membuat beban di level L3 & 4, OpenSSL digunakan dan sedikit keajaibannya sendiri dengan perpustakaan DPDK. DPDK adalah perpustakaan dari Intel yang memungkinkan Anda bekerja dengan antarmuka jaringan, melewati tumpukan Linux, dan dengan demikian meningkatkan efisiensi. Secara alami, kami menggunakan DPDK tidak hanya di level L3 & 4, tetapi juga di level L7, karena memungkinkan Anda untuk membuat aliran beban yang sangat tinggi, dalam beberapa juta permintaan per detik dari satu mesin.
Kami juga menggunakan generator lalu lintas tertentu dan alat khusus yang kami tulis untuk pengujian khusus. Jika kita mengingat kembali kerentanan di bawah SSH, maka dengan set di atas, ia tidak bisa diloloskan. Jika kita menyerang protokol surat, kita mengambil utilitas surat atau hanya menulis skrip padanya.
Kesimpulan
Sebagai hasilnya, saya ingin mengatakan:
- Selain pengujian beban klasik, pengujian tegangan juga harus dilakukan. Kami memiliki contoh dunia nyata di mana subkontraktor mitra hanya melakukan pengujian beban. Itu menunjukkan bahwa sumber daya tahan beban standar. Tetapi kemudian muncul beban abnormal, pengunjung situs mulai menggunakan sumber daya sedikit berbeda, dan pada output subkontraktor meletakkan. Oleh karena itu, ada baiknya mencari kerentanan bahkan jika Anda sudah terlindungi dari serangan DDoS.
- Penting untuk mengisolasi beberapa bagian sistem dari yang lain. , , . , - . - , , , , OAuth2.
- .
- CDN , .
- . L3&4 , , , . L7 , . , - , .
- . , SSH daemon, . , , .