วิธีติดตั้ง SafeLine WAF บน Linux VPS

เว็บแอปพลิเคชันที่เปิดสู่อินเทอร์เน็ตมักถูกสแกนหาช่องโหว่ SQL injection การใช้ข้อมูลรับรองในทางที่ผิด และรูปแบบช่องโหว่ที่รู้จักกันดีอยู่เป็นประจำ SafeLine คือ WAF แบบ self-hosted ที่ใช้สัญญาอนุญาต GPL-3.0 ที่ทำงานเป็น stack ของ Docker Compose และกรองทราฟฟิก HTTP/S ก่อนส่งต่อคำขอที่อนุญาตไปยัง origin โดยมี แพ็กเกจ Personal แบบฟรี รองรับได้สูงสุด 10 แอปพลิเคชัน

บทแนะนำนี้ครอบคลุมการติดตั้งและสามส่วนที่ต้องให้ความสนใจเป็นพิเศษ ได้แก่ การตัดสินใจเรื่องสถาปัตยกรรม reverse-proxy การตั้งค่าเครือข่าย Docker เมื่อ SafeLine อยู่หลัง proxy ที่มีอยู่แล้วอย่าง Nginx Proxy Manager และคำสั่งตรวจสอบที่คุณสามารถรันหลังติดตั้งเพื่อยืนยันว่า WAF กำลังดักจับการโจมตีจริง

เวอร์ชันสั้น

• ติดตั้ง SafeLine บน Linux VPS ด้วย Docker Compose ใช้ตัวติดตั้งแบบบรรทัดเดียว หรือเลือกเส้นทาง Docker Compose แบบทำมือเพื่อตรวจสอบนิยาม Compose และการตั้งค่าสภาพแวดล้อมก่อนเริ่มต้น stack
• ตัดสินใจสถาปัตยกรรม reverse-proxy ก่อนติดตั้ง ได้แก่ ให้ SafeLine เป็น proxy เพียงตัวเดียว ให้ SafeLine อยู่หลัง Nginx Proxy Manager ที่มีอยู่แล้ว หรือให้ SafeLine ใช้เครื่องร่วมกับ Caddy แต่ละรูปแบบต้องการการกำหนดพอร์ตและการตั้งค่า X-Forwarded-For ที่แตกต่างกัน
• หลังติดตั้ง ให้ตรวจสอบ WAF ด้วยการส่งคำสั่ง curl ทดสอบ SQL-injection ไปยัง URL ที่ปกป้องไว้ ในโหมด Balanced หรือ Strict การได้รับการตอบกลับ 403 พร้อมกับรายการใน Attack Events ที่ตรงกันยืนยันว่ามีการบล็อก ในโหมด Monitor เหตุการณ์ที่ตรงกันยืนยันการตรวจจับได้แม้ว่าการตอบกลับอาจยังคงสำเร็จ
• แพ็กเกจ Personal แบบฟรีครอบคลุมได้สูงสุด 10 แอปพลิเคชันและเอนจินตรวจจับหลัก ส่วนการบล็อกตามภูมิภาค การส่งออกบันทึกการโจมตี และการแจ้งเตือนภายนอกต้องใช้แพ็กเกจ Lite ส่วนการตรวจจับการโจมตีที่ทรงพลังกว่าและการทำ load balancing ต้องใช้ Pro

ก่อนเริ่มต้น สิ่งที่ต้องเตรียมและขอบเขตของบทแนะนำนี้

บทแนะนำนี้ถือว่าคุณมี Linux VPS ที่สามารถ SSH เข้าไปด้วยสิทธิ์ root หรือ sudo และติดตั้ง Docker ไว้แล้ว เมื่อจบบทนี้คุณจะได้ SafeLine ที่ทำงานได้ปกป้องเว็บไซต์อย่างน้อยหนึ่งแห่ง และคำสั่งตรวจสอบที่รันซ้ำได้ทุกเมื่อ

คุณต้องมี

• Linux VPS หนึ่งเครื่อง คำสั่งด้านล่างถือว่าเป็นระบบสไตล์ Debian หรือ Ubuntu ที่มี systemd โปรดตรวจสอบชื่อแพ็กเกจและชื่อบริการบนดิสทริบิวชันอื่น
• อย่างน้อย 1 vCPU, 1 GB RAM และดิสก์ 5 GB ตาม ข้อกำหนดการติดตั้งอย่างเป็นทางการ เพื่อให้มีพื้นที่รองรับการใช้งานจริง คู่มือนี้แนะนำ 2 vCPU, 4 GB RAM และดิสก์ 20 GB
• Docker 20.10.14 หรือใหม่กว่า และ Docker Compose 2.0 หรือใหม่กว่า
• CPU สถาปัตยกรรม x86_64 ที่รองรับ SSSE3 ตรวจสอบได้ด้วย lscpu | grep ssse3 แทนที่จะสันนิษฐานว่ามีชุดคำสั่งนี้อยู่แล้ว
• โดเมนหรือซับโดเมนที่ตั้งค่า DNS ชี้ไปยัง public IP ของ VPS หากคุณวางแผนจะเปิดแอปพลิเคชันที่ปกป้องไว้ผ่าน HTTPS สาธารณะ
• พอร์ตที่เหมาะสมกับโครงสร้างที่เลือก โดยทั่วไปรูปแบบ A และ C จะมอบพอร์ต 80 และ 443 ให้ SafeLine ส่วนรูปแบบ B จะปล่อยพอร์ตเหล่านั้นไว้กับ Nginx Proxy Manager และกำหนด listener อื่นให้ SafeLine เช่น 10080
• สิทธิ์เข้าถึงระดับ root หรือ sudo

ที่ไฟร์วอลล์หรือ security group ของผู้ให้บริการ VPS ให้เปิดเฉพาะพอร์ตสาธารณะที่โครงสร้างที่เลือกต้องการเท่านั้น จำกัด SSH และ TCP 9443 ให้เฉพาะแหล่งบริหารจัดการที่เชื่อถือได้ ในรูปแบบ B ให้ปิด TCP 10080 ไม่ให้เข้าถึงได้จาก public IPv4 และ IPv6 และเก็บพอร์ต backend เช่น 8080 ไว้เป็นการภายในในทุกโครงสร้าง การเข้าถึง 10080 โดยตรงจะข้าม NPM และทำให้ขอบเขตความเชื่อถือของ X-Forwarded-For ใช้ไม่ได้

หมายเหตุ: สำหรับการติดตั้งบน ARM64 แบบทำมือ ให้ตั้งค่า ARCH_SUFFIX=-arm SafeLine เอกสารการติดตั้งอย่างเป็นทางการ ระบุว่า ARM ต้องใช้สัญญาอนุญาต Pro และรุ่น Personal Edition ไม่รองรับบน ARM ให้ใช้ VPS สถาปัตยกรรม x86_64 สำหรับรุ่น Personal Edition

ตรวจสอบ Docker ก่อนเริ่มต้น

docker --version
docker compose version

ทั้งสองคำสั่งควรแสดงเวอร์ชันที่ติดตั้งไว้ ให้ดำเนินการต่อเฉพาะเมื่อ Docker เป็นเวอร์ชัน 20.10.14 หรือใหม่กว่า และ Docker Compose เป็นเวอร์ชัน 2.0.0 หรือใหม่กว่า มิฉะนั้นให้อัปเกรดก่อนติดตั้ง SafeLine

เลือกสถาปัตยกรรม Reverse-Proxy ของคุณก่อน

VPS ใหม่ที่ไม่มีอะไรทำงานอยู่จะยอมให้ SafeLine ครอบครองพอร์ต 80 และ 443 ได้ทั้งหมด แต่ VPS ที่รัน Nginx Proxy Manager, Caddy หรือ Nginx ของแอปพลิเคชันเองอยู่แล้วจะทำไม่ได้ และการตัดสินใจเรื่องสถาปัตยกรรมนี่เองคือความแตกต่างระหว่างการติดตั้งที่ราบรื่นกับความขัดแย้งของพอร์ตในการบูตครั้งแรก จัดการเรื่องนี้ให้ถูกต้องตั้งแต่ต้นเพียงครั้งเดียว แล้วส่วนที่เหลือของการติดตั้งจะเป็นเพียงงานประจำ

สามรูปแบบ

• รูปแบบ A ให้ SafeLine เป็น reverse proxy เพียงตัวเดียว SafeLine ครอบครองพอร์ต 80 และ 443 และจัดการ TLS ให้แอปพลิเคชันที่ปกป้องไว้ CE รุ่นปัจจุบัน มีขั้นตอนการทำงาน Free Cert รวมอยู่ด้วย ในขณะที่การอัปโหลดใบรับรองแบบทำมือยังคงใช้ได้ โปรดตรวจสอบตัวเลือกใบรับรองที่แน่นอนในรุ่นที่ติดตั้ง โดย backend ทำงานบนพอร์ตที่ไม่เปิดสาธารณะและ SafeLine จะกำหนดเส้นทางไปยังพอร์ตนั้น
• รูปแบบ B ให้ SafeLine อยู่หลัง Nginx Proxy Manager (NPM) NPM ยังคงถือพอร์ต 80 และ 443 และจัดการ SSL ส่วน SafeLine รับฟังบนพอร์ต 10080 (HTTP เท่านั้น เนื่องจาก NPM ได้ยุติ TLS ไปแล้ว) NPM ส่งต่อเข้าสู่ SafeLine และ SafeLine ส่งต่อเข้าสู่ backend นี่เป็นการตั้งค่าที่พบได้ทั่วไปเมื่อมี NPM ติดตั้งอยู่แล้ว
• รูปแบบ C ให้ SafeLine อยู่ร่วมกับ Caddy HTTPS อัตโนมัติของ Caddy จะแย่งพอร์ต 443 กับ SafeLine การจัดวางที่ใช้งานได้คือมอบพอร์ต 80 และ 443 ให้ SafeLine และย้าย Caddy ไปยังพอร์ต HTTP ภายในที่ไม่เปิดสาธารณะ เช่น 8080 สำหรับการส่งต่อจาก SafeLine ไป Caddy แล้วไปยังแอปพลิเคชัน

ประเด็นสำคัญ: รูปแบบ A ง่ายที่สุดสำหรับ VPS ใหม่ รูปแบบ B เป็นตัวเลือกที่เหมาะเมื่อ NPM ทำงานอยู่แล้ว ส่วนรูปแบบ C ต้องมีการกำหนดพอร์ตของ Caddy ใหม่อย่างตั้งใจ

ติดตั้ง SafeLine บน VPS ของคุณ

การติดตั้งเองเป็นส่วนที่ง่าย SafeLine มีเส้นทางการติดตั้งสองแบบ ได้แก่ ตัวติดตั้งอัตโนมัติที่ดึงสคริปต์จากระยะไกลจาก waf.chaitin.com และเส้นทาง Docker Compose แบบทำมือที่ให้คุณตรวจสอบทุกอย่างก่อนรัน เลือกแบบที่ตรงกับนโยบายความปลอดภัยของคุณ

ขั้นตอนที่ 1 ยืนยันว่า Docker พร้อมใช้งาน

ตรวจสอบเวอร์ชัน Docker อีกครั้งและตรวจว่า Docker daemon กำลังทำงานอยู่

docker --version
docker compose version
sudo systemctl status docker

ผลลัพธ์ที่คาดหวังมี active (running) สำหรับ Docker daemon หากยังไม่ทำงาน ให้เริ่มด้วย sudo systemctl start docker และตั้งให้เริ่มทำงานตอนบูตด้วย sudo systemctl enable docker.

ขั้นตอนที่ 2 รันตัวติดตั้ง SafeLine

มีเส้นทางย่อยสองแบบ เลือกหนึ่งแบบ

ขั้นตอนที่ 2a การติดตั้งอัตโนมัติ รันตัวติดตั้งด้วยสิทธิ์ root

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

สคริปต์จะถามว่าจะวางไดเรกทอรีข้อมูลของ SafeLine ไว้ที่ใด ดึง Docker image และเริ่มต้น stack หลังติดตั้งเสร็จ ให้รัน sudo docker exec safeline-mgt resetadmin เพื่อดึงหรือรีเซ็ตข้อมูลรับรองของผู้ดูแลระบบ ตามที่อธิบายไว้ใน คู่มือการติดตั้งอย่างเป็นทางการ จัดเก็บข้อมูลรับรองที่ได้รับไว้อย่างปลอดภัย

หมายเหตุ: คำสั่งนี้ดาวน์โหลดและรันเชลล์สคริปต์จากระยะไกลจาก waf.chaitin.com ในฐานะ root คำสั่งบรรทัดเดียวอย่างเป็นทางการมี curl -k ซึ่งปิดการตรวจสอบใบรับรอง TLS โปรดตรวจสอบสคริปต์ที่ดาวน์โหลดมาก่อนรัน หรือใช้ขั้นตอนที่ 2b หากยอมรับความเสี่ยงนั้นไม่ได้ SafeLine ยังมีให้บริการเป็นการติดตั้งแบบคลิกเดียวบน Cloudzy แต่ image นั้นใช้ /opt/safeline, /opt/safeline/.env, และ /opt/safeline/docker-compose.yml อย่าใช้ /data/safeline เส้นทางของคู่มือนี้โดยไม่แก้ไขบน image ของ Cloudzy

ขั้นตอนที่ 2b การติดตั้ง Docker Compose แบบทำมือ ดาวน์โหลดและตรวจสอบไฟล์ Compose อย่างเป็นทางการ จากนั้นเริ่มต้น 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

หลังจาก docker compose up -d เสร็จสมบูรณ์ ให้แสดงรายการคอนเทนเนอร์ที่กำลังทำงานเพื่อยืนยัน

sudo docker compose ps

คุณควรเห็นคอนเทนเนอร์ safeline-mgt, safeline-detector, safeline-tengine, safeline-pg, safeline-fvm, safeline-luigi และ safeline-chaos หากคอนเทนเนอร์ใดแสดง Exited โปรดดูขั้นตอนที่ 3 สำหรับสาเหตุที่พบบ่อยที่สุดสองประการ

ขั้นตอนที่ 3 แก้ไขข้อผิดพลาดการติดตั้งที่พบบ่อย

มีข้อผิดพลาดสองประการที่พบบ่อยพอที่จะสมควรมีขั้นตอนเป็นของตัวเอง

ซับเน็ตทับซ้อนกัน หากการติดตั้งล้มเหลวด้วย Pool overlaps with other one on this address space แสดงว่าซับเน็ตเริ่มต้นของ SafeLine ขัดแย้งกับเครือข่าย Docker ที่มีอยู่แล้ว ตามที่ระบุไว้ใน คู่มือแก้ไขปัญหาการติดตั้ง SafeLine แก้ไขปัญหานี้ด้วยการแก้ไข /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

ข้อผิดพลาด IPv6 resolver หาก safeline-tengine หยุดทำงานด้วย nginx: [emerg] invalid IPv6 address in resolver ให้ตรวจสอบไฟล์ resolver ก่อนและระบุว่าใครเป็นผู้จัดการมัน

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

อย่าแก้ไข /etc/resolv.conf โดยตรงหากไฟล์นั้นถูกสร้างโดย systemd-resolved, NetworkManager หรือผู้ให้บริการ VPS ให้แก้ไขค่า nameserver ที่ผิดรูปแบบในการตั้งค่าของบริการที่จัดการมัน สร้างไฟล์ resolver ใหม่ จากนั้นรีสตาร์ท Tengine

sudo docker restart safeline-tengine

ขั้นตอนที่ 4 เข้าถึงแดชบอร์ด

แดชบอร์ดจัดการของ SafeLine รับฟังบน TCP 9443 ผ่าน HTTPS อย่าปล่อยพอร์ตสำหรับการดูแลระบบนี้เปิดสู่อินเทอร์เน็ตทั้งหมด ให้จำกัดไว้เฉพาะที่อยู่ต้นทางที่เชื่อถือได้หรือ VPN หรือบล็อกการเข้าถึงสาธารณะแล้วใช้อุโมงค์ SSH

ssh -L 9443:127.0.0.1:9443 USER@SERVER_IP

เปิด https://localhost:9443 ผ่านอุโมงค์ คำเตือนเรื่องใบรับรองแบบ self-signed เป็นเรื่องปกติในการเข้าถึงครั้งแรก โปรดยืนยันว่าการเชื่อมต่อ SSH ไปถึงเซิร์ฟเวอร์ที่ตั้งใจไว้ก่อนดำเนินการต่อ

หากคุณทำข้อมูลรับรองเริ่มต้นหาย ให้รีเซ็ตรหัสผ่านผู้ดูแลระบบจากเครื่องโฮสต์

sudo docker exec safeline-mgt resetadmin

คำสั่งนี้จะแสดงข้อมูลรับรองผู้ดูแลระบบที่คุณสามารถใช้เข้าสู่ระบบอีกครั้ง

ตั้งค่า SafeLine ให้เหมาะกับสถาปัตยกรรมของคุณ

ตอนนี้ SafeLine ทำงานแล้ว แต่ยังไม่ได้ปกป้องสิ่งใด หน้า Applications ของแดชบอร์ดคือที่ที่คุณบอก SafeLine ว่าจะปกป้องเว็บไซต์ใดและจะส่งต่อทราฟฟิกที่ผ่านการกรองไปที่ใด การตั้งค่าจะแตกต่างกันไปตามสถาปัตยกรรมที่คุณเลือกไว้ก่อนหน้า ดังนั้นแต่ละรูปแบบจึงมีหัวข้อย่อยของตัวเอง ให้ทำเฉพาะรูปแบบที่ตรงกับการตั้งค่าของคุณ

รูปแบบ A ให้ SafeLine เป็น Reverse Proxy เพียงตัวเดียว

สำหรับรูปแบบ A นั้น SafeLine รับฟังบนพอร์ต 80 และ 443 โดยตรง และส่งต่อทราฟฟิกที่ผ่านการกรองไปยังแอปพลิเคชัน backend ของคุณบนพอร์ตที่ไม่เปิดสาธารณะ ในแดชบอร์ด

1. ไปที่ Applications จากนั้น Add Application.
2. ตั้งพอร์ตรับฟังเป็น 443 และเปิดใช้ SSL ใช้ขั้นตอนการทำงานเรื่องใบรับรองที่มีอยู่ในรุ่น SafeLine ที่คุณติดตั้ง CE รุ่นปัจจุบัน มีการขอ Free Cert และการจัดการต่ออายุ ในขณะที่การอัปโหลดใบรับรองแบบทำมือยังคงใช้ได้
3. ตั้งค่า upstream เป็น http://127.0.0.1:8080 หาก backend ทำงานใน Docker ให้เผยแพร่พอร์ตของมันเฉพาะบน loopback เท่านั้น เช่น "127.0.0.1:8080:8080" ในส่วน ports ของบริการ หลีกเลี่ยงการระบุ IP ของคอนเทนเนอร์แบบตายตัว เช่น 172.17.0.5 เพราะมันสามารถเปลี่ยนได้เมื่อคอนเทนเนอร์ถูกสร้างใหม่
4. บันทึกแอปพลิเคชัน SafeLine จะเริ่มรับฟังบน 443 และส่งต่อทราฟฟิกที่ผ่านการกรองไปยัง backend ทันที
5. ยืนยันว่าเรกคอร์ด DNS A ของโดเมนคุณชี้ไปยัง public IP ของ VPS และพอร์ต 80 กับ 443 สามารถเข้าถึงได้จากภายนอก

หากพอร์ต 443 ถูกจับจองโดยกระบวนการอื่นอยู่แล้ว คอนเทนเนอร์ของ SafeLine จะจับพอร์ตไม่สำเร็จและแดชบอร์ดจะแสดงข้อผิดพลาดบนแอปพลิเคชันนั้น ให้หยุดกระบวนการที่ขัดแย้ง หรือเลือกพอร์ตอื่น ก่อนเพิ่มแอปพลิเคชัน

รูปแบบ B ให้ SafeLine อยู่หลัง Nginx Proxy Manager

รูปแบบ B ให้ NPM ทำหน้าที่เดิมต่อไป (ครอบครอง 80 และ 443 จัดการ Let's Encrypt) และเสียบ SafeLine เข้าไปเป็นชั้นความปลอดภัยเฉพาะที่อยู่ด้านหลัง เส้นทางทราฟฟิกคือ ไคลเอนต์ จากนั้นไป NPM (พอร์ต 443 ยุติ TLS) จากนั้นไป SafeLine (พอร์ต 10080, HTTP) จากนั้นไปยังแอปพลิเคชัน backend

ภายในแดชบอร์ด SafeLine

1. Applications จากนั้น Add Application ตั้งพอร์ตรับฟังเป็น 10080 และปิด SSL ไว้ (NPM ได้ยุติ TLS ไปแล้ว)
2. ตั้งค่า upstream เป็นที่อยู่ภายในของแอปพลิเคชัน ตามที่อธิบายไว้ในรูปแบบ A
3. บันทึกแอปพลิเคชัน

ใน Nginx Proxy Manager

1. Hosts จากนั้น Proxy Hosts จากนั้น Add Proxy Host
2. แท็บ Details ตั้งชื่อโดเมน สกีมา http และพอร์ตส่งต่อ 10080 หาก NPM ทำงานบนโฮสต์โดยตรง ให้ใช้ 127.0.0.1 เป็น hostname สำหรับส่งต่อ หาก NPM ทำงานใน Docker บน Linux 127.0.0.1 จะชี้ไปยังคอนเทนเนอร์ NPM แทนที่จะเป็นโฮสต์ VPS ให้เพิ่มการแมป host-gateway ของ Docker เข้าไปในบริการ Compose ของ NPM จากนั้นใช้ host.docker.internal เป็น hostname สำหรับส่งต่อ

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

จากไดเรกทอรี Compose ของ NPM ให้รัน sudo docker compose up -d เพื่อให้คอนเทนเนอร์ถูกสร้างใหม่พร้อมการแมปโฮสต์ใหม่

3. แท็บ SSL ขอใบรับรอง Let's Encrypt บังคับใช้ SSL และเปิดใช้ HTTP/2
4. ปล่อยแท็บ Advanced ของ NPM ว่างไว้สำหรับ X-Forwarded-For ใน เทมเพลต NPM ปัจจุบัน เนื้อหาในแท็บ Advanced จะถูกแทรกที่ขอบเขต server และไม่ลบล้าง header ระดับ location ที่ถูกสร้างขึ้นภายใต้ กฎการสืบทอดของ NGINX. location ที่ถูกสร้างขึ้นจะส่ง

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

directive ที่สองจะต่อท้ายที่อยู่ที่ NPM สังเกตเห็นเป็นค่าที่อยู่ขวาสุดใน header

5. บันทึก Proxy Host

กลับมาที่ SafeLine ให้ตั้งค่าการดึง source-IP หลังจากยืนยันลำดับ header ที่มีผลจริงแล้วเท่านั้น SafeLine 9.3.1 ได้เพิ่มการดึงค่า XFF แบบยืดหยุ่นพร้อมการเลือกทิศทางและดัชนี

1. Settings จากนั้น Advanced จากนั้น Real IP from Header ตั้งชื่อ header เป็น X-Forwarded-For.
2. ใช้การดึงแบบกำหนดเองจากท้าย header และเลือกที่อยู่ขวาสุดที่ NPM เพิ่มเข้ามา ป้ายกำกับดัชนีที่แน่นอนจะต่างกันไปตามเวอร์ชัน จึงควรตรวจสอบผลลัพธ์ใน Logs จากนั้น Access หากรุ่นที่ติดตั้งเก่ากว่า 9.3.1 ให้อัปเดตก่อนทำตามโครงสร้างนี้
3. หาก Cloudflare หรือ CDN อื่นอยู่ก่อนหน้า NPM ให้ตั้งค่า NPM ให้เชื่อถือเฉพาะช่วงพร็อกซีที่ผู้ให้บริการนั้นเผยแพร่ก่อน เพื่อให้ที่อยู่ที่ NPM ต่อท้ายเข้ามาน่าเชื่อถือ อย่าเลือกตำแหน่งแบบตายตัวจนกว่าคุณจะได้ตรวจสอบและทดสอบลำดับ header จริงแล้ว
4. บันทึกและโหลดแอปพลิเคชันใหม่

ทดสอบการตั้งค่าจากเครื่องนอก VPS

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

บันทึกการเข้าถึงของ SafeLine ควรแสดงที่อยู่สาธารณะจริงของคุณ ไม่ใช่ 1.2.3.4 หรือที่อยู่ bridge ของ NPM

ป้องกันไม่ให้ผู้ใช้ข้าม SafeLine ด้วยการเก็บ listener ของ backend ไว้เป็นการภายใน สำหรับ backend แบบ Docker Compose ให้เผยแพร่พอร์ตเฉพาะบน loopback เท่านั้น

ports:
  - "127.0.0.1:8080:8080"

สำหรับบริการที่ทำงานบนโฮสต์โดยตรง ให้ตั้งค่าให้รับฟังบน 127.0.0.1:8080 แทนที่จะเป็น 0.0.0.0:8080 ตรวจสอบพอร์ตภายในทั้งสองจากเครื่องนอก VPS

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

การเชื่อมต่อ TCP ควรถูกปฏิเสธหรือหมดเวลา หากได้รับข้อผิดพลาด HTTP หรือ "Empty reply from server" ก็ยังหมายความว่าพอร์ตนั้นเข้าถึงได้จากสาธารณะและต้องได้รับการรักษาความปลอดภัย หากการผูกกับ loopback เป็นไปไม่ได้ ให้สร้างกฎไฟร์วอลล์ที่ปรับให้เหมาะกับอินเทอร์เฟซ เครือข่าย Docker และคอนเทนเนอร์ปลายทางจริง แทนที่จะใช้กฎ DOCKER-USER แบบทั่วไป

รูปแบบ C ให้ SafeLine อยู่กับ Caddy

สำหรับรูปแบบ C นั้น SafeLine รับพอร์ต 80 และ 443 ส่วน Caddy ย้ายไปยังพอร์ต HTTP ภายในที่ไม่เปิดสาธารณะ เส้นทางทราฟฟิกคือ ไคลเอนต์ จากนั้นไป SafeLine (443, TLS) จากนั้นไป Caddy (8080, HTTP ภายใน) จากนั้นไปยัง backend ของแอปพลิเคชัน

แก้ไข /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

ผู้ใช้ :8080 site block คือส่วนสำคัญ ตอนนี้ Caddy รับฟังบนพอร์ต HTTP ภายในแทนที่จะแย่งพอร์ต 443 กับ SafeLine โดยบรรทัด bind 127.0.0.1 จะเก็บ listener นั้นไว้ภายใน VPS โหลด Caddy ใหม่ด้วย sudo systemctl reload caddy และยืนยันด้วย sudo ss -ltnp | grep -E ':(443|8080)' ว่า Caddy ผูกอยู่กับ 8080 ไม่ใช่ 443

ใน SafeLine ให้เพิ่มแอปพลิเคชันที่รับฟังบน 443 โดยเปิดใช้ SSL จากนั้นตั้งค่า upstream เป็น http://127.0.0.1:8080 การตั้งค่า X-Forwarded-For สามารถคงไว้ที่ตัวเลือกการเชื่อมต่อเครือข่ายแบบเริ่มต้นได้ เพราะ Caddy อยู่หลัง SafeLine ไม่ใช่อยู่ด้านหน้า

เลือกโหมดการปกป้องและตรวจสอบว่า WAF กำลังบล็อกการโจมตี

SafeLine มีโหมดการปกป้องสามโหมดที่กำหนดว่าจะเกิดอะไรขึ้นเมื่อเอนจินระบุว่าคำขอเป็นอันตราย โหมดเริ่มต้นที่เหมาะสมขึ้นอยู่กับแอปพลิเคชัน ส่วนขั้นตอนการตรวจสอบเหมือนกันในทุกโหมด

โหมดการปกป้อง Monitor, Balanced, Strict

แต่ละแอปพลิเคชันใน SafeLine มีการตั้งค่าโหมดการปกป้องเป็นของตัวเอง ปรับได้ภายใต้ Applications จากนั้นแอปของคุณ จากนั้น Protection Mode:

• Monitor SafeLine จะบันทึกคำขอที่ปกติแล้วจะบล็อก แต่ไม่บล็อกจริง นี่เป็นจุดเริ่มต้นที่ปลอดภัยที่สุดสำหรับแอปพลิเคชันการใช้งานจริงที่ซับซ้อนซึ่งมีฟอร์มรับข้อมูลจำนวนมาก (เว็บบอร์ด แผงผู้ดูแลระบบที่มีช่อง WYSIWYG หรือ API ที่รับ payload JSON รูปแบบอิสระ) ให้รันโหมด Monitor สักสองสามวัน ตรวจสอบหน้า Attack Events และยืนยันว่าไม่มี false positive กับผู้ใช้จริงก่อนเลื่อนไปใช้ Balanced
• Balanced โหมดเริ่มต้น ตัวเลข ที่ผู้จำหน่ายเผยแพร่บน GitHub ของ SafeLine รายงานอัตราการตรวจจับ 71.65% ความแม่นยำ 99.45% และอัตรา false-positive 0.07% สำหรับโหมด Balanced ส่วนโหมด Strict รายงานที่การตรวจจับ 76.17% ความแม่นยำ 99.38% และอัตรา false-positive 0.22% ตัวเลขเหล่านี้เป็นผลลัพธ์ที่ผู้จำหน่ายรายงานเอง ไม่ใช่การเปรียบเทียบมาตรฐานอิสระ และไฟล์ README ไม่ได้ระบุว่าชุดข้อมูลคือ WAF-Eval ให้ถือว่าเป็นตัวเลขเปรียบเทียบผลิตภัณฑ์ ไม่ใช่ประสิทธิภาพการใช้งานจริงที่รับประกันได้
• Strict ชุดกฎที่เข้มงวดกว่าพร้อมฮิวริสติกที่รัดกุมยิ่งขึ้นและการแลกเปลี่ยนระหว่างการตรวจจับกับ false-positive ตามที่แสดงไว้ข้างต้น ควรลองใช้หลังจากใช้งานโหมด Balanced อย่างราบรื่นสักหนึ่งหรือสองสัปดาห์เมื่อคุณเข้าใจทราฟฟิกของตัวเองแล้ว

คำแนะนำ ใช้ Balanced สำหรับการติดตั้งใหม่ที่ไม่มีทราฟฟิกจริงให้รบกวน สำหรับแอปพลิเคชันการใช้งานจริงที่มีอยู่แล้ว ให้เริ่มด้วย Monitor สักสองสามวัน มองหา false positive ในบันทึก Attack Events แล้วเลื่อนไปใช้ Balanced เมื่อคุณปรับข้อยกเว้นต่างๆ เรียบร้อยแล้ว ส่วน Strict ควรลองใช้หลังจากใช้ Balanced สักหนึ่งหรือสองสัปดาห์เมื่อคุณเข้าใจทราฟฟิกของตัวเองแล้ว

ตรวจสอบ WAF ด้วยการทดสอบ SQLi ผ่าน curl

ขั้นตอนสุดท้ายก่อนถือว่าการติดตั้งเสร็จสมบูรณ์คือการยืนยันว่า WAF ดักจับการโจมตีได้จริง ให้รันคำสั่งทดสอบ SQL-injection ที่ไม่เป็นอันตรายกับเว็บไซต์ที่ปกป้องไว้จากเครื่องใดก็ได้ที่อยู่นอก VPS

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

นี่คือ เวกเตอร์ทดสอบ SQL-injection ที่ SafeLine เผยแพร่ ในโหมด Balanced หรือ Strict ให้คาดหวังสถานะ 403 และการตอบกลับการบล็อกของ SafeLine ในโหมด Monitor ให้คาดหวังว่าคำขอจะถูกบันทึกโดยไม่บล็อก เวอร์ชัน HTTP และเนื้อหาการตอบกลับที่แน่นอนอาจแตกต่างกันได้ จึงควรยืนยันผลลัพธ์ด้วยรายการที่ตรงกันใน Attack Events

จากนั้นเปิดแดชบอร์ดผ่านวิธีการเข้าถึงแบบจำกัดจากขั้นตอนที่ 4 และไปที่ Logs จากนั้น Attack Events คุณควรเห็นรายการใหม่ที่มี timestamp ตรงกัน ประเภทการโจมตี SQL Injection source IP ที่ตรงกับเครื่องที่คุณรัน curl และ query string ที่เป็นปัญหาในรายละเอียดคำขอ คลิกเข้าไปในเหตุการณ์เพื่อดูคำขอและการตอบกลับฉบับเต็มที่ SafeLine บันทึกไว้

หากคำขอ curl ส่งคืน 200 OK ให้ตีความผลลัพธ์ควบคู่กับบันทึก Attack Events

• เหตุการณ์ SQL Injection ที่ตรงกันหมายความว่าแอปพลิเคชันน่าจะอยู่ในโหมด Monitor การบันทึกโดยไม่บล็อกเป็นเรื่องที่คาดไว้
• หากไม่มีเหตุการณ์ที่ตรงกัน ให้ยืนยันว่า DNS แปลงชื่อไปยัง VPS ที่ตั้งใจไว้ ตรวจสอบการตั้งค่า listener และ upstream ของ SafeLine และเทียบเวลาของคำขอกับบันทึกการเข้าถึงของ SafeLine
• นอกจากนี้ให้ยืนยันว่าเปิดใช้การปกป้องอยู่ และไม่มี IP whitelist กฎอนุญาตแบบกำหนดเอง หรือข้อยกเว้นเส้นทางใดครอบคลุมคำขอทดสอบนี้

ประเด็นสำคัญ: หากคำสั่งทดสอบ curl ส่งคืน 403 พร้อมหน้าดักจับของ SafeLine และมีรายการปรากฏใน Attack Events ที่มีประเภทการโจมตี SQL Injection แสดงว่า WAF กำลังดักจับทราฟฟิกได้อย่างถูกต้อง

แพ็กเกจฟรีครอบคลุมอะไรบ้าง และอะไรที่ต้องใช้แพ็กเกจแบบเสียเงิน

แพ็กเกจ Personal แบบฟรีเพียงพอที่จะปกป้องการติดตั้งบน VPS เดี่ยวส่วนใหญ่ แพ็กเกจแบบเสียเงินจะเริ่มมีความสำคัญเมื่อคุณต้องการฟีเจอร์ด้านการปฏิบัติงาน (การแจ้งเตือน การส่งออกบันทึก การบล็อกตามภูมิภาค) หรือเมื่อคุณเกินขีดจำกัด 10 แอปพลิเคชัน

รายละเอียดแยกย่อย โดยอ้างอิงจาก หน้าราคาของ CyberServal:

• Personal แบบฟรี ได้สูงสุด 10 แอปพลิเคชัน รวมเอนจินตรวจจับเชิงความหมาย (SQLi, XSS, command injection, path traversal, SSRF, XXE, CRLF) การจำกัดอัตรา การท้าทายด้วย CAPTCHA สำหรับบอท การเข้ารหัส HTML/JS แบบไดนามิกเพื่อต้านโปรแกรมดึงข้อมูลอัตโนมัติ กฎ web ACL และการจัดการใบรับรอง CE รุ่นปัจจุบัน ยังรวมการขอ Free Cert และการจัดการต่ออายุด้วย
• Lite, $10/เดือน หรือ $100/ปี เพิ่มการบล็อกตามภูมิภาค ฐานข้อมูล IP ด้านข่าวกรองภัยคุกคาม การเชื่อมต่อการแจ้งเตือน Discord และ Telegram การส่งออกบันทึกการโจมตี และเพิ่มขีดจำกัดแอปพลิเคชันเป็น 20
• Pro, $100/เดือน หรือ $1,000/ปี เพิ่มการตรวจจับการโจมตีที่ทรงพลังกว่า การตั้งค่าแบบต่อบริการและแบบทั่วทั้งระบบ หน้าดักจับแบบกำหนดเอง การทำ load balancing ของ upstream การซิงค์โหนดแบบ master-slave และแอปพลิเคชันไม่จำกัด ดู ตารางราคาปัจจุบัน สำหรับการเปลี่ยนแปลง
• Ultimate ราคาแบบกำหนดเอง เงื่อนไขระดับองค์กรที่ปรับให้เหมาะสม พร้อมการสนับสนุนแบบตัวต่อตัวข้ามช่องทางและการพัฒนาฟีเจอร์แบบกำหนดเอง

SafeLine ประมวลผลและจัดเก็บข้อมูลแอปพลิเคชันไว้ภายใน stack ของ Compose บนเครื่องตัวเอง อย่างไรก็ตาม บันทึกการเปลี่ยนแปลงของ CE รุ่นปัจจุบัน กล่าวถึง Threat Intelligence Sharing ดังนั้นผู้ดูแลระบบควรตรวจสอบการควบคุม UEP ความเป็นส่วนตัว และการแบ่งปันข้อมูลของเวอร์ชันที่ติดตั้ง และสังเกตการเชื่อมต่อขาออกก่อนที่จะถือว่าการติดตั้งไม่มีการส่งข้อมูลออกเลย

จะไปต่อจากนี้อย่างไร

การติดตั้งเสร็จสมบูรณ์และตรวจสอบ WAF เรียบร้อยแล้ว งานติดตามผลอีกเล็กน้อยจะช่วยให้การติดตั้งอยู่ในสภาพดี

• สำหรับแอปพลิเคชันการใช้งานจริงที่มีการรับข้อมูลจากผู้ใช้จำนวนมาก (เว็บบอร์ด แผงผู้ดูแลระบบ API รูปแบบอิสระ) ให้ตั้งโหมดการปกป้องเป็น จอแสดงผล เป็นเวลาสามถึงเจ็ดวัน ตรวจสอบหน้า Attack Events ทุกวัน แล้วเลื่อนไปใช้ Balanced เมื่อคุณปรับ false positive ต่างๆ เรียบร้อยแล้ว
• ในแพ็กเกจ Lite ให้ตั้งค่าการเชื่อมต่อการแจ้งเตือน Discord หรือ Telegram เพื่อให้การแจ้งเตือนการโจมตีมาถึงคุณนอกแดชบอร์ด
• กำหนดช่วงเวลาบำรุงรักษาประจำเดือน ก่อนอัปเกรด ให้สำรองข้อมูลและการตั้งค่าสภาพแวดล้อมของ SafeLine อ่าน บันทึกการเปลี่ยนแปลงรุ่นปัจจุบัน และใช้ขั้นตอนการอัปเกรดที่รองรับสำหรับเวอร์ชันที่คุณติดตั้ง อย่าพึ่งพาเพียง docker compose pull ตามด้วย docker compose up -d เพราะนิยาม Compose หรือตัวแปรสภาพแวดล้อมที่จำเป็นสามารถเปลี่ยนแปลงได้ระหว่างรุ่นต่างๆ ผู้ใช้ Cloudzy แบบคลิกเดียวควรทำงานจาก /opt/safeline และทำตามคำแนะนำของ image ในมาร์เก็ตเพลส
• สมัครติดตาม หน้าการเผยแพร่รุ่นของ SafeLine เพื่อรับการแจ้งเตือนแพตช์ความปลอดภัย และติดตาม ที่เก็บโค้ดของโปรเจกต์ เพื่อติดตามปัญหา

หากคุณยังไม่มี VPS สำหรับการติดตั้งนี้ SafeLine มีให้บริการเป็นการติดตั้งแบบคลิกเดียวใน มาร์เก็ตเพลสของ Cloudzy. แผนที่มี 4 GB RAM ให้พื้นที่ว่างที่ใช้งานได้จริงตามที่แนะนำในคู่มือนี้ โปรดตรวจสอบ ตารางราคาปัจจุบัน บน Cloudzy ณ เวลาที่เผยแพร่ เนื่องจากข้อกำหนดของแผนอาจเปลี่ยนแปลงได้ อิมเมจแบบคลิกเดียวใช้ /opt/safeline และ /opt/safeline/docker-compose.yml ดังนั้นคำแนะนำเรื่องสถาปัตยกรรมและแดชบอร์ดจึงใช้ได้ แต่ /data/safeline คำสั่งของคู่มือนี้ใช้ไม่ได้เหมือนกันทุกประการ

คำถามที่พบบ่อย

SafeLine WAF ใช้แทน Nginx Proxy Manager หรือต้องรันทั้งสองอย่าง

SafeLine สามารถใช้แทน Nginx Proxy Manager ได้เมื่อติดตั้งเป็น reverse proxy เพียงตัวเดียว อย่างไรก็ตาม ไม่จำเป็นต้องใช้แทน NPM การตั้งค่าที่พบได้ทั่วไปคือเก็บ NPM ไว้ด้านหน้าสำหรับ SSL และการกำหนดเส้นทาง แล้ววาง SafeLine ไว้ด้านหลังเป็นชั้นความปลอดภัยเฉพาะ ทั้งสองแบบใช้งานได้ ทางเลือกขึ้นอยู่กับว่าคุณต้องการเครื่องมือเดียวทำงานทั้งสองอย่าง หรือสองเครื่องมือที่แต่ละอย่างทำงานหนึ่งอย่างได้ดี

แพ็กเกจฟรีเพียงพอสำหรับเว็บไซต์ WordPress เดียวหรือ SaaS ขนาดเล็กหรือไม่

ใช่ ในแง่ของการปกป้อง แพ็กเกจ Personal แบบฟรีมีเอนจินตรวจจับเชิงความหมาย การจำกัดอัตรา การท้าทายด้วย CAPTCHA สำหรับบอท และการเข้ารหัส HTML/JS แบบไดนามิก ซึ่งเป็นการป้องกันหลักสำหรับเว็บไซต์เดียว แพ็กเกจแบบเสียเงินเพิ่มฟีเจอร์ด้านการปฏิบัติงาน เช่น การบล็อกตามภูมิภาค การส่งออกบันทึกการโจมตี การแจ้งเตือนภายนอก ขีดจำกัดแอปพลิเคชันที่สูงขึ้น การตรวจจับที่ทรงพลังกว่า และ load balancing แพ็กเกจแบบเสียเงินจะจำเป็นหรือไม่ขึ้นอยู่กับฟีเจอร์ที่ต้องการและจำนวนแอปพลิเคชัน ไม่ใช่ปริมาณทราฟฟิกเพียงอย่างเดียว

SafeLine ทำงานบน VPS ที่มี RAM 1 GB ได้หรือไม่

SafeLine ขั้นต่ำอย่างเป็นทางการ คือ RAM 1 GB ซึ่งอาจเพียงพอสำหรับการทดสอบหรือภาระงานที่เบามาก แต่ความสามารถในการใช้งานจริงขึ้นอยู่กับทราฟฟิก ฟีเจอร์ที่เปิดใช้ และการเก็บบันทึก สำหรับการติดตั้งใช้งานจริงขนาดเล็ก 2 vCPU และ RAM 4 GB เป็นจุดเริ่มต้นที่ระมัดระวัง ให้ติดตามการใช้หน่วยความจำและปรับขนาดจากภาระงานที่วัดได้

ทำไม ARM64 จึงต้องใช้สัญญาอนุญาตแบบเสียเงิน

SafeLine เอกสารการติดตั้งอย่างเป็นทางการ ระบุว่าการติดตั้งบน ARM ต้องใช้สัญญาอนุญาต Pro และรุ่น Personal Edition ไม่รองรับบน ARM หากคุณต้องการรุ่น Personal Edition ให้เลือก VPS สถาปัตยกรรม x86_64 หากคุณจำเป็นต้องใช้ ARM ให้วางแผนสำหรับสัญญาอนุญาต Pro

Chaitin Tech ได้รับข้อมูลอะไรจาก SafeLine ของฉันบ้าง

ข้อมูลขาออกที่แน่นอนอาจแตกต่างกันไปตามรุ่นและฟีเจอร์ที่เปิดใช้ บันทึกการเปลี่ยนแปลงของ CE รุ่นปัจจุบัน กล่าวถึง Threat Intelligence Sharing ในขณะที่เวอร์ชันที่ติดตั้งอาจมีการควบคุม UEP หรือการแบ่งปันข้อมูลอื่นด้วย ให้ตรวจสอบการตั้งค่าเหล่านั้นและบันทึกการเปลี่ยนแปลงของเวอร์ชันที่คุณติดตั้ง จากนั้นตรวจสอบการส่งข้อมูลออกที่ระดับเครือข่าย คอนเทนเนอร์บนเครื่องของ SafeLine จัดการข้อมูลแอปพลิเคชัน แต่ข้อเท็จจริงนั้นเพียงอย่างเดียวไม่ได้พิสูจน์ว่าการปฏิเสธ UEP จะหยุดคำขอขาออกทุกรายการ