تحصين خادم VPS خلال الساعة الأولى

راقب journalctl -u ssh على خادم متصل بالإنترنت منذ ساعة واحدة، وستجد أن الكمية مثيرة للقلق في أول مرة تراها. لكنها لا ينبغي أن تكون كذلك. فما تراه هو الضجيج الخلفي للإنترنت: مجموعة من عمليات المسح، بعضها أكاديمي وبعضها تجاري وبعضها إجرامي، تُعدّد فضاء عناوين IPv4 بأكمله باستمرار وتُسلّم النتائج إلى برامج تخمين بيانات الاعتماد. عنوانك تمّ الوصول إليه لأنه موجود، بترتيب رقمي، وسيُصار إلى الوصول إليه مجددًا خلال ساعات قليلة مهما فعلت.

هذا يُغيّر شكل المشكلة بطريقة مفيدة. أنت لا تُدافع ضد خصم اختارك بعينك وسيتكيّف مع أفعالك؛ بل تُدافع ضد نص برمجي له ذخيرة ثابتة — root وadmin وubuntu وtest وgit وoracle وpostgres، وعشرون ألف كلمة مرور ظهرت في تسريبات البيانات. لا صبر له، ولا إبداع، ولا اهتمام بخادم لا يستجيب من أول محاولة. تعطيل المصادقة بكلمة المرور لا يُبطئ هذا المهاجم. بل يُخرجه من اللعبة كليًا.

هناك تفصيلان يستحقان المعرفة. أولاً، IPv6 أهدأ بشكل كبير، لأن مساحة /64 لا يمكن مسحها بالكامل — لكن بمجرد أن يصبح سجل AAAA الخاص بك عامًا، أو يظهر عنوان خادمك في ترويسة بريد إلكتروني أو في سجل شفافية شهادات (certificate-transparency)، ينتهي هذا الهدوء. لا تعامل IPv6 أبدًا كمخبأ؛ بل عامله كَكومة قش أصغر. ثانيًا، لعنوان IPv4 ماضٍ. كان له مستأجر قبلك، وإذا كان ذلك المستأجر قد شغّل خادم بريد بشكل سيئ أو استضاف شيئًا أُدرج في قوائم الحظر، فإنك ترث تلك السمعة إلى أن تتلاشى. إن كان البريد الإلكتروني يهمك، تحقق من العنوان في قوائم الحظر المعتادة قبل أن تبني عليه — فهذا فحص من خمس دقائق يوفر عليك أسبوعين من تصحيح مشكلات تسليم البريد.

يبدأ كل اختراق حقيقي تقريبًا لخادم صغير من أحد موضعين: كلمة مرور كان بالإمكان تخمينها، أو خدمة كانت تستمع على منفذ ولم يكن ينبغي لها ذلك. الإصلاحان المقابلان هما PasswordAuthentication no وجدار حماية بسياسة افتراضية drop. لا بريق فيهما، ويستغرقان معًا خمس عشرة دقيقة، وقيمتهما تفوق كل ضابط آخر في هذه الصفحة مجتمعًا.

السبب بنيوي لا إحصائي. فكلاهما مغلق افتراضيًا — أي أنهما يفشلان في اتجاه الأمان. لا يمكن اختراق sshd بمفاتيح فقط بهجوم القوة الغاشمة مهما كان عدد المحاولات، لأنه لا يوجد مسار في الكود يقبل كلمة مرور أصلاً. وجدار الحماية ذو الرفض الافتراضي يحمي خدمات لم تُثبّتها بعد، بما فيها قاعدة البيانات التي ستضيفها بعد ثلاثة أشهر وتنسى ربطها بـ localhost. أما كل ما تبقى في قائمة تحقق التحصين فهو تعداد لأشياء سيئة: قائمة بأمور محددة يجب إيقافها، وهي لن تكون أكمل من القائمة نفسها.

لذا إن كنت ستقرأ قسمًا واحدًا فقط ثم تُغلق الصفحة، اقرأ هذا القسم، ونفّذ الخطوات من 2 إلى 5 أدناه، واعتبر أن ساعتك أُنفقت في مكانها الصحيح. أما الباقي فهو مفيد فعلاً لكنه ثانوي فعلاً.

على Debian 13 وUbuntu 24.04، يبدأ ملف /etc/ssh/sshd_config بسطر Include /etc/ssh/sshd_config.d/*.conf، وتأتي صور الاستضافة السحابية بملف داخل ذلك المجلد — غالبًا 50-cloud-init.conf — يضبط PasswordAuthentication بالفعل. تعديل الملف الرئيسي وإضافة توجيهاتك الخاصة في نهايته يبدو أمرًا طبيعيًا، لكنه ينتج إعدادًا لا يفعل ما يقوله ظاهريًا.

القاعدة التي تُفاجئ الجميع تقريبًا بخصوص sshd هي: لكل كلمة مفتاحية، تفوز أول قيمة يتم الحصول عليها. وهذا عكس تمامًا كل نظام دمج إعدادات آخر استخدمته على الأرجح. سطر Include يقع قرب بداية الملف الرئيسي، لذا يُقرأ أي ملف إضافي قبل متن sshd_config — وبين الملفات الإضافية، الترتيب الأبجدي هو الفيصل. ملف باسم 10-hardening.conf يتغلب على 50-cloud-init.conf. أما ملف باسم 60-hardening.conf فيخسر أمامه، بصمت، ولن تعرف ذلك من عملية إعادة تشغيل تُبلغ عن نجاحها.

ولهذا السبب لا تثق أبدًا بالملف الذي كتبته للتو. اسأل الخدمة (daemon) عمّا استقرت عليه فعليًا:

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

يطبع sshd -T الإعداد الفعلي بعد حل كل الملفات المضمّنة والتجاوزات والقيم الافتراضية. إن كان الناتج يقول passwordauthentication yes، فالمصادقة بكلمة المرور مفعّلة، بغض النظر عمّا يدّعيه أي ملف على القرص. لا شيء آخر يُعتبر تحققًا فعليًا.

الفخ الثاني من العائلة نفسها. يبدأ Ubuntu 24.04 تشغيل sshd عبر تفعيل بالمقبس (socket activation): يملك ssh.socket المنفذ الذي يستمع عليه النظام، ويتم تجاهل Port في sshd_config كليًا. تحقق من ذلك بـ systemctl is-enabled ssh.socket؛ فإن كان مفعّلاً وأردت منفذًا مختلفًا، غيّره عبر systemctl edit ssh.socket وتجاوز بـ ListenStream= — وليس في sshd_config، حيث سيبدو الإعداد صحيحًا دون أن يُحدث أي أثر.

لنكن صادقين بخصوص هذه النقطة، لأن الإنترنت ليس كذلك. نقل sshd إلى المنفذ 2222 أو 47000 لا يُوقف أي مهاجم كفء. فحص TCP كامل لمضيف واحد يستغرق ثوانٍ، والخدمة تُعلن عن نفسها في اللافتة (banner)، وأي شخص قرر مهاجمتك أنت تحديدًا سيجدها قبل أن ينهي فنجان قهوته.

ما يفعله هذا الإجراء فعلاً هو تقليص سجل المصادقة لديك بنحو خمسة وتسعين بالمئة، ولهذا قيمة حقيقية: إنه الفرق بين سجلات تتصفحها بسرعة وسجلات تقرأها فعلاً. إشارة يمكنك رؤيتها أفضل من إشارة دفنتها. إن كنت تراقب أي شيء إطلاقًا، فملف auth.log هادئ هو أرخص وسيلة لجعل أي خلل ظاهرًا.

التكاليف صغيرة لكنها حقيقية، ولهذا نصفه بأنه اختياري لا مُوصى به. ستنسى المنفذ عندما تعود بعد ثمانية أشهر. ومن الناحية النظرية، يمكن لمنفذ غير قياسي أعلى من 1024 أن تستولي عليه عملية بلا صلاحيات إن توقف sshd عن الاستماع لأي سبب. كما أن جدران الحماية الصارمة للاتصالات الصادرة في شبكات بعض العملاء تحظر المنافذ غير المألوفة، لذا ستعجز أحيانًا عن الوصول إلى خادمك من مكتب أو فندق. وعلى نظام مُفعّل بالمقبس (socket activation) يجب تغييره في المكان الصحيح، كما ورد في القسم السابق. افعلها إن كانت السجلات الهادئة تهمك. لكن لا تفعلها ثم تشعر بالأمان، ولا تفعلها أبدًا بديلاً عن الاعتماد على المفاتيح فقط.

جدار الحماية الذي يُعدّد ما يجب حظره هو مجرد نظام أرشفة. أما جدار الحماية الذي يُعدّد ما يُسمح به فهو ضابط أمني حقيقي. هذا الفرق هو اللعبة بأكملها، لأن النوع الثاني وحده يغطي الخدمة التي ستُثبّتها الشهر المقبل، ومنفذ التصحيح (debug) الذي فتحته يوم جمعة، والحاوية التي قررت كشف نفسها للعالم.

على منصتنا لديك طبقتان مستقلتان. مرشّح الحافة (edge filter) اختياري، يُضبط لكل خادم من لوحة التحكم ويُطبَّق على مستوى المضيف الفعلي (hypervisor)، بحيث لا تصل الحركة المحظورة إلى خادمك الافتراضي أصلاً — وهو مفيد لقواعد الطبقة الرابعة التي تريد تطبيقها قبل أن تُنفق نواة نظامك دورة معالجة عليها، ولإبقاء خادم افتراضي مُخترَق بعيدًا عن متناول أي أحد أثناء عملك عليه. أما جدار حماية الخادم الافتراضي فهو ملكك بالكامل: nftables أو iptables أو pf أو أي ما تأتي به صورتك. نحن لا نلمسه إطلاقًا. استخدم الطبقتين إن كان الخادم مهمًا؛ واستخدم الثانية على الأقل دائمًا.

هناك أمران في مجموعة القواعد بالخطوة 5 يستحقان الشرح، لأن معظم مجموعات القواعد المنسوخة من مصادر أخرى تُخطئ فيهما. لا تُسقط كل حركة ICMP. يبدو ذلك مرتبًا لكنه يُعطّل اكتشاف path-MTU، ما ينتج عنه أسوأ نوع من الأعطال: الطلبات الصغيرة تعمل، والاستجابات الكبيرة تتجمد، ولا شيء في سجلاتك يُشير إلى جدار الحماية. اقبل على الأقل destination-unreachable وtime-exceeded وparameter-problem. لا تُصفِّ ICMPv6 حسب النوع ما لم تكن تعرف القائمة تمامًا. يعتمد IPv6 على ICMPv6 لاكتشاف الجيران والإعلان عن الموجّهات؛ احظره بشكل واسع وسيموت اتصال IPv6 لديك بطريقة تبدو وكأنها مشكلة توجيه. قبول كل حركة ICMPv6 على خادم واحد مقايضة معقولة، وهذا بالضبط ما تفعله مجموعة القواعد أدناه.

تحذير واحد قبل تشغيل flush ruleset: إن كان Docker مُثبّتًا، فهذا السطر يزيل قواعد NAT والتصفية التي كتبها Docker، وتتوقف شبكة الحاويات إلى أن تُعيدها systemctl restart docker. حمّل مجموعة قواعدك أولاً، ثم أعد تشغيل Docker ثانيًا، واقرأ القسم التالي قبل أن تنشر أي منفذ حاوية واحد.

اسأل الخادم عمّا يستمع عليه فعلاً. لا عمّا تظن أنك ثبّته — بل عمّا هو مرتبط بمنفذ الآن:

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

كل ما ينجو من هذا الفلتر يمكن الوصول إليه من مكان آخر غير الخادم نفسه. على صورة قياسية، الاكتشافات المعتادة هي rpcbind على المنفذ 111 (لا شيء تُشغّله يحتاجه)، ومستمع exim4 متبقٍّ من التثبيت الأساسي، وكعب systemd-resolved غير ضار طالما بقي على loopback لكنه يتحول إلى مُحلِّل مفتوح (open resolver) إن لم يكن كذلك. أما الخطيرة فتصل لاحقًا، مع برمجيات ثبّتها أنت عن قصد: PostgreSQL على 0.0.0.0:5432 لأن دليلاً تعليميًا قال بتعديل listen_addresses، وRedis بلا كلمة مرور لأن Redis لم يكن له كلمة مرور افتراضية طوال معظم تاريخه، وعقدة Elasticsearch، ومُصدِّر Prometheus، ودفتر Jupyter. كل واحدة من هذه كانت الخطوة الأولى في اختراق حقيقي مرات عديدة.

وهنا الفخ الذي يقع فيه الحذرون. لا يطلب Docker الإذن من جدار حمايتك. فعندما تكتب -p 5432:5432، يُدرج Docker قواعد DNAT في سلسلة PREROUTING من جدول nat، والتي تُقيّمها النواة قبل أن تصل الحزمة إلى سلسلة input لديك أصلاً؛ ثم تُحوَّل الحركة إلى الحاوية. سياسة الرفض الافتراضية لسلسلة input لا تُستشار إطلاقًا، ويُظهر ufw status أن المنفذ مغلق، بينما تكون قاعدة البيانات على الإنترنت العام. هذا سلوك موثّق لـ Docker، وهو على هذا الحال منذ عقد كامل، وقد كشف عددًا هائلاً من قواعد البيانات.

الإصلاح سطر واحد، وهو العادة التي تستحق أن تُبنى:

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

وأخيرًا، احصل على رأي خارجي. فحص المنافذ من داخل الخادم يُخبرك بما تظنه النواة؛ أما الفحص من مكان آخر فيُخبرك بما يراه العالم، وهو الرقم الوحيد المهم. شغّل nmap -Pn -p- <your-ip> من حاسوبك المحمول، لا من الخادم نفسه، وقارن النتيجة بالقائمة التي كنت تتوقعها.

النافذة الزمنية التي تُعرّض الخوادم الصغيرة للاختراق ليست ثغرة اليوم صفر. بل هي الأسابيع الأربعة بين إعلان ثغرة CVE للعموم مع إثبات مفهوم عملي، وبين المرة التالية التي تُصادف فيها تسجيل الدخول. أدوات الهجوم تستوعب أي خلل عن بُعد جديد خلال أيام؛ والخادم الذي تُصلحه «عندما تجد وقتًا لذلك» يبقى معرّضًا طوال تلك الفترة بأكملها، وكل مُشغّل صادق يعرف كم تطول تلك الفترة فعلاً.

الاعتراض على التحديثات التلقائية هو الخوف من كسر شيء ما، وهذا اعتراض يستحق أن يُؤخذ بجدية — ثم أن يُحصر في نطاقه. اقصر الأتمتة على حزمة الأمان (security) من توزيعتك، حيث يقوم القائمون على الصيانة بترحيل الإصلاحات إلى النسخة المُعبّأة نفسها بدلاً من إصدار إصدارات جديدة من المنبع. تحديث أمني على Debian لحزمة openssl هو بناء مُصحح لنفس النسخة التي تُشغّلها بالفعل؛ خطر أن يُغيّر سلوكها أصغر بكثير من خطر ترك ثغرة عن بُعد مفتوحة لشهر كامل. أما ترقيات الميزات فتبقى يدوية، حيث ينبغي أن تكون.

الجزء الذي يتجاهله الناس هو إعادة التشغيل. مكتبة libssl مُصححة على القرص لا تفيد بشيء العملية التي حمّلت النسخة القديمة عند الإقلاع، وتحديث النواة (kernel) لا يفعل شيئًا إطلاقًا حتى تُقلع بها. إما أن تقبل بإعادة تشغيل غير مراقَبة في نافذة زمنية تختارها أنت، أو ثبّت needrestart ودعه يُخبرك بالخدمات التي لا تزال تعمل بمكتبات محذوفة — لكن افعل أحد الأمرين. عبارة «التحديثات التلقائية مفعّلة» بينما يقرأ uptime 340 يومًا هي وهم مريح، وهو الوهم الأكثر شيوعًا الذي نراه.

يقرأ fail2ban سجلاتك، ويلاحظ الإخفاقات المتكررة من عنوان معيّن، ويحظره لفترة. يفعل CrowdSec الشيء نفسه، لكنه يُشارك الأحكام عبر شبكة من المشاركين، بحيث يمكنك حظر عنوان أساء التصرف في مكان آخر قبل أن يصل إليك. كلاهما برنامج جيد. لكن لا واحد منهما يفعل ما يظنه معظم الناس على خادم SSH يعتمد على المفاتيح فقط.

بمجرد أن يكون PasswordAuthentication مضبوطًا على no، لا يمكن لهجوم القوة الغاشمة على SSH أن ينجح. ليس «من غير المرجح أن ينجح» — بل لا يوجد مسار كود يسمح بذلك أصلاً. لذا فإن حظر عنوان بعد خمسة إخفاقات لا يمنع شيئًا؛ بل يُقلّل حجم السجلات وقدرًا ضئيلاً من استهلاك المعالج. هذه فائدة حقيقية، لكنها ليست فائدة أمنية، والمقايضة ليست مجانية: فقفص (jail) مكتوب بشكل سيئ يراقب السجل الخطأ قد أقفل الباب في وجه مدراء أنظمة أكثر مما أقفله في وجه مهاجمين.

المكان الذي تستحق فيه هذه الأدوات مكانتها فعلاً هو طبقة أعلى، على الخدمات التي تكشفها فعلاً: نموذج تسجيل دخول، لوحة إدارة ووردبريس، واجهة برمجية (API) بحدود معدل، خادم بريد بمصادقة SMTP AUTH. تلك الخدمات تقبل كلمات مرور فعلاً، ويمكن فعلاً تعريضها لهجمات القوة الغاشمة، وقائمة الحظر هي بالضبط الضابط المناسب لها. لذا حكمنا ضيق ومحدد: تجاوز قفص SSH. ضع CrowdSec أو fail2ban أمام الشيء الذي يملك حقل كلمة مرور. وأيًا كان اختيارك، ضع عنوان إدارتك الخاص في القائمة البيضاء أولاً — فخيار ignoreip موجود من أجل تلك الأمسية التي ستتذكرها لسبب خاطئ لو لم تفعل.

الوقاية هي ما يمكنك فعله خلال ساعة. أما الاكتشاف فهو ما يُخبرك أن تلك الساعة لم تكن كافية. لا حاجة لأن يكون معقدًا، وعلى خادم واحد، تُغطي ثلاثة أمور رخيصة معظم الأرضية.

احتفظ بالسجلات. على كثير من الصور، يعيش السجل (journal) في /run ويتبخر عند إعادة التشغيل، ما يعني أن سجل أي حادثة يختفي في إعادة التشغيل التي تليها. إنشاء /var/log/journal إصلاح من سطر واحد وأعلى الأمور قيمة في هذا القسم.

اجعل النظام يُخبرك بعمليات تسجيل الدخول. سطر واحد في /etc/ssh/sshrc يُشغّل logger عند بدء كل جلسة لا يُكلّف شيئًا ويمنحك سجلاً نظيفًا يمكن البحث فيه (greppable) منفصلاً عن ثرثرة sshd نفسه. تحذير واحد يُوقع الناس في الخطأ: يُشغّل sshd الملف ~/.ssh/rc بدلاً من /etc/ssh/sshrc إن كان لدى المستخدم واحد، لذا يُتجاوز الملف العام للنظام تحديدًا في حساب هو الأكثر احتمالاً لامتلاك ملف dotfile مخصص. إن احتجت خطافًا (hook) لا يمكن حجبه، استخدم pam_exec بدلاً من ذلك.

اعرف كيف كان نظام الملفات في اليوم الأول. يُسجّل AIDE بصمات (hashes) ملفاتك الثنائية ومكتباتك وملفات الوحدات (unit files) ويُبلغ عمّا تغيّر منذ ذلك الحين. المشكلة الجوهرية، والمُتجاهَلة عادة، هي أن قاعدة بيانات مُخزّنة على الخادم نفسه الذي تراقبه يمكن لمن اخترقه أن يُعيد توليدها، وعندها يُبلغ الفحص «لا تغييرات» إلى الأبد. انسخ قاعدة البيانات خارج الخادم، أو سجّل بصمتها في مكان آخر على الأقل، عندها تستحق الأداة العشرين دقيقة التي تأخذها. أما إن تُركت في مكانها فهي مجرد شعور زائف بالطمأنينة.

يستحق المبدأ العام أن يُذكر بمفرده: السجل الذي لا يمكنك الوثوق به هو ذلك الموجود على الخادم المُخترَق. أي شيء تنوي الاعتماد عليه فعلاً — سجل، قاعدة بيانات تكامل، نسخة احتياطية — ينبغي أن تكون له نسخة في مكان لا يتحكم فيه المهاجم نفسه. خادم صغير ثانٍ في ولاية قضائية أخرى إجابة مشروعة على ذلك، ويكفي خادم بخمسة دولارات فقط.

كل ما سبق هو عمل على المحيط الخارجي فقط، ويستحق الأمر أن نكون دقيقين بشأن هذا الحد حتى لا تخلط بين باب أمامي مُقفل وخزنة حقيقية.

لا يحمي البيانات على خادم قيد التشغيل. النواة المُحصّنة وجدار الحماية المُغلق لا قيمة لهما أمام أي شخص يملك وصولاً إلى المضيف الفعلي (hypervisor)، ولا أمام محتويات الذاكرة العشوائية أثناء عمل الخادم. إن كان قلقك هو القرص عندما يكون الخادم مُطفأً أو مُصادَرًا أو خارج الخدمة، فذلك هو تشفير القرص، وهو إجراء مختلف بنمط فشل مختلف — راجع تشفير قرص VPS باستخدام LUKS.

لا يجعلك مجهول الهوية. يمكن لخادم مُحصّن بشكل مثالي أن يُعلن عن مالكه رغم ذلك، عبر سجل WHOIS، أو مفتاح SSH مُعاد استخدامه، أو وسم تحليلات، أو عميل SSH يتصل من المنزل دون قفزة وسيطة، أو شهادة تربط بين هويتين. الدفع بعملة Monero ثم تسجيل الدخول من عنوانك الشخصي يُبطل أثر ذلك الدفع بالكامل. نمط الفشل هذا له صفحته الخاصة: الأخطاء التي تكشف هويتك.

لا يُصلح تطبيقك. حقن SQL، أو نقطة نهاية إدارية بلا مصادقة، أو اعتمادية تحوي بابًا خلفيًا، لا يهتم أي منها بإعدادات sshd لديك. معظم اختراقات الخوادم المُدارة جيدًا تصل عبر المنفذ الذي فتحته أنت عمدًا، بقصد، لخدمة كتبتها أو ثبّتها بنفسك.

وهذا ليس نسخة احتياطية. برامج الفدية، وأمر rm -rf بمتغير كان فارغًا، وترقية فاشلة، كلها تنتهي بالطريقة نفسها. خذ نسخة، وضعها في مكان آخر، واستعد منها مرة واحدة قبل أن تحتاجها فعلاً — الانضباط نفسه الذي يجعل الانتقال إلى مزوّد استضافة آخر قابلاً للنجاة يجعل يوم ثلاثاء سيئًا قابلاً للنجاة أيضًا.

لا شيء من هذا حجة ضد تلك الساعة. إنه حجة لصالح أن تعرف بالضبط ما الذي اشترته تلك الساعة.