Di halaman ini kami menyajikan beberapa cara untuk memitigasi serangan DoS saat ini. Semua pendekatan ini dapat dikombinasikan. Namun, saat ini belum ada satu solusi tunggal yang cocok untuk semua untuk masalah ini. Mempertahankan sebuah situs yang sedang diserang membutuhkan kreativitas dan pendekatan yang disesuaikan secara khusus.

Ikhtisar pertahanan yang telah diimplementasikan pada tor daemon diberikan pada bagian Overview dari spesifikasi Denial-of-service prevention mechanisms in Tor, dan di sini kami memberikan beberapa kiat praktis.

Pembatasan laju pada Introduction Points

Sejak Proposal 305 diimplementasikan, beberapa opsi torrc ditambahkan untuk membantu memitigasi serangan DoS pada introduction points:

  • HiddenServiceEnableIntroDoSDefense: Aktifkan pertahanan DoS pada tingkat intropoint. Saat ini diaktifkan, parameter laju dan ledakan akan dikirim ke intro point yang kemudian akan menggunakannya untuk menerapkan pembatasan laju pada permintaan pengenalan ke layanan ini.

  • HiddenServiceEnableIntroDoSBurstPerSec: Ledakan pengenalan klien yang diizinkan per detik pada introduction point. Jika opsi ini bernilai 0, maka dianggap tak terbatas sehingga jika HiddenServiceEnableIntroDoSDefense diatur, hal itu pada akhirnya menonaktifkan pertahanan.

  • HiddenServiceEnableIntroDoSRatePerSec: Laju pengenalan klien yang diizinkan per detik pada introduction point. Jika opsi ini bernilai 0, maka dianggap tak terbatas sehingga jika HiddenServiceEnableIntroDoSDefense diatur, hal itu pada akhirnya menonaktifkan pertahanan.

Untuk informasi lebih lanjut tentang cara kerjanya, lihat manpage tor(1) dan bagian Denial-of-Service defense extension (DOS_PARAMS) dari spesifikasi Onion Services v3.

Proof of Work (PoW) sebelum membangun Rendezvous Circuits

Mekanisme pertahanan Proof of Work (PoW) dijelaskan secara panjang lebar di PoW FAQ, dan dapat dikonfigurasi untuk setiap Onion Service dengan opsi torrc berikut:

  • HiddenServicePoWDefensesEnabled: Aktifkan mitigasi DoS layanan berbasis proof-of-work. Saat diaktifkan, tor akan menyertakan parameter untuk teka-teki klien opsional pada bagian terenkripsi dari deskriptor hidden service ini. Permintaan rendezvous yang masuk akan diprioritaskan berdasarkan besarnya upaya yang dipilih klien saat menghitung solusi untuk teka-teki tersebut. Layanan akan secara berkala memperbarui besaran upaya yang disarankan, berdasarkan beban serangan, dan menonaktifkan teka-teki sepenuhnya ketika layanan tidak kelebihan beban.

  • HiddenServicePoWQueueRate: Laju berkelanjutan permintaan rendezvous yang dikirim per detik dari antrean prioritas.

  • HiddenServicePoWQueueBurst: Ukuran ledakan maksimum untuk permintaan rendezvous yang ditangani dari antrean prioritas sekaligus.

Opsi global berikut berlaku untuk onion services maupun kliennya:

  • CompiledProofOfWorkHash: Saat mitigasi DoS proof-of-work aktif, baik layanan itu sendiri maupun klien yang terhubung akan menggunakan fungsi hash yang dihasilkan secara dinamis sebagai bagian dari komputasi teka-teki.

PoW diaktifkan secara default pada C Tor versi 0.4.8.1-alpha ke atas (tetapi dapat dinonaktifkan jika dikompilasi dengan --disable-module-pow). Dukungan PoW dasar dapat diperiksa dengan menjalankan perintah ini:

tor --list-modules
relay: yes
dirauth: yes
dircache: yes
pow: yes

Jika Anda memiliki pow: yes, maka Anda memiliki mekanisme pertahanan PoW yang terpasang di C Tor.

Karena persyaratan lisensi, pustaka teka-teki klien PoW v1 (Equi-X dan HashX oleh tevador, keduanya di bawah LGPL-3.0) hanya diaktifkan jika tor dikompilasi dengan --enable-gpl. Ini dapat dikonfirmasi dengan menjalankan perintah berikut:

tor --version
Tor versi 0.4.8.3-rc.
Build Tor ini tercakup oleh GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html)
Tor berjalan di Linux dengan Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A, dan Glibc 2.36 sebagai libc.
Tor dikompilasi dengan GCC versi 12.2.0

Jika C Tor yang Anda pasang tidak mengaktifkan PoW atau tidak dibangun dengan dukungan GNU GPL, maka Anda harus mencari paket lain atau mengompilasinya sendiri.

Batas stream pada Rendezvous Circuits yang telah dibangun

Opsi konfigurasi berikut dapat digunakan untuk membatasi koneksi pada sirkuit rendezvous:

  • HiddenServiceMaxStreams: Jumlah maksimum stream (koneksi) simultan per sirkuit rendezvous. Nilai maksimum yang diizinkan adalah 65535. (Mengatur ini ke 0 akan mengizinkan jumlah stream simultan tanpa batas.)

  • HiddenServiceMaxStreamsCloseCircuit: Jika diatur ke 1, maka melampaui HiddenServiceMaxStreams akan menyebabkan sirkuit rendezvous yang bermasalah dibongkar, alih-alih permintaan pembuatan stream yang melampaui batas diabaikan secara diam-diam.

Onionbalance

Onionbalance memungkinkan operator Onion Service mencapai sifat ketersediaan tinggi dengan mengizinkan beberapa mesin menangani permintaan untuk sebuah Onion Service. Anda dapat menggunakan Onionbalance untuk melakukan penskalaan horizontal. Semakin besar skala Anda, semakin sulit bagi penyerang untuk membanjiri Anda. Onionbalance tersedia untuk Onion Services v3.

Pembatasan laju webserver

Jika penyerang membanjiri Anda dengan sirkuit agresif yang melakukan terlalu banyak kueri, coba deteksi penggunaan berlebihan tersebut dan hentikan dengan opsi torrc HiddenServiceExportCircuitID. Anda dapat menggunakan heuristik Anda sendiri atau menggunakan modul pembatasan laju web server Anda.

Kiat-kiat di atas seharusnya membantu Anda tetap bertahan pada masa-masa yang bergejolak. Pada saat yang sama kami sedang mengerjakan pertahanan yang lebih canggih, sehingga lebih sedikit konfigurasi manual dan utak-atik yang dibutuhkan oleh operator onion.

Caching

Cara lain untuk mengurangi beban pada layanan Anda adalah menerapkan caching konten, baik langsung pada aplikasi backend maupun dengan menyiapkan frontend proxy caching.

Otorisasi klien atau beberapa alamat onion untuk mengisolasi pengguna Anda

Jika Anda memiliki pengguna yang Anda percayai, berikan mereka Onion Service khusus serta kredensial otorisasi klien agar layanan tersebut selalu tersedia. Untuk pengguna yang tidak Anda percaya, pisahkan mereka ke beberapa alamat. Meski begitu, memiliki terlalu banyak alamat onion sebenarnya buruk bagi keamanan Anda (karena penggunaan banyak guard node), jadi cobalah menggunakan otorisasi klien jika memungkinkan.

Captcha dan cookie

Jika Anda perlu membatasi laju pengguna lebih lanjut, bagi infrastruktur Anda menjadi beberapa lapisan dan tempatkan Captcha dekat dengan frontend. Dengan cara ini penyerang harus menyelesaikan Captcha sebelum mereka dapat menyerang lebih jauh ke dalam infrastruktur Anda.

Captcha adalah cara untuk memitigasi serangan DDoS. Ketika ada permintaan dari klien, periksa apakah klien memiliki cookie aman yang benar; jika tidak, alihkan ke halaman recaptcha. Klien memasukkan huruf captcha. Nginx mengirimkan huruf input ini ke server recaptcha untuk verifikasi.

Jawaban yang benar dari server recaptcha diawali dengan "true..."; jika tidak, diawali dengan "false...". Tambahkan cookie aman untuk klien terverifikasi yang benar, lalu alihkan klien ke halaman yang ingin dilihatnya.

Dimungkinkan untuk mengimplementasikan Captcha langsung di webserver Anda dengan Nginx dan OpenResty menggunakan Lua untuk membuat dan memverifikasi gambar captcha. Implementasi ini tidak mudah dikonfigurasi.

Alternatifnya, Anda bisa saja menerapkan tantangan test-cookie. Di webserver Anda, pastikan klien dapat mengatur cookie yang valid; klien berbahaya sering kali tidak memiliki fitur ini. Di Nginx, Cloudflare menyediakan sebuah pustaka untuk berinteraksi dengan cookie.

Metode lain termasuk memastikan bahwa klien yang terhubung ke .onion Anda memiliki header User-Agent yang valid dan header Referer tidak diatur ke nilai yang dapat Anda kaitkan dengan serangan.