Cara Men-deploy SafeLine WAF di VPS Linux

Aplikasi web yang menghadap internet secara rutin diselidiki untuk mencari SQL injection, penyalahgunaan kredensial, dan pola kerentanan yang sudah diketahui. SafeLine adalah WAF self-hosted GPL-3.0 yang berjalan sebagai stack Docker Compose dan menyaring lalu lintas HTTP/S sebelum meneruskan permintaan yang diizinkan ke origin. Paket Personal gratisnya mendukung hingga 10 aplikasi.

Tutorial ini membahas instalasi dan tiga area yang perlu perhatian khusus: keputusan arsitektur reverse-proxy, konfigurasi jaringan Docker ketika SafeLine berada di belakang proxy yang sudah ada seperti Nginx Proxy Manager, dan sebuah perintah verifikasi yang bisa Anda jalankan setelah instalasi untuk memastikan WAF benar-benar mencegat serangan.

Versi Singkat

• Instal SafeLine di VPS Linux dengan Docker Compose. Gunakan installer satu baris, atau tempuh jalur Docker Compose manual untuk memeriksa definisi Compose dan konfigurasi environment sebelum Anda menjalankan stack.
• Tentukan arsitektur reverse-proxy sebelum Anda menginstal: SafeLine sebagai satu-satunya proxy, SafeLine di belakang Nginx Proxy Manager yang sudah ada, atau SafeLine berbagi server dengan Caddy. Setiap bentuk membutuhkan penetapan port dan pengaturan X-Forwarded-For yang berbeda.
• Setelah instalasi, verifikasi WAF dengan mengirimkan probe SQL-injection melalui curl ke URL yang dilindungi. Dalam mode Balanced atau Strict, respons 403 ditambah entri Attack Events yang cocok mengonfirmasi pemblokiran. Dalam mode Monitor, event yang cocok mengonfirmasi deteksi meskipun responsnya mungkin tetap berhasil.
• Tier Personal gratis mencakup hingga 10 aplikasi dan mesin deteksi inti. Geo-blocking, ekspor log serangan, dan notifikasi eksternal membutuhkan tier Lite; deteksi serangan yang lebih kuat dan load balancing membutuhkan Pro.

Sebelum Anda Mulai: Prasyarat dan Apa yang Dibahas Tutorial Ini

Tutorial ini mengasumsikan Anda memiliki VPS Linux yang bisa Anda SSH dengan akses root atau sudo, dan Docker sudah terinstal. Anda akan selesai dengan instance SafeLine yang berfungsi melindungi setidaknya satu situs dan sebuah perintah verifikasi yang bisa Anda jalankan ulang kapan saja.

Anda memerlukan:

• Sebuah VPS Linux. Perintah di bawah mengasumsikan sistem bergaya Debian atau Ubuntu dengan systemd; verifikasi nama paket dan service pada distribusi lain.
• Setidaknya 1 vCPU, 1 GB RAM, dan 5 GB disk menurut persyaratan deployment resmi. Untuk ruang gerak produksi yang praktis, panduan ini merekomendasikan 2 vCPU, 4 GB RAM, dan 20 GB disk.
• Docker 20.10.14 atau lebih baru dan Docker Compose 2.0 atau lebih baru.
• CPU x86_64 dengan dukungan SSSE3; verifikasi dengan lscpu | grep ssse3 alih-alih mengasumsikan instruksi tersebut tersedia.
• Sebuah domain atau subdomain dengan DNS mengarah ke IP publik VPS jika Anda berencana mengekspos aplikasi yang dilindungi melalui HTTPS publik.
• Port yang sesuai dengan topologi yang dipilih. Bentuk A dan C biasanya memberikan port 80 dan 443 kepada SafeLine, sedangkan Bentuk B menyerahkan port tersebut kepada Nginx Proxy Manager dan menetapkan listener yang berbeda seperti 10080 untuk SafeLine.
• Akses root atau sudo.

Pada firewall atau security group penyedia VPS, ekspos hanya port publik yang dibutuhkan topologi yang dipilih. Batasi SSH dan TCP 9443 hanya untuk sumber administrasi tepercaya. Pada Bentuk B, jaga agar TCP 10080 tertutup untuk IPv4 dan IPv6 publik, dan jaga agar port backend seperti 8080 tetap privat di setiap topologi. Akses langsung ke 10080 akan melewati NPM dan membatalkan batas kepercayaan X-Forwarded-For.

Catatan: Untuk deployment ARM64 manual, atur ARCH_SUFFIX=-arm. Dokumentasi deployment resmi SafeLine menyatakan bahwa ARM membutuhkan lisensi Pro dan bahwa Personal Edition tidak didukung di ARM. Gunakan VPS x86_64 untuk Personal Edition.

Verifikasi Docker sebelum memulai:

docker --version
docker compose version

Kedua perintah tersebut harus mengembalikan versi yang terinstal. Lanjutkan hanya jika Docker versi 20.10.14 atau lebih baru dan Docker Compose versi 2.0.0 atau lebih baru; jika tidak, lakukan upgrade sebelum menginstal SafeLine.

Pilih Arsitektur Reverse-Proxy Anda Terlebih Dahulu

VPS yang baru memungkinkan SafeLine menguasai port 80 dan 443 sepenuhnya. VPS yang sudah menjalankan Nginx Proxy Manager, Caddy, atau Nginx milik aplikasi itu sendiri tidak bisa, dan keputusan arsitektur inilah yang membedakan antara instalasi yang mulus dan konflik port pada boot pertama. Lakukan ini dengan benar sekali di awal dan sisa deployment tinggal mekanis.

Tiga bentuk tersebut:

• Bentuk A, SafeLine sebagai satu-satunya reverse proxy. SafeLine menguasai port 80 dan 443 serta mengelola TLS untuk aplikasi yang dilindungi. Rilis CE saat ini menyertakan alur kerja Free Cert, sementara unggah sertifikat manual tetap tersedia; verifikasi opsi sertifikat yang tepat pada rilis yang terinstal. Backend berjalan di port non-publik dan SafeLine merutekan trafik ke sana.
• Bentuk B, SafeLine di belakang Nginx Proxy Manager (NPM). NPM tetap memegang port 80 dan 443 serta menangani SSL. SafeLine mendengarkan di port 10080 (HTTP saja, karena NPM sudah menerminasi TLS). NPM meneruskan ke SafeLine; SafeLine meneruskan ke backend. Ini adalah pengaturan yang umum ketika NPM sudah ter-deploy.
• Bentuk C, SafeLine berdampingan dengan Caddy. HTTPS otomatis dari Caddy bersaing dengan SafeLine untuk port 443. Pengaturan yang dapat diterapkan memberikan port 80 dan 443 kepada SafeLine, dan memindahkan Caddy ke port HTTP internal non-publik seperti 8080 untuk lompatan dari SafeLine ke Caddy ke aplikasi.

Poin utama: Bentuk A paling sederhana untuk VPS baru; Bentuk B adalah pilihan yang tepat ketika NPM sudah berjalan; Bentuk C membutuhkan penetapan ulang port Caddy secara sengaja.

Instal SafeLine di VPS Anda

Instalasinya sendiri adalah bagian yang mudah. SafeLine menyediakan dua jalur instalasi: installer otomatis yang menarik skrip jarak jauh dari waf.chaitin.com, dan jalur Docker Compose manual yang memungkinkan Anda memeriksa semuanya sebelum dijalankan. Pilih yang sesuai dengan kebijakan keamanan Anda.

Langkah 1: Konfirmasi Docker Sudah Siap

Periksa kembali versi Docker dan pastikan Docker daemon sedang berjalan:

docker --version
docker compose version
sudo systemctl status docker

Output yang diharapkan mencakup active (running) untuk Docker daemon. Jika tidak berjalan, jalankan dengan sudo systemctl start docker dan aktifkan saat boot dengan sudo systemctl enable docker.

Langkah 2: Jalankan Installer SafeLine

Ada dua sub-jalur. Pilih salah satu.

Langkah 2a, instalasi otomatis. Jalankan installer dengan hak akses root:

sudo bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Skrip menanyakan di mana harus meletakkan direktori data SafeLine, menarik image Docker, dan menjalankan stack. Setelah instalasi, jalankan sudo docker exec safeline-mgt resetadmin untuk mengambil atau mereset kredensial administrator, seperti dijelaskan dalam panduan deployment resmi. Simpan kredensial yang dihasilkan secara aman.

Catatan: Perintah ini mengunduh dan menjalankan skrip shell jarak jauh dari waf.chaitin.com sebagai root. One-liner resmi menyertakan curl -k, yang menonaktifkan verifikasi sertifikat TLS. Tinjau skrip yang diunduh sebelum dieksekusi, atau gunakan Langkah 2b jika risiko tersebut tidak dapat diterima. SafeLine juga tersedia sebagai deployment Cloudzy sekali klik, tetapi image tersebut menggunakan /opt/safeline, /opt/safeline/.env, dan /opt/safeline/docker-compose.yml. Jangan gunakan /data/safeline jalur dari panduan ini tanpa perubahan pada image Cloudzy.

Langkah 2b, instalasi Docker Compose manual. Unduh dan periksa file Compose resmi, lalu jalankan stack:

sudo mkdir -p /data/safeline
cd /data/safeline
sudo wget -O /data/safeline/compose.yaml "https://waf.chaitin.com/release/latest/compose.yaml"
POSTGRES_PASSWORD="$(openssl rand -hex 32)"
sudo tee .env >/dev/null <<EOF
SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD=$POSTGRES_PASSWORD
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=chaitin
ARCH_SUFFIX=
RELEASE=
REGION=-g
MGT_PROXY=0
EOF
unset POSTGRES_PASSWORD
# Also adjust SUBNET_PREFIX if your VPS already uses 172.22.222.0/24.
sudo chmod 600 /data/safeline/.env
sudo docker compose up -d

Setelah docker compose up -d selesai, daftar container yang berjalan untuk memastikan:

sudo docker compose ps

Anda seharusnya melihat container untuk safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi, dan safeline-chaos. Jika ada container yang menampilkan Exited, lihat Langkah 3 untuk dua penyebab paling umum.

Langkah 3: Atasi Kesalahan Instalasi yang Umum

Dua kesalahan cukup sering muncul sehingga layak mendapat langkahnya sendiri.

Tumpang tindih subnet. Jika instalasi gagal dengan Pool overlaps with other one on this address space, subnet default SafeLine berkonflik dengan jaringan Docker yang sudah ada. Seperti didokumentasikan dalam panduan pemecahan masalah instalasi SafeLine, perbaiki ini dengan menyunting /data/safeline/.env:

sudo nano /data/safeline/.env
# Find the line:
#   SUBNET_PREFIX=172.22.222
# Change to an unused range, for example:
#   SUBNET_PREFIX=172.30.30
sudo docker compose -f /data/safeline/compose.yaml down
sudo docker compose -f /data/safeline/compose.yaml up -d

Kesalahan resolver IPv6. Jika safeline-tengine crash dengan nginx: [emerg] invalid IPv6 address in resolver, pertama periksa file resolver dan tentukan siapa yang mengelolanya:

readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Jangan sunting /etc/resolv.conf secara langsung jika dihasilkan oleh systemd-resolved, NetworkManager, atau penyedia VPS. Perbaiki nilai nameserver yang salah bentuk pada konfigurasi service pengelola, hasilkan ulang file resolver, lalu restart Tengine:

sudo docker restart safeline-tengine

Langkah 4: Akses Dasbor

Dasbor manajemen SafeLine mendengarkan di TCP 9443 melalui HTTPS. Jangan biarkan port administratif ini terbuka untuk seluruh internet. Batasi hanya untuk alamat sumber tepercaya atau VPN, atau blokir akses publik dan gunakan tunnel SSH:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Buka https://localhost:9443 melalui tunnel. Peringatan sertifikat self-signed wajar muncul pada akses pertama; verifikasi bahwa koneksi SSH mencapai server yang dituju sebelum melanjutkan.

Jika Anda kehilangan kredensial awal, reset kata sandi admin dari host:

sudo docker exec safeline-mgt resetadmin

Perintah tersebut mencetak kredensial administrator yang bisa Anda gunakan untuk masuk kembali.

Konfigurasikan SafeLine untuk Arsitektur Anda

SafeLine sekarang berjalan, tetapi belum melindungi apa pun. Halaman Applications pada dasbor adalah tempat Anda memberi tahu SafeLine situs mana yang harus dilindungi dan ke mana meneruskan lalu lintas yang sudah dibersihkan. Konfigurasinya berbeda tergantung arsitektur yang Anda pilih sebelumnya, jadi setiap bentuk mendapat subbagiannya sendiri. Kerjakan hanya yang sesuai dengan pengaturan Anda.

Bentuk A: SafeLine sebagai Satu-satunya Reverse Proxy

Untuk Bentuk A, SafeLine mendengarkan langsung di port 80 dan 443 dan meneruskan lalu lintas yang sudah dibersihkan ke aplikasi backend Anda di port non-publik. Di dasbor:

1. Navigasikan ke Applications, lalu Add Application.
2. Atur port pendengaran ke 443 dan aktifkan SSL. Gunakan alur kerja sertifikat yang tersedia pada rilis SafeLine yang Anda instal. Rilis CE saat ini menyertakan pengajuan Free Cert dan penanganan perpanjangan, sementara unggah sertifikat manual tetap tersedia.
3. Atur upstream ke http://127.0.0.1:8080. Jika backend berjalan di Docker, publikasikan port-nya hanya di loopback, misalnya "127.0.0.1:8080:8080" di bagian ports service tersebut. Hindari IP container yang di-hardcode seperti 172.17.0.5 karena bisa berubah ketika container dibuat ulang.
4. Simpan aplikasi. SafeLine langsung mulai mendengarkan di 443 dan meneruskan lalu lintas yang sudah dibersihkan ke backend.
5. Pastikan record DNS A domain Anda mengarah ke IP publik VPS dan bahwa port 80 dan 443 dapat dijangkau dari luar.

Jika port 443 sudah dipakai proses lain, container SafeLine akan gagal melakukan bind dan dasbor akan menampilkan kesalahan pada aplikasi tersebut. Hentikan proses yang berkonflik, atau pilih port yang berbeda, sebelum menambahkan aplikasi.

Bentuk B: SafeLine di Belakang Nginx Proxy Manager

Bentuk B membiarkan NPM melakukan apa yang sudah dilakukannya (menguasai 80 dan 443, menangani Let's Encrypt) dan menyisipkan SafeLine sebagai lapisan keamanan khusus di belakangnya. Alur lalu lintasnya adalah: client, lalu NPM (port 443, terminasi TLS), lalu SafeLine (port 10080, HTTP), lalu aplikasi backend.

Di dalam dasbor SafeLine:

1. Applications, lalu Add Application. Atur port pendengaran ke 10080 dan biarkan SSL nonaktif (NPM sudah menerminasi TLS).
2. Atur upstream ke alamat internal aplikasi, seperti dijelaskan pada Bentuk A.
3. Simpan aplikasi.

Di Nginx Proxy Manager:

1. Hosts, lalu Proxy Hosts, lalu Add Proxy Host.
2. Tab Details: atur nama domain, skema http, dan forward port 10080. Jika NPM berjalan langsung di host, gunakan 127.0.0.1 sebagai forward hostname. Jika NPM berjalan di Docker pada Linux, 127.0.0.1 menunjuk ke container NPM alih-alih host VPS. Tambahkan pemetaan host-gateway Docker ke service Compose NPM, lalu gunakan host.docker.internal sebagai forward hostname:

extra_hosts:
  - "host.docker.internal:host-gateway"

Dari direktori Compose NPM, jalankan sudo docker compose up -d agar container dibuat ulang dengan pemetaan host yang baru.

3. Tab SSL: minta sertifikat Let's Encrypt, paksa SSL, dan aktifkan HTTP/2.
4. Biarkan tab Advanced NPM kosong untuk X-Forwarded-For. Dalam template NPM saat ini, konten Advanced disisipkan pada scope server dan tidak menimpa header tingkat location yang dihasilkan menurut aturan pewarisan NGINX. Location yang dihasilkan mengirimkan:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Direktif kedua menambahkan alamat yang diamati NPM sebagai nilai paling kanan dalam header.

5. Simpan Proxy Host.

Kembali di SafeLine, konfigurasikan ekstraksi source-IP hanya setelah memastikan rantai header yang efektif. SafeLine 9.3.1 memperkenalkan ekstraksi XFF yang fleksibel dengan pemilihan arah dan indeks.

1. Settings, lalu Advanced, lalu Real IP from Header. Atur nama header ke X-Forwarded-For.
2. Gunakan ekstraksi khusus dari ujung header dan pilih alamat paling kanan yang ditambahkan NPM. Label indeks yang tepat bervariasi menurut versi, jadi verifikasi hasilnya di Logs, lalu Access. Jika rilis yang terinstal lebih lama dari 9.3.1, perbarui sebelum mengikuti topologi ini.
3. Jika Cloudflare atau CDN lain berada di depan NPM, konfigurasikan NPM terlebih dahulu untuk hanya memercayai rentang proxy yang dipublikasikan penyedia tersebut agar alamat yang ditambahkan NPM dapat dipercaya. Jangan pilih posisi tetap sampai Anda memeriksa dan menguji rantai header yang sebenarnya.
4. Simpan dan muat ulang aplikasi.

Uji konfigurasi dari mesin di luar VPS:

curl -H "X-Forwarded-For: 1.2.3.4" "https://yourdomain.com/"

Log akses SafeLine seharusnya menampilkan alamat publik asli Anda, bukan 1.2.3.4 atau alamat bridge NPM.

Cegah pengguna melewati SafeLine dengan menjaga agar listener backend tetap privat. Untuk backend Docker Compose, publikasikan port hanya di loopback:

ports:
  - "127.0.0.1:8080:8080"

Untuk service yang berjalan langsung di host, konfigurasikan agar mendengarkan di 127.0.0.1:8080 alih-alih 0.0.0.0:8080. Verifikasi kedua port internal dari mesin di luar VPS:

curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:10080"
curl --connect-timeout 5 "http://YOUR_VPS_PUBLIC_IP:8080"

Koneksi TCP seharusnya ditolak atau timeout. Kesalahan HTTP atau "Empty reply from server" tetap berarti port dapat dijangkau publik dan harus diamankan. Jika binding loopback tidak memungkinkan, buat aturan firewall yang disesuaikan dengan interface, jaringan Docker, dan container tujuan yang sebenarnya alih-alih menerapkan aturan DOCKER-USER generik.

Bentuk C: SafeLine Dengan Caddy

Untuk Bentuk C, SafeLine mengambil port 80 dan 443; Caddy pindah ke port HTTP internal non-publik. Alur lalu lintasnya adalah: client, lalu SafeLine (443, TLS), lalu Caddy (8080, HTTP internal), lalu backend aplikasi.

Sunting /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

Pengguna :8080 blok site adalah bagian pentingnya: Caddy sekarang mendengarkan di port HTTP internal alih-alih bersaing dengan SafeLine untuk 443. Baris bind 127.0.0.1 menjaga listener tersebut tetap lokal di VPS. Muat ulang Caddy dengan sudo systemctl reload caddy dan konfirmasi dengan sudo ss -ltnp | grep -E ':(443|8080)' bahwa Caddy terikat ke 8080, bukan 443.

Di SafeLine, tambahkan aplikasi yang mendengarkan di 443 dengan SSL diaktifkan, lalu atur upstream ke http://127.0.0.1:8080. Pengaturan X-Forwarded-For dapat tetap pada opsi koneksi jaringan default karena Caddy berada di belakang SafeLine, bukan di depannya.

Pilih Mode Proteksi dan Verifikasi WAF Memblokir Serangan

SafeLine memiliki tiga mode proteksi yang menentukan apa yang terjadi ketika mesin menandai sebuah permintaan sebagai berbahaya. Mode awal yang tepat bergantung pada aplikasinya; langkah verifikasinya sama pada mode mana pun.

Mode Proteksi: Monitor, Balanced, Strict

Setiap aplikasi di SafeLine memiliki pengaturan mode proteksinya sendiri, yang dapat dikonfigurasi di bawah Applications, lalu aplikasi Anda, lalu Protection Mode:

• Monitor. SafeLine mencatat permintaan yang seharusnya diblokir tetapi tidak memblokirnya. Ini adalah titik awal paling aman untuk aplikasi produksi yang kompleks dengan formulir input yang kaya (forum, panel admin dengan bidang WYSIWYG, API yang menerima payload JSON bebas). Jalankan Monitor selama beberapa hari, tinjau halaman Attack Events, dan pastikan tidak ada false positive terhadap pengguna asli sebelum meningkatkan ke Balanced.
• Balanced. Mode default. Angka GitHub yang dipublikasikan vendor SafeLine melaporkan deteksi 71.65%, akurasi 99.45%, dan tingkat false-positive 0.07% untuk mode Balanced. Mode Strict dilaporkan sebesar deteksi 76.17%, akurasi 99.38%, dan tingkat false-positive 0.22%. Ini adalah hasil yang dilaporkan vendor, bukan tolok ukur independen, dan README tidak mengidentifikasi dataset tersebut sebagai WAF-Eval. Perlakukan angka-angka ini sebagai angka produk komparatif, bukan performa produksi yang dijamin.
• Strict. Kumpulan aturan yang lebih agresif dengan heuristik lebih ketat dan trade-off antara deteksi versus false-positive seperti ditunjukkan di atas. Layak dicoba setelah satu atau dua minggu operasi Balanced yang bersih, begitu Anda memahami lalu lintas Anda.

Rekomendasi: Balanced untuk deployment baru tanpa lalu lintas langsung yang bisa terganggu. Untuk aplikasi produksi yang sudah ada, mulai dengan Monitor selama beberapa hari, cari false positive di log Attack Events, dan tingkatkan ke Balanced setelah Anda menyetel setiap pengecualian. Strict layak dicoba setelah satu atau dua minggu Balanced begitu Anda memahami lalu lintas Anda.

Verifikasi WAF Dengan Uji SQLi curl

Langkah terakhir sebelum menganggap instalasi selesai adalah memastikan WAF benar-benar mencegat serangan. Jalankan probe SQL-injection yang tidak berbahaya terhadap situs Anda yang dilindungi dari mesin mana pun di luar VPS:

curl -i "https://yourdomain.com/?id=1%20and%201=2%20union%20select%201"

Ini adalah vektor uji SQL-injection yang dipublikasikan SafeLine. Dalam mode Balanced atau Strict, harapkan status 403 dan respons blokir SafeLine. Dalam mode Monitor, harapkan permintaan dicatat tanpa diblokir. Versi HTTP dan isi respons yang tepat bisa bervariasi, jadi konfirmasi hasilnya dengan entri yang cocok di Attack Events.

Kemudian buka dasbor melalui metode akses terbatas dari Langkah 4 dan navigasikan ke Logs, lalu Attack Events. Anda seharusnya melihat entri baru dengan timestamp yang cocok, jenis serangan SQL Injection, source IP yang cocok dengan mesin tempat Anda menjalankan curl, dan query string bermasalah pada detail permintaan. Klik ke dalam event untuk melihat permintaan dan respons lengkap yang ditangkap SafeLine.

Jika permintaan curl mengembalikan 200 OK, tafsirkan hasilnya bersama log Attack Events:

• Event SQL Injection yang cocok berarti aplikasi kemungkinan berada dalam mode Monitor; pencatatan tanpa pemblokiran adalah hal yang wajar.
• Jika tidak ada event yang cocok, pastikan DNS teresolusi ke VPS yang dituju, verifikasi konfigurasi listener dan upstream SafeLine, dan korelasikan waktu permintaan dengan log akses SafeLine.
• Pastikan juga bahwa proteksi diaktifkan dan tidak ada whitelist IP, aturan allow khusus, atau pengecualian path yang mencakup permintaan uji tersebut.

Poin utama: Jika probe curl mengembalikan 403 dengan halaman intersepsi SafeLine dan sebuah entri muncul di Attack Events dengan jenis serangan SQL Injection, WAF mencegat lalu lintas dengan benar.

Apa yang Dicakup Tier Gratis dan Apa yang Membutuhkan Paket Berbayar

Tier Personal gratis sudah cukup untuk melindungi sebagian besar deployment VPS tunggal. Tier berbayar mulai penting ketika Anda membutuhkan fitur operasional (notifikasi, ekspor log, geo-blocking) atau melampaui batas 10 aplikasi.

Rinciannya, bersumber dari halaman harga CyberServal:

• Personal, gratis. Hingga 10 aplikasi. Termasuk mesin deteksi semantik (SQLi, XSS, command injection, path traversal, SSRF, XXE, CRLF), rate limiting, tantangan CAPTCHA bot, enkripsi HTML/JS dinamis terhadap scraper otomatis, aturan ACL web, dan pengelolaan sertifikat. Rilis CE saat ini juga menyertakan pengajuan Free Cert dan penanganan perpanjangan.
• Lite, $10/bulan atau $100/tahun. Menambahkan geo-blocking, basis data IP threat intelligence, integrasi notifikasi Discord dan Telegram, ekspor log serangan, dan menaikkan batas aplikasi menjadi 20.
• Pro, $100/bulan atau $1,000/tahun. Menambahkan deteksi serangan yang lebih kuat, konfigurasi per-service dan global, halaman intersepsi khusus, load balancing upstream, sinkronisasi node master-slave, dan aplikasi tanpa batas. Lihat tabel harga saat ini untuk perubahan.
• Ultimate, harga khusus. Ketentuan enterprise yang disesuaikan dengan dukungan 1-lawan-1 di berbagai kanal dan pengembangan fitur khusus.

SafeLine memproses dan menyimpan data aplikasi di dalam stack Compose lokalnya. Namun, catatan rilis CE saat ini menyebutkan Threat Intelligence Sharing, jadi operator sebaiknya meninjau kontrol UEP, privasi, dan berbagi pada versi yang terinstal serta mengamati koneksi keluar sebelum menganggap deployment sebagai zero-egress.

Ke Mana Setelah Ini

Instalasi selesai dan WAF terverifikasi. Beberapa tugas lanjutan akan membantu menjaga deployment tetap sehat.

• Untuk aplikasi produksi apa pun dengan input pengguna yang kaya (forum, panel admin, API bebas), atur mode proteksi ke Monitor selama tiga hingga tujuh hari, tinjau halaman Attack Events setiap hari, dan tingkatkan ke Balanced setelah Anda menyetel setiap false positive.
• Pada tier Lite, atur integrasi notifikasi Discord atau Telegram agar peringatan serangan menjangkau Anda di luar dasbor.
• Jadwalkan jendela pemeliharaan bulanan. Sebelum melakukan upgrade, cadangkan data dan konfigurasi environment SafeLine, baca catatan rilis saat ini, dan gunakan prosedur upgrade yang didukung untuk versi yang Anda instal. Jangan hanya mengandalkan docker compose pull diikuti oleh docker compose up -d, karena definisi Compose atau variabel environment yang dibutuhkan dapat berubah antar rilis. Pengguna Cloudzy sekali klik sebaiknya bekerja dari /opt/safeline dan mengikuti instruksi image marketplace.
• Berlangganan halaman rilis SafeLine untuk notifikasi patch keamanan dan ke repositori proyek untuk pelacakan isu.

Jika Anda belum memiliki VPS untuk deployment ini, SafeLine tersedia sebagai deployment sekali klik di Marketplace Cloudzy. Paket dengan 4 GB RAM memberikan ruang praktis yang direkomendasikan dalam panduan ini; periksa kembali tabel harga saat ini di Cloudzy pada saat publikasi karena spesifikasi paket dapat berubah. Image satu klik menggunakan /opt/safeline dan /opt/safeline/docker-compose.yml, sehingga instruksi arsitektur dan dasbor berlaku, tetapi /data/safeline perintah dari panduan ini tidak berlaku secara identik.

Pertanyaan yang Sering Diajukan

Apakah SafeLine WAF Menggantikan Nginx Proxy Manager, atau Saya Menjalankan Keduanya?

SafeLine dapat menggantikan Nginx Proxy Manager ketika di-deploy sebagai satu-satunya reverse proxy. Namun, ia tidak harus menggantikan NPM. Pengaturan yang umum tetap menempatkan NPM di depan untuk SSL dan routing serta menempatkan SafeLine di belakangnya sebagai lapisan keamanan khusus. Keduanya berfungsi; pilihannya bergantung pada apakah Anda ingin satu alat mengerjakan kedua tugas atau dua alat yang masing-masing mengerjakan satu tugas dengan baik.

Apakah Tier Gratis Cukup untuk Satu Situs WordPress atau SaaS Kecil?

Ya, untuk proteksi. Tier Personal gratis mencakup mesin deteksi semantik, rate limiting, tantangan CAPTCHA bot, dan enkripsi HTML/JS dinamis, yang merupakan pertahanan inti untuk satu situs. Tier berbayar menambahkan fitur operasional seperti geo-blocking, ekspor log serangan, notifikasi eksternal, batas aplikasi lebih tinggi, deteksi lebih kuat, dan load balancing. Apakah tier berbayar diperlukan bergantung pada fitur yang dibutuhkan dan jumlah aplikasi, bukan pada volume lalu lintas semata.

Apakah SafeLine Berfungsi di VPS 1 GB RAM?

SafeLine minimum resmi adalah 1 GB RAM. Itu bisa cukup untuk pengujian atau beban kerja yang sangat ringan, tetapi kapasitas produksi bergantung pada lalu lintas, fitur yang diaktifkan, dan retensi log. Untuk deployment produksi kecil, 2 vCPU dan 4 GB RAM adalah titik awal yang konservatif; pantau penggunaan memori dan skalakan berdasarkan beban terukur.

Mengapa ARM64 Membutuhkan Lisensi Berbayar?

SafeLine deployment resmi SafeLine menyatakan bahwa deployment ARM membutuhkan lisensi Pro dan bahwa Personal Edition tidak didukung di ARM. Jika Anda menginginkan Personal Edition, pilih VPS x86_64; jika Anda membutuhkan ARM, rencanakan lisensi Pro.

Apa yang Diterima Chaitin Tech Dari Instance SafeLine Saya?

Data keluar yang sebenarnya bisa bervariasi menurut rilis dan fitur yang diaktifkan. Catatan rilis CE saat ini menyebutkan Threat Intelligence Sharing, sementara versi yang terinstal mungkin juga menampilkan UEP atau kontrol berbagi lainnya. Tinjau pengaturan tersebut dan catatan rilis untuk versi yang Anda instal, lalu validasi egress pada tingkat jaringan. Container lokal SafeLine menangani data aplikasi, tetapi fakta itu saja tidak membuktikan bahwa menolak UEP menghentikan setiap permintaan keluar.