Serangan pada mesin: apa yang kami lakukan dan apa yang bisa Anda lakukan

Kata "attack" terdengar sama dalam dua situasi yang sangat berbeda: ketika kanal Anda dibanjiri lalu lintas sampah dan ketika beberapa ratus permintaan per detik membuat aplikasi Anda tumbang. Keduanya ditangani secara berbeda, dan hal pertama yang harus dilakukan adalah menentukan mana yang sedang Anda hadapi.

Membedakan keduanya

Lihat grafik prosesor, memori, dan lalu lintas di "Overview" pada /hosting/vds/m/<id> selama 24 jam terakhir. Jika lalu lintas normal tetapi prosesor mentok di batas atas, itu beban aplikasi, dan Anda perlu menanganinya dari sisi Anda.

Yang bisa Anda lakukan

Membatasi laju permintaan di nginx:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    limit_req zone=perip burst=20 nodelay;
    limit_conn conn 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
}

Membatasi koneksi di firewall:

ufw limit 22/tcp

Aturan yang lebih fleksibel ada di artikel nftables: di sana Anda juga dapat membatasi laju koneksi baru dan menyimpan daftar alamat yang diblokir beserta time to live-nya.

Temukan sumbernya di log:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

Memblokir satu alamat atau jaringan untuk sementara:

ufw deny from 203.0.113.0/24

fail2ban dapat mengotomatiskan pemblokiran berdasarkan log.

Yang kami lakukan

Infrastruktur kami menyaring lalu lintas sampah dalam perjalanannya menuju node — sebelum menghabiskan bandwidth Anda. Ini bekerja melawan serangan volumetrik pada kanal dan tidak memerlukan konfigurasi apa pun dari Anda.

Yang tidak dilakukan perlindungan tingkat node: ia tidak menganalisis logika aplikasi Anda. Permintaan yang tampak normal dari luar tetap mencapai mesin Anda, dan hanya konfigurasi Anda sendiri yang melindunginya.

Jika mesin Anda menjadi sumber serangan — misalnya, mesin tersebut disusupi dan ikut serta dalam kampanye spam orang lain — akses akan dibatasi sesuai kebijakan penggunaan yang dapat diterima. Periksa mesin Anda terhadap tanda-tanda kompromi.

Caching dan file statis

Teknik paling efektif melawan banjir permintaan adalah tidak menghitung hal yang sama dua kali:

location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

Cache halaman berat di sisi aplikasi. Permintaan yang dilayani dari cache memakan biaya ratusan kali lebih sedikit.

Kesalahan umum

• Menetapkan limit_req tanpa burst — pengguna biasa yang halamannya menarik dua lusin file ikut terputus.
• Memblokir alamat satu per satu secara manual selama serangan terdistribusi: jumlahnya ribuan, dan Anda tidak akan sanggup mengikutinya.
• Memblokir ICMP sepenuhnya — ini merusak negosiasi ukuran paket, lihat MTU.
• Mengira bug Anda sendiri sebagai serangan: loop dalam kode, bot pencarian yang merayapi direktori yang lupa Anda kecualikan, percobaan ulang klien tanpa henti.

Tetapkan batas Anda terlebih dahulu, saat mesin sedang tenang. Selama banjir permintaan Anda tidak akan bisa menyetel nilai rate dan burst: Anda akan mengedit konfigurasi secara buta dan sepotong-sepotong.