Konferensi BLACK HAT. Pelajaran dari selamat dari serangan DDOS 300 Gb / s. Bagian 1Hal yang menarik tentang serangan ini adalah bahwa kami tidak berani menyerang secara langsung, tetapi mengikuti rantai penyedia kami. Mereka mulai menyerang penyedia hulu yang terletak di atas CloudFlare, dan sumber serangan itu memang di London. Pada awalnya saya tidak yakin tentang ini, tetapi karena Spamhaus juga di London, mungkin peretas ingin menempatkan mereka dalam posisi yang memalukan. Seperti yang saya katakan, inspirator teknis serangan itu tampaknya adalah seorang remaja dari London, mungkin dengan cara ini dia bisa lebih efektif melacak efek serangannya. Slide ini menunjukkan rute lalu lintas BGP, yang termasuk maksimum 30 node transit next-hop.
Saya menyembunyikan ekstensi alamat penyedia broadband London, hop terakhir adalah salah satu alamat IP Spamhaus, ada beberapa di jaringan kami. Anda lihat bagaimana lalu lintas dialihkan, sulit untuk menentukan jalur yang tepat dari data di atas, tetapi dikirim ke peralatan kami di London, di mana ia mendapat 17 milidetik setelah melewati alamat IP perbatasan jaringan kami, yang bekerja di London.
Pada awalnya, penyerang menyerang alamat ini ditandai dengan panah, dan karena DNS yang didistribusikan digunakan di sini, ia sedikit memukul London, sedikit ke Amsterdam dan Frankfurt, ke Amerika Serikat, Asia dan sedikit ke Australia. Kemudian hacker menyadari bahwa serangan itu tersebar dan tidak efektif, dan memutuskan untuk memanjat rantai perutean melewati bagian-bagian tambahan dari infrastruktur. Karena itu, setelah alamat IP terakhir, ia pindah ke alamat IP kedua dari belakang. Sekali lagi, jika Anda tidak tahu cara kerja perutean dan koneksi internet, saya akan mengatakan bahwa sebagian lalu lintas dipertukarkan langsung antara jaringan ketika saya menghubungkan jaringan saya langsung ke jaringan lain. Dalam kasus khusus ini, lalu lintas memasuki jaringan kami dari jaringan Sky, melewati apa yang dikenal sebagai London Internet Exchange, atau LINX.
Penyerang mulai melewati banyak lalu lintas melalui LINX sebagai port. Kami memiliki port di LINX dengan kemampuan yang relatif sederhana, jadi jika Anda mengirim 300 pertunjukan lalu lintas ke port LINX, Anda membebani port kami dan port lain dari pertukaran ini. Jadi solusi yang paling masuk akal bagi kami adalah memutuskan koneksi melalui port ini, segera setelah kami melihat itu sedang diserang, dan lalu lintas "mengalir" di sekitarnya dengan cara lain.
Masalahnya adalah bahwa ada kerusakan jaminan yang mempengaruhi port LINX lainnya, sehingga penyedia jaringan Internet besar lainnya juga mengalami masalah karena kami menurunkan lalu lintas. Ini agak tidak menyenangkan, dan kemudian kami bekerja dengan mereka untuk membantu mereka melindungi jaringan mereka.
Serangan itu menyebabkan pelanggaran regional sementara, tetapi kami memiliki peluang bagus untuk mengalihkan lalu lintas ke node lain untuk menciptakan kemampuan untuk tetap online untuk Spamhaus dan semua pelanggan kami lainnya. Penyerang juga mempengaruhi penyedia transit tingkat tinggi kami, mengirimkan sejumlah besar lalu lintas kepada orang-orang yang memiliki kontrak dengan kami untuk layanan jaringan. Tujuan mereka adalah untuk menimbulkan ketidaknyamanan bagi pelanggan kami sebanyak mungkin, sehingga bagian dari infrastruktur jaringan yang tidak terkait langsung dengan jaringan kami terpengaruh.
Mungkin saja serangan itu mencapai tingkat yang lebih tinggi, namun, saya tidak memiliki data yang akan mengkonfirmasi ini, tetapi mereka menyerang router dasar yang beroperasi di inti berbagai jaringan. Sebenarnya, serangan ini berfungsi sebagai pentest raksasa tidak hanya untuk jaringan kami, tetapi juga untuk jaringan yang mengelilingi kami, penyedia yang kami gunakan dan penyedia yang digunakan penyedia ini. Ternyata berkat serangan ini kami melakukan audit kerentanan kami. Kemudian, kami pergi ke berbagai pertukaran Internet seperti London dan menerapkan solusi terbaik dalam hal mengatur jaringan mereka untuk meningkatkan efektivitas menentang serangan semacam itu. Kami menemukan bahwa semua lalu lintas internal organisasi tidak boleh dialihkan melalui router tepi jaringan. Jadi, jika Anda tidak ingin menyerang salah satu pertukaran ini dalam jaringan pertukaran Internet, alamat IP-nya tidak boleh dialihkan melalui pertukaran ini. Idealnya, Anda harus menggunakan 192.168, salah satu alamat RFC 1918 yang tidak dapat diselesaikan yang tidak dapat dialihkan dan melewati lalu lintas melalui dirinya sendiri, yaitu jaringan yang tidak memerlukan akses eksternal untuk beroperasi. Ini adalah hal terbaik yang dapat Anda lakukan untuk menghadapi serangan semacam itu.
Ada hal-hal lain yang dapat Anda lakukan, seperti Next Hop Self routing secara internal, untuk memastikan bahwa lalu lintas yang dimaksudkan untuk transmisi di dalam jaringan tidak akan menggunakan paket yang datang dari luar. Anda seharusnya tidak hanya melakukan ini untuk jaringan Anda sendiri, tetapi juga meyakinkan penyedia hulu untuk melakukan hal yang sama.
Ada hal lain yang berguna - pemfilteran batas untuk alamat IP tertentu, berdasarkan pada pemahaman tentang operasi aplikasi kita. Sebagai contoh, aplikasi kita bekerja dengan protokol yang berbeda, dan jika kita melihat paket UDP yang tidak ditujukan untuk server DNS kita, maka ada yang tidak beres.
Sejak itu, kami telah membagi jaringan kami sedemikian rupa sehingga alamat IP untuk server web berbeda dari alamat IP untuk server DNS, dan kami dapat meminta penyedia upstream kami untuk hanya memblokir semua lalu lintas UDP yang datang ke alamat IP khusus ini untuk memastikan keamanan segmen jaringan kami. Pemisahan alamat ini memungkinkan kami melakukan penyaringan lalu lintas tingkat tinggi yang lebih agresif.
Filter BGP Flowspec adalah teman sejati kami, itu adalah protokol yang diusulkan Cisco. Terlepas dari kenyataan bahwa ada bug di dalamnya, kami menggunakan protokol ini dan lebih suka penyedia transit juga menggunakannya, karena memungkinkan kami untuk mentransfer aturan kami ke node jaringan jarak jauh yang mempengaruhi rute kami. Ini memungkinkan Anda untuk dengan cepat merespons serangan semacam itu.
Arsitektur nLayer tiga tingkat patut mendapat perhatian khusus, dan saya ingin mengucapkan terima kasih yang mendalam kepada para penciptanya dari GTT, yang telah melakukan pekerjaan luar biasa untuk membuat jaringan mereka sangat tahan terhadap serangan. Segera setelah mereka melihat puncak serangan ini, mereka dengan cepat mengalahkan lalu lintas bahkan dari perbatasan jaringan mereka. Pernahkah Anda bertanya-tanya betapa kerennya menjadi penyedia Tier-1, Layer3 atau NTT? Semua pekerjaan mereka adalah akhir pekan yang solid, karena penyedia tingkat pertama tidak membayar siapa pun untuk koneksi, dan ini juga berarti bahwa mereka tidak dapat mentransfer transit ke siapa pun. Ketika kami mulai memblokir serangan dengan memutuskan segmen jaringan kami, dampaknya terkonsentrasi pada sejumlah kecil penyedia Tier-1 yang berada di pusat serangan, dan "lubang hitam" terbentuk di dalam jaringan mereka, ke mana semua lalu lintas bergegas, karena tidak ada tempat untuk pergi . Jadi itu adalah ujian yang sulit bagi banyak penyedia tingkat pertama.
Ini adalah salah satu alasan Anda melihat Open Resolver Project dibuat pada hari Senin pertama setelah serangan. Orang-orang dari nLayer benar-benar tim yang mengerti teknologi dan mereka banyak membantu kami. Mereka memperlakukan kami dengan pengertian, dan tidak hanya mengatakan: "Keluar dari sini, Anda membuat terlalu banyak masalah bagi kami." Jadi, kami telah mengembangkan langkah-langkah praktis yang dapat Anda ambil untuk memastikan jaringan Anda aman.
Ini adalah empat rekomendasi, yang pertama kedengarannya konyol, tetapi jelas: pertama pastikan bahwa Anda bukan bagian dari masalah! Saya pikir banyak orang telah mengatakan ini kepada Anda dalam beberapa tahun terakhir. Berhentilah selama setidaknya satu detik dan periksa apakah kedua komponen ini tidak berjalan di jaringan Anda.
Yang pertama adalah resolvers terbuka. Jika mereka berada di ruang alamat IP perusahaan, jika pelanggan Anda menggunakannya, Anda perlu memblokir mereka atau membatasi kecepatan lalu lintas. Bahkan lebih baik untuk mengonfigurasi resolver sehingga mereka hanya menerima lalu lintas yang datang langsung dari jaringan Anda.
Pada slide ini, Anda melihat artikel favorit saya di The Register, yang ditulis oleh Trevor Pott. Itu disebut "Mengenali Profesional TI: Bagaimana Saya Membantu Serangan DDoS Terbesar."
Trevor menulis, “Saya pikir saya melakukan semuanya dengan benar. Tetapi ternyata saya memiliki resolver terbuka, dan saya melihat melalui traffic traffic bagaimana permintaan mencapai Spamhouse. " Saya tahu bahwa ada orang yang bertanggung jawab atas pengoperasian jaringan yang sangat besar yang memiliki resolvers DNS terbuka. Dengan melakukan ini, Anda berkontribusi pada penciptaan masalah di atas, jadi saya meminta Anda untuk menghabiskan waktu secara harfiah kedua dan menyingkirkan mereka.
Kedua, pastikan Anda menggunakan BCP38. Orang-orang dari jaringan iBall telah melakukan pekerjaan dengan baik, tetapi banyak orang yang menyediakan jaringan besar di sini percaya bahwa jaringan ditutup jika mereka tidak mengizinkan akses eksternal.
Namun, misalkan Anda memiliki satu server WordPress yang dikompromikan di jaringan Anda yang dapat memulai spoofing paket sumber yang tidak ditujukan untuk jaringan Anda, dan ini akan menyebabkan masalah besar bagi sisa Internet.
Masalahnya adalah resolvers terbuka, ini adalah 28 juta resolver, yang jumlahnya meningkat setiap minggu. Kita bisa mengalahkan masalah ini hanya dengan upaya bersama. Anda harus menetapkan tanda pada router perbatasan Anda yang memastikan bahwa mereka hanya menerima paket dari sumber tepercaya dalam jaringan Anda. Jika Anda melakukan ini, maka tolak penyerang kesempatan untuk mengeksploitasi kerentanan ini. Kesulitannya adalah menemukan mesin-mesin besar yang beroperasi di jaringan dan yang memungkinkan spoofing.
Jika Anda melihat serangan brute-force di WordPress, dan ada serangan lain di sana, misalnya, menggunakan jaringan botnet, maka akan sulit bagi Anda untuk menebak bahwa alasannya justru karena kemampuan menggunakan spoofing.
Rekomendasi lain adalah menggunakan protokol yang benar-benar andal. Anda dapat mengatakan: "Hai, saya mendapatkan alamat IP ini dan saya memulai layanan menggunakan UDP, dan layanan menggunakan TCP dan lalu lintas lainnya melalui ICMP, dan saya akan mengikat semua protokol ini ke IP yang sama." Saya ingin memperingatkan Anda bahwa jika muncul masalah yang membatasi kemampuan Anda untuk merespons secara fleksibel terhadap jenis serangan ini, terutama karena Anda dapat dengan mudah membagi jaringan sehingga setiap protokol bekerja pada alamat IP sendiri. Terbaik jika Anda dapat menyaring lalu lintas hulu. Tujuan dari setiap serangan ini bukan untuk menghentikan lalu lintas di dalam jaringan Anda, tetapi untuk memblokirnya sedekat mungkin dengan sumber lalu lintas, oleh karena itu, dengan memberi seseorang kesempatan untuk memblokir semua lalu lintas UDP yang diarahkan ke setiap IP, kecuali untuk alamat yang dipilih, Anda akan secara signifikan mengurangi permukaan serangan. yang bisa digunakan oleh penyerang.
Dengan demikian, protokol terpisah untuk masing-masing IP bekerja secara efektif ketika berinteraksi dengan penyedia hulu. Anda hanya mengajukan pertanyaan kepada mereka: "Hei, bisakah Anda menerapkan jenis penyaringan ini?". Ngomong-ngomong, salah satu alasan mengapa kita, sebagai pemasok, mendukung Flowspec adalah bahwa kita dapat dengan tepat bertanya kepada mereka: “Teman-teman, apakah Anda mendukung Flowspec?”, Dan jika mereka menjawab “Ya”, percakapan sudah selesai, dan kita dapat menggunakan filter kita sendiri di tepi jaringan secepat yang kita inginkan.
Rekomendasi ketiga adalah implementasi infrastruktur ACL, yaitu, penggunaan daftar kontrol akses. Maksud saya, sebuah paket tidak dapat ditentukan untuk jaringan internal Anda jika sumbernya bukan milik jaringan internal ini. Jika sebuah paket berasal dari jaringan Anda atau memasuki jaringan Anda dari router tepi, itu tidak boleh "bepergian" melalui infrastruktur jaringan internal Anda. Ada banyak cara untuk mengimplementasikan ketentuan ini. Anda dapat menerapkan penyaringan untuk mencegah beberapa alamat IP dari mencapai batas-batas jaringan, Anda dapat menggunakan Next Hop Self routing untuk mencegah akses ke beberapa alamat internal, Anda dapat menggunakan protokol RFC 1918 di dalam jaringan untuk memastikan bahwa IP internal Anda tidak digunakan untuk mengatasi dari dunia luar.
Ini benar-benar dapat membawa sakit kepala tambahan, karena memaksa Anda untuk memeriksa pengaturan router, benar-benar menggunakan jaringan VPN, daripada berpura-pura menggunakannya, dan seterusnya. Ini bukan solusi yang paling populer, tetapi jika tidak diimplementasikan, maka penyerang dapat melihat ke dalam jaringan Anda dan membidik segmen individu untuk melakukan lebih banyak kerusakan.
Rekomendasi keempat adalah Anda harus mengetahui lalu lintas hulu Anda dengan baik. Saya ingin menekankan sekali lagi bahwa serangan ini tidak menggunakan aplikasi kompleks atau paket-syn, itu hanya manusia gua dengan klub berat. Di satu sisi, Anda harus memiliki lebih banyak transit daripada orang jahat. Ini dapat menghasilkan 300 Gbps traffic, dan saya yakin beberapa dari mereka yang hadir dapat membanggakan jaringan dengan volume traffic yang demikian. Ini berarti bahwa Anda harus memiliki teman yang memiliki banyak lalu lintas keluar, dan, menariknya untuk bekerja sama, Anda melindungi Anda dari serangan semacam itu. Kami sangat selektif tentang lalu lintas keluar yang kami gunakan untuk dapat melihat serangan semacam ini pada waktunya.
Suatu hari, saya berbicara dengan kepala petugas teknis dari penyedia transit utama dan bertanya apakah dia akan menjual saya transit, yang dia jawab - tidak, teman-teman, dari sini Anda hanya akan mendapatkan sakit kepala tambahan sebagai klien.
Namun, kami mencari lalu lintas seperti itu dan bahkan membayar penyedia transit bonus yang kami gunakan, karena ketika serangan semacam ini terjadi, kami ingin dapat memanggil mereka dan meminta bantuan untuk mengurangi konsekuensi dari serangan itu. Anda tidak perlu membangun jaringan dengan throughput 3-4-5 terabit, jika Anda dapat mendistribusikan lalu lintas puncak di antara jaringan mitra.
Ini tidak harus menjadi perusahaan dengan perlindungan DDoS yang kuat, mereka hanya perlu menggunakan arsitektur nLayer untuk benar-benar melakukan pekerjaan mereka dan membantu Anda ketika masalah muncul. Bekerja sama dengan mereka untuk memperluas batas-batas jaringan Anda. Gunakan kebijakan konfigurasi jaringan yang memungkinkan Anda untuk bergabung dengan perbatasan jaringan mereka, dan penyedia bersedia melakukan ini jika Anda memiliki penyedia jaringan yang kompeten. Itulah keseluruhan cerita tentang serangan 300 gigabit, kami memiliki sekitar 10 menit tersisa untuk menjawab pertanyaan Anda.
Saya meminta Anda untuk menggunakan mikrofon jika Anda setuju untuk mengantre untuk mengajukan pertanyaan. Inovasi lain yang saya lupa katakan tentang: penyelenggara Blackhat ingin mendapatkan umpan balik dengan pembicara, dan jika Anda "menerangi" lencana Anda dari luar, mereka akan mentransfer informasi Anda ke NSA dan juga menerima umpan balik. Saya bercanda tentang bagian pertama, tetapi relatif kedua benar - Anda dapat menggunakan umpan balik, sehingga Anda dapat memanggil saya orang idiot dan umumnya mengajukan pertanyaan.
Pertanyaan: Protokol amplifikasi apa, selain UDP dan 53, yang Anda temui saat menjalankan CloudFlare?
Jawab: Anda bertanya, apakah ada protokol amplifikasi lain selain yang disebutkan? Kami masih mengamati penggunaan ICMP dalam melakukan serangan Smurf tua yang baik, tetapi tidak ada yang sebanding dengan skala serangan yang saya katakan. Jadi tahun depan kami akan menegaskan bahwa orang-orang tidak menggunakan resolvers terbuka, tetapi menggunakan server DNS yang sah dan resmi. Gunakan CloudFlare, Bind atau UltraDNS untuk memulai jaringan Anda, dan jika Anda dapat mendaftar semua domain yang menjadi tanggung jawab server resmi, menemukan domain yang memiliki daftar nama yang sangat besar, Anda dapat melindungi jaringan Anda, karena server seperti itu dapat membatasi jika perlu kecepatan lalu lintas. Kami telah mencurahkan banyak waktu untuk implementasi solusi ini, dan saya akan dengan senang hati memberitahukan hal ini kepada mereka yang benar-benar tertarik.
Pertanyaan: Botnet tidak digunakan dalam serangan ini, tetapi dapatkah Anda merekomendasikan sumber daya yang memungkinkan untuk mendeteksi apakah jaringan besar yang Anda kontrol menggunakan botnet untuk melakukan serangan DDoS?
Jawaban: itu tergantung pada di mana Anda berada - misalnya, Anda dapat mencari alat seperti itu di organisasi yang memantau perilaku botnet dan menemukan yang sesuai dengan kebutuhan Anda. Jika Anda memerlukan proyek open source, saya sarankan Honeypot, yang muncul beberapa tahun yang lalu. Dengan itu, kami secara efektif memantau bagian penting dari jaringan botnet global, Anda dapat menentukan rentang alamat IP Anda dan itu akan ditampilkan jika ada jaringan jahat di sana. Ini hanyalah salah satu dari banyak proyek semacam itu. Anda cukup mencari pola lalu lintas abnormal yang ditemukan di jaringan Anda, jadi jika Anda melihat gigabit lalu lintas yang dirutekan ke satu alamat IP, dan tidak ada alasan yang masuk akal mengapa ini terjadi pada waktu tertentu, maka lalu lintas ini mungkin akan datang bukan dari server web, tetapi dari jaringan botnet. Ini seharusnya membuat Anda curiga.
Pertanyaan: Google memiliki salah satu penyelesai DNS terbuka paling populer, bukankah menurut Anda ini dapat menyebabkan masalah?
Jawaban: mereka melakukan banyak pekerjaan untuk membatasi lalu lintas, dan cara terbaik untuk memverifikasi ini adalah dengan menggunakan permintaan yang sama seperti yang saya berikan kepada Anda sebagai contoh, dan mengganti alamat IP jaringan PCCW dengan 888. Siapa pun yang hadir dapat mengirim permintaan ini hanya satu kali, ulangi itu tidak akan berhasil. . , – UDP, , , , .
: , BGP Flowspec, , , , , , BGP Flowspec?
: , BGP Flowspec, - Cisco, . , , , . , Flowspec , . , Juniper, Flowspec. , 12 Cisco .
: Flowspec CloudFlare?
: , . , , Flowspec. , . , Flowspec, , . , , upstream-.
: CloudFlare, . , - , . , : «, »?
: , , . , , , , . , DDoS- , , 300 / . , Akamai, . , , «», , . , , .
, , , , . , , , . , , Akamai, Amazon, CloudFlare, Google, , , . , , ?
: , BC38, , DNSSec…
: , DNSSec!
: , , DNSSec, , ?
: . , DNSSec , . ? . , , – DNSSec , . , DNSSec, , , DNS-, .
DNSSec, , , , DNSSec. , Cloudflare, DNS, , . DNS- .
: upstream- ? .
: , , , upstream-. , . CloudFlare , , .
, , , - . , DNS DDoS: , , , .
Pertanyaan: Mungkinkah Anda menggeser pengeluaran Anda untuk membayar lalu lintas yang berlebihan karena serangan DDoS kepada pelanggan Anda, memotivasi keputusan ini dengan fakta bahwa mereka membutuhkan terlalu banyak uang dari Anda?Jawab: Anda meremehkan berapa banyak uang yang kami miliki di bank!Terima kasih semua, saya akan senang untuk berbicara dengan kalian di tempat lain, dan sekarang saatnya untuk menyerahkan platform ini ke pembicara berikutnya.Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikannya kepada teman-teman Anda,
diskon 30% untuk pengguna Habr pada analog unik dari server entry-level yang kami temukan untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps dari $ 20 atau bagaimana membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps hingga musim semi gratis ketika membayar selama setengah tahun, Anda dapat memesan di
sini .
Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV dari $ 249 di Belanda dan Amerika Serikat! Baca tentang
Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?