Lewati ke isi

Keamanan/Cyber Security

Cara Pasang Anubis di Depan Nginx dengan Docker

Panduan memasang Anubis lewat Docker di antara Nginx dan aplikasi, mengatur file kebijakan bot, tingkat kesulitan, dan mengizinkan Googlebot.

Terbit 7 menit baca

Jawaban singkat

Jalankan image ghcr.io/techarohq/anubis dengan Docker, arahkan blok server HTTPS Nginx ke Anubis, lalu biarkan Anubis meneruskan request yang lolos ke server backend Nginx. Atur bot lewat file kebijakan YAML dan pertahankan daftar izin crawler mesin pencari.

Daftar isi
  1. Seperti apa alur request setelah Anubis dipasang?
  2. Langkah 1: siapkan file kebijakan bot
  3. Langkah 2: jalankan Anubis dengan Docker Compose
  4. Langkah 3: ubah konfigurasi Nginx
  5. Berapa nilai DIFFICULTY yang wajar?
  6. Bagaimana menguji bahwa semuanya bekerja?
  7. Apa yang perlu diperhatikan sebelum memakai di produksi?
  8. Pertanyaan yang sering diajukan

Cara paling rapi memasang Anubis dengan Nginx adalah membagi Nginx menjadi dua peran: satu blok server menerima HTTPS lalu meneruskan semua request ke Anubis, dan Anubis meneruskan request yang lolos ke blok server kedua yang benar-benar melayani website. Anubis sendiri cukup dijalankan sebagai satu container Docker.

Kenapa repot begini? Karena Anubis dirancang sebagai penyaring di tengah, bukan pengganti web server. Anubis, proyek open-source dari Techaro berlisensi MIT, memberi tantangan kecil (umumnya proof-of-work di browser) sebelum request sampai ke aplikasi, sehingga scraper massal jadi mahal untuk terus mengambil data.

Panduan ini memakai server Linux dengan Docker dan Nginx yang sudah terpasang. Kalau Docker masih asing, baca dulu apa itu Docker.

Seperti apa alur request setelah Anubis dipasang?

Dokumentasi integrasi Nginx menyebut Anubis sebagai "filter proxy": konfigurasi Nginx dipecah menjadi terminasi TLS dan routing HTTP, lalu Anubis disisipkan di antaranya. Alurnya:

  • Nginx port 443 menerima koneksi HTTPS dan membuka TLS.
  • Anubis memeriksa request: diizinkan, ditantang, atau ditolak.
  • Nginx backend (port internal, misalnya 127.0.0.1:8080) melayani website seperti biasa, termasuk PHP atau proxy ke aplikasi lain.

Sertifikat SSL tetap dipasang di blok server 443.

Langkah 1: siapkan file kebijakan bot

Anubis diatur lewat variabel lingkungan dan file kebijakan (policy file) berformat YAML atau JSON. Titik awal yang praktis adalah file default data/botPolicies.yaml di repositori GitHub Anubis, lalu kamu sunting seperlunya. Simpan di /opt/anubis/botPolicy.yaml.

Per 4 November 2026, file default berisi lebih banyak impor, di antaranya empat baris berikut:

bots:
  - import: (data)/bots/_deny-pathological.yaml
  - import: (data)/meta/ai-block-aggressive.yaml
  - import: (data)/crawlers/_allow-good.yaml
  - import: (data)/common/keep-internet-working.yaml

Baris _allow-good.yaml adalah daftar izin crawler. Isinya mengimpor aturan untuk Google, Bing, Apple, DuckDuckGo, Internet Archive, dan beberapa mesin pencari lain. Aturan Googlebot di dalamnya tidak hanya mencocokkan User-Agent, tapi juga rentang IP resmi Google lewat kolom remote_addresses. Ini penting, karena siapa pun bisa memalsukan User-Agent "Googlebot".

Kalau kamu ingin lebih longgar terhadap bot AI, file default sendiri memberi alternatif ai-block-moderate.yaml atau ai-block-permissive.yaml sebagai pengganti ai-block-aggressive.yaml.

Ada empat aksi yang bisa dipakai di aturan buatanmu sendiri: ALLOW, DENY, CHALLENGE, dan WEIGH (menambah atau mengurangi bobot kecurigaan). Contoh mengizinkan jaringan kantor tanpa tantangan:

  - name: jaringan-kantor
    action: ALLOW
    remote_addresses:
      - 203.0.113.0/24

Ganti rentang IP itu dengan IP kantormu. Dokumentasi menganjurkan nama aturan huruf kecil dengan tanda hubung, karena nama ini muncul di metrik.

Langkah 2: jalankan Anubis dengan Docker Compose

Image resminya ghcr.io/techarohq/anubis. Tag latest berarti rilis bertanda terbaru. Per 4 November 2026, rilis terbaru di halaman GitHub adalah v1.28.2. Untuk produksi, menyematkan tag versi (misalnya v1.28.2) membuat pembaruan lebih terkendali.

Buat /opt/anubis/docker-compose.yml:

services:
  anubis:
    image: ghcr.io/techarohq/anubis:latest
    network_mode: host
    environment:
      BIND: "127.0.0.1:8923"
      TARGET: "http://127.0.0.1:8080"
      DIFFICULTY: "4"
      METRICS_BIND: "127.0.0.1:9090"
      POLICY_FNAME: "/data/cfg/botPolicy.yaml"
    volumes:
      - "./botPolicy.yaml:/data/cfg/botPolicy.yaml:ro"
    restart: unless-stopped

network_mode: host dipakai supaya Anubis bisa menjangkau Nginx backend di 127.0.0.1 tanpa urusan jaringan Docker. Mode ini berlaku di Linux. Perhatikan juga METRICS_BIND: nilai bawaannya :9090, yang dengan mode host akan terbuka di semua antarmuka. Mengikatnya ke 127.0.0.1 mencegah metrik terlihat dari internet. Dokumentasi menandai variabel ini sebagai cara lama dan menganjurkan pindah ke blok metrics di file kebijakan, jadi cek halaman konfigurasi saat memperbarui versi.

Container Anubis berjalan sebagai user ID 1000. Pastikan file kebijakan bisa dibaca user itu. Lalu jalankan docker compose up -d dari folder /opt/anubis.

Langkah 3: ubah konfigurasi Nginx

Pecah konfigurasi situsmu menjadi upstream, blok TLS, dan blok backend.

upstream anubis {
  server 127.0.0.1:8923;
}

server {
  listen 443 ssl;
  http2 on;
  server_name contoh.co.id;
  ssl_certificate     /etc/ssl/contoh.crt;
  ssl_certificate_key /etc/ssl/contoh.key;

  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Http-Version $server_protocol;
    proxy_set_header X-TLS-SNI-Name $ssl_server_name;
    proxy_pass http://anubis;
  }
}

server {
  listen 127.0.0.1:8080;
  server_name contoh.co.id;
  root /var/www/contoh;

  set_real_ip_from 127.0.0.1;
  real_ip_header X-Real-IP;

  # konfigurasi PHP, cache, dan lainnya tetap di sini
}

Header X-Real-IP wajib dikirim. Tanpanya, Anubis dan log backend hanya melihat 127.0.0.1 sebagai pengunjung, sehingga aturan berbasis IP (termasuk daftar izin Googlebot) tidak bekerja. Cek dengan nginx -t, lalu systemctl reload nginx.

Berapa nilai DIFFICULTY yang wajar?

DIFFICULTY adalah jumlah nol di depan hasil hash yang harus ditemukan browser. Nilai bawaannya 4. Setiap kenaikan satu angka membuat kerja browser jauh lebih berat, dan yang menanggung adalah HP pengunjung, bukan servermu.

File default per 4 November 2026 sebenarnya tidak memakai satu angka tetap. Ia memakai sistem bobot: request dengan bobot rendah diberi tantangan metarefresh (tanpa JavaScript, hanya menunggu), bobot sedang diberi proof-of-work kesulitan 2, dan baru bobot tinggi diberi kesulitan 4 atau 6. Untuk website bisnis biasa, pertahankan pola bawaan ini dulu, lalu naikkan hanya bila scraper masih lolos.

Kesulitan juga bisa diatur per aturan lewat kunci challenge, misalnya membuat tantangan lebih berat untuk User-Agent tertentu. Dokumentasi resmi mengingatkan bahwa aturan "tangkap semua yang mengandung kata bot" punya tingkat salah blokir yang tinggi.

Bagaimana menguji bahwa semuanya bekerja?

Buka website dari browser biasa. Kunjungan pertama seharusnya menampilkan halaman tantangan singkat, lalu kamu diarahkan ke halaman asli. Cookie lolos berlaku 168 jam secara bawaan (COOKIE_EXPIRATION_TIME), jadi kunjungan berikutnya tidak ditantang lagi.

Beberapa uji cepat dari terminal:

  • curl -A "GPTBot" https://contoh.co.id/ seharusnya tidak mendapat isi halaman asli bila kebijakan AI agresif aktif.
  • curl https://contoh.co.id/robots.txt tetap harus terbuka, karena aturan keep-internet-working mengizinkannya.
  • docker compose logs -f anubis menampilkan keputusan Anubis. Set SLOG_LEVEL: "DEBUG" sementara bila ingin melihat evaluasi tiap request.

Setelah beberapa hari, periksa Google Search Console. Bila ada lonjakan galat perayapan, cek apakah request Googlebot benar-benar membawa IP asli lewat X-Real-IP. Pemantauan rutin bisa ditambah dengan alat seperti di panduan Uptime Kuma dan Grafana.

Apa yang perlu diperhatikan sebelum memakai di produksi?

Proyek Anubis sendiri menyebut dirinya "a bit of a nuclear response": scraper kecil dan sebagian bot baik bisa ikut tertahan bila tidak masuk daftar izin. Pertimbangkan hal berikut:

  • API dan webhook. Klien API, aplikasi mobile, dan webhook pembayaran tidak menjalankan JavaScript. Buat aturan ALLOW untuk path seperti /api/ atau /webhook/, atau pisahkan ke subdomain tanpa Anubis.
  • WebSocket. Dokumentasi menyebut Anubis mungkin kurang cocok untuk aplikasi yang memakai WebSocket dengan koneksi terbuka lama.
  • Pengunjung tanpa JavaScript. Tantangan proof-of-work butuh JavaScript. Halaman tantangan meta refresh membantu, tapi tetap ada sebagian kecil pengunjung yang bisa terganggu.
  • Sumber daya. Dokumentasi menyebut kebutuhan sistemnya sangat kecil. Penulisnya menduga RAM 128Mi bisa cukup untuk banyak klien sekaligus, jadi anggap itu perkiraan, bukan jaminan.

Anubis bukan WAF yang membaca pola SQL injection. Fungsinya menyaring bot berdasarkan perilaku dan identitas. Untuk perlindungan serangan aplikasi, tetap butuh lapisan WAF, atau bandingkan pilihannya di Anubis vs Cloudflare Bot Fight Mode.

Pertanyaan yang sering diajukan

Apakah Anubis membuat website hilang dari Google?

Tidak bila daftar izin _allow-good.yaml tetap diimpor dan Nginx mengirim IP asli lewat header X-Real-IP. Aturan Googlebot bawaan mencocokkan User-Agent sekaligus rentang IP resmi Google.

Bisakah satu container Anubis melindungi beberapa website?

Dokumentasi Nginx menyebut Anubis tidak peduli header Host, jadi satu instance bisa menangani beberapa situs. Namun halaman instalasi menganjurkan satu instance per layanan yang dilindungi, dan itu lebih rapi bila tiap situs butuh kebijakan berbeda.

Apa beda Anubis dengan robots.txt?

robots.txt hanya permintaan yang dipatuhi secara sukarela oleh crawler. Anubis memaksa di sisi server, sehingga bot yang mengabaikan robots.txt tetap harus melewati tantangan. Keduanya bisa dipakai bersamaan.

Sumber & referensi

Baca juga