كيفية نشر SafeLine WAF على خادم Linux VPS

تتعرض تطبيقات الويب المكشوفة على الإنترنت باستمرار لمحاولات فحص بحثاً عن حقن SQL، وإساءة استخدام بيانات الاعتماد، وأنماط الثغرات المعروفة. SafeLine هو WAF ذاتي الاستضافة مرخّص بموجب GPL-3.0 يعمل كحزمة Docker Compose ويقوم بتصفية حركة مرور HTTP/S قبل توجيه الطلبات المسموح بها إلى الأصل. كما أن خطة Personal المجانية تدعم ما يصل إلى 10 تطبيقات.

يغطي هذا الدليل عملية التثبيت وثلاثة مجالات تتطلب اهتماماً خاصاً: قرار بنية الوكيل العكسي (reverse-proxy)، وتهيئة شبكة Docker عندما يقع SafeLine خلف وكيل قائم مثل Nginx Proxy Manager، وأمر تحقق يمكنك تشغيله بعد التثبيت للتأكد من أن الـ WAF يعترض الهجمات فعلياً.

النسخة المختصرة

• قم بتثبيت SafeLine على خادم Linux VPS باستخدام Docker Compose. استخدم أداة التثبيت ذات السطر الواحد، أو اسلك مسار Docker Compose اليدوي لفحص تعريف Compose وتهيئة البيئة قبل تشغيل الحزمة.
• حدد بنية الوكيل العكسي قبل التثبيت: SafeLine كالوكيل الوحيد، أو SafeLine خلف Nginx Proxy Manager قائم، أو SafeLine يتشارك الخادم مع Caddy. يتطلب كل شكل تعييناً مختلفاً للمنافذ وإعدادات X-Forwarded-For.
• بعد التثبيت، تحقق من الـ WAF بإرسال محاولة فحص لحقن SQL عبر curl إلى الرابط المحمي. في وضع Balanced أو Strict، يؤكد الحجبَ ردٌّ برمز 403 مع مدخل مطابق في Attack Events. في وضع Monitor، يؤكد المدخل المطابق الاكتشافَ حتى وإن بقي الرد ناجحاً.
• تغطي فئة Personal المجانية ما يصل إلى 10 تطبيقات ومحرك الاكتشاف الأساسي. أما الحجب الجغرافي، وتصدير سجل الهجمات، والإشعارات الخارجية فتتطلب فئة Lite؛ ويتطلب اكتشاف الهجمات الأقوى وموازنة التحميل فئة 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 أو أحدث.
• معالج x86_64 يدعم SSSE3؛ تحقق من ذلك باستخدام lscpu | grep ssse3 بدلاً من افتراض توفر التعليمة.
• نطاق أو نطاق فرعي مع سجل DNS يشير إلى عنوان IP العام للخادم إذا كنت تخطط لكشف التطبيق المحمي عبر HTTPS العام.
• المنافذ المناسبة للطوبولوجيا المختارة. عادةً ما يمنح الشكلان A وC المنفذين 80 و443 لـ SafeLine، بينما يترك الشكل B هذين المنفذين لـ Nginx Proxy Manager ويخصّص لـ SafeLine مستمعاً مختلفاً مثل 10080.
• صلاحيات root أو sudo.

عند جدار الحماية أو مجموعة الأمان لدى مزود الخادم، اكشف فقط المنافذ العامة التي تحتاجها الطوبولوجيا المختارة. قيّد SSH وTCP 9443 على مصادر إدارة موثوقة. في الشكل B، أبقِ TCP 10080 مغلقاً أمام IPv4 وIPv6 العامين، وأبقِ منافذ الخلفية مثل 8080 خاصة في كل طوبولوجيا. فالوصول المباشر إلى 10080 سيتجاوز NPM ويُبطل حدود الثقة الخاصة بـ X-Forwarded-For.

ملاحظة: للنشر اليدوي على ARM64، اضبط ARCH_SUFFIX=-arm. إن وثائق النشر الرسمية الخاصة بـ SafeLine تنص على أن ARM يتطلب ترخيص Pro وأن إصدار Personal غير مدعوم على ARM. استخدم خادم x86_64 VPS لإصدار Personal.

تحقق من Docker قبل البدء:

docker --version
docker compose version

ينبغي أن يُرجع كلا الأمرين الإصدارات المثبّتة. تابع فقط إذا كان Docker بالإصدار 20.10.14 أو أحدث وDocker Compose بالإصدار 2.0.0 أو أحدث؛ وإلا فقم بالترقية قبل تثبيت SafeLine.

اختر بنية الوكيل العكسي أولاً

يتيح الخادم الجديد لـ SafeLine امتلاك المنفذين 80 و443 بالكامل. أما الخادم الذي يشغّل بالفعل Nginx Proxy Manager أو Caddy أو Nginx الخاص بالتطبيق فلا يتيح ذلك، وقرار البنية هو الفارق بين تثبيت سلس وتعارض في المنافذ عند أول تشغيل. اضبط هذا الأمر مرة واحدة صحيحة في البداية وسيصبح بقية النشر مجرد إجراء آلي.

الأشكال الثلاثة:

• الشكل A، SafeLine كوكيل عكسي وحيد. يمتلك SafeLine المنفذين 80 و443 ويدير TLS للتطبيق المحمي. إصدارات CE الحالية تتضمن سير عمل Free Cert، بينما يبقى الرفع اليدوي للشهادة متاحاً؛ تحقق من خيارات الشهادات الدقيقة في الإصدار المثبّت. تعمل الخلفية على منفذ غير عام ويوجّه SafeLine الحركة إليها.
• الشكل B، SafeLine خلف Nginx Proxy Manager (NPM). يحتفظ NPM بالمنفذين 80 و443 ويتولى SSL. يستمع SafeLine على المنفذ 10080 (HTTP فقط، لأن NPM أنهى TLS بالفعل). يوجّه NPM الحركة إلى SafeLine؛ ويوجّهها SafeLine إلى الخلفية. هذا إعداد شائع عندما يكون NPM منشوراً بالفعل.
• الشكل C، SafeLine جنباً إلى جنب مع Caddy. ينافس HTTPS التلقائي في Caddy على المنفذ 443 مع SafeLine. يتمثل الترتيب الصالح للعمل في منح SafeLine المنفذين 80 و443، ونقل Caddy إلى منفذ HTTP داخلي غير عام مثل 8080 من أجل مسار الانتقال من SafeLine إلى Caddy إلى التطبيق.

الفكرة الرئيسية: الشكل A هو الأبسط لخادم جديد؛ والشكل B هو الخيار الصحيح عندما يكون NPM قيد التشغيل بالفعل؛ ويتطلب الشكل C إعادة تعيين متعمدة لمنفذ Caddy.

ثبّت SafeLine على خادمك

التثبيت نفسه هو الجزء السهل. يوفّر 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، ويشغّل الحزمة. بعد التثبيت، شغّل sudo docker exec safeline-mgt resetadmin لاسترجاع بيانات اعتماد المسؤول أو إعادة تعيينها، كما هو موضح في دليل النشر الرسمي. احفظ بيانات الاعتماد الناتجة بأمان.

ملاحظة: يقوم هذا الأمر بتنزيل وتنفيذ سكربت shell بعيد من waf.chaitin.com بصلاحيات root. يتضمن الأمر الرسمي ذو السطر الواحد curl -k، الذي يعطّل التحقق من شهادة TLS. راجع السكربت المنزَّل قبل تنفيذه، أو استخدم الخطوة 2b إذا كانت هذه المخاطرة غير مقبولة. يتوفر SafeLine أيضاً كنشر Cloudzy بنقرة واحدة، لكن تلك الصورة تستخدم /opt/safeline, /opt/safeline/.env، و /opt/safeline/docker-compose.yml. لا تستخدم /data/safeline مسارات هذا الدليل دون تعديل على صورة Cloudzy.

الخطوة 2b، التثبيت اليدوي عبر Docker Compose. نزّل ملف Compose الرسمي وافحصه، ثم شغّل الحزمة:

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. إذا تعطّل safeline-tengine مع ظهور nginx: [emerg] invalid IPv6 address in resolver، فافحص أولاً ملف المُحلِّل وحدّد من يديره:

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

لا تحرّر /etc/resolv.conf مباشرةً إذا كان مولَّداً بواسطة systemd-resolved أو NetworkManager أو مزود الخادم. صحّح قيمة nameserver المشوّهة في تهيئة الخدمة المديرة، وأعد توليد ملف المُحلِّل، ثم أعد تشغيل 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 عبر النفق. من المتوقع ظهور تحذير بشهادة موقّعة ذاتياً عند أول وصول؛ تحقق من أن اتصال SSH وصل إلى الخادم المقصود قبل المتابعة.

إذا فقدت بيانات الاعتماد الأولية، فأعد تعيين كلمة مرور المسؤول من المضيف:

sudo docker exec safeline-mgt resetadmin

يطبع الأمر بيانات اعتماد المسؤول التي يمكنك استخدامها لتسجيل الدخول مجدداً.

قم بتهيئة SafeLine وفقاً لبنيتك

يعمل SafeLine الآن، لكنه لا يحمي أي شيء بعد. صفحة Applications في لوحة التحكم هي المكان الذي تخبر فيه SafeLine بالمواقع التي يجب حمايتها وبالمكان الذي يوجّه إليه الحركة المُنقّاة. تختلف التهيئة تبعاً للبنية التي اخترتها سابقاً، لذا يحصل كل شكل على قسمه الفرعي الخاص. اتبع فقط القسم المطابق لإعدادك.

الشكل A: SafeLine كوكيل عكسي وحيد

في الشكل A، يستمع SafeLine على المنفذين 80 و443 مباشرةً ويوجّه الحركة المُنقّاة إلى تطبيق الخلفية على منفذ غير عام. في لوحة التحكم:

1. انتقل إلى Applications، ثم Add Application.
2. اضبط منفذ الاستماع على 443 وفعّل SSL. استخدم سير عمل الشهادات المتاح في إصدار SafeLine المثبّت لديك. إصدارات CE الحالية تتضمن طلب Free Cert والتعامل مع التجديد، بينما يبقى الرفع اليدوي للشهادة متاحاً.
3. اضبط الـ upstream على http://127.0.0.1:8080. إذا كانت الخلفية تعمل في Docker، فانشر منفذها على loopback فقط، على سبيل المثال "127.0.0.1:8080:8080" في قسم ports الخاص بالخدمة. تجنّب استخدام عنوان IP ثابت للحاوية مثل 172.17.0.5 لأنه قد يتغير عند إعادة إنشاء الحاوية.
4. احفظ التطبيق. يبدأ SafeLine فوراً بالاستماع على 443 وتوجيه الحركة المُنقّاة إلى الخلفية.
5. تأكّد من أن سجل DNS A لنطاقك يشير إلى عنوان IP العام للخادم وأن المنفذين 80 و443 قابلان للوصول من الخارج.

إذا كان المنفذ 443 مرتبطاً بالفعل بعملية أخرى، فستفشل حاوية SafeLine في الارتباط وستُظهر لوحة التحكم خطأً على ذلك التطبيق. أوقف العملية المتعارضة، أو اختر منفذاً مختلفاً، قبل إضافة التطبيق.

الشكل B: SafeLine خلف Nginx Proxy Manager

يُبقي الشكل B على NPM يؤدي ما يؤديه بالفعل (امتلاك 80 و443، والتعامل مع Let's Encrypt) ويدرج SafeLine كطبقة أمان مخصصة خلفه. تدفق الحركة هو: العميل، ثم NPM (المنفذ 443، إنهاء TLS)، ثم SafeLine (المنفذ 10080، HTTP)، ثم تطبيق الخلفية.

داخل لوحة تحكم 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 كاسم مضيف التوجيه. إذا كان NPM يعمل في Docker على Linux، فإن 127.0.0.1 يشير إلى حاوية NPM بدلاً من مضيف الخادم. أضف تعيين host-gateway الخاص بـ Docker إلى خدمة NPM في Compose، ثم استخدم host.docker.internal كاسم مضيف التوجيه:

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 على نطاق الخادم ولا يتجاوز رؤوس مستوى location المولَّدة بموجب قواعد الوراثة في NGINX. يرسل الـ location المولَّد:

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

يُلحق التوجيه الثاني العنوان الذي رصده NPM كأقصى قيمة على اليمين في الرأس.

5. احفظ الـ Proxy Host.

بالعودة إلى SafeLine، قم بتهيئة استخراج عنوان IP المصدر فقط بعد تأكيد سلسلة الرؤوس الفعّالة. SafeLine 9.3.1 قدّم استخراجاً مرناً لـ XFF مع اختيار الاتجاه والفهرس.

1. Settings، ثم Advanced، ثم Real IP from Header. اضبط اسم الرأس على X-Forwarded-For.
2. استخدم الاستخراج المخصص من نهاية الرأس واختر أقصى عنوان على اليمين أضافه NPM. تختلف تسميات الفهرس الدقيقة باختلاف الإصدار، لذا تحقق من النتيجة في Logs، ثم Access. إذا كان الإصدار المثبّت أقدم من 9.3.1، فحدّثه قبل اتباع هذه الطوبولوجيا.
3. إذا كان Cloudflare أو شبكة CDN أخرى تقع قبل NPM، فقم أولاً بتهيئة NPM ليثق فقط في نطاقات الوكيل المنشورة لذلك المزود لكي يكون العنوان الذي يُلحقه NPM جديراً بالثقة. لا تختر موضعاً ثابتاً حتى تفحص سلسلة الرؤوس الفعلية وتختبرها.
4. احفظ التطبيق وأعد تحميله.

اختبر التهيئة من جهاز خارج الخادم:

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

ينبغي أن يُظهر سجل وصول SafeLine عنوانك العام الحقيقي، وليس 1.2.3.4 أو عنوان جسر NPM.

امنع المستخدمين من تجاوز SafeLine بإبقاء مستمع الخلفية خاصاً. بالنسبة إلى خلفية Docker Compose، انشر المنفذ على loopback فقط:

ports:
  - "127.0.0.1:8080:8080"

بالنسبة إلى خدمة تعمل مباشرةً على المضيف، اضبطها للاستماع على 127.0.0.1:8080 بدلاً من 0.0.0.0:8080. تحقق من كلا المنفذين الداخليين من جهاز خارج الخادم:

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 داخلي)، ثم خلفية التطبيق.

تحرير /etc/caddy/Caddyfile:

:8080 {
bind 127.0.0.1
reverse_proxy 127.0.0.1:3000
}

المستخدم :8080 كتلة الموقع هي الجزء المهم: يستمع Caddy الآن على منفذ HTTP داخلي بدلاً من التنافس مع SafeLine على 443. إن bind 127.0.0.1 السطر يُبقي ذلك المستمع محلياً على الخادم. أعد تحميل 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 تقبل حمولات JSON حرة). شغّل Monitor لبضعة أيام، وراجع صفحة Attack Events، وتأكّد من عدم وجود إنذارات كاذبة ضد المستخدمين الحقيقيين قبل الترقية إلى Balanced.
• Balanced. الوضع الافتراضي. إن الأرقام المنشورة من المورّد على GitHub الخاصة بـ SafeLine تُبلّغ عن 71.65% اكتشاف و99.45% دقة و0.07% معدل إنذارات كاذبة لوضع Balanced. أما وضع Strict فيُبلَّغ عنه بـ 76.17% اكتشاف و99.38% دقة و0.22% معدل إنذارات كاذبة. هذه نتائج مُبلَّغ عنها من المورّد وليست معياراً مستقلاً، ولا يعرّف ملف README مجموعة البيانات على أنها WAF-Eval. تعامل معها كأرقام منتج مقارِنة، وليس أداءً مضموناً في بيئة الإنتاج.
• Strict. مجموعة قواعد أكثر صرامة مع أساليب استدلالية أشد والمفاضلة بين الاكتشاف والإنذارات الكاذبة الموضحة أعلاه. يستحق التجربة بعد أسبوع أو أسبوعين من تشغيل Balanced نظيف، بمجرد أن تفهم حركة مرورك.

التوصية: Balanced لنشر جديد لا توجد فيه حركة مرور حية يُخشى إزعاجها. أما لتطبيق إنتاجي قائم، فابدأ بـ Monitor لبضعة أيام، وابحث عن الإنذارات الكاذبة في سجل Attack Events، ورقِّ إلى Balanced بمجرد ضبط أي استثناءات. ويستحق Strict التجربة بعد أسبوع أو أسبوعين من Balanced بمجرد أن تفهم حركة مرورك.

تحقق من الـ WAF باختبار SQLi عبر curl

الخطوة الأخيرة قبل اعتبار التثبيت مكتملاً هي التأكد من أن الـ WAF يعترض هجوماً فعلياً. شغّل محاولة فحص حميدة لحقن SQL على موقعك المحمي من أي جهاز خارج الخادم:

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

هذا هو متجه اختبار حقن SQL المنشور من SafeLine. في وضع Balanced أو Strict، توقّع رمز حالة 403 ورد حجب من SafeLine. في وضع Monitor، توقّع تسجيل الطلب دون حجبه. قد يختلف إصدار HTTP ونص الرد الدقيق، لذا تأكّد من النتيجة بمدخل مطابق في Attack Events.

ثم افتح لوحة التحكم عبر طريقة الوصول المقيّدة من الخطوة 4 وانتقل إلى Logs، ثم Attack Events. ينبغي أن ترى مدخلاً جديداً بطابع زمني مطابق، ونوع الهجوم SQL Injection، وعنوان IP مصدر مطابق للجهاز الذي شغّلت منه curl، وسلسلة الاستعلام المخالفة في تفاصيل الطلب. انقر على الحدث لعرض الطلب والرد الكاملين اللذين التقطهما SafeLine.

إذا أعاد طلب curl الرمز 200 OK، ففسّر النتيجة إلى جانب سجل Attack Events:

• يعني وجود حدث SQL Injection مطابق أن التطبيق على الأرجح في وضع Monitor؛ والتسجيل دون حجب أمر متوقع.
• إذا لم يكن هناك حدث مطابق، فتأكّد من أن DNS يُحلّل إلى الخادم المقصود، وتحقق من تهيئة مستمع SafeLine والـ upstream، واربط وقت الطلب بسجل وصول SafeLine.
• تأكّد أيضاً من أن الحماية مفعّلة وأنه لا توجد قائمة IP بيضاء أو قاعدة سماح مخصصة أو استثناء مسار يشمل طلب الاختبار.

الفكرة الرئيسية: إذا أعادت محاولة الفحص عبر curl الرمز 403 مع صفحة اعتراض SafeLine وظهر مدخل في Attack Events بنوع الهجوم SQL Injection، فإن الـ WAF يعترض الحركة بشكل صحيح.

ما تغطيه الفئة المجانية وما يتطلب خطة مدفوعة

فئة Personal المجانية كافية لحماية معظم عمليات النشر على خادم واحد. تبدأ الفئات المدفوعة بالأهمية عندما تحتاج إلى ميزات تشغيلية (الإشعارات، وتصدير السجل، والحجب الجغرافي) أو عندما تتجاوز حد الـ 10 تطبيقات.

التفصيل، المستمَد من صفحة أسعار CyberServal:

• Personal، مجانية. ما يصل إلى 10 تطبيقات. تتضمن محرك الاكتشاف الدلالي (SQLi وXSS وحقن الأوامر واجتياز المسارات وSSRF وXXE وCRLF)، وتحديد المعدل، وتحدي CAPTCHA للبوتات، وتشفير HTML/JS الديناميكي ضد أدوات الكشط المؤتمتة، وقواعد ACL للويب، وإدارة الشهادات. إصدارات CE الحالية تتضمن أيضاً طلب Free Cert والتعامل مع التجديد.
• Lite، $10/month أو $100/year. تضيف الحجب الجغرافي، وقاعدة بيانات IP لاستخبارات التهديدات، وتكامل إشعارات Discord وTelegram، وتصدير سجل الهجمات، وترفع حد التطبيقات إلى 20.
• Pro، $100/month أو $1,000/year. تضيف اكتشاف هجمات أقوى، وتهيئات لكل خدمة وعامة، وصفحات اعتراض مخصصة، وموازنة تحميل للـ upstream، ومزامنة عُقَد master-slave، وتطبيقات غير محدودة. راجع جدول الأسعار الحالي لمعرفة التغييرات.
• Ultimate، تسعير مخصص. شروط مؤسسية مصممة خصيصاً مع دعم فردي عبر القنوات وتطوير ميزات مخصصة.

يعالج SafeLine بيانات التطبيقات ويخزّنها داخل حزمة Compose المحلية الخاصة به. ومع ذلك، فإن ملاحظات إصدار CE الحالية تذكر مشاركة استخبارات التهديدات (Threat Intelligence Sharing)، لذا ينبغي على المشغّلين مراجعة ضوابط UEP والخصوصية والمشاركة في الإصدار المثبّت ومراقبة الاتصالات الصادرة قبل اعتبار النشر خالياً من أي بيانات صادرة.

إلى أين تتجه من هنا

اكتمل التثبيت وتم التحقق من الـ WAF. ستساعد بعض المهام اللاحقة في الحفاظ على سلامة النشر.

• بالنسبة إلى أي تطبيق إنتاجي بمدخلات مستخدم غنية (منتدى، أو لوحة إدارة، أو واجهة API حرة)، اضبط وضع الحماية على الشاشة لمدة ثلاثة إلى سبعة أيام، وراجع صفحة Attack Events يومياً، ورقِّ إلى Balanced بمجرد ضبط أي إنذارات كاذبة.
• في فئة Lite، قم بإعداد تكامل إشعارات Discord أو Telegram لكي تصلك تنبيهات الهجمات خارج لوحة التحكم.
• حدّد نافذة صيانة شهرية. قبل الترقية، انسخ احتياطياً بيانات SafeLine وتهيئة البيئة، واقرأ ملاحظات الإصدار الحالية، واستخدم إجراء الترقية المدعوم لإصدارك المثبّت. لا تعتمد فقط على docker compose pull ثم نفّذ docker compose up -d، لأن تعريف Compose أو متغيرات البيئة المطلوبة قد تتغير بين الإصدارات. ينبغي على مستخدمي Cloudzy بنقرة واحدة العمل من /opt/safeline واتباع تعليمات صورة السوق.
• اشترك في صفحة إصدارات SafeLine لإشعارات التصحيحات الأمنية، وفي مستودع المشروع لتتبع المشكلات.

إذا لم يكن لديك بعد خادم لهذا النشر، فإن SafeLine متاح كنشر بنقرة واحدة في سوق Cloudzy. توفر خطة بسعة 4 GB RAM المساحة العملية الموصى بها في هذا الدليل؛ أعد التحقق من جدول الأسعار الحالي على Cloudzy وقت النشر لأن مواصفات الخطة قابلة للتغيير. تستخدم الصورة ذات النقرة الواحدة /opt/safeline و /opt/safeline/docker-compose.yml، لذا تنطبق تعليمات البنية ولوحة التحكم، لكن /data/safeline أوامر هذا الدليل لا تنطبق بالطريقة نفسها تماماً.

الأسئلة الشائعة

هل يحل SafeLine WAF محل Nginx Proxy Manager، أم أشغّل كليهما؟

يمكن لـ SafeLine أن يحل محل Nginx Proxy Manager عند نشره كوكيل عكسي وحيد. ومع ذلك، فهو لا يحتاج إلى استبدال NPM. يُبقي إعداد شائع على NPM في المقدمة لـ SSL والتوجيه، ويضع SafeLine خلفه كطبقة أمان مخصصة. كلاهما يعمل؛ ويعتمد الاختيار على ما إذا كنت تريد أداة واحدة تؤدي المهمتين أم أداتين تؤدي كل منهما مهمة واحدة بإتقان.

هل الفئة المجانية كافية لموقع WordPress واحد أو تطبيق SaaS صغير؟

نعم، للحماية. تتضمن فئة Personal المجانية محرك الاكتشاف الدلالي، وتحديد المعدل، وتحدي CAPTCHA للبوتات، وتشفير HTML/JS الديناميكي، وهي دفاعات أساسية لموقع واحد. تضيف الفئات المدفوعة ميزات تشغيلية مثل الحجب الجغرافي، وتصدير سجل الهجمات، والإشعارات الخارجية، وحدود تطبيقات أعلى، واكتشاف أقوى، وموازنة تحميل. تعتمد ضرورة الفئة المدفوعة على الميزات المطلوبة وعدد التطبيقات، وليس على حجم حركة المرور وحده.

هل يعمل SafeLine على خادم بذاكرة 1 GB RAM؟

إن الحد الأدنى الرسمي لـ SafeLine هو 1 GB RAM. قد يكون ذلك كافياً للاختبار أو لعبء عمل خفيف جداً، لكن سعة الإنتاج تعتمد على حركة المرور، والميزات المفعّلة، ومدة الاحتفاظ بالسجلات. لنشر إنتاجي صغير، يُعد 2 vCPU و4 GB RAM نقطة بدء متحفظة؛ راقب استخدام الذاكرة ووسّع بناءً على الحمل المُقاس.

لماذا يتطلب ARM64 ترخيصاً مدفوعاً؟

إن وثائق النشر الرسمية تنص على أن عمليات النشر على ARM تتطلب ترخيص Pro وأن إصدار Personal غير مدعوم على ARM. إذا كنت تريد إصدار Personal، فاختر خادم x86_64 VPS؛ وإذا كنت بحاجة إلى ARM، فخطط لترخيص Pro.

ما الذي تتلقاه Chaitin Tech من نسخة SafeLine الخاصة بي؟

قد تختلف البيانات الصادرة الدقيقة باختلاف الإصدار والميزات المفعّلة. ملاحظات إصدار CE الحالية تذكر مشاركة استخبارات التهديدات (Threat Intelligence Sharing)، بينما قد يكشف الإصدار المثبّت أيضاً عن UEP أو ضوابط مشاركة أخرى. راجع تلك الإعدادات وملاحظات الإصدار الخاصة بإصدارك المثبّت، ثم تحقق من البيانات الصادرة على مستوى الشبكة. تتولى حاويات SafeLine المحلية بيانات التطبيقات، لكن هذه الحقيقة وحدها لا تثبت أن رفض UEP يوقف كل طلب صادر.