Cách triển khai SafeLine WAF trên Linux VPS

Các ứng dụng web hướng ra Internet thường xuyên bị dò quét SQL injection, lạm dụng thông tin đăng nhập và các mẫu tấn công dựa trên lỗ hổng đã biết. SafeLine là một WAF tự lưu trữ theo giấy phép GPL-3.0 chạy dưới dạng stack Docker Compose và lọc lưu lượng HTTP/S trước khi chuyển tiếp các yêu cầu được cho phép đến origin. Gói Personal miễn phí hỗ trợ tối đa 10 ứng dụng.

Hướng dẫn này bao quát quá trình cài đặt và ba khía cạnh cần đặc biệt lưu ý: quyết định về kiến trúc reverse-proxy, cấu hình mạng Docker khi SafeLine đứng sau một proxy sẵn có như Nginx Proxy Manager, và một lệnh kiểm chứng bạn có thể chạy sau khi cài đặt để xác nhận WAF thực sự đang chặn các cuộc tấn công.

Phiên bản ngắn gọn

• Cài đặt SafeLine trên Linux VPS bằng Docker Compose. Dùng trình cài đặt một dòng, hoặc chọn hướng Docker Compose thủ công để kiểm tra định nghĩa Compose và cấu hình môi trường trước khi khởi động stack.
• Hãy quyết định kiến trúc reverse-proxy trước khi cài đặt: SafeLine làm proxy duy nhất, SafeLine đứng sau một Nginx Proxy Manager sẵn có, hoặc SafeLine chia sẻ máy chủ với Caddy. Mỗi mô hình cần cách gán cổng và thiết lập X-Forwarded-For khác nhau.
• Sau khi cài đặt, hãy kiểm chứng WAF bằng cách gửi một yêu cầu curl dò SQL-injection đến URL được bảo vệ. Ở chế độ Balanced hoặc Strict, phản hồi 403 kèm một mục Attack Events tương ứng xác nhận việc chặn. Ở chế độ Monitor, mục sự kiện tương ứng xác nhận đã phát hiện dù phản hồi vẫn có thể thành công.
• Gói Personal miễn phí bao gồm tối đa 10 ứng dụng và engine phát hiện lõi. Chặn theo vị trí địa lý, xuất log tấn công và thông báo ra bên ngoài cần gói Lite; khả năng phát hiện tấn công mạnh hơn và cân bằng tải cần gói Pro.

Trước khi bắt đầu: Điều kiện tiên quyết và nội dung hướng dẫn này bao quát

Hướng dẫn này giả định bạn có một Linux VPS mà bạn có thể SSH vào với quyền root hoặc sudo, và Docker đã được cài đặt. Kết thúc, bạn sẽ có một phiên bản SafeLine hoạt động bảo vệ ít nhất một trang web và một lệnh kiểm chứng bạn có thể chạy lại bất cứ lúc nào.

Bạn cần:

• Một Linux VPS. Các lệnh bên dưới giả định hệ thống kiểu Debian hoặc Ubuntu có systemd; hãy kiểm tra lại tên gói và tên dịch vụ trên các bản phân phối khác.
• Tối thiểu 1 vCPU, 1 GB RAM và 5 GB dung lượng đĩa theo yêu cầu triển khai chính thức. Để có dư địa thực tế cho môi trường production, hướng dẫn này khuyến nghị 2 vCPU, 4 GB RAM và 20 GB dung lượng đĩa.
• Docker 20.10.14 trở lên và Docker Compose 2.0 trở lên.
• Một CPU x86_64 có hỗ trợ SSSE3; hãy kiểm tra bằng lscpu | grep ssse3 thay vì mặc định cho rằng tập lệnh đó có sẵn.
• Một tên miền hoặc subdomain có DNS trỏ về IP công khai của VPS nếu bạn dự định công khai ứng dụng được bảo vệ qua HTTPS.
• Các cổng phù hợp với topology đã chọn. Mô hình A và C thường giao cho SafeLine các cổng 80 và 443, trong khi Mô hình B để các cổng đó cho Nginx Proxy Manager và gán cho SafeLine một listener khác chẳng hạn như 10080.
• Quyền root hoặc sudo.

Tại tường lửa hoặc security group của nhà cung cấp VPS, chỉ mở những cổng công khai mà topology đã chọn cần đến. Giới hạn SSH và TCP 9443 chỉ cho các nguồn quản trị tin cậy. Ở Mô hình B, giữ TCP 10080 đóng với IPv4 và IPv6 công khai, và giữ các cổng backend như 8080 ở chế độ riêng tư trong mọi topology. Truy cập trực tiếp vào 10080 sẽ bỏ qua NPM và làm mất hiệu lực ranh giới tin cậy X-Forwarded-For.

Lưu ý: Đối với triển khai ARM64 thủ công, hãy đặt ARCH_SUFFIX=-arm. Tài liệu triển khai chính thức của SafeLine nêu rõ rằng ARM yêu cầu giấy phép Pro và Personal Edition không được hỗ trợ trên ARM. Hãy dùng một VPS x86_64 cho Personal Edition.

Kiểm tra Docker trước khi bắt đầu:

docker --version
docker compose version

Cả hai lệnh đều phải trả về phiên bản đã cài đặt. Chỉ tiếp tục nếu Docker là phiên bản 20.10.14 trở lên và Docker Compose là phiên bản 2.0.0 trở lên; nếu không, hãy nâng cấp trước khi cài đặt SafeLine.

Chọn kiến trúc Reverse-Proxy của bạn trước tiên

Một VPS mới cho phép SafeLine sở hữu hoàn toàn các cổng 80 và 443. Một VPS đã chạy Nginx Proxy Manager, Caddy, hoặc Nginx riêng của ứng dụng thì không, và quyết định về kiến trúc chính là ranh giới giữa một lần cài đặt suôn sẻ và một xung đột cổng ngay ở lần khởi động đầu tiên. Làm đúng điều này một lần ngay từ đầu và phần còn lại của việc triển khai chỉ là thao tác máy móc.

Ba mô hình:

• Mô hình A, SafeLine làm reverse proxy duy nhất. SafeLine sở hữu các cổng 80 và 443 và quản lý TLS cho ứng dụng được bảo vệ. Các bản phát hành CE hiện tại bao gồm quy trình Free Cert, trong khi việc tải lên chứng chỉ thủ công vẫn khả dụng; hãy kiểm tra chính xác các tùy chọn chứng chỉ trong bản phát hành đã cài đặt. Backend chạy trên một cổng không công khai và SafeLine định tuyến đến nó.
• Mô hình B, SafeLine đứng sau Nginx Proxy Manager (NPM). NPM giữ các cổng 80 và 443 và xử lý SSL. SafeLine lắng nghe trên cổng 10080 (chỉ HTTP, vì NPM đã kết thúc TLS). NPM chuyển tiếp vào SafeLine; SafeLine chuyển tiếp vào backend. Đây là thiết lập phổ biến khi NPM đã được triển khai.
• Mô hình C, SafeLine song hành cùng Caddy. HTTPS tự động của Caddy tranh chấp cổng 443 với SafeLine. Một cách sắp xếp khả thi là giao cho SafeLine các cổng 80 và 443, và chuyển Caddy sang một cổng HTTP nội bộ không công khai như 8080 cho chặng SafeLine đến Caddy đến ứng dụng.

Điểm mấu chốt: Mô hình A đơn giản nhất cho một VPS mới; Mô hình B là lựa chọn đúng khi NPM đã chạy; Mô hình C cần một lần gán lại cổng Caddy có chủ đích.

Cài đặt SafeLine trên VPS của bạn

Bản thân việc cài đặt là phần dễ. SafeLine cung cấp hai hướng cài đặt: một trình cài đặt tự động kéo một script từ xa từ waf.chaitin.com, và một hướng Docker Compose thủ công cho phép bạn kiểm tra mọi thứ trước khi nó chạy. Hãy chọn hướng phù hợp với chính sách bảo mật của bạn.

Bước 1: Xác nhận Docker đã sẵn sàng

Kiểm tra lại phiên bản Docker và xác nhận Docker daemon đang chạy:

docker --version
docker compose version
sudo systemctl status docker

Kết quả kỳ vọng bao gồm active (running) cho Docker daemon. Nếu nó không chạy, hãy khởi động bằng sudo systemctl start docker và bật nó khi khởi động bằng sudo systemctl enable docker.

Bước 2: Chạy trình cài đặt SafeLine

Có hai hướng con. Hãy chọn một.

Bước 2a, cài đặt tự động. Chạy trình cài đặt với quyền root:

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

Script sẽ hỏi nơi đặt thư mục dữ liệu SafeLine, kéo các Docker image và khởi động stack. Sau khi cài đặt, hãy chạy sudo docker exec safeline-mgt resetadmin để lấy hoặc đặt lại thông tin đăng nhập quản trị viên, như được mô tả trong hướng dẫn triển khai chính thức. Hãy lưu trữ thông tin đăng nhập thu được một cách an toàn.

Lưu ý: Lệnh này tải xuống và thực thi một shell script từ xa từ waf.chaitin.com với quyền root. Lệnh một dòng chính thức bao gồm curl -k, vốn tắt việc xác minh chứng chỉ TLS. Hãy xem lại script đã tải xuống trước khi thực thi, hoặc dùng Bước 2b nếu rủi ro đó là không chấp nhận được. SafeLine cũng có sẵn dưới dạng triển khai một cú nhấp trên Cloudzy, nhưng image đó dùng /opt/safeline, /opt/safeline/.env, và /opt/safeline/docker-compose.yml. Đừng dùng các /data/safeline đường dẫn của hướng dẫn này một cách nguyên xi trên image Cloudzy.

Bước 2b, cài đặt Docker Compose thủ công. Tải xuống và kiểm tra file Compose chính thức, sau đó khởi động 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

Sau docker compose up -d hoàn tất, hãy liệt kê các container đang chạy để xác nhận:

sudo docker compose ps

Bạn sẽ thấy các container safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi và safeline-chaos. Nếu có container nào hiển thị Exited, hãy xem Bước 3 để biết hai nguyên nhân phổ biến nhất.

Bước 3: Khắc phục các lỗi cài đặt thường gặp

Có hai lỗi xảy ra đủ thường xuyên để xứng đáng có một bước riêng.

Trùng lặp subnet. Nếu quá trình cài đặt thất bại với Pool overlaps with other one on this address space, subnet mặc định của SafeLine xung đột với một mạng Docker sẵn có. Như được ghi lại trong một hướng dẫn khắc phục sự cố cài đặt SafeLine, hãy khắc phục bằng cách chỉnh sửa /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

Lỗi resolver IPv6. Nếu safeline-tengine gặp sự cố với nginx: [emerg] invalid IPv6 address in resolver, trước tiên hãy kiểm tra file resolver và xác định thành phần nào quản lý nó:

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

Đừng chỉnh sửa /etc/resolv.conf trực tiếp nếu nó được tạo ra bởi systemd-resolved, NetworkManager, hoặc nhà cung cấp VPS. Hãy sửa giá trị nameserver bị lỗi định dạng trong cấu hình của dịch vụ đang quản lý, tạo lại file resolver, rồi khởi động lại Tengine:

sudo docker restart safeline-tengine

Bước 4: Truy cập bảng điều khiển

Bảng điều khiển quản lý của SafeLine lắng nghe trên TCP 9443 qua HTTPS. Đừng để cổng quản trị này mở với toàn bộ internet. Hãy giới hạn nó chỉ cho một địa chỉ nguồn tin cậy hoặc VPN, hoặc chặn truy cập công khai và dùng một SSH tunnel:

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

Mở https://localhost:9443 thông qua tunnel. Cảnh báo chứng chỉ tự ký là điều dự kiến ở lần truy cập đầu tiên; hãy xác minh rằng kết nối SSH đã đến đúng máy chủ dự định trước khi tiếp tục.

Nếu bạn làm mất thông tin đăng nhập ban đầu, hãy đặt lại mật khẩu quản trị từ host:

sudo docker exec safeline-mgt resetadmin

Lệnh này in ra thông tin đăng nhập quản trị viên mà bạn có thể dùng để đăng nhập lại.

Cấu hình SafeLine cho kiến trúc của bạn

SafeLine đang chạy rồi, nhưng nó chưa bảo vệ điều gì cả. Trang Applications của bảng điều khiển là nơi bạn cho SafeLine biết cần bảo vệ những trang web nào và chuyển tiếp lưu lượng đã được lọc đến đâu. Cấu hình khác nhau tùy theo kiến trúc bạn đã chọn trước đó, nên mỗi mô hình có một tiểu mục riêng. Chỉ cần thực hiện theo mô hình khớp với thiết lập của bạn.

Mô hình A: SafeLine làm Reverse Proxy duy nhất

Với Mô hình A, SafeLine lắng nghe trực tiếp trên các cổng 80 và 443 và chuyển tiếp lưu lượng đã được lọc đến ứng dụng backend của bạn trên một cổng không công khai. Trong bảng điều khiển:

1. Điều hướng đến Applications, rồi Add Application.
2. Đặt cổng lắng nghe là 443 và bật SSL. Dùng quy trình chứng chỉ có sẵn trong bản phát hành SafeLine bạn đã cài đặt. Các bản phát hành CE hiện tại bao gồm việc đăng ký và xử lý gia hạn Free Cert, trong khi việc tải lên chứng chỉ thủ công vẫn khả dụng.
3. Đặt upstream là http://127.0.0.1:8080. Nếu backend chạy trong Docker, hãy chỉ publish cổng của nó trên loopback, ví dụ "127.0.0.1:8080:8080" trong phần ports của dịch vụ. Hãy tránh dùng một IP container cố định như 172.17.0.5 vì nó có thể thay đổi khi container được tạo lại.
4. Lưu ứng dụng. SafeLine ngay lập tức bắt đầu lắng nghe trên 443 và chuyển tiếp lưu lượng đã được lọc đến backend.
5. Xác nhận bản ghi DNS A của tên miền trỏ về IP công khai của VPS và rằng các cổng 80 và 443 có thể truy cập được từ bên ngoài.

Nếu cổng 443 đã bị một tiến trình khác chiếm dụng, container của SafeLine sẽ không bind được và bảng điều khiển sẽ báo lỗi trên ứng dụng đó. Hãy dừng tiến trình gây xung đột, hoặc chọn một cổng khác, trước khi thêm ứng dụng.

Mô hình B: SafeLine đứng sau Nginx Proxy Manager

Mô hình B giữ NPM làm đúng những gì nó vốn đang làm (sở hữu 80 và 443, xử lý Let's Encrypt) và đặt SafeLine vào như một tầng bảo mật chuyên trách phía sau nó. Luồng lưu lượng là: client, rồi NPM (cổng 443, kết thúc TLS), rồi SafeLine (cổng 10080, HTTP), rồi ứng dụng backend.

Trong bảng điều khiển SafeLine:

1. Applications, rồi Add Application. Đặt cổng lắng nghe là 10080 và để SSL tắt (NPM đã kết thúc TLS).
2. Đặt upstream là địa chỉ nội bộ của ứng dụng, như đã mô tả ở Mô hình A.
3. Lưu ứng dụng.

Trong Nginx Proxy Manager:

1. Hosts, rồi Proxy Hosts, rồi Add Proxy Host.
2. Tab Details: đặt tên miền, scheme http, và cổng chuyển tiếp 10080. Nếu NPM chạy trực tiếp trên host, hãy dùng 127.0.0.1 làm hostname chuyển tiếp. Nếu NPM chạy trong Docker trên Linux, 127.0.0.1 trỏ đến container NPM chứ không phải host VPS. Hãy thêm ánh xạ host-gateway của Docker vào dịch vụ Compose của NPM, rồi dùng host.docker.internal làm hostname chuyển tiếp:

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

Từ thư mục Compose của NPM, hãy chạy sudo docker compose up -d để container được tạo lại với ánh xạ host mới.

3. Tab SSL: yêu cầu một chứng chỉ Let's Encrypt, buộc dùng SSL, và bật HTTP/2.
4. Hãy để trống tab Advanced của NPM đối với X-Forwarded-For. Trong template NPM hiện tại, nội dung Advanced được chèn ở phạm vi server và không ghi đè các header cấp location được tạo tự động theo quy tắc kế thừa của NGINX. Location được tạo tự động sẽ gửi:

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

Directive thứ hai nối thêm địa chỉ mà NPM quan sát được vào làm giá trị ngoài cùng bên phải trong header.

5. Lưu Proxy Host.

Trở lại SafeLine, chỉ cấu hình trích xuất IP nguồn sau khi đã xác nhận chuỗi header thực tế. SafeLine 9.3.1 đã giới thiệu khả năng trích xuất XFF linh hoạt với lựa chọn hướng và chỉ mục.

1. Settings, rồi Advanced, rồi Real IP from Header. Đặt tên header là X-Forwarded-For.
2. Dùng trích xuất tùy chỉnh từ cuối header và chọn địa chỉ ngoài cùng bên phải do NPM thêm vào. Các nhãn chỉ mục chính xác thay đổi theo phiên bản, nên hãy kiểm chứng kết quả trong Logs, rồi Access. Nếu bản phát hành đã cài đặt cũ hơn 9.3.1, hãy cập nhật trước khi làm theo topology này.
3. Nếu Cloudflare hoặc một CDN khác đứng trước NPM, trước tiên hãy cấu hình NPM chỉ tin tưởng các dải proxy được công bố của nhà cung cấp đó để địa chỉ do NPM nối thêm là đáng tin cậy. Đừng chọn một vị trí cố định cho đến khi bạn đã kiểm tra và thử nghiệm chuỗi header thực tế.
4. Lưu và tải lại ứng dụng.

Kiểm thử cấu hình từ một máy bên ngoài VPS:

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

Access log của SafeLine phải hiển thị địa chỉ công khai thực của bạn, chứ không phải 1.2.3.4 hay địa chỉ bridge của NPM.

Ngăn người dùng bỏ qua SafeLine bằng cách giữ listener của backend ở chế độ riêng tư. Với một backend Docker Compose, hãy chỉ publish cổng trên loopback:

ports:
  - "127.0.0.1:8080:8080"

Với một dịch vụ chạy trực tiếp trên host, hãy cấu hình nó lắng nghe trên 127.0.0.1:8080 thay vì 0.0.0.0:8080. Kiểm chứng cả hai cổng nội bộ từ một máy bên ngoài VPS:

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

Các kết nối TCP phải bị từ chối hoặc hết thời gian chờ. Một lỗi HTTP hoặc "Empty reply from server" vẫn có nghĩa là cổng đó có thể truy cập được công khai và phải được bảo vệ. Nếu không thể bind loopback, hãy tạo các quy tắc tường lửa được thiết kế riêng cho interface, mạng Docker và container đích thực tế thay vì áp dụng một quy tắc DOCKER-USER chung chung.

Mô hình C: SafeLine với Caddy

Với Mô hình C, SafeLine chiếm các cổng 80 và 443; Caddy chuyển sang một cổng HTTP nội bộ không công khai. Luồng lưu lượng là: client, rồi SafeLine (443, TLS), rồi Caddy (8080, HTTP nội bộ), rồi backend ứng dụng.

Chỉnh sửa /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

Người :8080 khối site là phần quan trọng: Caddy giờ đây lắng nghe trên một cổng HTTP nội bộ thay vì tranh chấp cổng 443 với SafeLine. Dòng bind 127.0.0.1 giữ cho listener đó chỉ cục bộ trong VPS. Hãy tải lại Caddy bằng sudo systemctl reload caddy và xác nhận bằng sudo ss -ltnp | grep -E ':(443|8080)' rằng Caddy đã bind vào 8080, chứ không phải 443.

Trong SafeLine, hãy thêm một ứng dụng lắng nghe trên 443 với SSL được bật, rồi đặt upstream là http://127.0.0.1:8080. Thiết lập X-Forwarded-For có thể giữ ở tùy chọn kết nối mạng mặc định vì Caddy đứng sau SafeLine, chứ không phải trước nó.

Chọn chế độ bảo vệ và kiểm chứng WAF đang chặn các cuộc tấn công

SafeLine có ba chế độ bảo vệ quyết định điều gì xảy ra khi engine đánh dấu một yêu cầu là độc hại. Chế độ khởi đầu phù hợp tùy thuộc vào ứng dụng; bước kiểm chứng thì giống nhau ở mọi chế độ.

Các chế độ bảo vệ: Monitor, Balanced, Strict

Mỗi ứng dụng trong SafeLine có thiết lập chế độ bảo vệ riêng, có thể cấu hình tại Applications, rồi ứng dụng của bạn, rồi Protection Mode:

• Monitor. SafeLine ghi log các yêu cầu mà lẽ ra nó sẽ chặn nhưng không chặn chúng. Đây là điểm khởi đầu an toàn nhất cho một ứng dụng production phức tạp với nhiều biểu mẫu nhập liệu phong phú (một diễn đàn, một bảng quản trị có trường WYSIWYG, một API nhận payload JSON tự do). Hãy chạy Monitor trong vài ngày, xem lại trang Attack Events, và xác nhận không có cảnh báo sai đối với người dùng thật trước khi nâng lên Balanced.
• Balanced. Chế độ mặc định. Các số liệu do nhà cung cấp công bố trên GitHub của SafeLine báo cáo tỷ lệ phát hiện 71.65%, độ chính xác 99.45%, và tỷ lệ cảnh báo sai 0.07% cho chế độ Balanced. Chế độ Strict được báo cáo với tỷ lệ phát hiện 76.17%, độ chính xác 99.38%, và tỷ lệ cảnh báo sai 0.22%. Đây là các kết quả do nhà cung cấp báo cáo chứ không phải một benchmark độc lập, và README không xác định tập dữ liệu là WAF-Eval. Hãy xem chúng như các số liệu sản phẩm để so sánh, không phải hiệu năng production được đảm bảo.
• Strict. Một bộ quy tắc quyết liệt hơn với các heuristic chặt chẽ hơn và đánh đổi giữa khả năng phát hiện và cảnh báo sai như đã nêu ở trên. Đáng thử sau một hai tuần vận hành Balanced sạch sẽ, khi bạn đã hiểu rõ lưu lượng của mình.

Khuyến nghị: Balanced cho một triển khai mới không có lưu lượng trực tiếp để làm gián đoạn. Với một ứng dụng production sẵn có, hãy bắt đầu ở Monitor trong vài ngày, tìm các cảnh báo sai trong log Attack Events, và nâng lên Balanced khi bạn đã tinh chỉnh mọi ngoại lệ. Strict đáng thử sau một hai tuần chạy Balanced khi bạn đã hiểu rõ lưu lượng của mình.

Kiểm chứng WAF bằng một bài test curl SQLi

Bước cuối cùng trước khi coi việc cài đặt là hoàn tất là xác nhận WAF thực sự chặn được một cuộc tấn công. Hãy chạy một yêu cầu dò SQL-injection vô hại nhắm vào trang web được bảo vệ của bạn từ bất kỳ máy nào bên ngoài VPS:

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

Đây là vector test SQL-injection do SafeLine công bố. Ở chế độ Balanced hoặc Strict, hãy kỳ vọng một trạng thái 403 và một phản hồi chặn của SafeLine. Ở chế độ Monitor, hãy kỳ vọng yêu cầu được ghi log mà không bị chặn. Phiên bản HTTP và nội dung phản hồi chính xác có thể khác nhau, nên hãy xác nhận kết quả bằng một mục tương ứng trong Attack Events.

Sau đó mở bảng điều khiển thông qua phương thức truy cập bị giới hạn ở Bước 4 và điều hướng đến Logs, rồi Attack Events. Bạn sẽ thấy một mục mới với timestamp tương ứng, loại tấn công SQL Injection, IP nguồn khớp với máy bạn đã chạy curl, và query string vi phạm trong phần chi tiết yêu cầu. Nhấp vào sự kiện để xem toàn bộ yêu cầu và phản hồi mà SafeLine đã ghi lại.

Nếu yêu cầu curl trả về 200 OK, hãy diễn giải kết quả cùng với log Attack Events:

• Một sự kiện SQL Injection tương ứng có nghĩa là ứng dụng có lẽ đang ở chế độ Monitor; ghi log mà không chặn là điều dự kiến.
• Nếu không có sự kiện tương ứng, hãy xác nhận rằng DNS phân giải đến đúng VPS dự định, kiểm chứng listener và cấu hình upstream của SafeLine, và đối chiếu thời điểm yêu cầu với access log của SafeLine.
• Cũng hãy xác nhận rằng bảo vệ đã được bật và không có danh sách IP trắng, quy tắc cho phép tùy chỉnh, hay ngoại lệ đường dẫn nào bao trùm yêu cầu test.

Điểm mấu chốt: Nếu yêu cầu dò curl trả về 403 với trang chặn của SafeLine và một mục xuất hiện trong Attack Events với loại tấn công SQL Injection, thì WAF đang chặn lưu lượng đúng cách.

Gói miễn phí bao gồm những gì và những gì cần gói trả phí

Gói Personal miễn phí đủ để bảo vệ hầu hết các triển khai một-VPS. Các gói trả phí bắt đầu có ý nghĩa khi bạn cần các tính năng vận hành (thông báo, xuất log, chặn theo vị trí địa lý) hoặc vượt quá giới hạn 10 ứng dụng.

Bảng phân tích chi tiết, lấy nguồn từ trang giá của CyberServal:

• Personal, miễn phí. Tối đa 10 ứng dụng. Bao gồm engine phát hiện ngữ nghĩa (SQLi, XSS, command injection, path traversal, SSRF, XXE, CRLF), giới hạn tần suất, thử thách CAPTCHA cho bot, mã hóa HTML/JS động chống các công cụ thu thập tự động, quy tắc web ACL, và quản lý chứng chỉ. Các bản phát hành CE hiện tại cũng bao gồm việc đăng ký và xử lý gia hạn Free Cert.
• Lite, $10/tháng hoặc $100/năm. Bổ sung chặn theo vị trí địa lý, cơ sở dữ liệu IP tình báo mối đe dọa, tích hợp thông báo Discord và Telegram, xuất log tấn công, và nâng giới hạn ứng dụng lên 20.
• Pro, $100/tháng hoặc $1,000/năm. Bổ sung khả năng phát hiện tấn công mạnh hơn, cấu hình theo từng dịch vụ và cấu hình toàn cục, trang chặn tùy chỉnh, cân bằng tải upstream, đồng bộ node master-slave, và ứng dụng không giới hạn. Xem bảng giá hiện tại để biết các thay đổi.
• Ultimate, giá tùy chỉnh. Điều khoản doanh nghiệp được thiết kế riêng với hỗ trợ 1-1 qua nhiều kênh và phát triển tính năng tùy chỉnh.

SafeLine xử lý và lưu trữ dữ liệu ứng dụng bên trong stack Compose cục bộ của nó. Tuy nhiên, ghi chú phát hành CE hiện tại có đề cập đến Threat Intelligence Sharing, nên người vận hành cần xem lại các thiết lập UEP, quyền riêng tư và chia sẻ của phiên bản đã cài đặt và quan sát các kết nối ra bên ngoài trước khi coi triển khai này là không có lưu lượng đi ra.

Đi tiếp từ đây

Việc cài đặt đã hoàn tất và WAF đã được kiểm chứng. Một vài công việc tiếp theo sẽ giúp giữ cho triển khai luôn khỏe mạnh.

• Với bất kỳ ứng dụng production nào có nhiều dữ liệu nhập từ người dùng (một diễn đàn, một bảng quản trị, một API tự do), hãy đặt chế độ bảo vệ thành Màn hình trong ba đến bảy ngày, xem lại trang Attack Events hằng ngày, và nâng lên Balanced khi bạn đã tinh chỉnh mọi cảnh báo sai.
• Ở gói Lite, hãy thiết lập tích hợp thông báo Discord hoặc Telegram để các cảnh báo tấn công đến được với bạn ngoài bảng điều khiển.
• Hãy lên lịch một cửa sổ bảo trì hằng tháng. Trước khi nâng cấp, hãy sao lưu dữ liệu và cấu hình môi trường của SafeLine, đọc ghi chú phát hành hiện tại, và dùng quy trình nâng cấp được hỗ trợ cho phiên bản bạn đã cài đặt. Đừng chỉ dựa vào docker compose pull theo sau bởi docker compose up -d, vì định nghĩa Compose hoặc các biến môi trường bắt buộc có thể thay đổi giữa các bản phát hành. Người dùng một cú nhấp trên Cloudzy nên làm việc từ /opt/safeline và làm theo hướng dẫn của image trên marketplace.
• Đăng ký theo dõi trang phát hành của SafeLine để nhận thông báo về các bản vá bảo mật và theo dõi kho lưu trữ dự án để theo dõi các vấn đề.

Nếu bạn chưa có VPS cho triển khai này, SafeLine có sẵn dưới dạng triển khai một cú nhấp trong Marketplace của Cloudzy. Gói có 4 GB RAM cung cấp không gian thực tế được khuyến nghị trong hướng dẫn này; hãy kiểm tra lại bảng giá hiện tại trên Cloudzy tại thời điểm xuất bản vì thông số gói có thể thay đổi. Image một cú nhấp sử dụng /opt/safeline và /opt/safeline/docker-compose.yml, nên các hướng dẫn về kiến trúc và bảng điều khiển vẫn áp dụng, nhưng các /data/safeline lệnh trong hướng dẫn này không áp dụng y hệt.

Câu hỏi thường gặp

SafeLine WAF thay thế Nginx Proxy Manager, hay tôi chạy cả hai?

SafeLine có thể thay thế Nginx Proxy Manager khi được triển khai làm reverse proxy duy nhất. Tuy nhiên, nó không nhất thiết phải thay thế NPM. Một thiết lập phổ biến giữ NPM ở phía trước để lo SSL và định tuyến, rồi xếp SafeLine phía sau nó như một tầng bảo mật chuyên trách. Cả hai đều hiệu quả; lựa chọn tùy thuộc vào việc bạn muốn một công cụ làm cả hai việc hay hai công cụ, mỗi cái làm tốt một việc.

Gói miễn phí có đủ cho một trang WordPress đơn lẻ hoặc một SaaS nhỏ không?

Có, về mặt bảo vệ. Gói Personal miễn phí bao gồm engine phát hiện ngữ nghĩa, giới hạn tần suất, thử thách CAPTCHA cho bot, và mã hóa HTML/JS động, vốn là các phòng thủ cốt lõi cho một trang web đơn lẻ. Các gói trả phí bổ sung các tính năng vận hành như chặn theo vị trí địa lý, xuất log tấn công, thông báo ra bên ngoài, giới hạn ứng dụng cao hơn, khả năng phát hiện mạnh hơn, và cân bằng tải. Việc có cần một gói trả phí hay không tùy thuộc vào các tính năng cần thiết và số lượng ứng dụng, chứ không chỉ riêng lưu lượng truy cập.

SafeLine có hoạt động trên một VPS 1 GB RAM không?

Yêu cầu tối thiểu chính thức của SafeLine là 1 GB RAM. Con số đó có thể đủ cho thử nghiệm hoặc một khối lượng công việc rất nhẹ, nhưng năng lực production tùy thuộc vào lưu lượng, các tính năng được bật, và thời gian lưu giữ log. Với một triển khai production nhỏ, 2 vCPU và 4 GB RAM là điểm khởi đầu thận trọng; hãy theo dõi mức sử dụng bộ nhớ và mở rộng dựa trên tải đo được.

Tại sao ARM64 yêu cầu giấy phép trả phí?

Yêu cầu triển khai chính thức của SafeLine nêu rõ rằng các triển khai ARM yêu cầu giấy phép Pro và Personal Edition không được hỗ trợ trên ARM. Nếu bạn muốn Personal Edition, hãy chọn một VPS x86_64; nếu bạn cần ARM, hãy dự trù một giấy phép Pro.

Chaitin Tech nhận được gì từ phiên bản SafeLine của tôi?

Dữ liệu đi ra chính xác có thể khác nhau tùy theo bản phát hành và các tính năng được bật. Ghi chú phát hành CE hiện tại có đề cập đến Threat Intelligence Sharing, trong khi phiên bản đã cài đặt cũng có thể có UEP hoặc các thiết lập chia sẻ khác. Hãy xem lại các thiết lập đó và ghi chú phát hành cho phiên bản bạn đã cài đặt, rồi kiểm chứng lưu lượng đi ra ở cấp mạng. Các container cục bộ của SafeLine xử lý dữ liệu ứng dụng, nhưng riêng điều đó không chứng minh rằng việc từ chối UEP sẽ chặn mọi yêu cầu đi ra.