هذا دليل تثبيت Arcivéo Monitor وإعداده وصيانته. الأقسام مقسّمة إلى: نظرة عامة، ونشر لوحة التحكم، وربط أدوات الأمان، والوحدات المدمجة والتشخيص. يمكن نسخ الأوامر بالزر على اليمين.
تثبيت اللوحة موضّح في صفحات منفصلة خطوة بخطوة. اختر الطريقة:
Arcivéo Monitor — لوحة أمان السيرفر. يجمع البيانات من الأدوات المثبتة (Fail2ban وUFW وLynis وModSecurity وAIDE وClamAV وAuditd وCrowdSec وSuricata وFalco وغيرها) ويعرضها في واجهة موحدة تضم لوحة معلومات وخريطة هجمات وصفحات تفصيلية لكل أداة.
المونيتور ليس أداة حماية فعّالة — فهو لا يحجب الهجمات بنفسه. مهمته تجميع المعلومات من الأدوات العاملة بالفعل وعرضها بشكل مريح.
يعمل المونيتور محليًا فقط — يجب تثبيته على نفس السيرفر الذي يراقبه. لا يوجد أي SSH أو API عن بُعد.
تُنفّذ لوحة التحكم جميع الأوامر (fail2ban-client، ufw status، ipset list وغيرها) باسم مستخدم سيرفر الويب (عادةً www-data، وفي لوحات الاستضافة حساب الموقع) بـمجموعة صلاحيات محدودة من sudo — على أدوات محددة فقط، دون وصول root عام. تُحلَّل النتائج وتُعرَض في المتصفح.
تبدأ الدرجة من القيمة القصوى وتنخفض عند كل مشكلة يتم اكتشافها:
PermitRootLogin yes) — −20النتيجة: 80+ = محمي، 60–79 = انتباه، <60 = مُعرّض للخطر.
WebAuthn — معيار مصادقة بدون كلمة مرور عبر مفتاح أمان مادي. يدعم YubiKey وTouch ID وFace ID وWindows Hello وPasskey.
بعد تسجيل الدخول بكلمة المرور، يطلب النظام تأكيدًا عبر مفتاح أمان مُسجَّل. حتى لو تسرّبت كلمة المرور، يستحيل الدخول دون المفتاح المادي أو السمة الحيوية.
للإعداد، افتح مفاتيح WebAuthn من القائمة الجانبية واضغط «تسجيل مفتاح». سجّل مفتاحين معًا: إذا فُقد المفتاح الوحيد أو تعطّل، فسيتعذّر الدخول إلى اللوحة عبره.
يمكن للوحة إرسال تقرير الأمان إلى Telegram وإلى البريد (بضغطة زر أو حسب الجدولة). يُضبط ذلك في قسم «الإعدادات».
Telegram. تحتاج إلى توكن البوت وchat id:
@BotFather ← /newbot ← ستحصل على توكن بالشكل 123456:ABC....@userinfobot، أو افتح https://api.telegram.org/bot<TOKEN>/getUpdates وابحث عن "chat":{"id":...}.البريد الإلكتروني. طريقتان للاختيار في «الإعدادات» ← البريد الإلكتروني:
re_...) ونطاق المرسل المؤكَّد.حالة التقرير: «تنبيه» أو «سليم». يصبح العنوان «تنبيه» فقط عند وجود مشكلة فعلية أو إجراء بانتظار التنفيذ: عُثر على تهديد في ClamAV، أو تغييرات ملفات في AIDE، أو أحداث حرجة في Falco (Emergency/Alert/Critical خلال آخر 24 ساعة)، أو خدمة متوقفة في Monit، أو حاجة لإعادة التشغيل، أو قرب انتهاء SSL (≤14 يومًا)، أو تحديثات أمان بانتظار التطبيق. أما الضجيج الخلفي — محاولات SSH من البوتات، وعناوين IP المحظورة بواسطة fail2ban، وتنبيهات Suricata، وتحذيرات Lynis، وطلبات ModSecurity التي صُدَّت فعلًا — فهو لا يرفع الحالة، لذا فإن هذه الأرقام في التقرير لا تعني «تنبيه» بحد ذاتها.
تُفتح وحدات المراقبة التفصيلية (Lynis وUFW وModSecurity وخريطة الهجمات وAIDE وClamAV وغيرها) عند وجود ترخيص ساري المفعول. بدونه تعمل لوحة المعلومات والإعدادات والحساب، بينما تعرض الوحدات بطاقة «الترخيص مطلوب».
بعد الشراء في الحساب الشخصي يكون لديك رمز تفعيل بالصيغة ARCIVEO-XXXX-XXXX-XXXX-XXXX. يجب «تفعيله» على نطاق لوحتك — سيحوّل هذا الرمز إلى ملف ترخيص موقّع (الكتلة [license]) تقوم بلصقه في اللوحة.
كيفية التفعيل (٣ خطوات):
my.arciveo.com ← قسم «التراخيص» / «تفعيل الترخيص» — انسخ الرمز ARCIVEO-….monitor.example.com). اضغط تفعيل — سيُنشئ النظام ملف ترخيص مرتبطًا بهذا النطاق ويعرضه في حقل مع زر «نسخ».تتحقق اللوحة من المفتاح تشفيريًا: التوقيع والارتباط بالنطاق ومدة الصلاحية.
APP_URL في config.php وأدخل اسم المضيف فقط — بدون https:// وبدون البادئة www. التفعيل يتم مرة واحدة: يتحوّل الرمز إلى ترخيص للنطاق المُدخَل ولا يُفعَّل مجددًا — عند وجود خطأ في النطاق لن يناسب المفتاح لوحتك، وسيُستهلك الرمز. لذلك أدخل النطاق بعناية.
جميع المعطيات الأساسية للوحة محددة في ملف واحد config.php في الجذر (بجوار مجلد public/) عبر ثوابت define() اعتيادية. يُنشأ الملف أثناء التثبيت؛ ونادرًا ما تحتاج إلى تعديله يدويًا — غالبًا عند تغيير الدومين أو النقل أو الاتصال بقاعدة بيانات أخرى. بعد أي تعديل أعد تشغيل PHP-FPM (وإلا فلن تُطبّق التغييرات بسبب OPcache).
ضع قيمك مكان التظليلات؛ واترك الباقي كما هو:
قاعدة البيانات. بيانات الاتصال بـ MySQL/MariaDB:
DB_HOST — مضيف نظام قاعدة البيانات، وهو غالبًا localhost؛DB_NAME — اسم قاعدة بيانات اللوحة؛DB_USER — مستخدم القاعدة (وصول إلى قاعدته فقط)؛DB_PASS — كلمة مرور هذا المستخدم؛DB_CHARSET — ترميز الاتصال، اترك utf8mb4.التطبيق.
APP_URL — العنوان الكامل للوحة (مثل https://monitor.example.com). يجب أن يطابق الدومين الذي فُعّلت عليه الرخصة — وإلا فسيُرفض المفتاح (انظر قسم «الرخصة»)؛TIMEZONE — المنطقة الزمنية لـ PHP: تؤثر فقط على طريقة عرض اللوحة للتواريخ والأوقات. ولا تؤثر على أوقات تشغيل مهام cron — فتلك تتبع منطقة النظام (انظر «كل مهام cron»).مدة الجلسة. SESSION_LIFETIME — مهلة خمول الجلسة بالثواني (منزلقة: تتجدد عند النشاط). القيمة الافتراضية 28800 = 8 ساعات؛ وبعد هذه المدة من الخمول تطلب اللوحة إعادة الدخول. مثلاً 3600 = ساعة واحدة، 86400 = يوم كامل.
تسجيل الأخطاء. لا تُعرض الأخطاء للزوار أبدًا، بل تُكتب في logs/php_errors.log — وتظهر في صفحة «سجلات التطبيق». هذه الأسطر (display_errors=0 وlog_errors=1 والمسار error_log) لا حاجة لتعديلها عادةً — فالإعدادات محددة داخل الملف مباشرةً ولا تعتمد على php.ini.
public/)، وجذر الويب (DocumentRoot) لهذه اللوحة هو جذر اللوحة نفسه لا public/. والملف بذاته لا «يتسرّب»: ففي .htaccess الجذري يوجد منع صريح له (Require all denied) — فيعيد السيرفر 403. وحتى بدون هذه القاعدة لما تسرّب المصدر: فهذا PHP — ينفّذه السيرفر ولا يعرضه كنص. وللاحتياط: لا تنشره في مستودعات عامة ولا ترسله للدعم بكلمة مرور حقيقية. صلاحيات الملف — 640.
UFW (Uncomplicated Firewall) — واجهة بسيطة لـ nftables/iptables. يغلق كل المنافذ الواردة عدا المسموح بها صراحةً. صفحة «جدار الحماية UFW» تعرض الحالة والقواعد.
ufw enable اسمح بـ SSH إلزاميًا (ufw allow OpenSSH)، وإلا ستفقد الوصول إلى السيرفر.
deny لا يُعتبر متاحًا من الخارج.
Skipping adding existing rule — ليس خطأً. بهذا يُبلغ UFW أن قاعدة مطابقة تمامًا موجودة بالفعل ولا يضيفها مجددًا. عند إعادة تشغيل الإعداد التلقائي (وهو عملية عديمة التأثير التراكمي) تكون هذه رسالة اعتيادية — لا حاجة للتدخل.
يحظر عنوان IP تلقائياً بعد تجاوز عدد محاولات الدخول الفاشلة. يحلّل سجلّات SSH وnginx وApache وخدمات أخرى.
التثبيت الأساسي مذكور أعلاه. هنا إعداد عملي يوفّر عشرات الـ jail النشطة وآلاف الحظر: الإعدادات العامة، وأهم الـ jail، والحظر التلقائي للـ IP الخبيثة من قائمة ipsum.
الملف /etc/fail2ban/jail.local — الإعدادات العامة وأهم الـ jail:
ignoreip اكتب حتمًا عنوان IP الخاص بك والشبكات الموثوقة، وإلا فقد تحظر نفسك. بعد التعديلات: sudo fail2ban-client reload.
التحميل التلقائي لقائمة الحظر ipsum — في cron الخاص بـ root (sudo crontab -e): يُحمَّل level 1 (أكثر من 100 ألف IP) إلى المجموعة ipsum التي تُحظر على جدار الحماية (التفاصيل في قسم «قائمة الحظر IPset»):
ipsum — فهي التي تقرأها لوحة التحكم (بطاقة «IPset ipsum»). المستويات: levels/1.txt — أوسع تغطية، levels/3.txt — أدق (3 مصادر أو أكثر).
لماذا يُقسَّم «مراقب الأمان» إلى منطقتين. تعمل الحماية على مستويين، ولوحة التحكم لا تخلط بينهما:
sshd وapache-* وnginx-* وغيرها) والمعاودون الخطرون (jail recidive — من سبق حظرهم عدة مرات). هذه عناوين IP اقتحمتك فعلًا — وهي على خريطة الهجمات و«الخط الزمني».ipset ipsum، تُحظر على جدار الحماية بقاعدة DROP. معظم هذه العناوين لم تمسّ سيرفرك أصلًا — تُقطع مسبقًا؛ ويُظهر عدّاد «IPset ipsum» كم عنوانًا قُطع وقائيًا.الفرق بسيط: التفاعلي — «هؤلاء هاجموا وحُظروا»، والوقائي — «هؤلاء حُظروا قبل المحاولة». سابقًا كان list-3 ipsum يُحشر في recidive بشكل مصطنع (ومن هنا جاء التقسيم القديم «recidive القائمة»)؛ أما الآن فـ recidive للمعاودين الحقيقيين فقط، والوقائي كله على جدار الحماية.
ipsum — قائمة عامة بعناوين IP الخبيثة تُحدَّث يوميًا. يعرض المونيتور عدد العناوين المحمّلة على لوحة المعلومات وخريطة الهجمات ويأخذه بالحسبان في تقييم الأمان (−10 إذا لم تُحمَّل المجموعة).
الخيار الأدنى بدون fail2ban — مجموعة ipsum منفصلة مع الحظر عبر iptables:
@reboot. وبالمناسبة، الأمر create … -exist يضبط الحد maxelem 300000 (الافتراضي 65536 — لا تتّسع له level 1 وسيظهر «Hash is full»):
ipsum، وإذا كان المثبِّت هو من يدير جدار الحماية (VPS جديد — الملفان «الكامل»/«المخفّف»)، فإنه يربط المجموعة بـ UFW عبر قاعدة DROP — فيُحظر فعليًا المرور من هذه العناوين. تأتي القاعدة بعد ESTABLISHED,RELATED، لذا لا تنقطع الاتصالات الحالية (بما فيها SSH الخاص بك) — تُقطع فقط الاتصالات الجديدة من القائمة. تُستعاد المجموعة عند تحميل الخدمة ipsum-load.service قبل جدار الحماية (وإلا لما عمل UFW)، وتُحدَّث بالكرون الساعة 04:00. على سيرفر مُعدّ مسبقًا (لوحة تحكم، جدار حماية خاص) لا يتدخل المثبِّت في جدار الحماية — هناك يبقى ipsum قائمةً للوحة المعلومات وخريطة الهجمات، وتُضاف قاعدة DROP يدويًا عند الرغبة (الخيار الأدنى مع iptables … --match-set ipsum … -j DROP — أعلاه). عند التثبيت التلقائي لا حاجة لفعل أي شيء يدويًا.
بديل حديث لـ Fail2ban مع threat intelligence جماعي: حظر من المجتمع بالإضافة إلى قواعدك الخاصة. يتطلب bouncer منفصلاً لتطبيق الحظر على الجدار الناري.
systemctl is-active crowdsec). للتشغيل: sudo systemctl enable --now crowdsec؛ وعند التعطّل راجع sudo journalctl -u crowdsec -n 30. تنطبق القاعدة نفسها على أي خدمة بحالة «غير مُشغَّل» (Suricata، Falco، Monit، MySQL).
stream halted / الحظر لا يُطبَّق. هذا مفتاح api يتيم: أُزيل الـ bouncer من cscli bouncers list لكن مفتاحه القديم بقي في /etc/crowdsec/bouncers/*.yaml. أعد تسجيل الـ bouncer واكتب المفتاح الجديد:
AIDE (Advanced Intrusion Detection Environment) يأخذ لقطة لنظام الملفات ويُبلغ في كل فحص عن التغييرات في /etc و/bin و/usr. بعد التثبيت لا بد من تهيئة قاعدة البيانات (aideinit).
aideinit يظل الطرفية عالقة على السطر Running aide --init... لمدة 5–15 دقيقة — وهذا طبيعي (تجزئة نظام الملفات كاملاً، حِمل على القرص). لا تقاطعه بـ Ctrl+C. إذا بدا العملية «معلّقة» دون كتابة أي شيء — فقد تكون تنتظر الرد على طلب مخفي Overwrite existing aide.db.new [Yn]? (اضغط Y). للتحقق من النشاط من جلسة أخرى: pgrep -af aide.
aideinit: «21_aide_spamassassin … printf: invalid number» (return code 20) — علة معروفة في مقتطف إعدادات AIDE على Ubuntu 22.04. لا تُنشأ القاعدة. أخرِج المقتطف المعطوب وأعِد المحاولة:
aideinit لم يُشغَّل، أو (Ubuntu 24.04) أن الدليل /var/lib/aide أُنشئ بصلاحية 700 ولا يصل إليه www-data — ويُعالَج بـ sudo chmod 755 /var/lib/aide (انظر الكتلة أعلاه). «لم يُجرَ أي فحص» = القاعدة موجودة لكن لم يُنفَّذ فحص بعد — وهذا ليس خطأً. يقرأ المونيتور النتائج من /var/log/aide/aide.log.
/etc/cron.daily/aide القياسي على Ubuntu/Debian الحديثة ملف /var/log/aide/aide.log بالشكل المطلوب (كما أن aide.wrapper لم يعد موجوداً فيها). الأوثق إضافة كرون خاص بك مع --config صريح — فهو يكتب السجل من root بصلاحية 644، ويقرأه المونيتور دون مجموعات إضافية:
chmod 755 /var/lib/aide وكرون فحص في 02:00 — لا حاجة لأي شيء يدوياً.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
ماسح مضاد للفيروسات لنظام Linux. مفيد بشكل خاص لفحص /var/www بحثًا عن أصداف PHP والشيفرات الخبيثة.
enable --now؟ ثلاثة أسباب شائعة:
1. بقي السطر Example في ملف الإعداد — يرفض clamd الإقلاع طالما كان موجودًا:
2. لم يتم تنزيل قاعدة التواقيع — لا يُقلع clamd بدونها:
3. إنه يُحمّل فقط — يُحمّل clamd نحو 8 ملايين توقيع في الذاكرة خلال 30–60 ثانية. انتظر وتحقق: systemctl is-active clamav-daemon (الحالة activating ← ما زال يُحمّل).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd تُبقي التواقيع في الذاكرة فقط، وهي بذاتها لا تفحص أي شيء وفق جدول زمني. تعرض اللوحة نتائج الفحص المجدول، لذا يلزم مهمة cron تفحص وتكتب سجلًا. يثبّت التثبيت التلقائي الغلاف /usr/local/bin/clamav-scan.sh ومهمة cron في 01:30 — بعد التشغيل الأول تُملأ «الملفات المفحوصة» و«آخر فحص». للتشغيل فورًا دون انتظار الجدول: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) — أداة فحص للبرمجيات الخبيثة الموجّهة لتهديدات الويب: أصداف PHP والأبواب الخلفية للويب والمُحمّلات. يستخدم محرك ClamAV ويكمّله بتواقيعه الخاصة.
maldet --report.
update-rc.d: error: unable to read /etc/init.d/maldet — وهو غير ضار. لا يستخدم maldet آلية init.d، إذ يتم تشغيل تحديث التواقيع والفحوصات عبر /etc/cron.daily/maldet. إذا ظهر أدناه installation completed فقد اكتمل التثبيت.
apt بل في /usr/local/maldetect، وعند تفعيل open_basedir يُتحقق من وجوده عبر shell — راجع قسم «الصفحة فارغة رغم وجود البيانات على السيرفر».
نظام شبكي لكشف التسلل: يحلل حركة المرور على مستوى الحزم ويعرف آلاف توقيعات الهجمات. يكمّل ModSecurity (الذي يعمل على مستوى HTTP، بينما تعمل Suricata على مستوى TCP/IP).
/var/log/suricata/eve.json تحت root بصلاحية 750 على المجلد، ولا يستطيع سيرفر الويب (www-data) قراءته. افتح المجلد للمرور — تبقى الملفات بداخله محمية:
يعترض استدعاءات النظام عبر eBPF/kernel module ويكتشف الحالات الشاذة في الوقت الفعلي: تشغيل shell من nginx، قراءة عملية الويب لـ /etc/passwd، الكتابة في /bin وما إلى ذلك.
journalctl -u falco (دون sudo — عبر مجموعة systemd-journal). تأكد من أن www-data ضمن هذه المجموعة — راجع «إعداد sudo» (البند 2) في صفحة التثبيت اليدوي.
/etc/passwd، الكتابة في أدلة النظام). صفر أحداث حرجة خلال اليوم على سيرفر هادئ يعني حالة صحية.
journalctl صلاحيات على السجل؛ ولكي ترى اللوحة الأحداث بثبات، يفعّل التثبيت التلقائي في Falco خاصية file_output ← /var/log/falco/falco.log ويضبط للخدمة UMask=0022 (يمكن لسيرفر الويب قراءة السجل). لا حاجة لضبط ذلك يدوياً على تثبيت جديد.
ModSecurity — جدار حماية للويب (WAF) لـ Apache أو Nginx. يحجب الهجمات على مستوى التطبيق: حقن SQL، وXSS، وتجاوز المسارات، والماسحات.
IncludeOptional /etc/modsecurity/*.conf، بينما تضع الحزمة فقط modsecurity.conf-recommended — وهو لا يطابق النمط *.conf. إن لم تنسخه إلى modsecurity.conf، يبقى SecRuleEngine على Off: الوحدة محمّلة، وقواعد CRS محمّلة، لكن لا يُفحص أي مرور ولا يُنشأ سجل التدقيق. أما الوضع الوسيط DetectionOnly فيسجّل الأحداث فقط دون حجب الطلبات — وتعرضه اللوحة بالأصفر.
وصول اللوحة إلى سجل التدقيق. السجل /var/log/apache2/modsec_audit.log ملك لـ root (الصلاحيات 640)، ولا يستطيع مستخدم الويب قراءته. تأخذ اللوحة البيانات عبر غلاف — أنشئه:
SecRuleEngine بدون مسافة بادئة: فالأسطر ذات المسافة البادئة تقع داخل كتل <LocationMatch>/<Directory> (مثل تعطيل WAF لـ phpMyAdmin) ولا تحدد الوضع العام.www-data، وفي HestiaCP يعمل تجمّع الموقع تحت مالك الموقع (مثلاً admin) — تحقّق بـ grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf.X-Forwarded-For. لا يدخل في الإحصاءات إلا المعاملات التي انطبقت عليها قاعدة: فالتوجيه SecAuditLogRelevantStatus يكتب في سجل التدقيق أي استجابات 4xx/5xx، ولذلك تدخل فيه أيضاً استجابات 403/500 العادية — واللوحة لا تعتبرها أحداث WAF.---RULES--- — فاللوحة تعرض ليس فقط القواعد التي انطبقت، بل كل قواعد CRS المحمّلة والقواعد المخصّصة. المسارات الثلاثة في حلقة for f in … هي المواضع النمطية لقواعد CRS والإضافات المحلية؛ فإن كان لديك تخطيط مختلف (الحزمة تضع الملفات في مجلدها، أو القواعد المخصّصة ليست في /etc/modsecurity/custom-rules.conf)، فابحث عن المسارات الفعلية بالأمر sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null وأدرجها في القائمة. أما إذا كان الغلاف قديماً (بلا هذا القسم) — فسيعرض القسم تحذير «غير متاح» فقط، وبقية الصفحة تعمل كالسابق.
Auditd (Linux Audit Daemon) يسجّل استدعاءات النظام على مستوى النواة: تسجيلات الدخول والخروج، وأوامر sudo، ومحاولات المصادقة الفاشلة، وتغييرات الملفات. يعرض المونيتور تسجيلات الدخول والمحاولات الفاشلة وأوامر sudo لليوم.
ausearch (/usr/sbin/ausearch) وعند الحاجة من /var/log/audit/audit.log بأمر tail. يجب أن يكون كلاهما في sudoers.
يراقب الخدمات (nginx و php-fpm و mysql وغيرها) ويعيد تشغيلها عند تعطّلها. ويمكنه إرسال تنبيهات عبر البريد الإلكتروني.
monit status. يجب تفعيل واجهة HTTP في /etc/monit/monitrc (كتلة set httpd مع allow localhost)، وإلا فسيُرجع monit status خطأً.
set httpd في monitrc معلّق (يأتي افتراضيًا هكذا: # set httpd port 2812 …). أزِل التعليق عن الكتلة واسمح لـ localhost. (2) تفعيل httpd وحده لا يراقب شيئًا — إذ لا يحسب Monit سوى ما يُوصف بكتل check؛ وبدونها تبقى القائمة فارغة حتى مع عمل الواجهة. أدنى إعداد فعّال:
conf.d جاهزًا مع httpd على المنفذ 2812 ومجموعة من الفحوصات — لا حاجة للإعداد اليدوي على تثبيت جديد.
PSAD يحلّل سجل iptables ويكشف فحص المنافذ والهجمات الشبكية، ويسند لكل مصدر مستوى خطورة (1–5). يكمّل fail2ban وSuricata.
psad --Status (مطلوب في sudoers). بدون تسجيل iptables ستكون الصفحة فارغة — وهذا طبيعي ما لم تحدث عمليات فحص.
Mandatory Access Control يقيّد الملفات والموارد التي يمكن لأي برنامج الوصول إليها، حتى لو تم اختراقه. في Ubuntu/Debian يُستخدم AppArmor افتراضيًا (وغالبًا ما يكون مثبتًا ونشطًا بالفعل).
aa-status (يجب إضافته إلى sudoers). يعرض عدد الملفات التعريفية في وضع enforce/complain والعمليات بدون ملف تعريفي.
أن يكون «عدد الملفات التعريفية المحمّلة» أكبر من enforce + complain أمر طبيعي. في AppArmor 4.x (Ubuntu 24.04 وأحدث) ظهر وضع unconfined: الملف التعريفي محمّل في النواة لكنه لا يقيّد شيئًا. تضع Ubuntu هذا الوضع على عشرات الملفات التعريفية للبرامج التي تستخدم user namespaces (المتصفحات وعملاء التورنت وما شابه). عند وجود مثل هذه الملفات، تصبح بطاقة «عدد الملفات التعريفية المحمّلة» كهرمانية وتعرض عددها — مثلًا unconfined: 90 مع 120 محمّلًا و26 في enforce. الحماية الفعلية تأتي فقط من الملفات في وضع enforce؛ أما على Ubuntu 22.04 (AppArmor 3.x) فلا يوجد هذا الوضع وتتطابق الأرقام دائمًا.
unconfined إلى enforce يجب أن يتم بوعي فقط: فهي معطّلة ليس عن خطأ، بل لأن تفعيلها يعطّل عمل البرامج نفسها. أما الملفات في وضع complain فأمرها مختلف: قواعدها مكتوبة بالفعل ولكنها غير مطبَّقة فحسب.
debsums يتحقق من أن ملفات الحزم المثبّتة تطابق المجاميع الاختبارية من المستودع — يكشف الملفات الثنائية النظامية المستبدلة (يكمّل AIDE). يستغرق الفحص الكامل 1–2 دقيقة، لذا يُشغَّل عبر cron، وتقرأ اللوحة النتيجة من data/debsums/debsums.log وتصنّفها بنفسها (يهمّ فقط الملفات الثنائية والمكتبات).
المهمة تُضاف إلى كرون الجذر (sudo crontab -e). يُوضَع الغلاف الجاهز debsums-scan.sh في /usr/local/bin/ (chmod +x؛ راجع ملخص مهام cron) ويكتب التقرير بنفسه في data/debsums/ باللوحة.
الغلاف debsums-scan.sh يجد data/ باللوحة بنفسه — لا حاجة لكتابة المسار.
/etc/ (ملفات الإعداد) و/usr/share/ (الموارد) على السيرفر عادةً طبيعية — تميّزها اللوحة بلون منفصل. المقلق هو تغييرات الملفات الثنائية والمكتبات (/bin، /sbin، /usr/lib وما شابه) — بطاقة «الملفات الثنائية / المكتبات» تعرض هذه تحديدًا.
يُشغَّل Lynis يدويًا أو عبر cron. يجب حفظ التقرير في مجلد المشروع data/lynis/ — يقرأ المونيتور الملف lynis-report.dat.
lynis-scan.sh في الخلفية مباشرةً من اللوحة (دون انتظار cron): يعرض «جارٍ الفحص…» وعند الانتهاء يحدّث التقرير تلقائيًا. لذلك يحتاج مستخدم الويب إلى سطر sudoers لتشغيل السكربت — يضيفه المثبّت تلقائيًا في /etc/sudoers.d/monitor. إذا ثُبّتت اللوحة يدويًا/سابقًا، أضِف السطر بنفس المستخدم المذكور في الملف:
يجب أن يحفظ Logwatch التقارير اليومية في مجلد data/logwatch/ الخاص بالمشروع بصيغة .txt. يعرض المونيتور آخر تقرير والأرشيف.
لا يتطلب مراقب الشبكة أي تثبيت — فهو صفحة مدمجة في اللوحة. تعرض حالة الشبكة للسيرفر من مصادر محلية:
/proc/net/dev؛ip؛ss؛journalctl -k.تعمل المصادر الثلاثة الأولى دون sudo، لذا تظهر الواجهات وحركة البيانات والاتصالات والمنافذ فوراً. أما كتلة «أحداث النواة» فتستخدم journalctl -k — وتُقرأ عبر مجموعة systemd-journal («إعداد sudo»، البند 2)، ولا حاجة إلى sudo. للتحقق من أن كل شيء متاح لمستخدم الويب:
UFW BLOCK — فهي في صفحتَي «جدار الحماية UFW» و«خريطة الهجمات». الكتلة الفارغة مع علامة خضراء = لم تحدث أعطال شبكة خلال اليوم.
تعرض الصفحة المدمجة ثلاثة أشياء:
df)؛ يحمرّ الشريط عند ≥90%؛lsblk)، الحقيقية فقط (loop/snap مخفية)؛smartctl).تعمل المساحة وقائمة الأجهزة فورًا دون إعداد. أما SMART فيتطلب حزمة smartmontools. لا يملك عملية الويب وصولًا مباشرًا إلى أجهزة الأقراص، لذلك تُلتقط بيانات SMART عبر cron إلى الملف data/disk/smart.txt، وتقرأه لوحة التحكم.
المهمة تُضاف إلى كرون الجذر (sudo crontab -e). يوضع الغلاف الجاهز smart-scan.sh في /usr/local/bin/ (chmod +x؛ راجع ملخص مهام cron) ويكتب بنفسه في data/disk/ الخاص باللوحة.
يجد الغلاف smart-scan.sh بنفسه مجلد data/ الخاص باللوحة — لا حاجة لكتابة المسار. وفي الداخل يستبعد lsblk -e7,11 أقراص loop/cdrom.
تعرض الصفحة سِجل حِمل السيرفر خلال آخر 24 ساعة — Load Average، انشغال CPU وانتظار I/O، وRAM/Swap، وحركة الشبكة (استقبال/إرسال)، وI/O القرص (قراءة/كتابة)، وامتلاء القرص وinodes، وواصفات الملفات المفتوحة واتصالات MySQL، إضافةً إلى العدد الحالي لاتصالات TCP والعمليات.
يجمع البيانات cron/collect_metrics.php — كل 5 دقائق يكتب لقطة «خام» واحدة للعدّادات (/proc/loadavg، /proc/meminfo، /proc/stat، /proc/net/dev، /proc/diskstats، df/df -i، /proc/sys/fs/file-nr، SHOW GLOBAL STATUS LIKE 'Threads_connected') في جدول قاعدة البيانات system_metrics؛ أما النِسب والسرعات فتحسبها الصفحة بنفسها من الفرق بين اللقطتين المتجاورتين (امتلاء القرص/inodes/الواصفات/اتصالات MySQL قيمٌ لحظية، بلا إعادة حساب). لا حاجة إلى Sudo — تُقرأ المصادر دون صلاحيات root. تُحذف النقاط الأقدم من 24 ساعة تلقائيًا عند كل كتابة.
الغلاف collect-metrics-all.sh (انظر ملخص مهام cron) يعثر بنفسه على جميع نُسخ اللوحة المثبَّتة على السيرفر ويشغّل cron/collect_metrics.php لكلٍّ منها باسم مالك الموقع.
تنبيهات الحِمل (قسم «الإعدادات» ← «تنبيهات الحِمل») — عند تجاوز عتبة CPU/RAM/القرص/inodes ترسل اللوحة إشعارًا إلى Telegram/البريد (نفس القنوات المستخدمة في التقرير اليومي — لا حاجة لتفعيلها للتنبيهات على حدة)، وإشعارًا آخر عند عودة المقياس إلى الوضع الطبيعي. ولا تُكرِّر الإزعاج أثناء بقاء العتبة متجاوَزة: يصل الإشعار التالي فقط بعد دورة «عاد إلى الطبيعي ← تجاوز مجددًا».
collect_metrics.php نفسه عند كل تشغيل (كل 5 دقائق) — لا حاجة إلى cron منفصل. تُحفظ حالة «تم التنبيه / لم يتم بعد» في data/alerts_state.json، والعتبات في إعدادات اللوحة.
تحدّد صفحة «خريطة الهجمات» الدولة من عنوان IP باستخدام الأمر geoiplookup. بدون حزمة GeoIP لن تُحدّد الدول ولن تظهر النقاط على الخريطة:
/usr/share/GeoIP/GeoIP.dat، وتُخزَّن النتائج مؤقتًا في tmp/geoip_cache.json. أمّا الخريطة نفسها (Leaflet + بلاطات OpenStreetMap) فتُحمَّل في المتصفح — لذا يلزم اتصال بالإنترنت على الجهاز الذي فُتحت فيه اللوحة.
بطاقتان مدمجتان في لوحة التحكم تعرضان لا حالة «تشغيل/إيقاف» الأداة، بل مستوى الحماية الفعلي للسيرفر. لا تتطلبان أي إعداد، وتُقرآن محليًا دون sudo.
التعرض الخارجي — عدد الخدمات التي تستمع على كل الواجهات (0.0.0.0/[::]) والمتاحة من الخارج. يُبرز باللون الأحمر إذا كانت قواعد البيانات أو التخزين المؤقت مكشوفة للخارج (MySQL، PostgreSQL، Redis، MongoDB، Memcached، Elasticsearch) — فهذه ثغرة مباشرة (−10 من تقييم الأمان). المصدر: ss -tuln.
127.0.0.1 (bind-address في إعداد MySQL/PostgreSQL، وbind 127.0.0.1 في Redis) أو أغلق المنفذ في UFW.
127.0.0.1 (loopback) مرئية للسيرفر نفسه فقط — لا يمكن الوصول إليها من الخارج حتى لو كان المنفذ «مفتوحًا». لذلك فإن Postfix على المنفذ 25 المرتبط بـ loopback آمن: يضبط الإعداد التلقائي inet_interfaces = loopback-only (بالإضافة إلى smtpd_banner محايد — يعالج ملاحظة Lynis MAIL-8818 حول كشف الإصدار). بطاقة «التعرض الخارجي» تحتسب كمكشوف للخارج فقط ما يستمع على 0.0.0.0/[::]؛ أما خدمات loopback فلا تُحتسب.
/etc/postfix/main.cf اضبط smtpd_banner = $myhostname ESMTP (دون الإصدار ونظام التشغيل) وinet_interfaces = loopback-only، ثم sudo systemctl restart postfix.
تحديثات الأمان — عدد الرقع الأمنية التي تنتظر التثبيت وما إذا كانت هناك حاجة لإعادة التشغيل بعد تحديث النواة (−5 من تقييم الأمان عند وجود رقع). المصدر: /usr/lib/update-notifier/apt-check، والملف /var/run/reboot-required. القائمة التفصيلية — في صفحة «تحديثات الأمان».
update-notifier-common). إذا لم يكن apt-check موجودًا — يحتسب المونيتور الرقع عبر apt-get -s upgrade.
التحديثات الأمنية التلقائية (unattended-upgrades) — في صفحة «تحديثات الأمان» تعرض بطاقة منفصلة ما إذا كان التثبيت التلقائي للرقع الأمنية مفعّلًا ومتى جرى تشغيله آخر مرة. لا حاجة إلى sudo — تُقرأ الحالة عبر apt-config dump.
النسخ الاحتياطي هو التأمين الأساسي: فقدان البيانات أخطر من أي اختراق. تحتاج شيئين — نسخة احتياطية للسيرفر/المواقع ونسخة منفصلة لقاعدة بيانات اللوحة (فيها المستخدمون ومفاتيح WebAuthn والإعدادات والترخيص).
الخيار A — HestiaCP: تبويب Backup لدى المستخدم ← زر إنشاء نسخة احتياطية (أو حسب جدول في إعدادات السيرفر). تشمل النسخة المواقع وقواعد بياناتها.
الخيار B — يدويًا (cron): تفريغ قاعدة البيانات + أرشفة مجلد data/ الخاص باللوحة:
الترقية إلى إصدار جديد. أنشئ نسخة احتياطية أولاً. ثم أعد رفع ملفات الكود مع الحفاظ على بياناتك:
public/ وincludes/ وassets/ وcron/ وdatabase/، إضافةً إلى .htaccess الجذري (وحدة التحكم الأمامية — لا يجوز إبقاء التوجيه من الإصدار القديم) وmanifest.json وsw.js؛config.php (بيانات قاعدة البيانات) وdata/ (التقارير) وlogs/ وtmp/ (الجلسات والذاكرة المؤقتة).SSH_FX_PERMISSION_DENIED — Permission denied. ملفات اللوحة مملوكة لـwww-data (هكذا ضُبطت عند التثبيت)، بينما يتصل عميل SFTP بحسابك أنت الذي لا يملك صلاحية الكتابة. منح www-data ملكية اللوحة كاملةً «كي تعمل» هو تحديدًا ما يؤدي إلى هذا الخطأ؛ في الأسفل ثلاث طرق، كلٌّ منها يحل المشكلة.
data/ (التقارير) وtmp/ (الجلسات والذاكرة المؤقتة) وlogs/؛ وتبقى مملوكة لـwww-data. أما البقية فهي كود، ولا يحتاجه سيرفر الويب إلا للقراءة التي توفّرها مجموعة www-data بصلاحيات 644. ميزة جانبية: مع ثغرة في PHP لم يعد بالإمكان استبدال ملفات اللوحة. على لوحات الاستضافة (HestiaCP وما شابهها) لا حاجة للخيار A: فملفات الموقع مملوكة أصلاً للحساب الذي تدخل به عبر SFTP، وسيرفر الويب يقرؤها عبر المجموعة.
chmod لاحق على الملفات يعيد ضبط قناع ACL، فيختفي الوصول بصمت. إذا اصطدم الرفع من جديد بـPermission denied بعد «ترتيب الصلاحيات» — كرّر أمرَي setfacl كليهما.
2 في الخيار C هو setgid: الملفات المرفوعة عبر SFTP تبقى في مجموعة www-data، وإلا لن تستطيع اللوحة استبدالها. بعد الخيار C أعد الاتصال في FileZilla — المجموعة الجديدة لا تسري إلا عند تسجيل دخول جديد. التحقق: id deploy (يجب أن تظهر مجموعة www-data) وls -ld /path/to/monitor (drwxrwsr-x — حرف s يعني أن setgid مفعَّل).
النقل إلى سيرفر آخر:
config.php وdata/.mysqldump على القديم ← استيراد على الجديد؛ وصحّح بيانات قاعدة البيانات في config.php.adm، ومهام cron.إذا تعذّر عليك تسجيل الدخول — يمكن إصلاح كل شيء مباشرةً في قاعدة البيانات من السيرفر. افتح قاعدة البيانات (الاسم من config.php):
فقدان مفتاح WebAuthn (تعذّر اجتياز العامل الثاني) — عطّل 2FA، وسجّل الدخول بكلمة المرور، ثم سجّل مفتاحًا جديدًا:
نسيان كلمة المرور — عيّن تجزئة جديدة (أنشئها على السيرفر وضعها هنا):
حظرت نفسك بمرشّح IP — عطّل القيد:
sudo mysql على السيرفر، أو phpMyAdmin / قسم قاعدة البيانات في لوحة الاستضافة. بعد الاستعادة، أعد تفعيل WebAuthn ومرشّح IP.
ملخص المهام موجود في cron الخاص بـ root للسيرفر (تُضاف عبر sudo crontab -e). أبقِ فقط أسطر الأدوات التي تستخدمها؛ وعدّل المسارات لتناسب سيرفرك.
sudo crontab -l وأن خدمة cron فعّالة.
TIMEZONE من config.php. الثابت TIMEZONE يؤثّر على PHP فقط (كيف تعرض اللوحة التواريخ)، لكن خادم cron يُشغّل المهام حسب توقيت نظام التشغيل. إن لم تتطابق منطقة السيرفر مع منطقتك، سيصلك تقرير «08:00» في وقت مختلف. مثال: السيرفر في منطقة أخرى (Europe/Berlin، UTC+2)، وأنت في الرياض (UTC+3) → سيصلك تقرير «08:00» في التاسعة صباحًا بتوقيتك. تحقّق ووحّد منطقة النظام مع منطقتك عند الحاجة:
0 8 * * * عند الساعة 08:00 بالتوقيت المحلي. وإلا لاضطررت إلى إزاحة cron نفسه، لكن مع التحول بين التوقيت الشتوي/الصيفي ستختلّ الإزاحة مجددًا — لذا الأصح ضبط منطقة النظام.
crontab.txt) في مجلد system/ بجوار المشروع، خارج public_html. هذه ليست جزءًا من الموقع — لا حاجة لرفعها إلى جذر الويب؛ ضعها على السيرفر في المسارات النظامية (كما في crontab أعلاه):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — يُشغّل lynis audit system، وأثناء الفحص يضع العلامة /tmp/lynis-running وينسخ lynis-report.dat إلى data/lynis/ في اللوحة؛logwatch_daily.sh → /usr/local/bin/ (chmod +x) — يُنشئ تقرير Logwatch اليومي (sshd, fail2ban, sudo, postfix) في data/logwatch/؛smart-scan.sh → /usr/local/bin/ (chmod +x) — يلتقط حالة الأقراص (smartctl) في data/disk/؛debsums-scan.sh → /usr/local/bin/ (chmod +x) — يتحقق من سلامة الحزم (debsums) في data/debsums/؛clamav-scan.sh → /usr/local/bin/ (chmod +x) — فحص ClamAV للمسارات الخطرة (web, home, temp)؛ يكتب الملخص في /var/log/clamav/scan.log حيث تقرأه صفحة ClamAV (سطر 01:30 في crontab أعلاه)؛load-ipsum.sh → /usr/local/bin/ (chmod +x) — يحدّث مجموعة ipset باسم ipsum (level 1) في مكانها، دون كسر قواعد جدار الحماية الفعّالة (سطر 04:00 في crontab أعلاه)؛daily-report-all.sh → /usr/local/bin/ (chmod +x) — يُشغّل تقرير cron/daily_report.php الخاص باللوحة (سطر 08:00 في crontab أعلاه)؛daily_report.php — مضمّن أصلًا في اللوحة (cron/daily_report.php)، ويُشغّل عبر daily-report-all.sh، لا حاجة لوضعه منفصلًا؛collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — يُشغّل cron/collect_metrics.php الخاص باللوحة (صفحة «الأداء»، سطر */5 في crontab أعلاه)؛ collect_metrics.php مضمّن أصلًا في اللوحة، لا حاجة لوضعه منفصلًا؛crontab.txt (system/cron/) — نموذج للمهام؛ أضِف الأسطر التي تحتاجها عبر sudo crontab -e./usr/local/bin/. لا يمكن الكتابة إليه مباشرةً من FileZilla — فالدليل ملك لـ root، وسيحصل عميل SFTP على SSH_FX_PERMISSION_DENIED. الترتيب كالتالي: أولًا ارفع الملف إلى /tmp (يكتب إليه الجميع)، ثم انقله إلى مكانه بأمر واحد:
/tmp في جذر السيرفر — لا /var/tmp ولا tmp/ داخل اللوحة نفسها (الأخير ملك لـ www-data ومغلق أمام مستخدمك). في شجرة FileZilla يكون /tmp فرعًا في المستوى الأعلى، بجوار var، لا داخله.
/usr/local/bin/، والسجل في /var/log/arciveo-cron.log) — لا حاجة لفعل أي شيء يدويًا.
/home/*/web/*/public_html و/var/www/*، وتضع التقارير في data/ الخاص بها. إن كانت اللوحة في مسار آخر — أضِفه إلى سطر for app in … داخل السكربتات، وإلا فلن تصل تقارير Lynis/SMART/debsums/Logwatch إلى اللوحة.
logs/cron.log يُنشئه أولًا cron الخاص بـ root — فيصبح ملكًا لـ root، ولن يتمكن تبويب «سجل cron» في اللوحة من قراءته أو تفريغه. أنشئ الملف مسبقًا باسم مستخدم الويب (مالك دليل الموقع؛ في HestiaCP هو الحساب، مثلًا admin) — عندئذٍ سيكتفي cron الخاص بـ root بالإلحاق دون تغيير المالك:
stat -c %U /path/to/monitor.
sudo crontab -e)، وإلا فستُنفّذ مرتين.
sudo crontab عاريًا (فسيكون ذلك تصعيدًا مباشرًا إلى root لأي شخص يحصل على وصول لجلسة اللوحة)، بل سكربت ضيّق بأمرين (list/set) يمسّ كتلته الخاصة فقط بين التعليقات الخدمية. ثبّته مرة واحدة:
www-data — تحقّق من المستخدم الذي يعمل به مجمّع PHP-FPM للموقع (ps -o user= -C php-fpm)، وضعه في سطر sudoers.
public/crontab_monitor.php عبر FTP/SFTP باسم مستخدم نظام مختلف (مثلًا root) عن بقية ملفات الموقع، فلن يتمكن سيرفر الويب من قراءته. قارن المالك والصلاحيات مع ملف مجاور ووحّدهما:
يكتشف المونيتور وجود الأدوات عبر dpkg-query — قاعدة حزم APT. إذا ثُبّتت الأداة بطريقة أخرى غير apt (يدويًا، أو من snap، أو من المصدر)، فلن يراها dpkg.
الخطأ 500 — تحقق من سجلات PHP وnginx والمونيتور نفسه:
www-data بل تحت حساب المستخدم (مثلاً admin — مالك دليل الموقع). كل قواعد sudo والعضوية في المجموعات (adm، systemd-journal) يجب إسنادها لهذا المستخدم، وإلا ستُظهر الوحدات «غير نشط / 0» رغم عمل الخدمات. لمعرفة مستخدم PHP الفعلي: ps -o user= -C php-fpm | sort -u أو مالك دليل الموقع stat -c '%U' /path/to/monitor. وبعدها استبدله بـ www-data في كل الأوامر أدناه. التثبيت التلقائي يحدد مستخدم الويب بنفسه ويسند له sudoers.
البيانات لا تظهر — في الغالب هي صلاحيات sudo غير مُعرّفة. تحقق من الأمر المحدد باسم مستخدم الويب (استبدل www-data بمستخدمك). العلم -n = بدون كلمة مرور، مثل PHP — إذا طُلبت كلمة مرور، فهذا يعني عدم وجود قاعدة في sudoers:
sudo aa-status في الطرفية يعرض الملفات الشخصية، بينما صفحة «AppArmor» تُظهر «غير نشط»). السبب: مستخدم الويب لا يملك صلاحية sudo على أمر هذه الوحدة. تحقق منه من القائمة أعلاه: إذا طُلبت كلمة مرور — أضف السطر الناقص إلى /etc/sudoers.d/monitor («إعداد sudo»). أوامر «جديدة» شائعة: /usr/sbin/aa-status (MAC)، /usr/sbin/psad --Status (PSAD).
apache2ctl أو ausearch أو aa-status أو ss، أو أن مستخدم الويب ليس في مجموعتَي adm/systemd-journal (منهما تُقرأ سجلات fail2ban/auth/modsec وjournalctl — Falco وأحداث النواة).
العرض: تتوفر بيانات على السيرفر (تظهر عبر shell)، لكن الصفحة تعرض «لا توجد بيانات» أو حالة غير صحيحة — مثلاً يكتب AIDE «غير مهيأة» رغم إنشاء القاعدة.
السبب هو open_basedir: تقيّد كثير من اللوحات وشركات الاستضافة تجمّع PHP-FPM بمجلد الدومين، لذا تُحظر دوال PHP مثل file_exists() وfile_get_contents() وfilemtime() على المسارات النظامية (/var/lib/aide، /var/log، /proc…). يتجاوز المونيتور ذلك بقراءة هذه المسارات عبر أوامر النظام القياسية (cat، test، stat).
open_basedir. الحل الصحيح هو القراءة عبر أوامر النظام (مطبَّق فعلاً لـ AIDE ومونيتور الشبكة). لا داعي لتوسيع open_basedir ليشمل /var و/proc، وهو أقل أماناً.
يتحقق المونيتور من الشهادات عبر الاتصال بالنطاقات مباشرةً على المنفذ 443. إذا كان النطاق غير متاح من السيرفر نفسه أو كان المنفذ محجوبًا بالجدار الناري، فلن ينجح التحقق.
/etc/nginx/sites-enabled/، /etc/nginx/conf.d/) وApache (/etc/apache2/sites-enabled/) بالإضافة إلى المضيف الحالي من HTTP_HOST.
يتصل المونيتور بـ MySQL بمستخدم من config.php لا يملك سوى صلاحية الوصول إلى قاعدته. تُظهر MySQL في information_schema القواعد ذات الصلاحيات فقط — لذلك لا تظهر البقية.
لكي يرى المونيتور كل قواعد البيانات، امنح هذا المستخدم صلاحية القراءة فقط (مرة واحدة من root؛ ضع اسم المستخدم من config.php):
sudo mysql: تُجلب قائمة القواعد عبر اتصال PDO الخاص بها.
يتطلب PostgreSQL صلاحية على مستوى المستخدم postgres، وهي غير متوفرة لمستخدم الويب في اللوحة. فتح sudo psql واسع من PHP غير آمن — بدلاً من ذلك تستدعي اللوحة غلافًا ضيقًا بلا معاملات يطبع فقط الإصدار وعدد الاتصالات وقائمة قواعد البيانات مع أحجامها. أنشئه:
monitor-pgstat من sudoers (الخطوة 13 من التثبيت اليدوي) ولا تنشئ السكربت نفسه: ستبقى بطاقة PostgreSQL غير نشطة فقط.
تُظهر لوحة التحكم ما يحدث؛ وفيما يلي ما يجب فعله في الحالات النمطية. المبدأ العام: لا تُصب بالذعر، قارن الأمر بالنشاط المشروع (أفعالك، التحديثات، النسخ الاحتياطية)، وتعامل معه حسب خطورته.
ignoreip./etc، خارج /usr/share) — احتمال تلاعب. تحقق من الحزمة: debsums PACKAGE_NAME، وعند الشك أعِد تثبيتها (apt install --reinstall).127.0.0.1 أو أغلق المنفذ في UFW. هذه ثغرة حقيقية.certbot renew أو الإعدادات في لوحة التحكم).sudo apt update && sudo apt upgrade؛ وبعد تحديث النواة أعِد تشغيل السيرفر.