Variti mengembangkan perlindungan terhadap bot dan serangan DDoS, dan juga melakukan pengujian stres dan beban. Pada konferensi HighLoad++ 2018 kami berbicara tentang cara mengamankan sumber daya dari berbagai jenis serangan. Singkatnya: isolasi bagian-bagian sistem, gunakan layanan cloud dan CDN, dan perbarui secara berkala. Namun Anda tetap tidak akan dapat menangani perlindungan tanpa perusahaan khusus :)
Sebelum membaca teks, Anda dapat membaca abstrak singkatnya .
Dan jika Anda tidak suka membaca atau hanya ingin menonton videonya, rekaman laporan kami ada di bawah spoiler.
Rekaman video laporan
Banyak perusahaan yang sudah mengetahui cara melakukan load test, namun tidak semua melakukan stress test. Beberapa pelanggan kami berpendapat bahwa situs mereka kebal karena mereka memiliki sistem beban tinggi, dan melindungi dengan baik dari serangan. Kami menunjukkan bahwa hal ini tidak sepenuhnya benar.
Tentu saja, sebelum melakukan pengujian, kami memperoleh izin dari pelanggan, ditandatangani dan dicap, dan dengan bantuan kami serangan DDoS tidak dapat dilakukan terhadap siapa pun. Pengujian dilakukan pada waktu yang dipilih oleh pelanggan, ketika lalu lintas ke sumber dayanya minimal, dan masalah akses tidak akan memengaruhi klien. Selain itu, karena selalu terjadi kesalahan selama proses pengujian, kami selalu berhubungan dengan pelanggan. Hal ini memungkinkan Anda tidak hanya melaporkan hasil yang dicapai, tetapi juga mengubah sesuatu selama pengujian. Setelah menyelesaikan pengujian, kami selalu membuat laporan di mana kami menunjukkan kekurangan yang terdeteksi dan memberikan rekomendasi untuk menghilangkan kelemahan situs.
Bagaimana kami bekerja?
Saat pengujian, kami meniru botnet. Karena kami bekerja dengan klien yang tidak berada di jaringan kami, untuk memastikan bahwa pengujian tidak berakhir pada menit pertama karena batasan atau perlindungan dipicu, kami menyediakan beban bukan dari satu IP, tetapi dari subnet kami sendiri. Selain itu, untuk membuat beban yang signifikan, kami memiliki server pengujian kami sendiri yang cukup kuat.
Postulat
Terlalu banyak bukan berarti baik
Semakin sedikit beban yang kita dapat menyebabkan kegagalan sumber daya, semakin baik. Jika Anda dapat membuat situs berhenti berfungsi dengan satu permintaan per detik, atau bahkan satu permintaan per menit, itu bagus. Karena menurut hukum kekejaman, pengguna atau penyerang secara tidak sengaja akan terjerumus ke dalam kerentanan khusus ini.
Kegagalan sebagian lebih baik daripada kegagalan total
Kami selalu menyarankan untuk membuat sistem menjadi heterogen. Selain itu, ada baiknya memisahkannya pada tingkat fisik, dan bukan hanya melalui containerisasi. Dalam kasus pemisahan fisik, bahkan jika ada sesuatu yang gagal di situs, ada kemungkinan besar bahwa situs tersebut tidak akan berhenti berfungsi sepenuhnya, dan pengguna akan terus memiliki akses ke setidaknya sebagian dari fungsi tersebut.
Arsitektur yang baik adalah dasar keberlanjutan
Toleransi kesalahan sumber daya dan kemampuannya menahan serangan dan beban harus ditetapkan pada tahap desain, bahkan pada tahap menggambar diagram alur pertama di notepad. Karena jika kesalahan fatal terjadi, ada kemungkinan untuk memperbaikinya di kemudian hari, namun sangat sulit.
Tidak hanya kodenya yang harus bagus, tetapi konfigurasinya juga harus bagus
Banyak orang berpikir bahwa tim pengembangan yang baik adalah jaminan layanan yang toleran terhadap kesalahan. Tim pengembangan yang baik sangat diperlukan, tetapi harus ada operasional yang baik, DevOps yang baik. Artinya, kita memerlukan spesialis yang dapat mengkonfigurasi Linux dan jaringan dengan benar, menulis konfigurasi dengan benar di nginx, menetapkan batasan, dll. Jika tidak, sumber daya hanya akan berfungsi dengan baik dalam pengujian, dan pada titik tertentu semuanya akan rusak dalam produksi.
Perbedaan antara pengujian beban dan pengujian stres
Pengujian beban memungkinkan Anda mengidentifikasi batas-batas fungsi sistem. Stress test bertujuan untuk menemukan kelemahan pada suatu sistem dan digunakan untuk memecahkan sistem tersebut serta melihat bagaimana perilakunya dalam proses kegagalan bagian-bagian tertentu. Dalam hal ini, sifat beban biasanya tidak diketahui oleh pelanggan sebelum stress test dimulai.
Ciri khas serangan L7
Kami biasanya membagi jenis beban menjadi beban pada level L7 dan L3&4. L7 adalah beban di tingkat aplikasi, paling sering itu berarti hanya HTTP, tetapi yang kami maksud adalah beban apa pun di tingkat protokol TCP.
Serangan L7 memiliki ciri khas tertentu. Pertama, mereka datang langsung ke aplikasi, artinya kecil kemungkinannya akan tercermin melalui sarana jaringan. Serangan semacam itu menggunakan logika, dan oleh karena itu, serangan ini menghabiskan CPU, memori, disk, database, dan sumber daya lainnya dengan sangat efisien dan dengan sedikit lalu lintas.
Banjir HTTP
Dalam kasus serangan apa pun, beban lebih mudah dibuat daripada ditangani, dan dalam kasus L7 hal ini juga berlaku. Tidak selalu mudah untuk membedakan lalu lintas serangan dari lalu lintas yang sah, dan paling sering hal ini dapat dilakukan berdasarkan frekuensi, tetapi jika semuanya direncanakan dengan benar, maka tidak mungkin untuk memahami dari log di mana serangan itu terjadi dan di mana permintaan yang sah berada.
Sebagai contoh pertama, pertimbangkan serangan HTTP Flood. Grafik menunjukkan bahwa serangan seperti itu biasanya sangat kuat; pada contoh di bawah, jumlah puncak permintaan melebihi 600 ribu per menit.
HTTP Flood adalah cara termudah untuk membuat beban. Biasanya, dibutuhkan semacam alat pengujian beban, seperti ApacheBench, dan menetapkan permintaan dan target. Dengan pendekatan sederhana seperti itu, ada kemungkinan besar terjadinya cache server, tetapi mudah untuk melewatinya. Misalnya, menambahkan string acak ke permintaan, yang akan memaksa server untuk terus-menerus menyajikan halaman baru.
Juga, jangan lupakan agen pengguna dalam proses pembuatan beban. Banyak agen pengguna alat pengujian populer difilter oleh administrator sistem, dan dalam hal ini beban mungkin tidak mencapai backend. Anda dapat meningkatkan hasilnya secara signifikan dengan memasukkan header yang kurang lebih valid dari browser ke dalam permintaan.
Meskipun serangan HTTP Flood sederhana, serangan ini juga mempunyai kelemahan. Pertama, diperlukan daya dalam jumlah besar untuk menciptakan beban. Kedua, serangan semacam itu sangat mudah dideteksi, apalagi jika berasal dari satu alamat. Akibatnya, permintaan segera mulai disaring baik oleh administrator sistem atau bahkan di tingkat penyedia.
Apa yang harus dicari
Untuk mengurangi jumlah permintaan per detik tanpa kehilangan efisiensi, Anda perlu menunjukkan sedikit imajinasi dan menjelajahi situs. Dengan demikian, Anda tidak hanya dapat memuat saluran atau server, tetapi juga masing-masing bagian aplikasi, misalnya database atau sistem file. Anda juga dapat mencari tempat di situs yang melakukan perhitungan besar: kalkulator, halaman pemilihan produk, dll. Terakhir, sering kali situs tersebut memiliki semacam skrip PHP yang menghasilkan halaman beberapa ratus ribu baris. Skrip seperti itu juga memuat server secara signifikan dan dapat menjadi sasaran serangan.
Di mana mencarinya?
Saat kami memindai sumber daya sebelum menguji, tentu saja pertama-tama kami melihat situs itu sendiri. Kami mencari semua jenis kolom input, file berat - secara umum, segala sesuatu yang dapat menimbulkan masalah pada sumber daya dan memperlambat pengoperasiannya. Alat pengembangan dangkal di Google Chrome dan Firefox membantu di sini, 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 membebaninya, ini dapat menimbulkan masalah pada sumber daya utama.
Situs ini mungkin memiliki subdomain api.abc.com. Kemungkinan besar, ini adalah sumber untuk aplikasi seluler. Aplikasi dapat ditemukan di App Store atau Google Play, memasang titik akses khusus, membedah API dan mendaftarkan akun pengujian. Masalahnya adalah orang sering berpikir bahwa apa pun yang dilindungi oleh otorisasi kebal terhadap serangan penolakan layanan. Seharusnya, otorisasi adalah CAPTCHA terbaik, namun sebenarnya bukan. Sangat mudah untuk membuat 10-20 akun pengujian, tetapi dengan membuatnya, kami mendapatkan akses ke fungsionalitas yang kompleks dan tidak disamarkan.
Biasanya, kami melihat riwayat, robots.txt dan WebArchive, ViewDNS, dan mencari sumber daya versi lama. Terkadang pengembang telah 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 padanya, tetapi terus menggunakan database. Oleh karena itu, dengan menggunakan versi lama, Anda dapat menggunakan sumber daya backend secara efektif dan segala sesuatu yang ada di balik tata letak. Tentu saja hal ini tidak selalu terjadi, namun hal ini masih cukup sering kita jumpai.
Secara alami, kami menganalisis semua parameter permintaan dan struktur cookie. Anda dapat, misalnya, membuang beberapa nilai ke dalam array JSON di dalam cookie, membuat banyak sarang, dan membuat sumber daya berfungsi untuk waktu yang sangat lama.
Beban pencarian
Hal pertama yang terlintas dalam pikiran saat meneliti suatu situs adalah memuat database, karena hampir semua orang memiliki pencarian, dan sayangnya, bagi hampir semua orang, database tersebut tidak terlindungi dengan baik. Untuk beberapa alasan, pengembang kurang memperhatikan pencarian. Namun ada satu rekomendasi di sini - Anda tidak boleh membuat permintaan dengan jenis yang sama, karena Anda mungkin mengalami caching, seperti halnya banjir HTTP.
Membuat query acak ke database juga tidak selalu efektif. Jauh lebih baik membuat daftar kata kunci yang relevan dengan pencarian. Jika kita kembali ke contoh toko online: katakanlah situs tersebut menjual ban mobil dan memungkinkan Anda mengatur radius ban, jenis mobil, dan parameter lainnya. Oleh karena itu, kombinasi kata yang relevan akan memaksa database bekerja dalam kondisi yang jauh lebih kompleks.
Selain itu, ada baiknya menggunakan penomoran halaman: jauh lebih sulit bagi pencarian untuk mengembalikan halaman kedua dari belakang hasil pencarian daripada yang pertama. Artinya, dengan bantuan penomoran halaman, Anda dapat sedikit mendiversifikasi beban.
Contoh di bawah ini menunjukkan beban pencarian. Terlihat bahwa sejak detik pertama pengujian dengan kecepatan sepuluh permintaan per detik, situs tersebut down dan tidak merespons.
Jika tidak ada pencarian?
Jika tidak ada pencarian, ini tidak berarti bahwa situs tersebut tidak berisi kolom input rentan lainnya. Bidang ini mungkin otorisasi. Saat ini, pengembang suka membuat hash yang kompleks untuk melindungi database login dari serangan tabel pelangi. Ini bagus, tetapi hash seperti itu menghabiskan banyak sumber daya CPU. Aliran besar otorisasi palsu menyebabkan kegagalan prosesor, dan akibatnya, situs berhenti bekerja.
Kehadiran segala macam bentuk komentar dan masukan di situs adalah alasan untuk mengirim teks yang sangat besar ke sana atau sekadar membuat banjir besar. Terkadang situs menerima file lampiran, termasuk dalam format gzip. Dalam hal ini, kami mengambil file 1TB, mengompresnya menjadi beberapa byte atau kilobyte menggunakan gzip dan mengirimkannya ke situs. Kemudian dibuka ritsletingnya dan diperoleh efek yang sangat menarik.
API sisanya
Saya ingin memberi sedikit perhatian pada layanan populer seperti Rest API. Mengamankan Rest API jauh lebih sulit daripada situs web biasa. Bahkan metode perlindungan sepele terhadap kekerasan kata sandi dan aktivitas tidak sah lainnya tidak berfungsi untuk Rest API.
Rest API sangat mudah dibobol karena mengakses database secara langsung. Pada saat yang sama, kegagalan layanan semacam itu menimbulkan konsekuensi yang cukup serius bagi bisnis. Faktanya adalah Rest API biasanya digunakan tidak hanya untuk situs web utama, tetapi juga untuk aplikasi seluler dan beberapa sumber daya bisnis internal. Dan jika semua ini gagal, maka efeknya jauh lebih kuat dibandingkan jika terjadi kegagalan situs web sederhana.
Memuat konten berat
Jika kami ditawari untuk menguji beberapa aplikasi satu halaman biasa, halaman arahan, atau situs web kartu nama yang tidak memiliki fungsi kompleks, kami mencari konten yang berat. Misalnya, gambar besar yang dikirimkan server, file biner, dokumentasi pdf - kami mencoba mengunduh semua ini. Pengujian semacam itu memuat sistem file dengan baik dan menyumbat saluran, sehingga efektif. Artinya, meskipun Anda tidak mematikan server, mengunduh file besar dengan kecepatan rendah, Anda hanya akan menyumbat saluran server target dan kemudian penolakan layanan akan terjadi.
Contoh pengujian tersebut menunjukkan bahwa pada kecepatan 30 RPS situs berhenti merespons atau menghasilkan kesalahan server ke-500.
Jangan lupa tentang menyiapkan server. Anda sering dapat menemukan seseorang membeli mesin virtual, menginstal Apache di sana, mengkonfigurasi semuanya secara default, menginstal aplikasi PHP, dan di bawah ini Anda dapat melihat hasilnya.
Disini bebannya sampai ke root dan hanya sebesar 10 RPS. Kami menunggu 5 menit dan server mogok. Memang benar bahwa tidak diketahui sepenuhnya mengapa dia terjatuh, tetapi ada asumsi bahwa dia memiliki terlalu banyak ingatan dan karena itu berhenti merespons.
Berbasis gelombang
Dalam satu atau dua tahun terakhir, serangan gelombang menjadi cukup populer. Hal ini disebabkan oleh fakta bahwa banyak organisasi membeli perangkat keras tertentu untuk perlindungan DDoS, yang memerlukan waktu tertentu untuk mengumpulkan statistik guna mulai memfilter serangan. Artinya, mereka tidak memfilter 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 hal di situs sehingga sumber daya akan bertahan lama hingga semua permintaan diselesaikan.
Dalam kasus serangan di bawah ini, ada jeda 10 menit, setelah itu bagian serangan baru yang dimodifikasi tiba.
Artinya, pertahanan belajar, mulai menyaring, namun bagian serangan baru yang benar-benar berbeda tiba, dan pertahanan mulai belajar lagi. Faktanya, pemfilteran berhenti berfungsi, perlindungan menjadi tidak efektif, dan situs tidak tersedia.
Serangan gelombang ditandai dengan nilai puncak yang sangat tinggi, dapat mencapai seratus ribu atau satu juta permintaan per detik, dalam kasus L7. Jika kita berbicara tentang L3&4, lalu lintasnya bisa mencapai ratusan gigabit, atau, karenanya, ratusan mpps, jika Anda menghitungnya dalam paket.
Masalah dengan serangan tersebut adalah sinkronisasi. Serangan tersebut berasal dari botnet dan memerlukan sinkronisasi tingkat tinggi untuk menciptakan lonjakan satu kali yang sangat besar. Dan koordinasi ini tidak selalu berhasil: terkadang keluarannya berupa puncak parabola, yang terlihat agak menyedihkan.
Bukan HTTP saja
Selain HTTP di L7, kami ingin mengeksploitasi protokol lain. Biasanya, situs web biasa, terutama hosting biasa, memiliki protokol email dan MySQL yang menonjol. Protokol email memiliki beban yang lebih sedikit dibandingkan database, namun protokol tersebut juga dapat dimuat dengan cukup efisien dan berakhir dengan kelebihan beban CPU di server.
Kami cukup berhasil menggunakan kerentanan SSH 2016. Sekarang kerentanan ini telah diperbaiki untuk hampir semua orang, tetapi ini tidak berarti bahwa beban tidak dapat dikirimkan ke SSH. Bisa. Ada banyak sekali otorisasi, SSH memakan hampir seluruh CPU di server, dan kemudian situs web ditutup karena satu atau dua permintaan per detik. Oleh karena itu, satu atau dua permintaan berdasarkan log ini tidak dapat dibedakan dari muatan yang sah.
Banyak koneksi yang kami buka di server juga tetap relevan. Sebelumnya, Apache bersalah dalam hal ini, sekarang nginx sebenarnya bersalah dalam hal ini, karena sering kali dikonfigurasi secara default. Jumlah koneksi yang dapat dibuka oleh nginx terbatas, jadi kami membuka jumlah koneksi ini, nginx tidak lagi menerima koneksi baru, dan akibatnya situs tidak berfungsi.
Cluster pengujian kami memiliki cukup CPU untuk menyerang jabat tangan SSL. Pada prinsipnya, seperti yang diperlihatkan oleh praktik, botnet terkadang juga melakukan hal ini. Di satu sisi, jelas bahwa Anda tidak dapat melakukannya tanpa SSL, karena hasil, peringkat, dan keamanan Google. Di sisi lain, sayangnya SSL mengalami masalah CPU.
L3&4
Ketika kita berbicara tentang serangan di level L3&4, kita biasanya berbicara tentang serangan di level link. Beban seperti itu hampir selalu dapat dibedakan dari beban yang sah, kecuali jika beban tersebut merupakan serangan banjir SYN. Masalah dengan serangan SYN-flood untuk alat keamanan adalah volumenya yang besar. Nilai L3&4 maksimum adalah 1,5-2 Tbit/s. Lalu lintas semacam ini sangat sulit untuk diproses bahkan untuk perusahaan besar, termasuk Oracle dan Google.
SYN dan SYN-ACK adalah paket yang digunakan saat membuat koneksi. Oleh karena itu, SYN-banjir sulit dibedakan dari beban yang sah: tidak jelas apakah SYN ini datang untuk membuat sambungan, atau bagian dari banjir.
UDP-banjir
Biasanya penyerang tidak memiliki kemampuan yang kita miliki, sehingga amplifikasi dapat digunakan untuk mengatur serangan. Artinya, penyerang memindai Internet dan menemukan server yang rentan atau tidak dikonfigurasi dengan benar, misalnya, sebagai respons terhadap satu paket SYN, merespons dengan tiga SYN-ACK. Dengan memalsukan alamat sumber dari alamat server target, dimungkinkan untuk meningkatkan daya, katakanlah, tiga kali lipat dengan satu paket dan mengarahkan lalu lintas ke korban.
Masalah dengan amplifikasi adalah sulitnya dideteksi. Contoh terbaru termasuk kasus sensasional mengenai memcache yang rentan. Ditambah lagi, sekarang ada banyak perangkat IoT, kamera IP, yang sebagian besar juga dikonfigurasi secara default, dan secara default tidak dikonfigurasi dengan benar, itulah sebabnya penyerang paling sering melakukan serangan melalui perangkat tersebut.
Banjir SYN yang sulit
SYN-flood mungkin merupakan jenis serangan yang paling menarik dari sudut pandang pengembang. Masalahnya adalah administrator sistem sering menggunakan pemblokiran IP untuk perlindungan. Selain itu, pemblokiran IP tidak hanya memengaruhi administrator sistem yang bertindak menggunakan skrip, namun sayangnya juga beberapa sistem keamanan yang dibeli dengan harga mahal.
Cara ini bisa menjadi bencana karena jika penyerang mengganti alamat IP, perusahaan akan memblokir subnetnya sendiri. Ketika Firewall memblokir clusternya sendiri, outputnya akan gagal dalam interaksi eksternal dan sumber daya akan gagal.
Selain itu, tidak sulit untuk memblokir jaringan Anda sendiri. Jika kantor klien memiliki jaringan Wi-Fi, atau jika kinerja sumber daya diukur menggunakan berbagai sistem pemantauan, maka kami mengambil alamat IP sistem pemantauan ini atau Wi-Fi kantor klien dan menggunakannya sebagai sumber. Pada akhirnya, sumber daya tampaknya tersedia, tetapi alamat IP target diblokir. Dengan demikian, jaringan Wi-Fi konferensi HighLoad, tempat produk baru perusahaan dipresentasikan, mungkin diblokir, dan ini memerlukan biaya bisnis dan ekonomi tertentu.
Selama pengujian, kami tidak dapat menggunakan amplifikasi melalui memcache dengan sumber daya eksternal apa pun, karena ada perjanjian untuk mengirimkan lalu lintas hanya ke alamat IP yang diizinkan. Oleh karena itu, kami menggunakan amplifikasi melalui SYN dan SYN-ACK, ketika sistem merespons pengiriman satu SYN dengan dua atau tiga SYN-ACK, dan pada output serangannya dikalikan dua atau tiga kali.
Alat
Salah satu alat utama yang kami gunakan untuk beban kerja L7 adalah Yandex-tank. Secara khusus, hantu digunakan sebagai senjata, ditambah lagi ada beberapa skrip untuk menghasilkan kartrid dan untuk menganalisis hasilnya.
Tcpdump digunakan untuk menganalisis lalu lintas jaringan, dan Nmap digunakan untuk menganalisis server. Untuk membuat beban di level L3&4, OpenSSL dan sedikit keajaiban kami dengan perpustakaan DPDK digunakan. DPDK adalah perpustakaan dari Intel yang memungkinkan Anda bekerja dengan antarmuka jaringan melewati tumpukan Linux, sehingga meningkatkan efisiensi. Tentu saja, kami menggunakan DPDK tidak hanya pada level L3&4, tetapi juga pada level L7, karena ini memungkinkan kami membuat aliran beban yang sangat tinggi, dalam kisaran 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 pada SSH, maka rangkaian di atas tidak dapat dieksploitasi. Jika kita menyerang protokol email, kita menggunakan utilitas email atau cukup menulis skrip pada protokol tersebut.
Temuan
Sebagai kesimpulan saya ingin mengatakan:
- Selain pengujian beban klasik, perlu dilakukan pengujian tegangan. Kami memiliki contoh nyata di mana subkontraktor mitra hanya melakukan pengujian beban. Hal ini menunjukkan bahwa sumber daya mampu menahan beban normal. Namun kemudian muncul beban yang tidak normal, pengunjung situs mulai menggunakan sumber daya dengan cara yang sedikit berbeda, dan akibatnya subkontraktor melakukan pekerjaan tersebut. Oleh karena itu, ada baiknya mencari kerentanan meskipun Anda sudah terlindungi dari serangan DDoS.
- Penting untuk mengisolasi beberapa bagian sistem dari bagian lainnya. Jika Anda memiliki pencarian, Anda perlu memindahkannya ke mesin yang terpisah, bahkan tidak ke Docker. Karena jika pencarian atau otorisasi gagal, setidaknya sesuatu akan tetap berfungsi. Dalam kasus toko online, pengguna akan terus mencari produk di katalog, membuka agregator, membeli jika sudah diotorisasi, atau mengotorisasi melalui OAuth2.
- Jangan abaikan semua jenis layanan cloud.
- Gunakan CDN tidak hanya untuk mengoptimalkan penundaan jaringan, tetapi juga sebagai sarana perlindungan terhadap serangan terhadap kehabisan saluran dan sekadar membanjiri lalu lintas statis.
- Penting untuk menggunakan layanan perlindungan khusus. Anda tidak dapat melindungi diri Anda dari serangan L3&4 di tingkat saluran, karena kemungkinan besar Anda tidak memiliki saluran yang memadai. Anda juga tidak mungkin bisa melawan serangan L7, karena ukurannya bisa sangat besar. Ditambah lagi, pencarian serangan kecil masih menjadi hak prerogatif layanan khusus, algoritma khusus.
- Perbarui secara teratur. Ini tidak hanya berlaku pada kernel, tetapi juga pada daemon SSH, terutama jika Anda membukanya dari luar. Pada prinsipnya, semuanya perlu diperbarui, karena kecil kemungkinannya Anda dapat melacak kerentanan tertentu sendiri.
Sumber: www.habr.com