Konferensi DEFCON 19. Tiga generasi serangan DoS (melibatkan penonton sebagai korban). Bagian 1Tetapi lebih buruk lagi ... Saya mencoba mengembangkan sebuah proyek untuk murid-murid saya, dan ternyata lucu, tetapi masalahnya adalah bahwa tidak mungkin untuk melihat alamat "terbunuh", karena ini adalah apa yang Anda butuhkan untuk melihat konfigurasi IP. Tetapi jika saya melakukan serangan dengan sangat cepat, sistem akan segera merespons dan tidak ada yang akan melihat apa yang terjadi padanya.
Saya membuatnya sehingga Anda bisa melihat seluruh jaringan, semua alamat halaman jaringan ini demi halaman. Daftar ini dapat dibuat lebih besar, karena 5 alamat IP per detik ditambahkan ke dalamnya. Ketika saya memulai proyek ini untuk pertama kalinya, bagi saya sepertinya tidak ada yang terjadi, karena mesin Windows saya sepertinya tidak bereaksi sama sekali terhadap apa yang telah terjadi.
Siswa tidak akan tertarik, karena mereka tidak akan belajar apa-apa jika mereka tidak dapat melihat kerusakan yang disebabkan oleh serangan itu. Saya pikir “ok, ini proyek yang buruk, apa yang harus saya lakukan?”, Tetapi kemudian saya sadar - hal ini membunuh pengontrol domain, server mail dan semua itu, sangat buruk. Ini sangat buruk sehingga saya tidak bisa memberi tahu siswa saya tentang itu sama sekali, lebih baik saya akan memberi tahu Microsoft tentang hal itu dengan tenang!
Jadi saya mengirim tweet bahwa Windows 7 mengandung kerentanan berbahaya, yang, bagaimanapun, sama sekali tidak mengejutkan. Saya mengatakan bahwa sehubungan dengan ini saya memerlukan kontak dari layanan keamanan Windows, dan orang-orang di Twitter membantu saya menemukan orang yang tepat di Microsoft. Setelah 2 hari, saya mendapat tanggapan resmi dari Microsoft, di mana dilaporkan bahwa Mark Hughes memberi tahu mereka tentang hal ini setahun yang lalu. Tapi itu tidak masalah, karena mereka tidak berniat untuk melakukan koreksi ke versi Windows saat ini, karena Vista, Windows 7, Windows Server 2003, Windows Server 2008, Windows XP secara bertahap sekarat dan mereka berhenti mendukungnya. Sebaliknya, mereka akan memperbaiki kerentanan ini di Windows 8 atau Windows 9 jika mereka masih tidak menemukan sesuatu.
Saya pikir - baiklah, jika Anda akan bertindak seperti ini, saya akan memberi tahu seluruh dunia tentang hal itu dan membiarkan siswa saya menguji proyek ini sebagai pekerjaan rumah, memperingatkan mereka untuk menggunakannya dalam jaringan yang terisolasi, karena jika tidak, Anda dapat membunuh semua komputer di perguruan tinggi , termasuk server kami. Mereka melakukan hal itu, jadi saya masih mengajar di sana, daripada berdiri di jalan dengan cangkir untuk sedekah.
Bagaimanapun, ini adalah serangan yang sangat kuat, dan saya ingin berbicara sedikit tentang bagaimana Anda dapat bertahan melawannya. Tetapi sebelum saya mulai, saya akan menyerahkan masalah ini kepada Matthew, dan satu-satunya yang saya inginkan adalah Anda sekarang menguji dampak serangan ini pada diri Anda sendiri.
Semua mesin Windows dan komputer dengan salah satu versi Free BSD Unix rentan terhadap serangan RA Flood, tetapi mesin dengan MAC OS dan Open BSD tidak kebal terhadapnya. Jika Anda melihat konfigurasi MacBook saya, Anda akan melihat bahwa itu juga host dan telah bergabung dengan beberapa jaringan yang ada di sini, Anda lihat di sini jaringan inet6 dengan alamat mulai dari tahun 2001.
Dia terhubung ke beberapa jaringan yang tidak berguna ini, tetapi tidak ke semua jaringan. Saya pikir itu bisa menjadi jaringan DefCon. Tapi bagaimanapun, Anda melihat bahwa "MacBook" saya untuk beberapa waktu terhubung ke 10 jaringan pertama yang ditemukan dan tidak lagi memperhatikan RA. Ini adalah pertahanan yang sangat bagus, dan saya pikir Microsoft seharusnya berasal dari Windows juga, tetapi mereka tidak tertarik dengan pendapat saya. Cisco merilis tambalan yang dirancang untuk melindungi peralatan mereka dari serangan semacam ini, dan Juniper belum melakukannya.
Jadi jika Anda memiliki perangkat untuk pengujian, Ryan akan mengatur jaringannya yang terisolasi dan membunuh seseorang di sana. Jika Anda ingin mengambil bagian dalam hal ini, Anda dapat bergabung dengan jaringan SSID yang disebut "Jangan gunakan", yang menggunakan enkripsi WPA2, jadi Anda harus memasukkan kata sandi "Jangan gunakan". Jika Anda bergabung dengan jaringan ini, Ryan akan melihat berapa banyak orang di jaringan dan membunuh Anda. Pembunuhan ini cukup menarik, karena membantu untuk mencari tahu apa perangkat lain yang rentan, kecuali untuk Windows dan Free BSD.
Beberapa orang mengatakan bahwa mereka akan membawa perangkat yang menarik di sini, dan saya ingin mengetahuinya, jadi saya akan meminta Anda setelah demonstrasi untuk pergi ke ruang Tanya Jawab dan membicarakannya. Lalu kami dapat memberi tahu pabrikan untuk mendorongnya agar merilis tambalan untuk kerentanan perangkatnya yang terungkap. Saya pikir banyak orang yang rentan terhadap serangan semacam ini, tetapi tidak mengetahuinya.
Sekarang saya akan memberikan dasar kepada Matius untuk menceritakan kisah LulzSec, dan kemudian saya akan melanjutkan pembicaraan tentang pertahanan, jika kita punya waktu. Untuk saat ini, saya akan menutup semua jendela untuk menghapus desktop. Maaf, nama jaringannya adalah "Jangan terhubung" dan kata sandinya juga "Jangan terhubung"!
Matthew Prince: Sam adalah satu-satunya orang yang saya kenal yang dapat melakukan serangan DDoS dengan pesona seperti itu. Nama saya Matthew Prince, saya tahu Sam, kami berdua tinggal di San Francisco dan keduanya terlibat dalam kisah LulzSec.
Oleh karena itu, saya akan menceritakan sebuah kisah tentang bagaimana mereka menyeret saya ke sini, tentang beberapa serangan DDoS yang kami amati selama 23 hari, dan tentang apa yang kami lakukan untuk menghentikannya.
Pada tanggal 2 Juni 2011, sekitar pukul 16.54 GMT, LulzSec mengumumkan di akun Twitter mereka bahwa mereka telah membuat halaman Keamanan Lulz di
lulzsecurity.com . Yang mengejutkan adalah bahwa halaman ini sedang offline selama 15 menit karena serangan DDoS yang kuat. Saya tidak tahu perincian serangan khusus ini, karena kami belum terlibat dalam hal ini.
Sekitar satu jam setelah posting tentang penciptaan halaman dipublikasikan, LulzSec tweeted bahwa mereka mampu memecahkan masalah penolakan layanan. Satu-satunya hal yang telah berubah selama waktu ini, seperti yang kemudian saya ketahui, adalah mereka mendaftar untuk layanan CloudFlare kami 9 menit sebelum pesan ini. Kami membuat situs web lebih cepat dan melindunginya dari beberapa jenis serangan, tetapi kami tidak menganggap diri kami sebagai layanan untuk mencegah serangan DDoS, sehingga beberapa dari kami terkejut dengan tindakan LulzSec ini.
Kejutan besar lainnya adalah ketika satu jam kemudian, peretas mempublikasikan pesan yang ditujukan kepada saya di mana mereka mengakui cinta mereka untuk CloudFlare dan bertanya apakah mereka dapat mengandalkan akun premium gratis sebagai ganti rum.
Saya tidak tahu siapa LulzSec itu pada waktu itu, jadi saya menulis pesan di Twitter, yang kemudian dihapus oleh pengacara saya: "Itu tergantung pada seberapa bagus rum itu." Saya harus segera mengatakan bahwa mereka tidak pernah mengirimi kami rum, dan kami tidak pernah memberi mereka akun pro. Tetapi CloudFlare adalah layanan gratis, setiap hari kami memiliki ribuan situs terdaftar, dan biasanya kami tidak memiliki masalah dengan mereka.
Jadi, selama 23 hari ke depan, orang-orang ini mendatangkan malapetaka dalam berbagai cara. Akhirnya, pada 25 Juni, mereka memposting tweet yang menandai akhir dari serangan itu.
Sangat menarik bahwa CloudFlare berfungsi sebagai proxy terbalik, jadi semua lalu lintas yang menuju ke Lulz Security pertama kali melewati jaringan kami, yang memiliki dua efek signifikan. Yang pertama - siapa pun yang menyerang Lulz Security menyerang kami, yang kedua - terima kasih kepada kami, Lulz Security dapat menyembunyikan lokasi sumber serangan mereka, yaitu tempat hosting mereka sebenarnya berada. Ini adalah efek samping dari arsitektur sistem kami, tetapi peretas telah menggunakannya untuk keuntungan mereka.
Sam menghubungi saya beberapa waktu yang lalu dan mengatakan dia akan berbicara tentang DDoS. Kami berbicara tentang pengalaman kami dan dia bertanya apakah saya bisa berbagi informasi tentang ini. Kami memiliki penasihat hukum, kami adalah perusahaan nyata dengan kebijakan privasi kami sendiri, dan bahkan jika Anda berada di daftar orang yang dicari secara internasional untuk kejahatan dunia maya, kami berusaha untuk menghormati privasi Anda. Karena itu, saya menulis surat kepada LulzSec dan mengirimkannya ke alamat email yang ditunjukkan oleh mereka di akun saya.
Saya mengatakan kepada mereka bahwa saya diundang ke DefCon sebagai pembicara, jadi saya berbicara tentang serangan terhadap CloudFlare terkait dengan aktivitas komunitas mereka. Saya menulis bahwa beberapa informasi yang ingin saya komunikasikan selama presentasi saya dilindungi oleh kebijakan privasi kami, jadi saya meminta LulzSec untuk menyetujui pengungkapannya. Setelah 11 hari, seseorang bernama Jack Sparrow menjawab saya dengan teks: "Anda mendapat persetujuan saya."
Dan inilah saya, untuk membicarakan beberapa hal yang tidak dapat saya bicarakan tanpa izin ini. Saya dapat berbicara tentang bagaimana mereka memengaruhi kami, tetapi saya tidak akan mengungkapkan kepada Anda host yang mereka gunakan untuk menyerang atau alamat IP asli.
Biarkan saya memberi tahu Anda sedikit lebih banyak tentang apa yang terjadi dalam 23 hari ini dan menunjukkan analisis lalu lintas aktual ke situs web Lulz Security selama waktu ini.
Selama waktu ini, lebih dari 18 juta tampilan halaman dibuat ketika orang mengunjungi situs ini. Anda dapat melihat bahwa hampir sejak awal serangan dari 22 Juni hingga 5 Juli, puncak lalu lintas normal diamati, dan kemudian situs berhenti bekerja, meskipun masih menggunakan CloudFlare. Jika Anda mencoba mengunjungi situs ini hari ini, Anda hanya akan melihat halaman konfigurasi Apache di sana, dan saya tidak tahu apa yang akan mereka lakukan selanjutnya.
Sangat menarik untuk melihat lalu lintas serangan yang menjatuhkan situs.
Saya akan mengatakan bahwa semua lalu lintas ke puncak di tengah hanya kebisingan latar belakang normal, di mana tidak ada yang istimewa dan yang tidak menandakan apa pun dari apa yang akan saya tunjukkan pada slide dalam beberapa detik. Faktanya, tiga minggu selama LulzSec menggunakan layanan CloudFlare cukup tenang mengenai serangan DoS. Ini aneh karena banyak orang mengatakan bahwa mereka menyerang LulzSec pada waktu itu.
Puncak di tengah grafik disebabkan oleh beberapa peristiwa yang sangat jelas, yang akan saya bahas nanti. Kami juga akan berbicara tentang jenis serangan yang digunakan terhadap LulzSec dan apa yang kami lakukan untuk melindungi diri.
Peristiwa yang sangat menarik terjadi pada 25 Juni. Itu dikaitkan dengan Jester. Saya tidak tahu siapa dia, jadi Sam memberi saya beberapa materi tentang dia.
Tampaknya Jester menghabiskan banyak waktu mencari tahu lokasi situs web LulzSec dan dengan bangga menerbitkan alamat IP sumber daya mereka di
halamannya : www.lulzsecurity.com: 204.197.240.133 dan lulzsecurity.com: 111.90.139.55.
Saya tahu host situs web LulzSec pada tanggal 25 Juni dan saya dapat memberi tahu Anda bahwa alamat ini tidak ada hubungannya dengan itu. Selama 23 hari ini, mereka menggunakan 7 host berbeda, awalnya host tersebut berlokasi di Montreal, Kanada. Untuk beberapa waktu, pada awal Juni, hosting Malaysia digunakan dengan alamat IP 111.90.139.55. Sebagian besar host yang mereka gunakan berlokasi di Amerika Serikat, termasuk satu host besar yang mengkhususkan diri dalam mengurangi efek serangan DoS, dan pada akhirnya mereka beralih ke hosting Jerman, di mana situs tersebut berada hari ini.
Menariknya, banyak orang mengklaim bahwa merekalah yang menjatuhkan situs web LulzSec dan memposting foto yang relevan ke Internet. Bahkan, ini hanya menunjukkan layanan yang kami tawarkan di CloudFlare - jika server back-end Anda terputus, kami menunjukkan versi cached-nya, sebagaimana dibuktikan oleh bilah oranye di bagian atas halaman. Ini memberi tahu pengguna bahwa ia sedang menelusuri cache, sama halnya dengan cache halaman di Google.
Saya pikir ketika orang-orang mengklaim bahwa mereka telah menurunkan situs LulzSec, yang sebenarnya terjadi adalah orang-orang dari LulzSec diusir begitu saja dari tuan rumah mereka. Jadi, untuk periode 36 jam yang singkat, mereka benar-benar menunjukkan alamat IP yang tidak valid 2.2.2.2 sebagai alamat mereka, karena tidak ada host atau server web aktif di bawah alamat ini. Saya pikir mereka hanya memilih alamat IP acak sehingga sistem kami hanya "mendorong" mereka secara online, karena versi cache ada untuk jangka waktu terbatas hingga habis masa berlakunya. Pada titik ini, mereka secara singkat kembali ke host dan menunjukkan alamat palsu hanya untuk muncul di cache kami.
Saya tidak tahu satu orang yang akan menunjukkan bahwa situs web LulzSec bekerja offline setidaknya untuk waktu yang singkat, terlepas dari kenyataan bahwa banyak orang mencoba untuk mematikannya dari mode online. Bahkan, pada saat yang sama LulzSec yang menjatuhkan situs orang lain, misalnya, situs web CIA, dan menarik untuk mengamati serangan-serangan ini. Slide daftar serangan mana yang kami amati.
Kami sangat terkejut dan benar-benar "menempatkan semua orang di telinga" selama serangan DDoS, yang mencoba menjatuhkan situs selama tiga minggu, karena kami biasanya mengamati serangan yang berlangsung dalam periode waktu yang jauh lebih singkat. Tidaklah berbahaya untuk menggoda para peretas yang merumput di Twitter seperti menggoda para mafia dunia maya Cina atau Eropa Timur atau orang-orang yang terlibat dalam pemerasan internet, karena merekalah yang mampu melakukan serangan DDoS yang kuat. Ya, orang-orang ini juga cukup pintar, tapi tetap saja, serangan seperti itu bukan level mereka.
Kami telah mengamati beberapa serangan yang relatif tidak berbahaya di OSI level 7 menggunakan alat seperti Slowloris. Tetapi server web internal CloudFlare dirancang khusus untuk tidak hanya "membunuh" serangan ke tingkat 7, tetapi juga untuk memperbaiki semua alamat IP dari mana serangan ini dibuat. Maksudku, pada kenyataannya, kita hanya senang ketika peretas menyerang tingkat ke-7 kita, karena serangan DDoS pada tingkat 3 atau 4 menyebabkan kita lebih banyak kesulitan.
Dalam hal ini, kami mengurangi konsekuensi mereka, karena kami menggunakan jaringan Anycast. Ini berarti bahwa kami memiliki banyak mesin, ratusan dan ratusan komputer yang bekerja di 14 pusat data yang berbeda di seluruh dunia dan terikat dengan alamat IP yang sama.
Ini memungkinkan Anda untuk "menyemprotkan" DoS terdistribusi - serangan atau serangan dengan sejumlah besar lalu lintas ke permukaan jaringan yang besar, yang membuatnya sangat sulit untuk menggunakan serangan semacam itu terhadap kami.
Lebih banyak masalah membawa kami serangan dari jenis yang berbeda. Yang pertama diproduksi menggunakan sesuatu seperti jaringan yang sangat besar dengan sejumlah besar lalu lintas yang dikirim penyerang langsung kepada kami. Jaringan ini terletak secara geografis dekat dengan pusat data kami di San Jose, dan mereka menggunakan hampir semua bandwidthnya. Kami harus mentransfer pelanggan kami ke pusat data lain yang kurang sibuk, jadi ini tidak mempengaruhi mereka. Tetapi pusat data di San Jose pada waktu itu hanya dapat melayani Lulz Security, sambil terus menjaga mereka online.
Serangan yang lebih menarik, yang mengancam sebagian besar orang yang terhubung dengan kami, menggunakan Google sebagai "reflektor" lalu lintas. Kami mematuhi aturan khusus mengenai alamat IP Google untuk memastikan bahwa kami tidak pernah memblokir lalu lintas yang sah datang dari sana kepada kami. Seseorang yang benar-benar pintar menemukan bahwa jika Anda mengirim banyak permintaan SYN ke Google dengan tajuk palsu yang menunjuk ke alamat IP kami, maka Google akan mengembalikannya kepada kami. Solusi untuk masalah ini cukup sederhana dan hanya membutuhkan beberapa menit - kami memblokir ACK yang tidak dilampirkan SYN, dan kemudian memanggil teman-teman kami di Google dan mengatakan bahwa mereka tidak akan pernah menerima lalu lintas dari sumber-sumber ini, jadi gunakan firewall untuk melawan mereka . Itu adalah serangan yang benar-benar cerdas yang memperhitungkan sifat infrastruktur kami dan memanfaatkan fitur-fitur kerjanya.
Serangan terakhir, yang menyebabkan kami banyak masalah, didasarkan pada fakta bahwa seseorang dengan hati-hati memindai rentang alamat IP kami dan menemukan antarmuka router di sana yang terkena pengaruh eksternal. Menggunakan ini, penyerang meluncurkan serangan jenis kamus dan menonaktifkan beberapa router kami, setelah berhasil melewati Anycast.
Solusi untuk masalah ini ternyata cukup sederhana - kami memblokir alamat IP yang berada di luar jaringan kami, tetapi serangan itu tetap saja menyebabkan kerusakan, karena selama beberapa menit router kami pingsan offline.
Anda tahu, ketika saya membandingkan serangan terbesar yang kami saksikan, saya bahkan menontonnya ketika klien kami menerima email dengan teks: "Halo, kami adalah agen pemerintah Tiongkok yang telah menemukan bahwa seseorang di jaringan akan menyerang Anda "Dan jika Anda mengirimi kami $ 10.000, maka kami mungkin akan bisa menyelesaikan masalah ini." Jelas, ini bukan agen, tetapi mereka benar-benar dapat menyelesaikan masalah ini, karena mereka sendiri yang membuatnya. Namun, ada beberapa serangan semacam itu.
Saya akan berbicara tentang beberapa hal yang lebih menarik. Lonjakan latar belakang lalu lintas latar belakang normal bertepatan dengan pernyataan LulzSec bahwa mereka menabrak server Minecraft. Setelah serangan berakhir, lalu lintas sedikit menurun.
Penggemar Minecraft di kantor kami memulai perdebatan besar tentang apakah LulzSec tidak boleh meninggalkan jaringan kami setelah itu, karena mereka melakukan banyak kerusakan dan secara umum, itu tidak keren sama sekali. Jadi Anda bisa belajar pelajaran bahwa jika Anda akan mengatur serangan DDoS terhadap seseorang, lebih baik tidak menyentuh Minecraft.
Saya memiliki sedikit informasi tentang siapa sebenarnya orang-orang Lulz Security ini, bagi kami hanya salah satu nama pengguna yang membuat akun di Cloudflare. Ini sangat mirip dengan nama orang yang ditangkap, dan saya tidak tahu apakah ini hanya kebetulan atau apakah orang-orang ini benar-benar menjatuhkan situs-situs ini. Kami tidak melihat aktivitas hebat di belakang mereka untuk memindahkan host mereka, terlebih lagi, situs mereka sekarang turun.
Namun, menarik bagi kami untuk mengamati bagaimana seluruh dunia mencoba "membunuh" mereka selama 23 hari, dan karena itu, kami membantu mereka tetap bertahan. Terima kasih telah mengundang saya ke sini!
Sam Bone: Terima kasih, Matthew, telah memutuskan untuk datang. Sekarang saya akan kembali ke presentasi saya. Saya mendengar banyak pembicaraan tentang bagaimana menyerang lebih mudah daripada bertahan, jadi saya akan menunjukkan kepada Anda serangan yang akan menghilangkannya. , , Microsoft , . . , RA Flood.
, IPv6, , , . Router Discovery , , IPv6, , , .
RA Windows, . , . Cisco RA Guard, Windows, . , Cisco . RA Guard , RA-, .
, : , . — , — , .
, , . , Mod Security, , DDoS 7- . , — IP- , , Tor , .
, Akamai, , . Load Balancer, , , . , , 4 , .
. , - HT More , DNS- C&C , . , . Flood- , Anonymous Low Orbit Ion Canon.
CloudFlare, , — , , , , . , , , . , CloudFlare, .
, . , , , . , – , , . , , .
, , ? - ? - ? ? , , . , . , !
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 buat 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).
Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang
Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?