Di peta serangan ada bercak pekat di atas satu negara, dan aturan «larang negara itu seluruhnya» muncul dengan sendirinya. Aturan itu hampir tidak memberi apa-apa: mengganti negara keluar hanya memakan beberapa menit bagi penyerang, sementara yang terkena larangan adalah pengunjung Anda sendiri dan Anda sendiri saat bepergian. Lebih buruk lagi, perayap yang terlihat dan datang dari satu awan akan pindah ke alamat rumahan setelah diblokir dan menjadi tidak terbedakan dari manusia.

Di bawah ini ada lima langkah yang di server yang sama benar-benar memberi hasil: memutus pemindai, membatasi laju, tidak memutus yang diperlukan, dan — jika memang perlu — memblokir dengan benar. Semuanya bisa diperiksa dan disiapkan dalam sekali duduk.

Langkah 1. Lihat siapa yang sebenarnya membuat bercak itu

Pertama temukan log permintaan. Di server dengan beberapa situs, access.log sering kosong, sedangkan catatannya masuk ke log host virtual yang bersangkutan:

sudo ls -lS /var/log/apache2/*access*.log /var/log/apache2/*requests*.log 2>/dev/null

Pada semua perintah berikutnya, gantilah dengan berkas yang berada di urutan teratas daftar itu. Pertama alamat-alamat teratas selama sehari, lalu apa sebenarnya yang diminta oleh yang paling atas:

sudo awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20
sudo grep '^203\.0\.113\.' /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Perintah kedua menjawab pertanyaan utama. Jika dalam keluaran ada puluhan halaman berbeda dari situs Anda sendiri, itu pengumpul konten: tidak berbahaya, dan cukup dengan tidak menghitungnya sebagai pengunjung. Jika di sana ada /wp-login.php, /.env, /phpmyadmin dan hal lain yang tidak Anda miliki, itu pemindai, dan langkah 2 menanganinya. Pada nginx, log berada di /var/log/nginx/, bidangnya sama.

Langkah 2. Jail untuk permintaan ke sesuatu yang tidak Anda miliki

Jalur yang diminta tidak bisa dipalsukan — justru itulah niatnya, berbeda dengan alamat dan User-Agent. Penyaring /etc/fail2ban/filter.d/web-probes.local:

[Definition]
failregex = ^<HOST> .* "(GET|POST|HEAD) /(wp-login\.php|wp-admin|xmlrpc\.php|\.env|\.git/|phpmyadmin|administrator/)
ignoreregex =

Jail /etc/fail2ban/jail.d/web-probes.local:

[web-probes]
enabled  = true
port     = http,https
filter   = web-probes
logpath  = /var/log/apache2/*access.log
maxretry = 1
findtime = 1h
bantime  = 1d

Di sini maxretry = 1 dapat dibenarkan: tidak ada yang secara kebetulan masuk ke panel administrasi milik orang lain. Terapkan dan pastikan penyaringnya menangkap baris di log Anda sendiri:

sudo fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/web-probes.local
sudo systemctl reload fail2ban && sudo fail2ban-client status web-probes

Langkah 3. Batasi laju

Pemindai dan perayap membongkar dirinya lewat kecepatan, tidak peduli dari negara mana mereka berasal. Tiga puluh halaman per menit dari satu alamat adalah ambang yang tidak menyentuh orang yang sedang membuka-buka katalog:

[http-flood]
enabled  = true
port     = http,https
filter   = apache-overflows
logpath  = /var/log/apache2/site_access.log
maxretry = 30
findtime = 60
bantime  = 1h

Rincian yang menentukan adalah log mana yang tercantum di logpath. Jika polanya juga mencakup log panel kendali itu sendiri atau bagian administrasi, Anda akan memblokir diri sendiri: satu halaman di sana menarik selusin permintaan untuk gaya dan skrip, dan tiga puluh terkumpul hanya dalam dua klik. Karena itu panel diberi berkas log tersendiri yang tidak cocok dengan pola jail, sedangkan berkas statis diberi masa simpan singgah yang panjang agar peramban tidak memintanya lagi pada setiap perpindahan halaman. Gejalanya, kalau toh terjadi: HTML sampai, tampilannya tidak, halaman menggantung. Mencabut pemblokiran:

sudo fail2ban-client set http-flood unbanip 203.0.113.10

Langkah 4. Lindungi apa yang tidak boleh diputus

Sebelum menyalakan pemblokiran, tuliskan pengecualiannya — kalau tidak, yang pertama terkena justru hal yang diperlukan:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24 66.249.64.0/19

Apa yang wajib ada di baris itu dan mengapa:

  • Alamat Anda sendiri atau subjaringan kantor. Penyebab paling sering hilangnya akses ke server adalah aturan sendiri, bukan serangan;
  • Rentang 66.249.64.0/19. Robot pencari Google dikenali lewat User-Agent, tetapi bagian darinya yang menjalankan JavaScript datang sebagai Chrome/Linux biasa dan tidak menyebut dirinya. Aturan apa pun semacam «blokir lalu lintas dari pusat data» justru mengenai bagian itu, setelah itu halaman diam-diam keluar dari indeks. Alamat yang mencurigakan bisa diperiksa dengan kueri balik: dig -x 66.249.66.1 +short harus mengembalikan nama di zona googlebot.com;
  • Alamat pemberitahuan pembayaran. Webhook sistem pembayaran datang dari server AWS dan Azure. Jika Anda menutup awan-awan itu seluruhnya, konfirmasi pembayaran berhenti sampai, dan Anda baru tahu ketika seorang pelanggan menulis bahwa uangnya sudah terpotong tetapi aksesnya tidak ada. Rentangnya diambil dari dokumentasi penyedia pembayaran Anda.

Langkah 5. Kalau pemblokiran memang perlu — blokir subjaringan, bukan negara

Penebalan yang bertahan dari satu jaringan, yang berlangsung berhari-hari dan disertai permintaan yang seragam, berarti satu pelaksana yang berjalan menurut daftar. Kasus seperti itu diblokir secara tepat sasaran dan untuk jangka waktu tertentu:

sudo ufw deny from 198.51.100.0/22 to any
sudo ufw status numbered

Dengan perintah kedua, catat nomor aturannya: pemblokiran nanti harus dicabut lewat nomor itu, sudo ufw delete <nomor>. Sepakati dengan diri sendiri sebuah tenggat — misalnya sebulan — dan tuliskan pencabutannya di kalender. Aturan yang dipasang «selamanya» setelah setahun berubah menjadi daftar yang tidak ada yang berani menyentuhnya, karena tidak ada yang ingat mengapa alamat-alamat itu sampai ke sana.

Subjaringan mana yang harus diblokir bisa diketahui dari alamat pada langkah pertama: whois 198.51.100.17 | grep -iE 'route|cidr|netname'.

Apa yang berubah setelah lima langkah ini

Pemindai diputus berdasarkan niat, bukan berdasarkan asal, dan tertangkap pada permintaan pertama. Perayap membentur batas laju. Robot pencari dan pemberitahuan pembayaran tetap lewat. Satu-satunya pemblokiran yang masih lebar bersifat tepat sasaran, dengan tenggat yang diketahui dan alasan yang jelas.

Peta itu sendiri tidak hilang, tetapi perannya berubah: ia diperlukan bukan untuk menutup negara, melainkan untuk menyadari penebalan itu sendiri dan membandingkannya dengan keadaan seminggu lalu. Untuk itu diperlukan riwayat, bukan potret hari berjalan. Bagaimana peta semacam itu terlihat bersama log pemblokiran dan daftar porta terbuka ditunjukkan oleh halaman demo di bawah.