تأمين سيرفر لينكس لتطبيقات الشركات: أوبونتو وNginx وSSH خطوة بخطوة

كثير من الشركات المصرية تشغّل اليوم موقعها أو متجرها أو نظام ERP أو الـ Backend الخاص بتطبيق الموبايل على سيرفر لينكس، غالباً أوبونتو على مزود سحابي أو VPS، مع Nginx في الواجهة وتطبيق Node.js وقاعدة بيانات PostgreSQL خلفه. وكثيراً ما يُجهَّز السيرفر بسرعة من أجل الإطلاق ثم يُترك كما هو. وهذا خطر، لأن بعض الإعدادات الافتراضية المهمة مفتوحة: OpenSSH يقبل الدخول بكلمة المرور ما لم توقفه، والجدار الناري UFW في أوبونتو معطل حتى تفعّله.

الإجابة المختصرة: لتأمين سيرفر لينكس لتطبيقات الشركات ادخل عبر SSH بالمفاتيح فقط وأوقف الدخول بكلمة المرور ودخول root، وفعّل جداراً نارياً لا يفتح إلا المنافذ اللازمة، وطبّق التحديثات الأمنية تلقائياً، وضع التطبيق خلف Nginx مع TLS حديث وتجديد تلقائي للشهادات، وأبعد قاعدة البيانات عن الإنترنت، وشغّل الخدمات بأقل صلاحيات، وراقب السجلات والنسخ الاحتياطية. هذا الدليل يعطي المدير قائمة الفحص، ويعطي فريق IT الأوامر بعد مراجعتها على الوثائق الرسمية لأوبونتو وOpenSSH وNginx وPostgreSQL.

الخلاصة السريعة

• القيمة الافتراضية لـ PasswordAuthentication في OpenSSH هي yes: انتقل للدخول بالمفاتيح وأوقف كلمات المرور صراحة.
• UFW معطل افتراضياً في أوبونتو؛ اسمح بـ SSH أولاً ثم فعّله بالمنافذ اللازمة فقط.
• اجعل التحديثات الأمنية تلقائية، وخطط لتحديثات النواة (Kernel) بإعادة تشغيل أو بخدمة Livepatch.
• استخدم إعدادات TLS المتوسطة (Intermediate) وجدد الشهادات تلقائياً لأن مدة شهادات Let's Encrypt تقصر.
• قاعدة البيانات وتطبيق Node.js يستمعان على localhost أو شبكة خاصة فقط، لا على الإنترنت.
• اكتب خطوات التأمين وراجعها دورياً، ومعايير CIS مرجع تفصيلي مفيد.

قبل البدء: جرد السيرفر وطريق آمن للعودة

• اعرف ما يعمل على السيرفر: التطبيقات والدومينات والمنافذ. الأمر sudo ss -tlpn يعرض منافذ TCP المفتوحة والعمليات التي تستخدمها، وأي شيء لا تعرف سببه يُحذف أو يُغلق.
• احتفظ بوصول للكونسول: تأكد أنك تستطيع دخول كونسول مزود الاستضافة أو وضع الاسترجاع إذا أغلق تعديل SSH الباب عليك.
• خذ Snapshot أو نسخة احتياطية قبل تغيير الإعدادات.
• حدد من له صلاحية الدخول: حساب باسم كل شخص، لا حساب مشترك تتناقله الرسائل على واتساب.

الخطوة 1: مفاتيح SSH وإيقاف كلمات المرور ودخول root

أنشئ مستخدماً إدارياً ومفتاحاً شخصياً

أنشئ مستخدماً عادياً (مثلاً sudo adduser deploy ثم sudo usermod -aG sudo deploy). وعلى جهاز كل مسؤول أنشئ مفتاحاً وانسخه إلى السيرفر؛ توصي وثائق أوبونتو سيرفر الخاصة بـ OpenSSH بالأمر ssh-keygen -t ed25519 ثم ssh-copy-id username@target_machine. احمِ المفتاح الخاص بعبارة مرور ولا ترسله بالبريد أبداً.

أوقف الدخول بكلمة المرور ودخول root

وفق دليل إعدادات sshd_config في OpenSSH فإن القيمة الافتراضية لـ PasswordAuthentication هي yes، وكذلك KbdInteractiveAuthentication، بينما القيمة الافتراضية لـ PermitRootLogin هي prohibit-password. أي أن تخمين كلمات المرور على سيرفرك يظل ممكناً حتى تغيّر ذلك.

وتوضح وثائق أوبونتو أن الملف /etc/ssh/sshd_config يبدأ بسطر Include /etc/ssh/sshd_config.d/*.conf، ولأن OpenSSH يأخذ أول قيمة يجدها لمعظم الإعدادات، فإن ما في ملفات المجلد sshd_config.d يتغلب على الملف الرئيسي. والملفات تُقرأ بالترتيب الأبجدي، لذا ضع إعداداتك في ملف يأتي أولاً مثل /etc/ssh/sshd_config.d/00-hardening.conf، وراجع باقي ملفات المجلد بحثاً عن PasswordAuthentication yes متعارض:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers deploy

ثم اختبر الإعدادات وطبّقها وتأكد من القيم الفعلية. أبقِ الجلسة الحالية مفتوحة وجرّب دخولاً جديداً من نافذة أخرى قبل إغلاق أي شيء:

sudo sshd -t
sudo systemctl restart ssh.service
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

الخطوة 2: فعّل الجدار الناري

تذكر وثائق الجدار الناري في أوبونتو أن UFW معطل افتراضياً، وأن عليك السماح بـ SSH قبل تفعيله. لسيرفر ويب نموذجي:

sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

لا تفتح منفذ قاعدة البيانات (5432) ولا منفذ تطبيق Node.js (مثل 3000) على الإنترنت. وإذا كان مزود السحابة يوفر جداراً نارياً للشبكة أو Security Group فطبّق القواعد نفسها هناك أيضاً لتكون الحماية على طبقتين.

الخطوة 3: التحديثات الأمنية وترقيع النواة

تثبّت وثائق التحديث التلقائي في أوبونتو الأداة بالأمر sudo apt install unattended-upgrades، وتُضبط في /etc/apt/apt.conf.d/50unattended-upgrades و/etc/apt/apt.conf.d/20auto-upgrades. والمصادر المسموح بها تشمل مستودع التحديثات الأمنية لأوبونتو، فتُطبق الإصلاحات دون انتظار أن يتذكرها أحد.

• تحديثات النواة تحتاج إعادة تشغيل لتعمل؛ حدد نافذة صيانة شهرية، مثلاً فجر يوم الجمعة حين تكون المكاتب مغلقة.
• Livepatch: بحسب أوبونتو ترقّع الخدمة ثغرات النواة الحرجة والعالية أثناء عمل النظام، وتُفعّل بالأمرين sudo pro attach وsudo pro enable livepatch. وهي مجانية حتى 5 أجهزة للاستخدام الشخصي أو التجربة، ولا ترقّع مكتبات مثل OpenSSL التي تعتمد على التحديثات العادية.
• البرامج من خارج مستودعات أوبونتو مثل Node.js المثبت منفصلاً ومكتبات npm الخاصة بتطبيقك تحتاج روتين تحديث خاصاً بها.

الخطوة 4: Nginx وTLS والشهادات

اجعل Nginx هو الواجهة المفتوحة على الإنترنت، ويمرر الطلبات للتطبيق الذي يستمع على 127.0.0.1 فقط. بعض الإعدادات التي تستحق المراجعة:

server_tokens off;
ssl_protocols TLSv1.2 TLSv1.3;
add_header Strict-Transport-Security "max-age=63072000" always;
client_max_body_size 10m;
location / { proxy_pass http://127.0.0.1:3000; }

• server_tokens: توضح وثائق nginx أن القيمة الافتراضية on، فيظهر رقم إصدار nginx في صفحات الخطأ وترويسة Server، وإيقافها يخفي الإصدار.
• إعدادات TLS: انتقلت إرشادات Mozilla لإعداد TLS على السيرفر إلى موقع TLSRef. والإعداد المتوسط (Intermediate) الموصى به للسيرفرات العامة يدعم TLS 1.2 وTLS 1.3 ويستخدم HSTS بقيمة max-age=63072000 (سنتان). استخدم أداة التوليد عندهم للحصول على إعدادات التشفير الكاملة لإصدار Nginx لديك، ولا تفعّل HSTS إلا إذا كانت كل النطاقات الفرعية تعمل بـ HTTPS.
• حجم الطلب: القيمة الافتراضية لـ client_max_body_size هي 1m؛ اضبطها عمداً على أكبر ملف تقبله.
• بعد أي تعديل نفّذ sudo nginx -t قبل sudo systemctl reload nginx.

جدد الشهادات تلقائياً

أعلنت Let's Encrypt في ديسمبر 2025 أن مدة شهاداتها، وهي 90 يوماً اليوم، ستنخفض إلى 45 يوماً بحلول 2028: الإعداد الافتراضي ينتقل إلى 64 يوماً في 10 فبراير 2027 ثم إلى 45 يوماً في 16 فبراير 2028. التجديد اليدوي لن يلحق بذلك؛ استخدم certbot أو عميل ACME آخر بتجديد مجدول، واختبره بالأمر sudo certbot renew --dry-run، وأضف تنبيهاً قبل انتهاء الشهادة. راجع شهادات SSL.

الخطوة 5: أقل الصلاحيات للتطبيق وقاعدة البيانات

التطبيق

• شغّل تطبيق Node.js بمستخدم مخصص غير root، عبر مدير عمليات مثل PM2 مضبوط ليبدأ مع تشغيل السيرفر تحت هذا المستخدم.
• احفظ الأسرار في ملف بيئة لا يقرؤه إلا هذا المستخدم (chmod 600)، ولا تضعها في مستودع Git أبداً.
• فعّل تدوير سجلات التطبيق حتى لا يمتلئ القرص، وهو سبب شائع لتوقف الأنظمة.
• احذف الحزم والخدمات غير المستخدمة: سيرفر FTP قديم، أو قاعدة بيانات تجريبية، أو phpMyAdmin متبقٍ من مشروع سابق.

قاعدة البيانات

توضح وثائق PostgreSQL أن القيمة الافتراضية لـ listen_addresses هي localhost، أي لا تُقبل إلا الاتصالات المحلية. أبقها كذلك إذا كان التطبيق وقاعدة البيانات على السيرفر نفسه. وإذا كانت لقاعدة البيانات سيرفر مستقل، فاجعلها تستمع على الشبكة الخاصة فقط، واسمح بعنوان سيرفر التطبيق وحده في pg_hba.conf مع مصادقة scram-sha-256، وقيّد المنفذ في الجدار الناري:

sudo ufw allow from 10.0.0.5 to any port 5432 proto tcp

وامنح التطبيق مستخدم قاعدة بيانات بالصلاحيات التي يحتاجها فقط، لا Superuser، واحفظ النسخ الاحتياطية خارج السيرفر؛ راجع دليل النسخ الاحتياطي واستعادة الأنظمة.

الخطوة 6: المراقبة والسجلات والمساءلة

• راقب SSH: الأمر sudo journalctl -fu ssh.service يعرض محاولات الدخول لحظياً؛ راجع الدخول الناجح والفاشل بانتظام.
• التوافر والموارد: تنبيهات عند التوقف، وامتلاء القرص فوق 80%، وارتفاع الذاكرة، وقرب انتهاء الشهادة.
• سجلات التطبيق: الدخول وتغيير الصلاحيات والتصدير، محفوظة مدة تكفي للتحقيق في أي حادث.
• مراجعة الصلاحيات: احذف مفاتيح SSH الخاصة بالموظفين والموردين الذين غادروا في اليوم نفسه.

والأمر قانوني أيضاً في مصر. ففي قانون مكافحة جرائم تقنية المعلومات 175 لسنة 2018 تعاقب المادة 29 مسؤول إدارة الموقع أو النظام المعلوماتي الذي يعرّضه لارتكاب جريمة، مع عقوبة أخف إذا كان ذلك نتيجة إهمال في اتخاذ الاحتياطات والتدابير الأمنية الواردة في اللائحة التنفيذية. ويُلزم قانون حماية البيانات الشخصية 151 لسنة 2020 المتحكم باتخاذ التدابير التقنية والتنظيمية لتأمين البيانات الشخصية. راجع شرح القانون 175 لسنة 2018 للشركات والإخطار عن تسريب البيانات خلال 72 ساعة.

قائمة فحص تأمين سيرفر لينكس

وللتعمق توفر معايير CIS Benchmarks توصيات إعداد تفصيلية يضعها خبراء بالتوافق، مع ملفات PDF مجانية، وتشمل أوبونتو وNginx وPostgreSQL وغيرها. ويفيد أيضاً الفحص الخارجي؛ راجع اختبار الاختراق وتقييم الثغرات، وخطة الأمن السيبراني للشركات الصغيرة والمتوسطة للصورة الكاملة.

كيف تساعدك Nilex

تنشر Nilex أنظمتها على أوبونتو سيرفر مع Nginx كوسيط عكسي (Reverse Proxy)، وPM2 لإدارة العمليات، وشهادات SSL تلقائية، وتتبع الخطوات السابقة: SSH بالمفاتيح فقط، وقواعد الجدار الناري، والتحديثات الأمنية التلقائية، وعزل قاعدة البيانات، والمراقبة. ويمكننا تأمين سيرفر تعمل عليه حالياً، وتوثيق إعداداته، وتسليم فريقك قائمة فحص يستطيع متابعتها.

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

هل سيرفر أوبونتو الجديد آمن افتراضياً؟

ليس بالكامل. أوبونتو أساس قوي، لكن UFW معطل افتراضياً وOpenSSH يسمح بالدخول بكلمة المرور ما لم يُضبط غير ذلك. عليك تأمين SSH وتفعيل الجدار الناري وضبط التحديثات بنفسك.

هل أغيّر منفذ SSH من 22؟

تغيير المنفذ يقلل ضجيج الفحص الآلي لكنه لا يضيف حماية حقيقية؛ الدخول بالمفاتيح وإيقاف كلمات المرور والجدار الناري أهم بكثير. وإذا غيّرته فعدّل قواعد الجدار الناري أولاً حتى لا تغلق الباب على نفسك.

كل كم يُحدَّث سيرفر الإنتاج؟

التحديثات الأمنية تُثبّت تلقائياً يومياً، مع نافذة صيانة منتظمة لإعادة التشغيل بعد تحديثات النواة أو استخدام Livepatch، وتحديث Node.js ومكتبات التطبيق بجدولك الخاص بعد الاختبار.

هل يمكن وضع قاعدة البيانات على نفس سيرفر التطبيق؟

نعم، وهذا شائع وآمن في الأنظمة الصغيرة والمتوسطة إذا كانت PostgreSQL تستمع على localhost فقط والنسخ الاحتياطية محفوظة في مكان آخر. والأنظمة الأكبر تستفيد من سيرفر قاعدة بيانات مستقل على شبكة خاصة.

ماذا يحدث إذا لم تُجدد شهادة Let's Encrypt؟

يعرض المتصفح تحذيراً أمنياً ولا يستطيع العملاء استخدام موقعك أو تطبيقك بأمان. ومع تقلص المدة نحو 45 يوماً بحلول 2028 يصبح التجديد التلقائي وتنبيه الانتهاء ضرورة.

نظامك يعمل على سيرفر لينكس لم يراجعه أحد منذ الإطلاق؟ اطلب مراجعة لتأمين السيرفر أو استشارة مجانية عبر صفحة التواصل.