البحث في الموقع

نشرح طريقة الاتصال بخدمة GitHub عبر SSH، وذلك بتوليد زوج المفاتيح مفتاح عام يضاف إلى إعدادات GitHub ومفتاح خاص نحتفظ به لدينا للمصادقة.

نشرح طريقة الاتصال الآمنة عبر SSH بخوادم لينكس باستعمال برمجية PuTTY. وهذا يتضمن إعداد الوصول إلى الخادم عبر كلمة المرور، أو عبر مفتاح عام.

مقدمة إذا كنت تعمل(على الشبكة) مُستخدمًا بروتوكول النقل الآمن Secure Shell) SSH)، فإنّك تعلم مُسبقًا أنّ الجلسة session ستُغلق تلقائيًا بعد دقائقٍ قليلةٍ من عدم النشاط "الخمول"، وذلك لأسبابٍ أمنية.من الممكن في الحقيقة أن تكون قد نسيت إغلاقها، وبالتالي فقد يتمكن شخص آخر من السيطرة على نظامك. ولكن إذا كنت لا ترى في ذلك مشكلة، فبإمكانك تغيير هذا السلوك في ضبط GNU/Linux. يجب تنفيذ الأوامر التالية من عميل SSH. كيفيّة منع SSH من قطع الاتصال يجب تنفيذ الخطوات التالية في عميل SSH، وليس في الخادم البعيد. افتح محرّر النص خاصتك في البداية وعدّل ملف الـ config الحالي للمستخدم الخاص بك، والذي تجده في المسار التالي: ~/.ssh/config أضف الأسطر التالية: تأكّد من أن السطر الثاني سيبدأ بمسافة فارغة. يُخبر السطر الأول الـ SSH بتطبيق هذا الضبط على جميع المضيفات البعيدة remote hosts. كما يمكنك بالطبع تحديد واحد منها فقط، وذلك باستبدال رمز الـ "*" بالمضيف المطلوب. ستحتاج بعد الانتهاء من ذلك إلى تطبيق الإعدادات المذكورة أعلاه: sudo source ~/.ssh/config أضف أو عدّل السطر التالي في ملف etc / ssh / ssh_config/ لتطبيق هذه الإعدادات على المستوى العام globally: ServerAliveInterval 60 احفظ الملف واغلقه. وبهذه الطريقة، لن تُغلق جلسة SSH بعد الآن بسبب الخمول. الخلاصة تذكّر أن أمان نظامك، وخصوصًا في حالة الخادم server، ليس أمرًا ثانويًا، وذلك كلّه بيديك. إنّ تغيير سلوك برامج مثل SSH يجب أن يتم فقط في حال كنت تعرف بالضبط ما تريده، وبعد التأكّد من أنّ ذلك لن يضعك في مشكلةٍ ما. ترجمة وبتصرّف للمقال How to prevent SSH from disconnecting sessions لصاحبه Giuseppe Molica

SSH عبارة عن بروتوكول آمن يُستخدم كوسيلة أساسيّة للاتصال بخوادم لينكس عن بُعد. SSH تُقدّمُ واجهة نصّية بحيثُ تعطيك الصّلاحيّة لكتابة أي أوامر وتنفيذها مباشرة على الخادوم. بعد الاتصال، جميع الأوامر التي تكتبها على الطرفيّة محليّاً تُرسل إلى الخادوم عن بعد وتُنفّذ هناك. في هذا الدّليل السّريع، سنُغطّي بعضاً من أكثر وسائل الاتّصال بSSH شيوعاً لتحقيق أهدافك. هذا المقال يُمكن أن يُستعمل كمرجع سريعٍ كلّما احتجت إلى معرفة كيفية الاتصال بخادومك أوضبطه بطرق مختلفة. نظرة عامة على SSH أشهر وسيلة للاتّصال بخادوم لينكس عن بعد هي استعمال SSH .SSH اختصار ل Secure Shell أو شل آمن، حيث تُوفّر وسيلة آمنة لتنفيذ الأوامر، إضافة تعديلات وضبط الخدمات عن بُعد. عندما تتّصل عبر SSH، تقوم بتسجيل الدّخول باستخدام حساب موجود على الخادوم. كيف يعمل SSH عندما تتّصل عبر SSH، ستدخلُ إلى جلسة شل (shell session)، وهي واجهة نصّيّة تُمكّنك من التّفاعل مع خادومك. أثناء الجلسة جميع الأوامر التي تُنفّذها في الطرفيّة محليّاً تُرسل عبر نفق SSH أو SSH tunnel مُشفّر وتُنفّذ على الخادوم. اتصال SSH يُنفّذ باستخدام نموذج خادوم خاص بالعميل. هذا يعني أن إنشاء اتصال SSH يتطلّب تشغيل برمجيّة تسمى عفريت SSH على الخادوم. تستمع هذه البرمجيّة للاتصالات على منفذ شبكة معيّن، طلبات تسجيل الدّخول والاستيثاق authentication من هوية صاحب الاتصال وتقوم بتقديم البيئة المناسبة إذا قام المستخدم بتوفير المعلومات الصّحيحة. يجب على المُستخدم أن يمتلك على جهازه برمجية تسمى عميل SSH أو SSH client، البرمجية تعرف كيف تتواصل باستخدام بروتوكول SSH ويُمكن أن تُمنَح معلومات عن المُضيف البعيد (الخادوم) للاتّصال به،عن طريق اسم المستخدم ومعلومات يجب تمريرها للاتّصال بنجاح. يمكن للعميل أيضاً أن يحدّد تفاصيل معيّنة عن نوع الاتّصال المرغوب فيه. كيف يقوم SSH بتسجيل دخول المستخدمين العميل يصادق إمّا باستخدام كلمات المُرور ( أقلّ أماناً وغير منصوح بها) أو عن طريق مفاتيح SSH، التي تعتبر آمنة جدّاً. كلمات المرور تُشفَّرُ وتعتبر سهلة الفهم بالنّسبة للمُستخدمين الجُدد. لكنّ المُخترقين يستعملون برمجيّات خبيثة يُمكن لها أن تُكرّر محاولات الدّخول إلى حواسيب من يستخدمون كلمات المرور، ما قد يُؤدي إلى اختلال أمني. لهذا السّبب ننصح دائما بالاعتماد على استيثاق SSH المبدئي لمُعظم الإجراءات. مفاتيح SSH هي مجموعة من المفاتيح المُشفّرة يُمكن استعمالها للاستيثاق. كلّ مجموعة تحتوي على مفتاح عام وخاص. يُمكن نشر المفتاح العام بشكل حرّ، أما المفتاح الخاص فيجب الاحتفاظ به ولا يجب أن يُكشف لأحد. للاستيثاق باستخدام مفاتيح SSH، يجب على المستخدم أن يمتلك زوج مفتاح SSH على جهازه المحلي. وعلى الخادم البعيد المفتاح العام يجب أن ينسخ إلى ملفّ بداخل مجلّد منزل المُستخدم على ssh/authorized_keys./~ . هذا الملفّ يحتوي على قائمة من المفاتيح العامّة - واحد في كلّ سطر- مُخوّلٌ لها بالدّخول إلى الحساب. عندما يتّصل عميل بالمُضيف Host راغباً باستخدام استيثاق مفتاح SSH، سيُعلم الخادومَ عن أي مفتاح عام يستخدم. يتحقّق الخادوم بعد ذلك من ملفّ المفاتيح المُخوّل لها authorized_keys باحثاً عن المفتاح العام المُستخدم. ثم يولّد سلسلة نصّية عشوائيا ويُشفّر باستخدام المفتاح العام، هذا النّص المُشفّر يُمكن فك تشفيره فقط باستعمال المفتاح الخاصّ المُقترن. سيُرسل الخادوم هذه الرّسالة المُشفرة إلى العميل لاختبار إذا ما كان فعلا يمتلك المفتاح الخاصّ المُرتبط. عند استلام الرّسالة، سيقوم العميل بفك التّشفير باستخدام المفتاح الخاص ويجمع السّلسلة نصّية العشوائية مع هوية جلسة سابقة (session ID) . ويولّد بعد ذلك مزيج MD5 الخاص بالقيمة وينقلها مجدّدا إلى الخادوم. الخادوم يمتلك سابقا الرّسالة الأصليّة وهوية الجلسة، لذلك يُمكنه أن يُقارن مزيج MD5 المولّد من القيّم ويُحدّد بأن العميل يجب أن يمتلك المفتاح الخاص. الآن بما أنّك تعلم كيف يعمل SSH، يُمكننا البدء في الحديث عن بعض الأمثلة للتعرّف على الطّرق المُختلفة للعمل مع SSH. توليد مفاتيح SSH والعمل معها هذا القسم سيغطي كيف تولّد مفاتيح SSH على جهاز عميل ونشر المفتاح العام إلى الخوادم حيث يجب أن تُستخدم. هذا قسم جيّد للبدء به إذا لم يسبق لك أن ولّدت مفاتيح، ويجب عليك البدء به إذا أردت تأمين خادومك نظراً لزيادة الأمان التي تتيحه لنا في الاتصّالات المُستقبليّة. توليد زوج مفاتيح SSH توليد زوج مفاتيح SSH عام وخاص على جهازك المحلي هو أول خطوة نحو استيثاق مع خادوم عن بعد بدون كلمة مرور. إلا إذا كنت تملك سببا جيدا لعدم فعل ذلك، يجب عليك دائما الاتصال باستخدام مفاتيح SSH. يمكن استخدام مجموعة من خوارزميّات التشفير لتوليد مفاتيح SSH، مثل RSA، DSA، ECDSA. مفاتيح RSA مُفضلة بشكل عام وهي نوعية المفاتيح الافتراضية. لتوليد زوج مفاتيح RSA على جهازك المحلي، أكتب: $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/demo/.ssh/id_rsa): هذا المحث (prompt) يتيح لك اختيار مكان لتخزين مفتاح RSA الخاص. اضغط Enter للخيار الافتراضي، الذي سيُخزنها في مجلّد .ssh المخفي قي مجلد المنزل. ترك المسار الافتراضي سيتيح لعميل SSH إيجاد المفاتيح آلياً. Enter passphrase (empty for no passphrase): Enter same passphrase again: المحث التالي يتيح لك إدخال جملة مرور بطول اعتباطي لتأمين مفتاحك الخاص. افتراضياً يجب عليك إدخال جملة المرور هذه في كل مرّة تستعمل المفتاح الخاص، كإجراء أمني إضافي. يُمكنك أن تضغط Enter لترك الحقل فارغا إذا لم ترغب في إنشاء كلمة مرور. تذكّر فقط أن هذا سيخوّل أي شخص يملك قابلية التحكم بمفتاح SSH الخاص للدخول إلى الخادوم الخاص بك. إذا اخترت وضع كلمة مرور لن يظهر شيء على الشاشة أثناء الكتابة، وهذا من أجل الاحتياط الأمني. Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 8c:e9:7c:fa:bf:c4:e5:9c:c9:b8:60:1f:fe:1c:d3:8a root@here The key's randomart image is: +--[ RSA 2048]----+ | | | | | | | + | | o S . | | o . * + | | o + = O . | | + = = + | | ....Eo+ | +-----------------+ هذه العملية ولّدت زوج مفاتيح SSH من نوع RSA، وملفّات تحت المجلد المخفي .ssh في مجلد المنزل وهذه الملفّات هي: ssh/id_rsa./~: المفتاح الخاص. لا تنشر هذا الملفّ! ssh/id_rsa.pub./~: المفتاح العام المُرتبط. هذا الملفّ يمكن مشاركته بحرية. توليد زوج مفاتيح مع رقم أكبر من البتات Bits مفاتيح SSH تكون افتراضياً 2048 بت. هذا يعتبر جيّداً بشكل عام أمنياً، لكنّك تستطيع تحديد عدد أكبر لمزيد من الأمان. لفعل ذلك ضَمِّن معامل -b مع عدد البتات الذي تريد. معظم الخوادم تدعم 4096 بت على الأقل. المفاتيح الأطول يُمكن ألّا تُقبل لأغراض الحماية من DDOS: ssh-keygen -b 4096 إذا سبق لك أن أنشئت مفتاحاً، سيُطلب منك إذا ما كنت ترغب في الكتابة فوق المفتاح السّابق: Overwrite (y/n)? إذا اخترت نعم (y)، فإن المفتاح الجديد سيكتب فوق المفتاح السّابق ولن تستطيع استعمال المفتاح القديم بعدها للدّخول إلى الخادوم، لذلك كن حذرا أثناء تغيير المفتاح. حذف وتغيير جملة المرور على المفتاح الخاص إذا سبق لك وأن عيّنت جملة مرور للمفتاح الخاص ورغبت في تغييرها فالأمر بسيط، ويمكنك أن تقوم به بسهولة. ملاحظة: لتغيير أو حذف جملة المُرور، يجب عليك معرفة جملة المرور الأصليّة. إذا فقدت جملة المرور إلى المفتاح،فللأسف لا يوجد طريقة لإرجاعها وسيتوجّب عليك توليد زوج مفاتيح جديد. لتغيير أو حذف جملة المرور، فقط أكتب: ssh-keygen -p Enter file in which the key is (/root/.ssh/id_rsa): يُمكنك أن تُحدد مسار المفتاح الذي تحاول تعديله أو اضغط Enter لقبول القيمة الافتراضيّة: Enter old passphrase: أكتب جملة المرور القديمة المراد تغييرها. بعد ذلك ستُسأل لإدخال جملة مرور جديدة: Enter new passphrase (empty for no passphrase): Enter same passphrase again: هنا أكتب جملة المرور الجديدة أو اضغط Enter لحذفها. عرض بصمة مفتاح SSH ينشر كل زوج مفاتيح بصمة مُشفّرة يُمكن استعمالها لتعريف المفاتيح بشكل فريد. يُمكن أن يكون هذا جيّدا في كثير من الحالات. لإيجاد بصمة مفتاح SSH، اكتب: ssh-keygen -l Enter file in which the key is (/root/.ssh/id_rsa): إذا كان هذا هو مسار المفتاح الصحيح اضغط ENTER ، أو اكتب المسار الخاص إذا كان المسار مختلفاً، ستُرجع سلسلة نصيّة تحتوي على سعة المفتاح من البتات، البصمة، والحساب والمُضيف الذي أنشئت له، والخوارزمية المُستخدمة: 4096 8e:c4:82:47:87:c2:26:4b:68:ff:96:1a:39:62:9e:4e demo@test (RSA) نسخ مفتاح SSH العام إلى الخادوم مع SSH-Copy-ID لنسخ مفتاحك العام إلى الخادوم، بغرض الاستيثاق بدون كلمة مرور، سنتخذ بعض الإجراءات. إذا كنت حالياً تمتلك وصولا إلىSSH عن طريق كلمة مرور مضبوطاً على الخادوم، وتمتلك أداة ssh-copy-id مثبّتة، فهذه العمليّة بسيطة. أداة ssh-copy-id تأتي مضمّنة على حزم OpenSSH في كثير من توزيعات لينكس، لذلك فمن المُحتمل أن تكون لديك افتراضيا. إذا كنت تملك هذا الخيّار، يُمكنك بسهولة نقل مفتاحك العام باستعمال: ssh-copy-id username@remote_host سيُطلب منك إدخال كلمة مرور المُستخدم على الجهاز البعيد: The authenticity of host ‘111.111.11.111 (111.111.11.111)’ can’t be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys demo@111.111.11.111’s password: بعد كتابة كلمة المرور، مُحتوى مفتاح ssh/id_rsa.pub./~ سوف يُلحق إلى آخر ملف ssh/authorized_keys./~ الخاصّ بحساب المُستخدم: Number of key(s) added: 1 Now try logging into the machine, with: "ssh ‘demo@111.111.11.111’" and check to make sure that only the key(s) you wanted were added. يُمكنك الآن الدّخول إلى الحساب بدون كلمة مرور: ssh username@remote_host نسخ مفتاح SSH العام إلى خادوم بدون SSH-Copy-ID إذا لم تكن تملك أداة ssh-copy-id، لكنك لا زلت تملك وصولا إلى الخادوم البعيد بكلمة مرور، يُمكنك نسخ محتويات المفتاح العام بطريقة مختلفة. يُمكنك إرجاع مُحتويات المفتاح وتمريرها إلى أمر SSH، في الجهة البعيدة يُمكنك التأكد إذا ما كان مجلّد ssh./~ موجوداً، وبعد ذلك ألحق المحتوى المُمَرّر إلى ملفّ ssh/authorized_keys./~: cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys" سيُطلب منك كتابة كلمة المرور للحساب البعيد: The authenticity of host ‘111.111.11.111 (111.111.11.111)’ can’t be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes demo@111.111.11.111’s password: بعد إدخال كلمة المرور، سيُنسخ مفتاحك، متيحاً لك الاتصال بدون كلمة مرور: ssh username@remote_IP_host نسخ مفتاح SSH العام إلى خادوم يدويا إذا لم تكن تملك وصولا عن طريق كلمة مرور، ستحتاج لإضافة مفتاحك العام إلى الخادوم البعيد يدويّاً. على جهازك المحليّ، يُمكنك إيجاد محتويات ملفّ مفتاحك العام بكتابة: cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test يُمكنك نسخ هذه القيمة، ولصقها يدويّاً في المكان المناسب على الخادوم البعيد. يجب عليك أن تتّصل بالخادوم بوسيلة مختلفة. على الخادوم البعيد، أنشئ مجلّد ssh./~ إذا لم يكن موجوداً من قبل: mkdir -p ~/.ssh بعد ذلك، يُمكنك إنشاء أو إلحاق ملفّ ssh/authorized_keys./~ بكتابة: echo سلسلة_المفتاح_العام >> ~/.ssh/authorized_keys يجب عليك الآن أن تتمكّن من الدّخول إلى الخادوم بدون كلمة مرور عبر أمر ssh: ssh username@remote_IP_host ترجمة -مع شيءٍ من التصرّف- للقسم الأول من مقال: SSH Essentials: Working with SSH Servers, Clients, and Keys.

يؤمن تطبيق المفكرة Jupyter Notebook موجه أوامر تفاعلي شبيه بتطبيقات الويب، والذي يمكن استخدامه مع العديد من لغات البرمجة مثل Python و Julia و R و Haskell و Ruby، وذلك في التطبيقات الخاصة بالبيانات والإحصاء والذكاء الصناعي. سيتم في هذه المقالة شرح طريقة تهيئة وإعداد تطبيق المفكرة Jupyter Notebook للعمل مع أكواد لغة البرمجة Python 3 محليًا أو من الخادم Ubuntu 16.04 server. إن تطبيق المفكرة Jupyter Notebook هو عبارة عن برنامج مفكرة يقوم بتوليد المستندات المتضمنة على الأكواد البرمجية والشروحات والصور والمخططات البيانية والمعادلات الرياضية، لاستخدامها في عرض وتطوير ومشاركة الأبحاث العلمية. المتطلبات قبل البدء يجب توفر بيئة برمجية مهيّأة محليًا (على الحاسب الشخصي) أو على الخادم Ubuntu 16.04 مع امتلاك صلاحية مدير النظام (المستخدم الجذر root) أو استخدام الأمر sudo عند تنفيذ الأوامر في موجه أوامر لينكس. الخطوة الأولى- تنصيب تطبيق المفكرة Jupyter Notebook سيتم استخدام أداة إدارة الحزم pip لتنصيب تطبيق المفكرة Jupyter Notebook في بيئة Python البرمجية المُنشأة مسبقًا. لكن يجب في البداية الانتقال إلى المجلدenvironments الخاص ببيئة Python البرمجية my_env المُنشأة مسبقًا وتفعيلها، وذلك بتنفيذ الأوامر التالية في موجه أوامر النظام: sammy@ubuntu:~$ cd ~/environments sammy@ubuntu:~/environments$ . my_env/bin/activate (my_env) sammy@ubuntu:~/environments$ ثم علينا التأكد من أن الأداة pip محدّثة لآخر إصدار وذلك بتنفيذ الأمر التالي: (my_env) sammy@ubuntu:~/environments$ pip install --upgrade pip ثم نقوم عن طريق الأداة pip بتنصيب تطبيق المفكرة Jupyter Notebook في البيئة البرمجية my_env، وذلك بتنفيذ الأمر التالي: (my_env) sammy@ubuntu:~/environments$ pip install jupyter وهكذا تم تنصيب تطبيق المفكرة Jupyter Notebook في البيئة البرمجية. الخطوة التالية وهي اختيارية للذين يريدون الاتصال عبر قناة الاتصال SSH بواجهة الويب التفاعلية لتطبيق المفكرة Jupyter Notebook المنصَّب على الخادم. الخطوة الثانية (اختيارية)- الاتصال بتطبيق المفكرة Jupyter Notebook المنصَّب على الخادم عبر قناة الاتصال SSH سيتم في هذه الخطوة شرح طريقة الاتصال بواجهة الويب التفاعلية لتطبيق المفكرة Jupyter Notebook المنصَّب مسبقًا على الخادم، وذلك عبر قناة الاتصال SSH. حيث تؤمن قناة الاتصال SSH اتصالاً آمنًا بتطبيق المفكرة Jupyter Notebook كونه يستخدم منفذ محدد في الخادم (مثل المنفذ :8888 أو :8889 الخ). سيتم في الفقرتين التاليتين شرح طريقة إنشاء قناة الاتصال SSH. الأولى من نظام التشغيل ماكنتوش أو لينكس، والثانية من نظام التشغيل ويندوز. طريقة إنشاء قناة الاتصال SSH من نظام التشغيل ماكنتوش أو لينكس سيتم في هذه الفقرة شرح طريقة إنشاء قناة اتصال SSH من نظام التشغيل ماكنتوش أو لينكس، باستخدام الأمر ssh مع مجموعة من المعاملات التي تؤمن نجاح عملية الاتصال. يمكن إنشاء قناة اتصال SSH جديدة بتنفيذ الأمر التالي في نافذة جديدة لموجه أوامر النظام: $ ssh -L 8888:localhost:8888 your_server_username@your_server_ip حيث يستخدم الأمر ssh من أجل فتح اتصال SSH، في حين يستخدم العلم -L لتحديد المنفذ المعطى في المضيف المحلي (العميل) الذي سيتم توجيهه إلى المنفذ والمضيف البعيد (الخادم) المعطى، أي أن أي شيء سيعمل على المنفذ الثاني (مثلا 8888) على الخادم، سيظهر على المنفذ الأول (مثلا 8888) على العميل (الحاسب الشخصي). ويفضل تغيير رقم المنفذ 8888 إلى أي رقم آخر اختياري لتجنب وجود عملية أخرى تعمل على نفس المنفذ. إن المُعامل your_server_username هو اسم المستخدم (مثلا sammy) الذي تم إنشاؤه مسبقًا على الخادم، والمُعامل your_server_ip هو عنوان IP للخادم (مثلا 203.0.113.0). أي يصبح الأمر السابق بعد إدخال اسم المستخدم وعنوان IP للخادم كما يلي: $ ssh -L 8888:localhost:8888 sammy@203.0.113.0 وفي حال نجاح عملية الاتصال بالخادم وعدم حدوث أي خطأ، ينتقل موجه أوامر النظام إلى البيئة البرمجية المهيّأة مسبقًا على الخادم كما يلي: (my_env) sammy@ubuntu:~/environments$ ثم نقوم بتشغيل تطبيق المفكرة Jupyter Notebook المنصَّب مسبقًا في بيئتنا البرمجية كما يلي: (my_env) sammy@ubuntu:~/environments$ jupyter notebook والآن أصبح بالإمكان التفاعل مع تطبيق المفكرة Jupyter Notebook من خلال واجهة الويب التفاعلية الخاصة به، وذلك بإدخال العنوان الالكتروني http://localhost:8888 في المتصفح، كما يجب إدخال السلسلة الرمزية token الخاصة بالتصديق عند طلبها من قبل المتصفح، أو كتابتها بعد العنوان في المتصفح. طريقة إنشاء قناة الاتصال SSH من نظام التشغيل ويندوز عن طريق Putty تستخدم الأداة Putty لإنشاء قناة اتصال SSH في نظام التشغيل ويندوز، لذا يجب في البداية تنصيبها، وعند فتحها تظهر واجهة الأداة كما هو موضح بالشكل التالي: حيث يتم إدخال العنوان الإلكتروني URL للخادم أو عنوان IP ضمن حقل اسم المضيف Host Name، ثم الضغط على الخيار SSH في أسفل النافذة اليسارية من واجهة الأداة، فتظهر قائمة منسدلة من الخيارات، نختار منها الخيار Tunnels فتظهر في النافذة اليمينية مجموعة من خيارات التحكم بقناة الاتصال SSH كما هو موضح بالشكل التالي: ثم نقوم بإدخال رقم منفذ الحاسب الشخصي المراد استخدامه لتطبيق المفكرة Jupyter Notebook (مثلًا 8888)، ضمن حقل منفذ المصدر Source port، ويفضل أن يكون رقم هذا المنفذ أكبر من 8888 لضمان عدم وجود أي تطبيق أخر يعمل على هذا المنفذ. ثم ندخل العنوان localhost:8888 في حقل الهدف Distination حيث :8888 هو رقم المنفذ الذي يعمل عليه تطبيق المفكرة Jupyter Notebook في الخادم، ثم نضغط على زر الإضافة Add، فيظهر المنفذ في قائمة المنافذ الموجَّهة Forwarded ports. وأخيرًا نضغط على زر الفتح Open من أجل الاتصال بالخادم عن طريق قناة الاتصال SSH، ثم ندخل العنوان localhost:8888 (طبعًا يجب أن يكون رقم المنفذ موافقًا لرقم المنفذ الذي تم اختياره) في متصفح الويب من أجل الاتصال بتطبيق المفكرة Jupyter Notebook العامل على الخادم، كما يجب إدخال السلسلة الرمزية token الخاصة بالتصديق عند طلبها من قبل المتصفح، أو كتابتها بعد العنوان في المتصفح. الخطوة الثالثة- تشغيل تطبيق المفكرة Jupyter Notebook بعد الانتهاء من تنصيب تطبيق المفكرة Jupyter Notebook، يصبح بالإمكان تشغيله من موجه أوامر النظام بتنفيذ الأمر التالي: (my_env) sammy@ubuntu:~/environments$ jupyter notebook فيُطبع في نافذة موجه الأوامر سجل معلومات تشغيل تطبيق المفكرة Jupyter Notebook كما يلي: [I NotebookApp] Serving notebooks from local directory: /home/sammy [I NotebookApp] 0 active kernels [I NotebookApp] The Jupyter Notebook is running at: http://localhost:8888/ [I NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation). ... حيث تتضمن هذه المعلومات على رقم المنفذ الذي يعمل عليه التطبيق، وعند تشغيل التطبيق لأول مرة سيكون رقم المنفذ 8888. يقوم المتصفح الافتراضي تلقائياً بفتح واجهة الويب التفاعلية الخاصة بتطبيق المفكرة Jupyter Notebook عند تشغيله على الحاسب الشخصي (ليس على الخادم)، وفي حال لم يتم ذلك أو تم إغلاق المتصفح، يمكن إعادة فتحه من جديد بإدخال عنوانه http://localhost:8888/ الظاهر في سجل معلومات التطبيق في المتصفح. يتم إنهاء تطبيق المفكرة Jupyter Notebook بالضغط على المفاتيح CTRL و C ثم ضغط المفتاح y (نعم) عند السؤال عن تأكيد عملية الإنهاء، ثم ضغط المفتاح ENTER، فتُطبع رسالة تأكيد عملية إنهاء التطبيق التالية في نافذة موجه الأوامر: [C 12:32:23.792 NotebookApp] Shutdown confirmed [I 12:32:23.794 NotebookApp] Shutting down kernels الخطوة الرابعة- استخدام تطبيق المفكرة Jupyter Notebook سيتم في هذه الفقرة شرح أساسيات استخدام تطبيق المفكرة Jupyter Notebook، لكن يجب في البداية تشغيله إن لم يكن في حالة العمل، وذلك بتنفيذ الأمر التالي: (my_env) sammy@ubuntu:~/environments$ jupyter notebook نستطيع الآن الإتصال به والتفاعل معه من خلال واجهة الويب التفاعلية. يمتاز تطبيق المفكرة Jupyter Notebook بالقوة حيث يحتوي على الكثير من الميزات، لكن سيقتصر الشرح على بعض الميزات الأساسية التي تسمح بمباشرة العمل على هذا التطبيق. يعرض تطبيق المفكرة Jupyter Notebook جميع الملفات والمجلدات الواقعة ضمن المسار الذي تم تشغيله منه، لذا يجب تشغيله دائمًا من مسار المشروع البرمجي الذي يتم العمل عليه. يتم إنشاء ملف مفكرة Jupyter Notebook جديد بالضغط على خيار جديد New الموجود في الزاوية اليمينية العُلوية من واجهة الويب التفاعلية، فتظهر قائمة منسدلة نختار منها Python 3 كما هو موضح بالشكل التالي: فيُفتح الملف الجديد المُنشأ ضمن واجهة الويب التفاعلية. نستطيع الآن كتابة وتنفيذ كود Python ضمن خليّة الكود البرمجي. كما يمكن تغيير هذه الخلية لتقبل لغة التوصيف Markdown، وذلك بالضغط على خيار الخلية Cell ثم خيار نوع الخلية Cell Type ثم خيار التوصيف Markdown من الشريط العلوي، فيصبح بالإمكان الآن استخدام هذه الخلية لكتابة الملاحظات وحتى تضمين المعادلات الرياضية المكتوبة بلغة LaTeX بعد وضعها بين الرمزين ($$)، فمثلا يمكن كتابة كود التوصيف التالي ضمن الخلية بعد تحويلها لخلية توصيف: # Simple Equation Let us now implement the following equation: $$ y = x^2$$ where $x = 2$ يتم تحويل هذا الكود إلى نص بضغط المفاتيح CTRL و ENTER فنحصل على النتيجة التالية: وهكذا نلاحظ أنه يمكن استخدام خلايا التوصيف من أجل توثيق الكود البرمجي. سنقوم الآن بإنشاء معادلة رياضية بسيطة ونطبع نتيجة تنفيذها، وذلك بالضغط على الخلية العلوية ثم الضغط على المفاتيح ALT و CTRL من أجل إنشاء خلية جديدة تحتها ثم ندخل فيها الكود التالي: x = 2 y = x**2 print(y) ثم نقوم بتنفيذ الكود بضغط المفاتيح CTRL و ENTER فنحصل على النتيجة التالية: أصبح بمقدورك الآن وبعد أن تعلمت أساسيات تطبيق المفكرة Jupyter Notebook ، أن تقوم باستيراد النماذج البرمجية، وأن تستخدم هذه المفكرة كما تريد مع أي بيئة برمجية أخرى. ملخص أصبحت قادرا الآن على كتابة أكواد Python والملاحظات القابلة للتطوير والمشاركة، بعد أن تعلمت كيفية تنصيب وتشغيل والعمل على تطبيق المفكرة Jupyter Notebook. يمكن الحصول على مزيد من المعلومات والمساعدة حول كيفية استخدام هذه المفكرة، بالدخول إلى User Interface Tour عن طريق الخيار Help الموجود في الشريط العلوي من واجهة الويب التفاعلية. ترجمة المقال How To Set Up Jupyter Notebook for Python 3 لصاحبته Lisa Tagliaferri

إن كنت مدير قواعد بيانات DBA فإنه من المحتمل جدًّا أن يكون سطرُ الأوامر هو وسيلتك للتخاطب مع قواعد البيانات التي تديرها. يستزف استخدام سطر الأوامر الوقت عندما تحتاج للاتّصال بقواعد بيانات عدّة تعمل على مضيفات متباعدة؛ استخدامُ واجهة رسوميّة مفيد في هذه الحالة. يمكنك بالطبع تثبيت phpMyAdmin على كلّ خادوم، إلا أنك ستحتاج إلى تسجيل الدخول إلى واجهة وِب مختلفة بالنسبة لكلّ خادوم. ماذا لو كانت لديك واجهة وحيدة للاتّصال بجميع قواعد بيانات MySQL التي تديرها؟ إن كان هذا ما تبحث عنه فأنت في المكان الصّحيح. MySQL Workbench هو واجهة رسومية موَّحدة للتعامل مع قواعد بيانات MySQL، توفّر لمعماريّي البرمجيّات Architects، المطوّرين ومديري الأنظمة آليّة فعّالة للتعامل مع قواعد بيانات متعدّدة على مضيفات متباعدة. يمكن بهذه الأداة الحصول بنظرة على معلومات عن حالة خادوم قاعدة البيانات، اتصالات العملاء ومتغيّرات الخادوم. كما تمكّنك من إدارة المستخدمين وصلاحيّاتهم، تصدير البيانات واستيرادها، تنفيذ الاستعلامات Queries، إنشاء مخطّطات Schemas جديدة وغيرها من المهامّ. يتيح MySQL Workbench أيضًا إمكانيّة تهجير Migrate البيانات من أنظمة إدارة قواعد بيانات أخرى، مثل Microsoft SQL Server وPostreSQL إلى MySQL بسهولة ويُسر. سنبيّن في هذا الدرس كيفية تثبيت الأداة على حاسوبك الشخصي وخطوات ينبغي تطبيقها جهةَ خواديم قواعد البيانات للسماح للأداة بالاتصال بهذه الخواديم. سنأخذ مثالا لتثبيت MySQL Workbench على حاسوب شخصي يعمل بالإصدار 17.04 من أوبونتو وجعله يتّصل بقاعدة بيانات على خادوم يعمل بأوبونتو 16.04. تنطبق نفس الخطوات على بقيّة توزيعات لينكس مع اختلافات تمليها طبيعة مدير الحزم الخاص بالتوزيعة. تثبيت MySQL Workbench يمكن الحصول على الأداة MySQL Workbench من صفحة التنزيل على موقع الأداة. اختر صيغة الحزمة والمعماريّة المناسبتَيْن (حزمة deb. ومعماريّة 64 بت بالنسبة لنا) ثم اطلُب تنزيل الملف (قد تحتاج لتسجيل الدخول إلى حساب أوراكل أو إنشاء حساب جديد إن لم يكن لديك واحد، الحساب والأداة مجانيّان). انتقل بعد اكتمال التنزيل إلى المُجلَّد حيثُ نزّلت الأداة (المجلّد Downloads بالنسبة لنا): cd ~/Downloads ثم استخدم الأمر dpkg لتثبيت حزمة الأداة: sudo dpkg -i mysql-workbench-community-*.deb قد تظهر رسائل خطأ تفيد بغياب حزم تعتمد عليها الأداة MySQL Workbench (رسائل الخطأ dependency problems). يمكن حلّ هذه المشاكل بتنفيذ الأمر التالي لتثبيت الحزم المفقودة: sudo apt-get install -f يحلّ الأمر السابق بتثبيت الحزم التي تطلبها الأداة MySQL Workbench. نحن الآن جاهزون لتشغيل الأداة MySQL Workbench على الحاسوب الشخصي (العميل)، ولكن قبل ذلك سنضبُط خادوم قاعدة البيانات للسماح للاتصالات البعيدة (أي التي تأتي من عملاء لا يتواجدون مع خادوم قاعدة البيانات على نفس الجهاز). إعداد خادوم MySQL للاتصالات البعيدة إن لم تضبُط خادوم MySQL لقبول اتصالات بعيدة فإن MySQL Workbench لن يمكنه الاتصال بقواعد البيانات الموجودة على هذا الخاودم. يجب أولا ضبط MySQL لقبول اتصالات قادمة من عناوين غير العنوان المحلّي 127.0.0.1. سجّل الدخول إلى الخادوم - مثلا عبر SSH - ثم افتح الملف التالي لتحريره: sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf ابحث عن السطر التالي: bind-address 127.0.0.1 وعدّله ليصبح: bind-address 0.0.0.0 احفظ الملف ثم أغلقه. أعد تشغيل خادوم MySQL بالأمر التالي: sudo systemctl restart mysql.service خادوم قاعدة البيانات جاهز الآن لتلقّي الاتصالات. الخطوة الموالية هي تحديد المستخدمين المسموح لهم بالاتصال بخادوم قاعدة البيانات ومن أي عنوان يمكنهم ذلك. يُضبَط هذا الإعداد من محثّ الأوامر command prompt في MySQL. ننفّذ الأمر التالي للانتقال إلى محثّ أوامر MySQL: mysql -u root -p ملحوظة: أبدل root باسم الحساب الإداري لديك خادوم في قاعدة البيانات. أدخل كلمة السّر عندما تُطلَب منك، ستجد بعدها أنك أمام سطر أوامر خاص بـMySQL. سنحتاج لتنفيذ أمر يعطي حساب المدير القدرة على الاتصال بخادوم قاعدة البيانات عن بعد (عبر MySQL Workbench). سنفترض أن عنوان الجهاز الذي ثبّتنا عليه MySQL Workbench هو 192.168.1.139 وأننا نريد السماح للمسخدم root بالاتصال بجميع قواعد البيانات الموجودة على الخادوم انطلاقا من العنوان السابق. ننفّذ الأمر التالي للحصول على النتيجة المذكورة: GRANT ALL ON *.* TO 'root'@'192.168.1.139' IDENTIFIED BY 'PASSWORD' WITH GRANT OPTION; حيث PASSWORD كلمة سرّ المستخدم root (أو أي مستخدم آخر تريد إعطاءه ميزة الاتصال عن بعد بالقاعدة). تأكّد من أن الأمر نُفِّذ دون أخطاء. نفّذ الأمر: exit; للخروج من سطر أوامر MySQL. يمكنك الآن الاتصال بخادوم MySQL انطلاقا من MySQL Workbench. الاتصال بقاعدة البيانات من MySQL Workbench شغّل التطبيق MySQL Workbench ثم توجّه إلى القائمة Databaseواختر Connect to database. تظهر النافذة التالية. نحدّد في هذه النافذة تفاصيل الاتصال: عنوان الخادوم، المنفذ (مبدئيّا 3306) واسم المستخدم ثم اضغط على الزرّ OK. سيُطلب منك إدخال كلمة سر المستخدم. تظهر بعد إدخال كلمة السر الصحيحة النافذة التاليّة التي يمكن من خلالها تنفيذ إجراءات مختلفة على قاعدة البيانات. تُستخدَم الطريقة السابقة لإنشاء اتصال واحد. إن كنت تعرف أنك ستتصّل بهذا الخادوم مرارا فالأفضل أن تختار Manage Connections من القائمة Database. تظهر النافذة التالية. انقر على الزّر New، حدّد التفاصيل المطلوبة للاتصال بقاعدة البيانات. تأكّد من إعطاء اسم للاتصال (خانة Connection name) ثم انقر على زرّ Test Connection لاختبار الاتصال. أدخل كلمة السر عندما تُطلَب منك ثم انقر على الزرّ OK. انقر على الزرّ OK مرة أخرى بعد نجاح اختبار الاتصال ثم Close لإغلاق نافذة الاختبار. سيُحفَظ الاتصال بعد إغلاق نافذة الاختبار. يمكنك بعدها الذهاب إلى القائمة Database واختيار Connect to Database ثم تحديد الخادوم الذي تريد الاتصال به من القائمة المنسدلة Stored Connection يمكنك بالوصول إلى هذه النقطة البدء في إنشاء قواعد البيانات وإدارتها بمساعدة أداة رسوميّة فعّالة وصديقة للمستخدم. ليس MySQL Workbench سوى أداة من بين أدوات رسومية كثيرة تساعد في جعل إدارتك لقواعد بيانات MySQL أكثر فاعليّة، جرّبها وستجد أنها ستصبح وسيلتك اليومية لإدارة قواعد بيانات MySQL. ترجمة - بتصرّف - للمقال How to Install and Use MySQL Workbench As Your Database GUI لصاحبه Jack Wallen.

تمهيد هنالك بعض خطوات الضبط التي عليك إجراؤها عندما تُنشِئ خادومك، إذ ستزيد من حمايته وسهولة استخدامه، وستوفر لك أساسًا تستطيع البناء عليه لإجراء عمليات أخرى. الخطوة الأولى: تسجيل الدخول بحساب الجذر لتسجيل الدخول إلى خادومك، فعليك معرفة عنوان IP العام الخاص به إضافةً إلى كلمة مرور المستخدم الجذر root؛ إذا لم تُسجِّل دخولك من قبل إلى خادومك. إذا لم تكن متصلًا بخادومك، فاستعمل الأمر الآتي الذي يُسجِّل دخولك بحساب الجذر root، لاحظ أنَّ عليك وضع عنوان IP العام لخادومك بدلًا من عبارة SERVER_IP_ADDRESS: ssh root@SERVER_IP_ADDRESS أكمل عملية تسجيل الدخول بقبولك للتحذير عن صحة وموثوقية الخادوم إن ظهر لك، ثم بتوفيرك لطريقة الاستيثاق المطلوبة لحساب الجذر (عبر كلمة مرور أو مفتاح خاص [private key]). إذا كانت هذه هي أوّل مرة تسجِّل فيها دخولك إلى الخادوم، فسيُطلَب منك تغيير كلمة مرور الجذر أيضًا. ما هو المستخدم الجذر؟ المستخدم الجذر root هو الحساب الإداري في بيئة لينكس والذي يملك صلاحيات وامتيازات واسعة جدًا؛ وبسبب امتلاك هذا الحساب لهذه الامتيازات، فمن غير المستحسن استعماله في الأحوال العادية، لأن القدرات التي يملكها حساب الجذر قادرة على إلحاق الضرر بنظامك، لو خطأً. الخطوة التالية هي إعداد حساب مستخدم له صلاحيات أقل من صلاحيات الجذر لاستعماله في إجراء المهام اليومية، ثم سنتعلم كيف نزيد من امتيازات هذا الحساب عندما نحتاج إليها. الخطوة الثانية: إنشاء حساب مستخدم جديد بعد أن نسجِّل الدخول بحساب الجذر root، فأصبحنا جاهزين لإضافة حساب مستخدم جديد الذي سنستعمله من الآن وصاعدًا لتسجيل الدخول إلى النظام. سنُنشِئ بواسطة الأمر الآتي مستخدمًا جديدًا باسم demo، لكن يمكنك استخدام أي اسم يحلو لك: adduser demo علينا بعد ذلك أن نسند كلمة مرور إلى المستخدم الجديد (تذكر أن تضع اسم المستخدم الذي اخترته بدلًا من demo): passwd demo ادخل كلمة مرور قوية، ثم كرِّر كتابتها للتأكيد. الخطوة الثالثة: الحصول على امتيازات الجذر أصبح لدينا الآن حساب مستخدم جديد يملك امتيازاتٍ عاديةً، لكننا سنحتاج في بعض الأحيان إلى إجراء عمليات إدارية. ولتنجب الحاجة إلى تسجيل الخروج من حساب المستخدم العادي ثم الدخول مجددًا بحساب الجذر، فسنحاول ضبط إمكانية الحصول على امتيازات الجذر من حساب المستخدم العادي، وهذا يسمح للمستخدم العادي بتشغيل الأوامر بصلاحيات إدارية بوضع الكلمة sudo قبل كل أمر ينفذه. لإضافة هذه الامتيازات إلى مستخدمنا الجديد، فعلينا إضافة المستخدم الجديد إلى مجموعة wheel؛ فالسلوك المبدئي لنظام CentOS 7 يسمح للمستخدمين الذين ينتمون إلى المجموعة wheel بالحصول على امتيازات الجذر باستعمال الأمر sudo. نفِّذ الأمر الآتي بعد تسجيل دخولك بحساب الجذر لإضافة المستخدم الجديد إلى مجموعة wheel (لا تنسَ أن تضع اسم المستخدم الذي أنشَأته بدلًا من demo): gpasswd -a demo wheel يمكن للمستخدم الآن أن ينفِّذ الأوامر بامتيازات الجذر؛ ولمزيدٍ من المعلومات عن هذا الموضوع، أنصحك بقراءة درس How To Edit the Sudoers File on Ubuntu and CentOS. الخطوة الرابعة: ضبط الاستيثاق عبر مفتاح عمومي (خطوة مستحسنة) الخطوة التالية في طريق زيادة حماية خادومك هي ضبط الاستيثاق عبر مفتاح عمومي (public key authentication) للمستخدم الجديد الذي أنشَأته؛ مما يزيد من حماية خادومك بطلب مفتاح SSH خاص لإتمام تسجيل الدخول. توليد زوج من المفاتيح إذا لم يكن لديك زوجٌ من مفاتيح SSH، والتي تتألف من مفتاح عمومي ومفتاح خاص، فعليك توليدها؛ أما إذا كان زوج المفاتيح متوافرًا عندك فاذهب إلى خطوة «نسخ المفتاح العمومي» مباشرةً. نفِّذ الأمر الآتي في طرفية الجهاز المحلي لتوليد زوج جديد من المفاتيح: ssh-keygen ولنفترض جدلًا أنَّ اسم المستخدم المحلي هو localuser، فستشاهد ناتجًا شبيهًا بالناتج الآتي: Generating public/private rsa key pair. Enter file in which to save the key (/Users/localuser/.ssh/id_rsa): اضغط على زر Enter لقبول اسم الملف ومساره، أو أدخِل اسمًا جديدًا له. سيُطلَب منك الآن إدخال عبارة مرور (passphrase) لتأمين المفتاح، يمكنك أن تدخِل ما تشاء في هذا الحقل أو أن تتركه فارغًا. ملاحظة: إذا تركتَ حقل عبارة المرور فارغًا فستتمكن من استخدام المفتاح الخاص للاستيثاق دون الحاجة إلى إدخال عبارة المرور؛ أما إذا أدخلت عبارة المرور، فعليك توفير المفتاح الخاص إضافةً إلى عبارة المرور عند تسجيل الدخول. وصحيحٌ أنَّ إنشاء مفاتيح محمية بعبارة مرور أكثر أمانًا، لكن هنالك مواطن استخدام لكلا الطريقتين اللتين تصنفان أنهما أكثر أمانًا من الاستيثاق التقليدي عبر كلمات المرور (passwords). سيولّد مفتاح خاص باسم id_rsa ومفتاح عام باسم id_rsa.pub في مجلد ‎.ssh الموجود في مجلد المنزل التابع للمستخدم المحلي localuser؛ تذكر أنَّ المفتاح الخاص يجب ألّا يُشارك مع أي شخص لا يحق له الوصول إلى خواديمك. نسخ المفتاح العمومي بعد توليد زوج مفاتيح SSH، عليك نسخ المفتاح العمومي إلى خادومك الجديد، وسنشرح طريقتين سهلتين لفعل ذلك. الطريقة الأولى: استخدام سكربت ssh-copy-id إذا كان السكربت ssh-copy-id مثبتًا على جهازك المحلي، فيمكنك استخدامه لتثبيت المفتاح العمومي لأي مستخدم تملك معلومات الوصول الخاصة به. شغِّل سكربت ssh-copy-id بتحديد اسم المستخدم وعنوان IP للخادوم الذي تريد تثبيت المفتاح عليه، كما في الأمر الآتي: ssh-copy-id demo@SERVER_IP_ADDRESS بعد كتابة كلمة المرور عند طلبها، فيجب أن يُضاف المفتاح العمومي الخاص بك إلى ملف ‎.ssh/authorized_keys في الخادوم البعيد؛ ويمكن الآن استخدام المفتاح الخاص لتسجيل الدخول إليه. الطريقة الثانية: تثبيت المفتاح يدويًا بفرض أنَّك ولدت زوجًا من مفاتيح SSH باستعمال الخطوة السابقة، يمكنك تنفيذ الأمر الآتي في طرفية جهازك المحلي لطباعة محتويات المفتاح العمومي (id_rsa.pub): cat ~/.ssh/id_rsa.pub يجب أن تظهر أمامك محتويات المفتاح العمومي، والذي سيبدو كما يلي: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local حدِّد المفتاح العمومي وانسخه إلى الحافظة. يجب أن نضيف المفتاح العمومي إلى ملفٍ خاص في مجلد المنزل للمستخدم الذي أنشأناه على الخادوم البعيد، وذلك لتمكين الاستيثاق عبره في SSH. نُفِّذ الأمر الآتي بعد تسجيلك بحساب الجذر root إلى الخادوم للتبديل إلى حساب المستخدم الجديد الذي أنشأتَه (تذكر أن تضع الاسم الذي اخترتَه بدلًا من demo): su - demo ستنتقل الآن إلى مجلد المنزل الخاص بالمستخدم الجديد. أنشِئ مجلدًا جديدًا باسم ‎.ssh وامنع بقية المستخدمين من الوصول إليه، وذلك بتنفيذ الأمرين الآتيين: mkdir .ssh chmod 700 .ssh أنشِئ ملفًا جديدًا في مجلد ‎.ssh باسم authorized_keys باستعمال محررك النصي المفضل، سنستخدم هنا محرر vi لتعديل الملف : vi .ssh/authorized_keys بدِّل إلى نمط الإدخال بالضغط على i ثم ألصق المفتاح العمومي (الذي يجب أن يكون موجودًا في الحافظة)، ثم اضغط على زر ESC للخروج من نمط الإدخال. أدخِل ‎:x ثم اضغط على Enter لحفظ الملف والخروج من المحرر النصي. ثم امنع الوصول إلى ملف authorized_keys لجميع المستخدمين ما عدا المستخدم المالك باستعمال هذا الأمر: chmod 600 .ssh/authorized_keys ثم نفِّذ هذا الأمر مرةً واحدةً للعودة إلى حساب المستخدم الجذر: exit يمكنك الآن تسجيل الدخول بحساب المستخدم الجديد عبر SSH باستعمال المفتاح الخاص للاستيثاق. لمزيدٍ من المعلومات حول طريقة عمل الاستيثاق عبر المفاتيح، فأنصحك بقراءة مقالة العمل مع خواديم SSH: العملاء والمفاتيح. الخطوة الخامسة: ضبط خدمة SSH بعد تهيئتنا لحساب المستخدم الجديد، فيمكننا الآن تأمين الخادوم قليلًا بتعديل ضبط خدمة SSH (وهي الخدمة التي تسمح لنا بتسجيل الدخول عن بعد) لمنع الوصول عبر SSH إلى حساب الجذر root. ابدأ بفتح ملف الضبط بمحررك النصي المفضل باستعمال حساب الجذر root: vi /etc/ssh/sshd_config يمكننا هنا تعطيل تسجيل الدخول بحساب الجذر إلى SSH، وهذا أكثر أمانًا، وتذكر أننا نستطيع الوصول إلى خادومنا عبر حساب المستخدم العادي ثم الحصول على امتيازات الجذر عند اللزوم. لتعطيل تسجيل الدخول لحساب الجذر عن بعد، عليك العثور على سطرٍ شبيهٍ بالسطر الآتي: #PermitRootLogin yes تلميح: للبحث عن السطر السابق في محرر vi، يمكنك أن تكتب ‎/PermitRoot ثم تضغط على Enter، مما سيحرك المؤشر إلى الحرف P في السطر السابق. احذف رمز التعليق من السطر السابق بحذف محرف # (اضغط على Shift-x). ثم انقل المؤشر إلى الكلمة yes بالضغط على c. استبدل كلمة yes بالضغط على cw ثم اكتب الكلمة no ثم اضغط على زر Escape بعد أن تنتهي من التعديلات؛ ويجب أن يصبح السطر كما يلي: PermitRootLogin no أدخِل ‎:x ثم Enter لحفظ الملف والخروج من المحرر النصي. إعادة تحميل خدمة SSH بعد أن أجرينا تعديلاتنا، سنحتاج إلى إعادة تشغيل خدمة SSH لكي تستعمل الضبط المُعدَّل. اكتب السطر الآتي لإعادة تحميل SSH: systemctl reload sshd قبل أن نُسجِّل خروجنا من الخادوم، علينا أن نختبر الضبط الجديد، فلا نريد أن نقطع الاتصال قبل أن نتأكد من إمكانية إنشاء اتصالات جديدة بنجاح. افتح نافذة طرفية جديدة لإنشاء اتصال جديد إلى الخادوم، لكن هذه المرة سنستخدم حساب المستخدم الجديد للاتصال بدلًا من حساب الجذر. سنستخدم الأمر الآتي للاتصال إلى الخادوم، تذكر أن تضع المعلومات الخاصة بمستخدمك بما يناسب الأمر الآتي: ssh demo@SERVER_IP_ADDRESS ملاحظة: إذا كنتَ تستخدم برمجية PuTTY للاتصال إلى خواديمك، فاحرص على تحديث رقم المنفذ ليُطابِق إعدادات النظام الحالي. تذكر أنَّ تضع الأمر sudo قبل الأوامر التي تريد تنفيذها بامتيازات الجذر كما يلي: sudo command_to_run إذا جرى كل شيءٍ على ما يرام، فاخرج من كلا الجلستين بكتابة: exit ما هي الخطوات القادمة؟ أنشأنا في هذا الدرس أساسًا صلبًا لخادومك، ويمكنك الآن تثبيت أي برمجيات تحتاج لها عليه. لمزيدٍ من المعلومات حول الخواديم عمومًا، فتصفح قسم DevOps في أكاديمية حسوب ترجمة –وبتصرف– للمقال Initial Server Setup with CentOS 7 لصاحبه Mitchell Anicas

مقدمة يُستخدم ميثاق (بروتوكول) الوِب TLS (اختصار لـ Transport Layer Security، أمان طبقة النقل) وسلفه SSL (اختصار لـ Secure Sockets Layer، طبقة المقابس الآمنة) لتغليف البيانات العاديّة ضمن إطار محميّ وآمن. يمكن للخواديم باستخدام هذه التقنية أن تؤمّن تبادل البيانات بينها وبين العملاء حتى ولو اعتُرِضت طريقُ الرسائل بين الخادوم والعميل. يساعد نظام الشهادات الأمنية Certificates المستخدِمين والزوار في التحقّق من أمان المواقع التي يتّصلون بها. سنقدّم في هذا الدليل الخطوات اللازمة لإعداد شهادة أمنيّة موقَّعة ذاتيًّا Self-signed certificate لاستخدامها مع خادوم الوِب Apache على أوبونتو 16.04. ملحوظة: تعمّي الشهادات الموقَّعة ذاتيًّا الاتصالات بين الخادوم والعملاء؛ لكن لن يمكنَ للعملاء استخدامُها للتحقّق من التحقّق من هويّة خادومك تلقائيًّا، إذ أنه لم تُوقّعها سلطة معترف بها. تتضمَّن المتصفّحات مثل فيرفكس وكروم قائمة بالسلطات المعترف بها والمخوَّلة إصدار شهادات TLS. يُناسب استخدام الشهادات الموقَّعة ذاتيًّا بيئات الاختبار، على الحاسوب الشخصي أو عندما لا يكون لديك نطاق Domain؛ مثلا في واجهات الوِب غير المتاحة للعموم. إن كان لديك نطاق فالأفضل أن تستخدم شهادة أمنية من سطلة معترف بها. يمكنك الحصول على شهادة مجانيّة من Let’s encrypt وإعدادها. المتطلبات ستحتاج قبل البدء بتنفيذ الخطوات الواردة في هذا الدرس إلى إعداد مستخدم إداري بامتيازات sudo غير المستخدم الجذر. راجع درس الإعداد الابتدائي لخادوم أوبونتو لمعرفة كيفية ذلك. ستحتاج أيضا لتثبيت خادوم الوِب Apache. إن رغبت في تثبيت كامل حزم LAMP (أي لينكس Linux، أباتش Apache، وMySQL وPHP) فالدرس كيف تثبت حزم MySQL ،Apache ،Linux :LAMP و PHP موجود لهذا الغرض؛ أما إن كنت ترغب في تثبيت Apache لوحده فيمكنك الاعتماد على الدرس المُشار إليه مع ترك الخطوات الخاصّة بكلّ من MySQL وPHP. تأكّد من توفّرك على المتطلّبات ثم نفّذ الخطوات المشروحة أدناه. الخطوة اﻷولى: إنشاء شهادة SSL يعمل بروتكول TLS (وسلفه SSL) باستخدام مفتاحيْن للتعميّة واحد عمومي Public وآخر خاصّ (أو سرّي) Private. يُخزَّن المفتاح السّري على الخادوم ولا يجوز أن يطّلع عليه أي عميل فهو خاصّ بالخادوم الذي يستخدمه لتعميّة المحتوى المُرسَل إلى العملاء. يُمكن لأيّ عميل الاطّلاع على شهادة TLS. تحوي هذه الشهادة المفتاح العموميّ الذي يُستخدَم لفكّ التعميّة عن المحتوى القادم من الخادوم. ملحوظة: رغم أن استخدام البروتكول SSL يقلّ يومًا بعد يوم إلا أن المصطلح “شهادة SSL” لا يزال يُستَخدَم كثيرًا، ويُقصَد به - في الغالب - TLS، الذي هو نسخة محسَّنة من SSL. تتيح مكتبة OpenSSL (مكتبة برمجيّة توفّر أدوات للتعامل مع شهادات SSL/TLS) إنشاء مفتاح تعميّة موقَّع ذاتيًّا بالأمر التالي: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt ستُطرَح عليك مجموعة من الأسئلة، ولكن قبل النظر في تلك الأسئلة سنشرح الخيارات المذكورة في الأمر السابق: openssl: هذا هو الأمر الأساسي لإنشاء الشهادات، المفاتيح وبقية الملفات وإدارتها في OpenSSL. req: يحدّد هذا الأمر الفرعي المعيار X.509 لاستخدامه في البنية التحتيّة التي نريد استخدامها لإدارة المفاتيح العموميّة. يعتمد الميثاقان SSL وTLS المعيار X.509 لإدارة المفاتيح العمومية. نستخدم هذا الأمر الفرعي لطلب إنشاء شهادة تتوافق مع هذا المعيار. x.509: يغيّر هذا الخيار طريقة عمل الأمر الفرعي السابق ليخبره أننا في طور إنشاء شهادة موّقَّعة ذاتيًّا بدلا من إرسال طلب لتوقيع شهادة الذي هو السلوك المبدئي للأمر الفرعي. nodes: يطلُب هذا الخيار من openssl تجاوز خيار تأمين الشهادة بعبارة سرّ Passphrase. نريد أن يكون Apache قادرا على قراءة الشهادة بدون تدخّل من المستخدم عند بدْء تشغيل الخادوم. يمنع وجود عبارة سرّ Apache من قراءة ملفّ الشهادة وسنحتاج عند وجودها لإدخالها في كلّ مرة نعيد فيها تشغيل الخادوم. days 365: يحدّد هذا الخيار مدّة صلاحيّة الشهادة. اخترنا سنة. newkey rsa:2048: يخبر هذا الخيار الأمر openssl أننا نريد توليد شهادة ومفتاح جديد في نفس الوقت. بما أننا لم نولّد المفتاح المطلوب لتوقيع الشهادة في خطوة منفصلة فإننا نحتاج لإنشائه مع الشهادة. يحدّد الجزء rsa:2048 نوعيّة المفتاح بـ RSA وطوله بـ 2048 بت. keyout: يحدّد المسار الذي نريد حفظ المفتاح الخاصّ فيه. out: يحدّد المسار الذي نريد حفظ الشهادة فيه. ستنشئ هذه الخيارات مفاتيح التعميّة والشهادة. يطلُب الأمر كما أسلفنا الإجابة على بضعة أسئلة كما في الصورة التالية. تتعلّق الأسئلة بمعلومات عامة من قبيل الدولة والمدينة والمؤسّسة والمنظَّمة المُصدِرة للشهادة إضافة إلى معلومات عن الخادوم. يتعلّق أهمّ الأسئلة المطروحة - السطر Common Name - بالخادوم. يجب أن تجيب باسم النطاق الذي يعمل عليه الخادوم أو - وهو الأكثر شيوعا - عنوان IP العمومي للخادوم. يبدو المحثّ Prompt على النحو التالي: Country Name (2 letter code) [AU]:حرفان يمثّلان الدولة State or Province Name (full name) [Some-State]:اسم المنطقة (المحافظة أو الولاية) Locality Name (eg, city) []:اسم المدينة Organization Name (eg, company) [Internet Widgits Pty Ltd]:اسم المنظَّمة أو الشركة Organizational Unit Name (eg, section) []:اسم الفرع Common Name (e.g. server FQDN or YOUR name) []:عنوان الخادوم Email Address []:بريد المسؤول سيوضع الملفان المنشآن في مجلّدات فرعيّة من المجلّد etc/ ssl/ حسب ماهو محدَّد في الأمر. سنحتاج أيضًا - ما دمنا نتحدَّث عن OpenSSL - إلى إنشاء مجموعة Diffie-Hellman قويّة لتُستخدَم عندما يُناقش الخادوم طريقة نقل البيانات مع العملاء (خطوة من خطوات عدّة ضمن تقنيّة SSL/TLS لتأمين نقل البيانات). ينشئ اﻷمر التالي المطلوب: sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048 يمكن أن يستغرق الأمر بضعة دقائق، نحصُل بعدها على مجموعة Diffie-Hellman مناسبة (على المسار etc/ssl/certs/dhparam.pem/) لاستعمالها في إعداداتنا. الخطوة الثانية: إعداد Apache لاستخدام SSL أنشأنا في الخطوة السابقة ملفّيْ الشهادة والمفتاح الخاصّ. نحتاج الآن لضبط Apache للاستفادة من هذيْن الملفّيْن. سنعدّل بضعة إعدادات: سننشئ مقطعا جديدًا في إعدادات Apache لتحديد خيارات إعداد مبدئيّة آمنة لـ SSL. سنعدّل المضيف الافتراضي Virtual host الخاص بـ SSL للإشارة إلى شهادة SSL التي أنشأناها في الخطوة السابقة. سنعدّل المضيف الافتراضي غير المُعمَّى ليعيد توجيه جميع الطلبات إلى المضيف الافتراضي المُعمَّى (الخاص بـ SSL). يُنصَح بهذا الإجراء لجعل جميع الاتصالات القادمة إلى الموقع آمنة (تمرّ عبر شهادة SSL). يجدر بالإعدادات التي سنحصُل عليها بعد تنفيذ النقاط المُشار إليها أعلاه أن تكون آمنة. تحديد خيارات إعداد مبدئيّة آمنة في Apache سننشئ أولا ملفّ إعداد جديدًا في Apache نعرّف فيه بعض إعدادات SSL. سنضبُط Apache للعمل بخوارزميّات تعميّة فعّالة ونفعّل بعض الميزات المتقدّمة لمساعدتنا في إبقاء خادومنا آمنا. سيُمكن لأيّ مضيف افتراضي يفعّل SSL. أنشئ ملفّ إعداد جديد ضمن المجلَّد etc/apache2/conf-available/ (مجلَّد إعدادات Apache). سنسمّي هذا الملف بـssl-params.conf حتى يكون واضحًا أنه يتعلّق بمعطيات Parameters إعداد SSL. sudo nano /etc/apache2/conf-available/ssl-params.conf سنعتمد لضبط إعدادات Apache بطريقة آمنة على توصيّات Remy van Elst من موقع Cipherli.st. جُهِّز هذا الموقع لتوفير إعدادات تعميّة جاهزة للاستعمال في أكثر البرمجيّات شيوعًا على الخواديم. ملحوظة توفّر الإعدادات المُقترَحة مبدئيًّا في الموقع أعلاه درجة أمان عاليّة. يمكن أن تأتي هذه الدرجة من الأمان على حساب التوافق مع البرامج العميلة (المتصفّحات أو أنظمة التشغيل القديمة). إن أردت دعم إصدارات قديمة من هذه البرامج فإن الموقع يوفّر إعدادات بديلة للإعدادات المبدئيّة، يمكنك الحصول عليها بالنقر على الرابط “Yes, give me a ciphersuite that works with legacy / old software” وستلاحظ أن الإعدادات تبدّلت. يعتمد الخيار بين النسخة المبدئية من الإعدادات والنسخة البديلة على نوعيّة العملاء التي تريد دعمها. توفّر النسختان أمانًا جيّدًا. سننسخ - لأغراض هذا الدرس - الإعدادات المقترحة، مع إجراء تعديليْن عليها. سنعدّل التعليمة SSLOpenSSLConfCmd DHParameters لتشير إلى ملف Diffie-Hellman الذي أنشأناه في الخطوة الأولى. سنعدّل أيضًا تعليمات الترويسة لتغيير عمل الخاصيّة Strict-Transport-Security وذلك بحذف التعليمة preload. توفّر هذه الخاصيّة أمانًا عاليَّا جدًّا إلا أنها يمكن إن فُعِّلت بدون وعي أو بطريقة غير صحيحة - خصوصًا عند استخدام الميزة preload - أن تؤدّي إلى اختلالات كبيرة في عمل الخادوم. تأكّد عندما تفعِّل هذه الميزة أنك تدرك جيّدًا ما تفعله. # from https://cipherli.st/ # and https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH SSLProtocol All -SSLv2 -SSLv3 SSLHonorCipherOrder On # تعطيل التعليمة preload في الخاصيّة Strict-Transport-Security # يمكنك إن أردت تفعيل هذه الخاصية وذلك بنزع علامة التعليق # من بداية السطر #Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload" # نفس التعليمة السابقة ولكن دون preload Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains" Header always set X-Frame-Options DENY Header always set X-Content-Type-Options nosniff # Requires Apache >= 2.4 SSLCompression off SSLSessionTickets Off SSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)" # أضفنا هنا المسار إلى ملفّ Diffie-Hellman SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem" احفظ الملفّ ثم أغلقه عندما تكون جاهزا لذلك. تعديل ملف مضيف SSL الافتراضي المبدئي ننتقل الآن إلى الملف المبدئي Default لمضيف SSL الافتراضي الموجود على المسار etc/apache2/sites-available/default-ssl.conf/. إن كنت تستخدم مضيفا اقتراضيًّا آخر فأبدله بالمضيف الافتراضي المبدئي في الأمر أدناه. نأخذ أولًا نسخة احتياطية من الملف: sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak ثم نفتح ملف المضيف الافتراضي لتحريره: sudo nano /etc/apache2/sites-available/default-ssl.conf يبدو محتوى الملف، بعد نزع أغلب التعليقات، على النحو التالي: <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # BrowserMatch "MSIE [2-6]" \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 </VirtualHost> </IfModule> سنعدّل قليلا على الملف بإعداد تعليمات بريد مدير الخادوم، عنوان، اسم الخادوم… إلخ. كما سنعدّل تعليمة SSL لتشير إلى مسار ملفّيْ الشهادة والمفاتيح. نختُم بنزع التعليق عن خيار يوفّر الدعم للمتصفّحات القديمة لتفعيله. يبدو الملف بعد التعديلات كالتالي: <IfModule mod_ssl.c> <VirtualHost _default_:443> # بريد مدير الخادوم ServerAdmin your_email@example.com # نطاق الخادوم أو عنوان IP الخاص به ServerName server_domain_or_IP DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # دعم المتصفحات القديمة BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost> </IfModule> احفظ الملف ثم أغلقه. إعادة توجيه طلبات HTTP (غير المُعمَّاة) إلى HTTPS يجيب الخادوم بإعداداته الحاليّة على الطلبات الآمنة (HTTPS) وغير الآمنة (HTTP) على حدّ السواء. يُنصَح في أغلب الحالات من أجل أمان أعلى أن تُوجَّه طلبات HTTP تلقائيَّا إلى HTTPS. نفتح ملف المضيف الافتراضي - أو المضيف الذي تريده - لتحريره: sudo nano /etc/apache2/sites-available/000-default.conf كلّ ما نحتاجه هو إضافة تعليمة إعادة إعادة التوجيه Redirect داخل إعداد الوسم VirtualHost والإشارة إلى النسخة الآمنة من الموقع (https): <VirtualHost *:80> . . . Redirect "/" "https://your_domain_or_IP/" . . . </VirtualHost> احفظ الملف ثم أغلقه. الخطوة الثالثة: تعديل الجدار الناري إن كان جدار ufw الناري مفعّلًا، وهو ما توصي به الدروس المُشار إليها في المتطلّبات، فقد تحتاج لتعديل إعداداتِه من أجل السماح للبيانات المُؤَمَّنة (عبر SSL). يُسجّل Apache أثناء تثبيته مجموعات من المعلومات المختصرة Profiles لدى جدار ufw الناري. يمكننا عرض المجموعات المتوفّرة بالأمر التالي: sudo ufw app list تظهر مُخرجات الأمر : Available applications: Apache Apache Full Apache Secure OpenSSH يمكنك عرض الإعداد الحالي بالأمر sudo ufw status إن كان إعدادك الحالي يسمح لطلبات HTTP فقط فستبدو إعداداتك كالتالي” Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6) يمكننا تفعيل المجموعة Apache Full للسماح لطلبات HTTPS وHTTP معًا، ثم حذف المجموعة Apache لأننا لم نعد بحاجة إليها، فهي متَضَمَّنة في المجموعة Apache Full : sudo ufw allow 'Apache Full' sudo ufw delete allow 'Apache' ملحوظة: يمكنك استخدام الأمر sudo ufw app info PROFILE حيث PROFILE اسم مجموعة المعلومات لمعرفة المنافذ Ports والبروتوكولات التي تسمح المجموعة للطلبات بالمرور عبرها. يجب أن تبدو حالة الجدار الناري الآن على النحو التالي: sudo ufw status المخرجات: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6) الخطوة الرابعة: اعتماد التغييرات في Apache نحن جاهزون الآن، بعد أن عدّلنا الإعدادات، لتفعيل وحدات Modules الترويسات Headers وSSL في Apache، وتفعيل المضيف الافتراضي الجاهز لاستخدام SSL ثم إعادة تشغيل Apache. يفعّل الأمران التاليّان على التوالي mod_ssl (وحدة SSL في Apache) وmod_headers (وحدة الترويسات) اللتين تحتاجهما إعداداتنا للعمل: sudo a2enmod ssl sudo a2enmod headers ثم نفعّل المضيف الافتراضي (ضع اسم المضيف مكان default-ssl إن كنت تستخدم مضيفًا غير المضيف المبدئي): sudo a2ensite default-ssl نحتاج أيضًا لتفعيل ملفّ الإعداد ssl-params الذي أنشأناه سابقا: sudo a2enconf ssl-params يجدر بالوحدات المطلوبة أن تكون الآن مفعَّلة وجاهزة للعمل، بقي لنا فقط اعتماد التغييرات. لكن قبل ذلك سنتأكّد من أنه لا توجد أخطاء صياغة في الملفات التي أعددناها وذلك بتنفيذ الأمر التالي: sudo apache2ctl configtest إن جرى كلّ شيء على ما يُرام فستظهر رسالة تشبه ما يلي: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Syntax OK السطر الأول ليس سوى رسالة تفيد بأنّ التعليمة ServerName غير مضبوطة لتعمل على كامل الخادوم (مثلا مضبوطة في المضيفات الافتراضية فقط). يمكنك التخلّص من هذه الرسالة - إن أردت - بضبط قيمة التعليمة ServerName على نطاق الخادوم أو عنوان IP الخاصّ به في ملف الإعدادات العام etc/apache2/apache2.conf/. هذا الإعداد اختياري، فالرسالة لا تتسبّب في أي خلل. تظهر في السطر الثاني نتيجة التحقّق من الصياغة Syntax OK وتفيد بأنه لا توجد مشكلة من هذه الناحيّة. يمكننا إذن إعادة تشغيل خادوم الوِب لاعتماد التعديلات: sudo systemctl restart apache2 الخطوة الخامسة: اختبار التعمية افتح متصفّح الوِب وأدخل العنوان //:https متبوعًا باسم نطاق الخادوم أو عنوان IP الخاصّ به: https://server_domain_or_IP بما أنّ الشهادة الأمنيّة التي أنشأناه لا تصدُر من سلطة شهادات يثق بها المتصفّح فستظهر صفحة مخيفة عند زيارة الموقع تحمل الرسالة التالية. هذا السلوك متوقَّع وطبيعي. نهتمّ في هذا الدرس بجانب التعميّة من الشهادات الأمنيّة دون جانب التحقّق من هويّة المضيف (الموقع) الذي توفّره سلطات الشهادات (وهو جانب مهمّ أيضًا لأمان التصفّح). انقر على زرّ ADVANCED ثم انقر على الرابط الذي ينقلك إلى موقعك (يوجد عادة أسفل الصفحة). ستُنقَل إلى صفحة الموقع. إن نظرت إلى شريط العناوين في المتصفّح فسترى صورة قفل عليه علامة x أمام عنوان الموقع. يعني هذا الرّمز أن المتصفّح لم يستطع التحقّق من هوية الشهادة، إلا أنه يعمّي الاتصال بينك والخادوم. إن أعددتَ إعادة توجيه طلبات HTTP إلى HTTPS فيمكنك التحقق من نجاح الأمر بالذهاب إلى العنوان http://server_domain_or_IP (بدون حرف s في http). إن ظهرت نفس الأيقونة السابقة في شريط العناوين فهذا يعني نجاح الإعداد. الخطوة السادسة: جعل إعادة التوجيه دائما إن كنت متأكّدًا من رغبتك في السماح للطلبات الآمنة فقط (القادمة عبر HTTPS)، وتحقّقت في الخطوة السابقة من عمل توجيه طلبات HTTP إلى HTTPS فيجب عليك جعل إعادة التوجيه دائمة. افتح ملف إعداد المضيف الافتراضي الذي نريد: sudo nano /etc/apache2/sites-available/000-default.conf نبحث عن سطر إعادة التوجيه الذي أضفناه في خطوة سابقة ثم نضيف إليه الكلمة المفتاحية permanent على النحو التالي: <VirtualHost *:80> . . . Redirect permanent "/" "https://your_domain_or_IP/" . . . </VirtualHost> احفظ الملف ثم أغلقه. ملحوظة: إعادة التوجيه التي أعددناها في الخطوة الثانية باستخدام التعليمة Redirect فقط هي من النوع 302. تصبح إعادة التوجيه هذه من النوع 301 (الفرق بين إعادة التوجيه 301و302) عند إضافة الكلمة المفتاحية permanent (دائم) إلى التعليمة. نتحقّق من خلو الإعدادات من أخطاء في الصياغة: sudo apache2ctl configtest ثم عندما يكون كلّ شيء على ما يرام نعيد تشغيل خادوم الوِب: sudo systemctl restart apache2 ترجمة - بتصرّف للمقال How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 16.04 لصاحبه Justin Ellingwood.

توجد بعض الإعدادات التي يجب إجراؤها في البداية كجزء من عملية التثبيت الأولية عند إنشاء خادوم جديد. تؤدي هذه الخطوات إلى تعزيز أمان وقابلية استخدام Usability خادومك ممّا يعطيك أساسًا صلبا للإجراءات اللاحقة. الخطوة الأولى - الولوج Login إلى الحساب الجذر Root يتوجّب عليك، للولوج إلى خادومك، معرفة عنوان IP العمومي Public IP Address إضافةً إلى كلمة سر حساب المستخدم الجذر. إن لم تكن قمتَ بالولوج إلى خادومك من قبل فبإمكانك الاطّلاع على الدرس أساسيات وخيارات الاتصال بخادوم عن بعد باستخدام SSH (البرنامج المسؤول عن الاتصال بالخادوم عن بعد)، الذي يُغطي هذه العملية بالتفصيل. ابدأ بالاتصال بخادومك عن طريق الأمر التّالي (أبدِل الكلمة البارزة بعنوان IP خادومك العمومي): ssh root@SERVER_IP_ADDRESS أكمِل عملية الولوج بقبول التحذيرات حول موثوقية المستضيف Host authenticity في حال ظهورها، وإعطاء معلومات التحقق (كلمة السّر أو المفتاح السري). سيُطلب منك تبديل كلمة سر حساب المستخدِم الجذر إن كانت هذه أول مرة تلِج إلى الخادوم باستخدام كلمة السر. حول المستخدم الجذر المستخدم الجذر هو المُدير في أنظمة لينوكس، ولديه امتيازات Privileges واسعة جدًًا. عمليًا، يُنصَح بعدم استخدام الحساب الجذر في الأمور الاعتيادية، فالصلاحيات الواسعة التي يتمتع بها تُتيح إحداث تغييرات - قد تكون مدمِّرة - في النظام . وليسَ نادرا أن يحدث ذلك بشكل غير مقصود. الخطوة الموالية ستكون إنشاء حساب مستخدم بديل بمجال تأثير محدود للقيام بالعمل اليومي. ستتعلّم أيضًا كيفية الحصول على امتيازات أكبر عندما تحتاج إليها. الخطوة الثانية - إنشاء مستخدم جديد بعد الولوج باستخدام الحساب الجذر تُصبِح على استعداد لإضافة الحساب الجديد الذي سنلِج باستخدامه من الآن فصاعدا. يُنشئ المثال التالي مستخدما باسم "demo"، أبدِلهُ باسم المستخدم الذي تراه مناسِبا: adduser demo ستُطرَح عليك بعض الأسئلة، بدءًا بكلمة سرالحساب. أدخِل كلمة سر قوية. يُمكنك تعبئة بقية المعلومات الإضافية حسب رغبتك. اضغط على زر Enter في لوحة المفاتيح لتجاوز أي حقل لا تودّ تعبئته. الخطوة الثالثة - امتيازات الجذر لدينا الآن حساب مستخدم جديد بامتيازات حساب عادي. سنحتاج في بعض الأحيان إلى القيام ببعض الأعمال الإدارية التي تتطلّب امتيازات الجذر. نستطيع إعداد "مستخدم أعلى" Super user لتجنب الخروج من الحساب العادي والولوج بالحساب الجذر أثناء القيام بالمهام الإدارية. المستخدم الأعلى هو مستخدم عادي ولكنه يستطيع الحصول على امتيازات المستخدم الجذر مؤقتا عن طريق كتابة sudo أمام الأوامر التي يطلب تنفيذها. يتوجّب علينا إضافة المستخدم الجديد إلى مجموعة المستخدمين Users group sudo حتى يتسنى له الحصول على الامتيازات الإدارية. يُسمَح - في الإعداد الافتراضي لأوبنتو 14.04 - للمستخدمين الأعضاء في مجموعة sudo باستخدام أمر sudo. نفّذ باستخدام الحساب الجذر، الأمر التالي لإضافة المستخدم الجديد إلى المجموعة sudo (أبدِل الكلمة البارزة بالاسم الذي اخترتَه للمستخدم الجديد): gpasswd -a demo sudo يُمكِن للمستخدِم الجديد الآن تنفيذ أوامر بامتيازات المستخدِم الأعلى. الخطوة الرابعة - إضافة الاستيثاق عن طريق المفتاح العمومي Public Key Authentication (يوصى بهذه الخطوة) الخطوة التالية في تأمين خادومك هي إعداد مفتاح عمومي Public Key للمستخدم الجديد. هذا الإعداد سيرفع من أمان خادومك بطلب مفتاح SSH سري للولوج. توليد زوج من المفاتيح سيتوجّب عليك توليد زوج مفاتيح (مفتاح عمومي وآخر سرّي). إن كان لديك مفتاح عمومي ترغب في استخدامه تجاوز إلى خطوة نسخ المفتاح العمومي. لتوليد زوج مفاتيح جديدة نفِّذ الأمر التالي على الطّرفيةTerminal محليًّا (على حاسوبك الشخصي): ssh-keygen ستظهر لك مُخرجات شبيهة بما يلي (localuser هنا هو اسم المستخدم الذي يُنفِّذ الأمر): Generating public/private rsa key pair. Enter file in which to save the key (/Users/localuser/.ssh/id_rsa): اضغط زر Enter على لوحة المفاتيح لقبول اسم ومسار حفظ الملف، أو أدخل مسارا لملف جديد. سيُطلب منك بعدها إدخال عبارة سر Passphrase لتأمين المفتاح. عبارة السّر اختيارية ويُمكنك تجاوزها وتركها خاوية. ملحوظة: عند ترك عبارة السر خاوية يُمكن استخدام المفتاح السري للاستيثاق دون الحاجة لإدخال عبارة سر، أما في حال إنشاء عبارة سر فستحتاج للإثنين (عبارة السر والمفتاح السري) للولوج. إنشاء عبارة سر يُعطي أمانا أكبر ولكن لكل من الطريقتين (المفتاح السري وحده أو مع عبارة سر) استخداماتُها، كما أنهما أكثر أمانا من الاستيثاق الأساسي عن طريق كلمة سر. حصلنا الآن على مفتاح سري (id_rsa)، وآخر عمومي (id_rsa.pub) يوجدان في المجلَّد ssh. الموجود في المجلّد الشخصي للمستخدم localuser. تذكَّر أنه لا يجوز على الإطلاق مُشاركة المفتاح السري مع أي شخص لا يحق له الاتصال بخواديمك. نسخ المفتاح العمومي بعد توليد المفتاح العمومي محليًّا ننقلهُ إلى الخادوم. استخدم الأمر التالي لإظهار مفتاحك العمومي (أبدِل مسار الملف في حال غيّرت مسار الحفظ أثناء توليد المفتاح) cat ~/.ssh/id_rsa.pub سيظهر مفتاحك العمومي الذي يُشبه شكلُه التالي: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local حدّد المفتاح العمومي وانسخه إلى الحافِظة Clipboard. إضافة المفتاح العمومي إلى المستخدم الجديد على الخادوم يجب إضافة مفتاح SSH إلى ملف خاص يوجد بالمجلد الشخصي للمستخدِم على الخادوم حتى يتسنى له استعمالُه للاستيثاق. استعمل الأمر التالي - على الخادوم - للانتقال من المستخدِم الجذر إلى المستخدِم الذي أنشأناه في الخطوات الأولى من هذا الدّليل (أبدِل demo باسم المستخدِم الذي اخترتَه): su - demo ستُنقَل بعدَ الولوج إلى الخادوم إلى ملف المستخدم الشخصي. أنشئ مجلَّدا فرعيا جديدا في المجلّد الشخصي باسم ssh. (النقطة جزء من الاسم) مع تقييد الأذون Permissions عن طريق الأوامر التالية: mkdir .ssh chmod 700 .ssh سنُنشئ الآن ملفًا باسم authorized_keys مع فتحه عن طريق محرِّر نصوص. سنستخدِم محرِّر Nano للتعديل على الملف، كما في الأمر التالي: nano .ssh/authorized_keys ثم نأتي لإدراج المفتاح العمومي في الملف عن طريق لصقه في المحرِّر. اضغط على الزريْن CTRL و X معًا في لوحة المفاتيح للخروج من المحرِّر ثم زر Y لحفظ التغييرات وEnter لتأكيد اسم الملف. نُقيّد الأذون على الملف authorized_keys عن طريق الأمر: chmod 600 .ssh/authorized_keys للعودة إلى المستخدِم الجذر ننفِّذ الأمر التالي: exit بإمكانك الآن الولوج إلى حساب المستخدم الجديد عن طريق SSH باستخدام المفتاح السري. الخطوة الخامسة - إعداد SSH يُمكننا، بعد أن أنشأنا حسابَ مستخدم جديدًا، زيادة تأمين الخادوم عن طريق تغيير إعداد SSH . نبدأ بفتح ملف الإعدادات بواسطة محرِّر نصوص مع استعمال المستخدِم الجذر: nano /etc/ssh/sshd_config تغيير منفذ Port الاتصال عن طريق SSH (اختياري) أولى التغييرات ستكون تعديل المنفذ الذي يستخدمه SSH للاتصال بالخادوم. ابحث عن السّطر التالي: Port 22 عند تغيير هذا الرقم إلى آخر بين 1025 و 65536 فإن خدمة SSH ستستخدم المنفذ الجديد للاتصال بالخادوم بدلا من المنفذ الافتراضي (22). يُحاول بعض المستخدمين غير المسموح لهم بالولوج استعمال منفذ SSH الافتراضي الوصول إلى الخادوم. تغيير المنفذ يعني إضافة خطوات جديدة أمام هذا النوع من المستخدمين لأنه يضطرهم إلى تجربة منافذ عديدة لمعرفة أيها يُستخدم من طرف SSH. يجب عند تغيير منفذ SSH تذكر رقم المنفذ الجديد حتى يُمكن الاتصال عن بعد بالخادوم. سنُغيِّر منفذ SSH إلى 4444. يعني هذا أنه يتوجب إخبار الخادوم عند الاتصال برقم المنفذ المُستخدَم لكي لا يستخدم المنفذ الافتراضي، وهو ما سنشرحه لاحقا. Port 4444 تقييد ولوج المستخدم الجذر عبر SSH بعد تغيير منفذ SSH نبحث عن السّطر التالي: PermitRootLogin yes يُتيح هذا السطر إمكانية السماح للمستخدم الجذر أو منعه من الولوج عن طريق SSH. يُعتبَر هذا الإجراء أكثر أمانا حيثُ يمكن الولوج بالمستخدم العادي عن طريق SSH ثم استخدام صلاحيات المستخدم الجذر عن الحاجة. نُغيّر السطر بإبدال yes ب no لمنع المستخدم الجذر من الولوج عن بعد. PermitRootLogin no يُنصَح دائما، من أجل أمان أكبر، بتقييد ولوج المستخدم الجذر عبر SSH. بعد إنهاء التعديلات احفَظ الملف وأغلقه باستخدام الطريقة التي رأيناها سابقا (CTRL+X، ثم Y و ENTER بعد ذلك). الخطوة السادسة - إعادة تحميل SSH انتهينا الآن من تحرير الإعدادات. لأخذها في الاعتبار نُعيد تشغيل خدمة SSH عن طريق الأمر التالي: service ssh restart يجب أن نتأكد من أن الإعداد الجديد يعمل بشكل جيّد قبل الخروج، حتى لا نجد أنفسَنا في وضعية لا يُمكن فيها الولوج عن بعد إلى الخادوم. افتح نافذة جديدة لواجهة الأوامر على حاسوبك الشخصي. سنجري في النافذة الجديدة اتصالا مع الخادوم باستعمال حساب المستخدم العادي الذي أنشأناه بدلا من المستخدِم الجذر. يجب ذكر رقم منفذ الولوج إلى خادوم لا يستخدم المنفذ الافترضي للاتصال عن طريق SSH وذلك بإضافة العبارة "p 4444-" إلى أمر الاتصال حيثُ 4444 هو رقم المنفذ الجديد. للولوج إلى الخادوم عن طريق المنفَذ الذي أعددناه في الخطوة السابقة نستخدم الأمر التالي (أبدِل SERVER_IP_ADDRESS بعنوان خادومك و demo باسم المستخدِم): ssh -p 4444 demo@SERVER_IP_ADDRESS ملحوظة: لا تنسَ، إن كنت تستخدم برنامج PuTTY، تغيير إعداد المنفَذ في البرنامج حتى يتوافق مع الإعداد الحالي لخادومك. سيُطلب منك إدخال كلمة سر المستخدم الجديد ثم، بعد التحقق، ستلِج إلى المجلد الشخصي للمستخدم على الخادوم. تذكّر إضافة sudo أمام الأوامر التي ترغي في تنفيذها بصلاحيات المستخدِم الجذر: sudo command_to_run حيثُ command_to_run هو الأمر المُراد تنفيذه. إذا جرت الخطوات السّابقة كما وصفناها فإن كل شيء على ما يُرام ويُمكنك الخروج عن طريق الأمر exit ماذا بعد هذا الدرس؟ بالوصول إلى هذه النقطة فإن لدى خادومك أساسا قويا، ويُمكنك تثبيت أي برنامج ترغب فيه عليه. يُمكنك المُتابعة مع هذه السلسة بقراءة مقال خطوات إضافية موصى بها لخواديم أوبنتو 14.04 الجديدة الذي يشرح أمورا من قبيل تفعيل fail2ban للحد من فعاليّة هجمات القوة العمياء Brute force attacks، الإعدادات الأساسية للجدار الناري Firewall، بروتكول NTP وملفات الإبدال Swap. كما أنّ به روابطَ لشروح حول كيفية تثبيت وإعداد بعض تطبيقات الويب الشائعة. مقالات مثل إعداد حِزم LAMP أو LEMP جيّدة لمن يُريد استكشاف المزيد. ترجمة -وبتصرّف- للمقال: Initial Server Setup with Ubuntu 14.04 لصاحبه Justin Ellingwood.

مقدمة في كثيرٍ من الأحيان يصبح نقل الملفات من وإلى الخادوم عملية متعبة، يعرف ذلك جيدًا كل من يمتلك أو يدير خادومًا يضم موقعه الشخصي أو ماشابه، إنه يعرف تلك العملية المستمرة المتكررة والتي تبدأ بتنزيل الملفات من الخادوم البعيد لإدخال بعض التعديلات عليها (والتي غالبًا ما تكون صغيرة) ومن ثم إعادة رفعها واختبارها، وإذا كان التعديل خاطئا فستجد نفسك محبطًا لاضطرارك تنزيل نسخة جديدة من الملف لتعديلها وإعادة رفعها. لحسن الحظ هناك طريقة بسيطة تتيح لنا ربط الخادوم البعيد مع جهازنا الشخصي، بحيث نتمكّن من إدارته كما لو كان قرصًا محليًا لدينا بما في ذلك إنشاء وتعديل الملفات عليه بينما تتم عملية رفع الملفات الجديدة أو المعدلة تلقائيًا إلى الخادوم. سيتناول هذا المقال كيفية تركيب واستخدام الأداة SSHFS للقيام بذلك. تركيب SSHFS على دبيان والتوزيعات المبنية عليها بنيت SSHFS لتعمل على لينكس أساسًا، لذا يمكن تركيبها بسهولة على جهازك عن طريق استدعائها من المستودع الرسمي لتوزيعتك، لمستخدمي دبيان لينكس (أو الأنظمة المبنية عليها مثل Ubuntu أو Mint) يتم ذلك من خلال الأمر apt-get. sudo apt-get install sshfs على فيدورا، CentOS يمكن استخدام مدير الحزم yam كما يلي (وفق صلاحيات الجذر root). yum install fuse-sshfs على Archlinux من خلال مدير الحزم pacman. sudo pacman -S sshfs على نظام OSX مستخدمو أجهزة Mac عليهم تركيب كلًا من حزمتي FUSE و SSHFS من موقع osxfuse. على نظام Windows لاستخدام SSHFS على الأجهزة العاملة بنظام Windows نحتاج للحصول على برنامج win-sshfs من مستودعه الخاص على google code من الرابط أدناه. بعد تنزيل الحزمة السابقة يمكن تركيبها بسهولة بالنقر المزودج عليها، قد يخبرك معالج التركيب بالحاجة إلى تنزيل ملفات إضافية من الشبكة (مثل إطار .NET Framework 4.0) وتركيبها على الجهاز. https://win-sshfs.googlecode.com/files/win-sshfs-0.0.1.5-setup.exe استخدام SSHFS لربط نظام ملفات بعيد التعليمات التالية مخصصة لأنظمة لينكس و Mac OSX، مستخدمي ويندوز عليهم الانتقال إلى الفقرة التالية. في البداية يتوجب علينا إنشاء مجلد جديد لاستخدامه كنقطة ربط لنظام الملفات المستهدف. sudo mkdir /mnt/test يمكنك استبدال test بأي اسم ترغب به. كل شيء بات جاهزًا حيث يمكنك الآن ربط نظام الملفات محليًا باستخدام الأمر التالي: sudo sshfs root@192.168.1.200:/ /mnt/test ملاحظات: 192.168.1.200، هو عنوان IP الذي استخدمته للدخول إلى خادوم دبيان الخاص بي. مجلد test سيعرض نظام الملفات البعيد. ستسألك sshfs عن كلمة المرور في حال كنت تستخدم واحدة، أدخلها للمتابعة. أما في حال استخدامك مفتاح توثيق key authorization لتسجيل الدخول، فعليك اخبار sshfs بمفتاحك العام من خلال الأمر التالي والذي سيطلب منك إدخال عبارة المرور التي استخدمتها أثناء إنشاءك المفتاح مع ssh-keygen sudo sshfs -o IdentityFile=~/.ssh/id_rsa root@192.168.1.200:/ /mnt/test يمكنك الآن العمل على نظام الملفات البعيد كما لو كان قرصًا إضافيًا موصولًا إلى جهازك. على سبيل المثال كل ملف تعمل على إنشائه في مجلد test المحلي سيتم رفعه إلى الخادوم البعيد الخاص بك مباشرة (سواء أكنت تستخدم خادومًا افتراضيًا أو حقيقيًا)، يشمل ذلك النسخ، التعديل، الحذف، وغيره.. نقطة مهمة يجب الانتباه إليها، وهي أن عملية الربط السابقة مع الخادوم مؤقتة فإذا ما تم إيقاف أو إعادة تشغيل جهازك أو جهاز الخادوم فيجب تكرار الخطوات السابقة مجددًا. عندما تنتهي من العمل يمكنك إلغاء ربط نقطة الوصول بسهولة باستخدام sudo umount /mnt/test ربط نظام الملفات بشكل دائم إذا كنت ترغب في تثبيت نقطة الربط السابقة كي لا يتم إلغاؤها مع إيقاف أو إعادة تشغيل أيٍّ من جهازك أو الخادوم البعيد، فنحن بحاجة إلى إدخال بعض التعديلات على ملف /etc/fstab في جهازك المحلي لتفعيل نقطة الربط تلقائيًا مع كل إقلاع. في البداية علينا تحرير ملف /etc/fstab بصلاحيات الجذر باستخدام محرر nano في الطرفية sudo nano /etc/fstab بعد ذلك أضف السطر التالي أسفل ملف fstab sshfs#root@192.168.1.200:/ /mnt/test احفظ التعديلات بالضغط على Ctrl مع X ثم اكتب yes واضغط Enter. بينما تغني الخطوة الأخيرة عن تكرار عملية الربط بشكل يدوي وإدخال عبارة المرور ومفاتيح ssh في كل مرة، إلا أنها تنطوي على مخاطر أمنية، ففي حال تعرض جهازك المحلي لاختراق أو سرقة على سبيل المثال فسيغدوا خادومك البعيد عرضةً لذلك أيضًا، لذا لا ينصح عادةً بالتعديل على ملف fstab لإنشاء ربط تلقائي. استخدام Win-SSHFS لربط نظام الملفات على أجهزة Windows لربط نظام ملفات بعيد على Windows سنستعين ببرنامج win-sshfs والذي يملك واجهة رسومية بسيطة تقودنا خطوة بخطوة لإنجاز المطلوب، وذلك على النحو المبين آتيًا: بعد تشغيل البرنامج اضغط على زر Add أسفل يسار النافذة. أدخل اسما للخادوم الذي ستستضيف ملفاته من خانة Drive Name field. أدخل عنوان الـ IP الخاص بالخادوم. أبق الرقم 22 في خانة المنفذ SSH port (إلا إذا قمت بتغيير منفذ SSH يدويًا). أدخل اسم المستخدم في حقل Username. أدخل كلمة مرور SSH خاصتك في خانة password (في Windows لا يمكننا إعداد الحساب بتوثيق مفاتيح SSH). أدخل المسار الذي ترغب بربطه من الخادوم البعيد في حقل Directory، استخدم / لربط نظام الملفات ابتداء من مسار الجذر، أو /var/www لربط مجلد المنزل. اختر حرفًا من حقل Dirve Leter كي يستخدمه Windows كاسم لقرص نظام الملفات البعيد عند ربطه في جهاز الكمبيوتر. أخيرًا إضغط على زر Mount لإنشاء الإتصال وتفعيل نقطة الربط. يمكنك التوجه إلى جهاز الكمبيوتر حيث ستشاهد قرصًا جديدًا يحمل الحرف الذي كنت قد اخترته منذ قليل ويحوي نظام ملفاتك البعيد. استخدامات نقطة الربط كما سبق وأشرنا يمكن التعامل مع نقطة الربط المنشأة كما لو كانت قرصًا إضافيًا على جهازك المحلي، يشمل ذلك عمليات النسخ، اللصق، النقل، التحرير، الإنشاء، الضغط، وأية عملية يمكن إجراءها على نظام الملفات باستثناء القدرة على تشغيل البرامج أو السكربتات scripts. علاوة على تسهيل الوصول إلى ملفات الخادوم البعيد الخاص بك، يتيح إنشاء نقطة الربط استخدام البرامج التي تفضلها، إذ يمكنك تحرير ملفّات موقعك الشخصي على سبيل المثال بالمحرر الذي تحبّ، كما يمكنك تعديل البرمجيات باستخدام بيئة IDE التي تفضل، وحالما تنتهي من إجراء التعديلات وحفظها على حاسبك، ستكون في طريقها إلى الخادوم البعيد كذلك. إضافةً إلى ذلك فإن استخدام نقطة الربط يتيح لك اختبار التعديلات التي تعمل عليها بشكل فوري ودون الحاجة إلى تنزيل الملف من الخادوم، التعديل عليه، ومن ثم إعادة رفعه لمشاهدة النتائج، لا سيما عند إجراء اختبارات متكررة والتي تجعل من العملية السابقة مملة بشكل كبير. ترجمة -وبتصرّف- للمقال How To Use SSHFS to Mount Remote File Systems Over SSH

ينصبّ الاهتمام عند إعداد بنية تحتيّة Infrastructure - عادةً - على جعل التّطبيقات تعمل بالطّريقة المرجوّة. ما لا ينتبه له الكثيرون أنّ التّركيز على عمل التّطبيقات دون الاهتمام الكافيّ بالاحتيّاجات الأمنيّة للبنية التحتيّة يُمكن أن تنتُج عنه نتائج كارثيّة في حال حدوث عمليّات اختراق. سنشرح في هذا الدّليل بعض التّصرّفات الأمنيّة الأساسيّة الّتي ينبغي تنفيذها قبل إعداد تطبيقاتك أو أثناءه. مفاتيح SSH تُستخدَم مفاتيح SSH بديلًا عن الاستيثاق المعتمد على كلمات السّرّ Password-based authentication للاتّصال بخادوم SSH؛ وهي عبارة عن زوج من المفاتيح، علنيّ Public وسريّ Private، تُنشأ قبل الاستيثاق. يحتفظ المستخدم بالمفتاح السّرّي ولا يُشاركه مع أيّ كان، في حين يُمكن مشاركة المفتاح العلنيّ. يجب وضع المفتاح العلنيّ للمستخدِم ضمن مجلَّد خاصّ على الخادوم حتى يُمكنَ استخدامُ الاستيثاق عن طريق مفاتيح SSH. يطلُب الخادوم، عند محاولة المستخدِم الاتّصال به، دليلًا على أنّ العميل Client يمتلك المفتاح السّري الموافق للمفتاح العلنيّ الموجود على الخادوم. يستخدم عميل SSH طريقة تُثبت للخادوم امتلاكه للمفتاح السّرّي للمستخدِم؛ فيسمح الخادوم للمستخدِم بالولوج دون كلمة سرّ. 1- كيف تحسّن مفاتيح SSH من الأمان؟ تُعمّى Encryption تمامًا كلّ إجراءات الاستيثاق، بما فيها الاستيثاق عن طريق كلمة السّر، عند استخدام SSH. في المقابل، يُمكن لسيّئي النّيّات - عند السّماح بالاستيثاق عن طريق كلمات السّرّ - محاولة الولوج إلى الخادوم مرارًا وتكرارًا عبر تخمين كلمة السّرّ. تمنح القدرات الحاليّة للحواسيب المهاجمين على تشغيل محاولات الاختراق آليًّا إلى أن يُعثَر على كلمة السّرّ الصّحيحة. يسمح إعداد استيثاق يعتمد على مفاتيح SSH بتعطيل الاستيثاق عن طريق كلمات السّرّ؛ إذ تحوي مفاتيح SSH عمومًا محارف أكثر بكثير من أيّ كلمة سرّ وهو ما يعني وجود إمكانيّات أكثر يجب على المُهاجم تجربتها. تعدّ الكثير من خوارزميّات غير قابلة للكسر، لسبب بسيط هو أنّ العتاد المتوفّر حاليًّا سيستغرق عقودًا أو أكثر للمرور بجميع الاحتمالات الممكنة. 2- ما مدى صعوبة إعداد الاستيثاق اعتمادًا على مفاتيح SSH؟ ضبط مفاتيح SSH سهلٌ جدًّا، كما أنّها الطّريقة الّتي يُنصَح بها للولوج عن بعد إلى خواديم لينكس ويونكس. يُمكن في ظرف دقائق إنشاء زوج من مفاتيح SSH على جهازك الشّخصيّ ثمّ نقل المفتاح العلنيّ إلى الخواديم. إذا كنت تشعر أنّك تحتاج للاستيثاق بالاعتماد على كلمات السّر فمن الجيّد استخدام حلول مثل fail2ban على خادومك للحدّ من إمكانيّة تخمين كلمة السّرّ. الجدران النّاريّة Firewalls الجدار النّاري عبارة عن برنامج (أو عتاد) يتحكّم في الخِدْمات المعروضة عبر الشّبكة. يعني هذا حظر أو تقييد الوصول إلى أي منفَذ Port لا يدخل ضمن المنافذ المتاحة للعموم. توجد بعض الخدمات الّتي تُشغَّل افتراضيًّا في الكثير من الخواديم. يُمكن تقسيم هذه الخِدْمات إلى المجموعات التّاليّة: الخِدْمات العموميّة الّتي يُمكن لأيّ كان الوصول إليها عبر الإنترنت، غالبًا بصفةِ مجهول. خادوم الويب مثال جيّد على هذه المجموعة، إذ يسمح عادةً للجميع بالوصول إلى موقع الويب. الخِدْمات الخاصّة الّتي لا يُمكن الوصول إليها لغير مجموعة حسابات مُرخَّص لها أو من أماكن محدَّدة . لوحة التّحكّم في قاعدة البيانات مثال على هذه المجموعة من الخِدْمات. الخِدْمات الدّاخليّة الّتي يمكِن الوصول إليها فقط من الخادوم نفسِه؛ دون أن تُعرَض للعالم الخارجيّ. قاعدة بيانات لا تقبل سوى الاتّصالات المحليّة (من الخادوم) مثال على هذه المجموعة. تتأكد الجدران النّاريّة من أنّ الوصول إلى برنامجك مقيّد وفقًا للمجموعات أعلاه. تُترك الخِدمات العموميّة مفتوحةً ومتاحةً للجميع بينما يُحصَر الوصول إلى الخِدْمات الخاصّة اعتمادا على معايير محدَّدة. بالنّسبة للخِدمات الدّاخليّة فيُمكن جعلُها غير مرئيّة تمامًا من خارج الخادوم. تمنع أغلب إعدادات الجدران النّاريّة تمامًا الوصولَ إلى المنافذ غير المستعملة. 1- كيف تحسّن الجدران النّاريّة من الأمان؟ الجدران النّاريّة جزء أساسيّ من إعداد أيّ خادوم. يُشكّل الجدار النّاري طبقة حماية إضافيّة، حتى ولو كانت البرامج الّتي تستخدمها تطبّق تدابير أمنيّة أو تقتصِر على الواجهات الّتي تريد لهذه البرامج العمل عليها. يمنع جدار ناريّ مضبوط بطريقة صحيحة الوصول إلى جميع الخِدمات ما عدا تلك الّتي تحتاج إلى أن تبقى مفتوحة. يقلّل عرض مجموعة برامج قليلة من الجوانب الّتي يُمكن إتيان الخادوم منها ممّا يعني قابليّةً أقلّ للتّعرّض للثّغرات الأمنيّة. 2- ما مدى صعوبة إعداد الجدران النّاريّة؟ توجد جدران ناريّة كثيرة على أنظمة لينكس، تختلف في صعوبة التّعامل معها. بصفة عامّة، يجب ألّا تتجاوز مدّة ضبط الجدار النّاري بضع دقائق؛ كما أنّه عمليّة تُجرى عند الإعداد الابتدائيّ للخادوم أو عند تغيير الخِدمات المتاحة عبر الخادوم. جدار UFW خيّار سهل. توجد أيضًا خيّارات أخرى مثل استخدام iptables أو جدار CSF النّاريّ. الشّبكات الخاصّة الافتراضيّة VPN والتّشبيك الخاصّ Private Networking الشّبكات الخاصّة هي شبكات متاحة لبعض الخواديم أو المستخدمين فقط؛ أمّا الشّبكات الخاصّة الافتراضيّة Virtual private network (أو VPN) فهي طريقة لإنشاء اتّصالات آمنة بين جهازيْن متباعديْن بحيث يظهر الاتّصال كما لو أنّه في شبكة خاصّة محليّة. تُتيح الشّبكات الخاصّة الافتراضيّة طريقة لإعداد خِدمات موجودة على خواديم متباعدة بحيثُ تظهر وكأنّها في شبكة خاصّة كما أنّها تؤمّن الاتّصالات بين خواديم متباعدة. 1- كيف تحسّن الشّبكات الخاصّة من الأمان؟ يُنصح دائمًا بتفضيل الشّبكات الخاصّة بدلًا من العموميّة في الاتّصالات الدّاخليّة كل ما كان ذلك ممكنًا. مع ذلك يجب تطيق تدابير أمنيّة إضافيّة لتأمين الاتّصالات بين الخواديم والحؤول دون وصول مستخدمي الشّبكة الدّاخليّة غير المرخَّص لهم إلى خواديمك. يُعدّ استخدام شبكات خاصّة افتراضيّة طريقة ذات فعاليّة لوضع شبكة خاصّة لا تُمكن لغير رؤيتها خواديمك؛ ستكون الاتّصالات خاصّة ومؤمّنة تمامًا. يُمكن ضبطُ بقيّة التّطبيقات لتمرير بياناتها عبر الواجهات الافتراضيّة الّتي يعرضها برنامج الشّبكات الخاصّة الافتراضيّة. لا تُعرض في هذا الإعداد عبر شبكة الإنترنت سوى سوى الخدمات الموجهة للعملاء العموميين. 2- ما مدى صعوبة إعداد الشّبكات الخاصّة الافتراضيّة؟ من السّهل استخدام الشّبكات الخاصّة في مراكز البيانات Data centers الّتي لديها هذه القدرة، إذ يقتصر الأمر على تفعيل واجهات الشّبكة أثناء إنشاء الخادوم وإعداد التّطبيقات والجدار النّاريّ لاستخدام الشّبكة الخاصّة. انتبه إلى أنّ الشّبكات الخاصّة الّتي تمتدّ عبر مركز البيانات تشترك في نفس الشّبكة مع بقيّة الخواديم. بالنّسبة للشّبكات الخاصّة الافتراضيّة فإنّ الإعداد الابتدائيّ أكثر تعقيدًا؛ إلّا أنّ الرّفع من مستوى الأمان يُعوّض الجهد في أغلب الحالات. يتطلّب إعداد شبكات خاصّة افتراضيّة تثبيت وضبط إعداد الأمان المشتركة على كلّ خادوم؛ ثمّ بعد إطلاق وتشغيل الشّبكة الخاصّة الافتراضيّة، إعداد التّطبيقات لاستخدامها. البنية التّحتيّة للمفاتيح العلنيّة PKI والتّعميّة بواسطة SSL/TLS تُحيل البنية التّحتيّة للمفاتيح العلنيّة Public key infrastructure (أو PKI) إلى نظام مُصمّم لإنشاء، إدارة والتحقق من شهادات Certificates تحديد الهويّة وتعميّة الاتّصال. يُمكن استخدام شهادات SSL أو TLS لتوثيق عناصر من النّظام لدى أخرى. يمكن - بعد الاستيثاق - استخدام الشّهادات لتعميّة الاتّصال. 1- كيف تحسّن البنية التّحتيّة للمفاتيح العلنيّة من الأمان؟ يُمكّن التّأسيس لسلطة شهادات Certificate authority وإدارتها ضمن خواديمك كلَّ عنصُر داخل بنيتك التّحتيّة من التّحقّق من هويّة بقيّة العناصر وتعميّة البيانات المتلادلة معها. يُمكن أن تمنع هذه الآليّة هجمات من نوع “رجل في الوسط” Man-in-the-middle الّتي يحاكي فيها المهاجم أحد الخواديم ضمن بنيتك التّحتيّة بهدف التقاط حركة البيانات. يُمكن ضبط كلّ خادوم ليثق في سلطة شهادات مركزيّة بحيث تُصبح أي شهادة تُوقّع عليها السّلطة المركزيّة موثوقة. إذا كانت التّطبيقات والبروتوكولات الّتي تستخدمها للاتّصال تدعم التّعمية بواسطة TLS/SSL، فإنّ هذه طريقة لتعميّة النّظام دون إغراق الاتّصال عن طريق شبكة خاصّة افتراضيّة (يدخل SSL غالبًا في آليّة عمل الشّبكات الخاصّة الافتراضيّة). 2- ما مدى صعوبة إعداد بنية التّحتيّة للمفاتيح العلنيّة؟ قد يحتاج إعداد سلطة شهادات وتثبيت بقيّة البنية التّحتيّة للمفاتيح العلنيّة في البداية لكثير من المجهود. علاوةً على ذلك فإنّ إدارة الشّهادات قد تزيد عبئًا إضافيًّا عند الحاجة لإنشاء شهادات جديدة، توقيعها أو إبطالها. لن يُشكّل تنفيذ بنية تحتيّة متكاملة للمفاتيح العلنيّة إضافةً محسوسة للكثير من المستخدمين إلّا عند زيادة احتيّاجاتهم. ربّما يكون تأمين الاتّصال بين عناصر البنية التّحتيّة عبر شبكات خاصّة افتراضيّة إجراءً مناسبًا إلى أن يصلوا إلى المرحلة الّتي تُصبح فيها بنية المفاتيح العلنيّة تعوّض الجهد الإضافيّ المبذول لإدارتها. فحص الخدمات Service auditing تطرّقنا حتى الآن لتقنيّات يُمكن اللّجوء إليها للرّفع من مستوى الأمان. يقبع جزء مهمّ من الأمان في تحليل الأنظمة المستخدَمة، فهم الجوانب الّتي يُمكن أن تُؤتَى منها، وقفل العناصر حسب إمكاناتك. يُشير فحص الخدمات إلى العمليّة الّتي تكتشف عن طريقها الخدمات العاملة في البنية التّحتيّة. يُضبط - غالبًا - نظام التّشغيل ليبدأ تشغيل خدمات معيّنة عند الإقلاع Boot. قد تجرّ البرامج الإضافيّة اعتماديّات Dependencies تُشغَّل هي الأخرى آليًّا عند الإقلاع. يسمح فحص الخدمات بمعرفة الخدمات العاملة على النّظام، المنافذ المستخدمة للاتّصالات، والبروتوكولات المقبولة. تُساعد هذه المعلومات في ضبط إعدادات الجدار النّاريّ. 1- كيف يُحسّن فحص الخدمات من الأمان؟ تُشغّل الخواديم عمليّات Processes عديدة لأداء أعمال داخليّة في الخادوم أو للتّعامل مع عملاء خارجيّين. يُمثّل كلّ واحد من هذه العناصر وسيلةً محتملة قد يستغلّها مستخدمون ذوو نيّات خبيثة لمهاجمة الخادوم؛ فكلّ ما زادت الخدمات الّتي تشغّلها زاد احتمال وجود ثغرات في البرامج الّتي تستخدمها. يُمكن أن تبدأ تحليل الخدمات الموجودة على جهازك فور حصولك على فكرة جيّدة عنها. في ما يلي بعض الأسئلة الّتي يجب أن تطرحها لكلّ واحدة من هذه الخِدمات: هل أحتاج لهذه الخدمة؟ هل تعمل الخدمة على واجهات لا تحتاج إليها؟ هل يحب تحديدها بعنوان IP واحد؟ هل قواعد الجدار النّاريّ معدّة بطريقة تسمح للبيانات المرخَّص لها بالمرور إلى الخدمة؟ هل يمنع الجدار النّاريّ الوصول غير المرخَّص إلى الخدمة؟ هل لديك وسيلة تحصُل بها على إشعارات عن الثّغرات المُكتشفة في البرنامج؟ يجب أن يكون فحص الخدمة تدبيرًا قيّاسيًّا عند إعداد أي خادوم جديد. 2- ما مدى صعوبة إعداد فحص الخدمات؟ الفحص الأساسيّ للخدمة سهلٌ جدًّا، إذ يعرض أمر netstat الخدمات الّتي تُنصِت لحركة البيانات عبر منافذ كلّ واجهة. في ما يلي مثال يعرض اسم البرنامج، معرّف العمليّة PID والعناوين المستخدَمة لحركة البيانات وفقًا لبروتوكول نقل البيانات (TCP أو UDP): sudo netstat -plunt ستكون المُخرجات مقاربة للتّاليّة: Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 887/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/nginx tcp6 0 0 :::22 :::* LISTEN 887/sshd tcp6 0 0 :::80 :::* LISTEN 919/nginx الأعمدة الأساسيّة الّتي يجب عليك الانتباه إليها هي Porto (المنفذ) ، Local Address (العنوان المحلّي)، ومعرّف العمليّة/البرنامج (PID/Program). إذا كان عنوان IP الّذي تستقبل الخدمة عليه الاتّصالات هو 0.0.0.0 فهذا يعني أنّ الخدمة تقبل الاتّصالات من جميع الواجهات. فحص الملفّات وأنظمة الكشف عن التّطفّل Intrusion detection systems نعني بفحص الملفّات العمليّة الّتي بموجبها نُقارن وضعيّة النّظام الحاليّة بسجلّ لملفّات النّظام وخصائصها عندما كان في وضعيّة تُعرف بأنّها جيّدة. يُستخدم فحص الملفّات للتّعرّف على التّغييرات الّتي يُمكن أن يكون النّظام قد سمح بها. نظام الكشف عن التّطفّل (IDS اختصارًا) هو برنامج يُراقب نظام التّشغيل أو الشّبكة بحثًا عن أنشطة غير مسموح بها. تعتمد الكثير من أنظمة الكشف عن التّطفّل المُستضافة على الخادوم على طريقة فحص الملفّات للتّحقّق من وجود تعديلات في نظام التّشغيل. 1- كيف تُحسّن أنظمة الكشف عن التّطفّل وفحص الملفّات من الأمان؟ إذا كنت مهتمًّا بالرّفع من مستوى أمان بنيتك التّحتيّة فمن المفيد إجراء فحوص على مستوى الملفّات، مثلها مثل الخدمات. يُمكن أن يكون هذا الإجراء دوريًّا، يؤدّيه المسؤول؛ أو آليًّا ضمن نظام للكشف عن التّطفّل. تعدّ هذه الوسائل من الطّرق القليلة الّتي تتأكّد من خلالها أنّ نظام الملفّات Filesystem لم يغيِّره أو يُعدِّل عليه مستخدم أو برنامج. يُفضّل المتطفّلون في كثير من الأحيان، لأسباب مختلفة، البقاء متخفّين للاستمرار في استغلال الثّغرات الموجودة في النّظام لمدّة أطول. يُمكن لمن يستغلّ ثغراتٍ في النّظام أن يُبدل ملفّات تنفيذيّة بنُسخ مُعدَّلة منها؛ سيُخبرك فحص نظام الملفّات بالملفّات المُعدًّل عليها إن وُجدت ممّا يُساعد في التّأكّد من تكامل بيئة الخادوم. 2- ما مدى صعوبة إعداد فحص الملفّات وأنظمة الكشف عن التّطفّل؟ قد يكون تثبيت نظام للكشف عن التّطفّل أو إجراء فحص للملفّات عمليّة إضافيّة تأخذ جهدًا لا بأس به. يتضمّن الإعداد الابتدائيّ إخبارَ نظام الكشف عن التّطفّل يكلّ التّغييرات غير القياسيّة الّتي أجريتها على الخادوم، وتحديدَ مسارات قد تُستثنى لإنشاء خطّ مرجعيّ للاعتماد عليه. تجعل أنظمة الكشف عن التّطفّل من عمليّات الإدارة اليوميّة أكثر تكرارًا وتعقّد من تحديث البرامج ونظام التّشغيل، حيث ستحتاج لإعادة التّحقّق من النّظام قبل تنفيذ التّحديثات ثمّ إعادة إنشاء الخطّ المرجعيّ بعد تنفيذ التّحديثات لرصد أي تغييرات على إصدارات البرامج. يجب أيضًا نقل تقارير الكشف إلى مكان آخر غير النّظام الّذي حدث فيه الكشف لمنع المتطفّلين من تعديلها للتّغطيّة على آثارهم. ستزيد أنظمة الكشف عن التّطفّل بلا شكّ من عبْء الإدارة، ولكنّ مقارنة حالة النّظام الحاليّة بأخرى تعرف أنّها جيّدة هيّ الطّريقة الوحيدة للتّأكّد من أنّ الملفّات لم يُعدَّل عليها من دون علمك. Tripwire وAide من أكثر أنظمة الكشف عن التّطفّل انتشارًا. بيئات تنفيذ Execution environments معزولة يُحيل مفهوم “بيئة التّنفيذ المعزولة” إلى أيّ طريقة تشغيل تعمل بموجبها العناصر في مساحات عمل مخصَّصة لها. يُمكن أن تُعدّ بيئة تنفيذ معزولة بتشغيل عناصر التّطبيقات في خواديم خاصّة بها، أو بإعداد الخدمات للعمل في بيئات chroot أو حاويّات Containers. يعتمد مستوى العزل إلى حدّ بعيد على متطلّبات تطبيقاتك وواقع بنيتك التّحتيّة. 1- كيف يُحسّن عزل بيئات التّنفيذ من الأمان؟ يزيد عزل العمليّات في بيئات تنفيذ مستقلّة من قدرتك على تحديد المشاكل الأمنيّة الّتي يُمكن أن تتعرّض لها. يحُدّ الفصل بين العناصر المستقلّة في البنية التّحتيّة من وصول المخترقين إلى بقيّة العناصر في البنية التّحتيّة. 2- ما مدى صعوبة عزل بيئات التّنفيذ؟ تتوقّف صعوبة - أو سهولة - عزل التّطبيقات على طريقة الفصل الّتي تختارها. يُمكن عبر تحزيم التّطبيقات في حاويّات مستقلّة، الحصول بسرعة على مستوى من عزل التّطبيقات؛ ولكن يجب الانتباه إلى أنّ Docker لا يتعامل مع إعداد الحاويّات على أنّه ميزة أمنيّة. قد يوفّر إعداد بيئة Chroot لكلّ عنصُر مستوى من العزل هو الآخر، لكنّ هذه الطّريقة ليست مضمونةً بالكامل لعزل التّطبيقات؛ إذ توجد دائمًا وسيلة لكسر بيئات Chroot. يوفّر نقل العناصر إلى أجهزة مُخصَّصة أفضل مستوى من العزل، كما أنّه الوسيلة الأسهل في كثير من الأحيان؛ ولكنّه في المقابل الخيّار الأغلى نظرًا لثمن الأجهزة الإضافيّة. خاتمة قدّمنا في هذا الدّليل بعض التّحسينات الممكنة، وليس كلّها، من أجل الرّفع من مستوى الأمان في البنية التّحتيّة. تقلّ فعاليّة التّدابير الأمنيّة كلّ ما طال الانتظار في إجرائها. لا يجوز النّظر إلى التّدابير الأمنيّة على أنّها ملحقات، ويجب تنفيذها من البداية إلى جانب الخدمات والتّطبيقات. ترجمة بتصرّف لمقال 7 Security Measures to Protect your Servers.

أحيانًا تكون على شبكة غير آمنة أو لديها جدار ناري يملك قيودًا مُفرطة، وتحتاج الوصول إلى موقع على شبكة الإنترنت. تريد أن تتأكد أنه لا أحد في المنتصف يشاهد البيانات المارة. أحد الحلول هو استخدام VPN، ولكن يتطلب VPN برنامج عميل خاص على حاسوبك، وقد لا يكون لك صلاحيات اللازمة لتثبيته. إذا كان كل ما تريد تأمينه هو متصفح الويب الخاص بك، فهناك بديل بسيط: نفق وسيط SOCKS 5. وسيط SOCKS هو بالأساس نفق SSH حيث توّجه تطبيقات مُحدّدة دفق بياناتها خلال النفق إلى الخادوم، ثمّ على الخادوم، يقوم الوسيط (Proxy) بإعادة توجيه دفق البيانات إلى شبكة الإنترنت. على عكس VPN، يجب أن يتم ضبط وسيط SOCKS لكل تطبيق على حدة في حاسوب العميل، ولكن يُمكن إعداده بدون أي وكلاء عميل متخصصة. طالما لديك خادوم بوصول SSH، فيمكن استخدامه كوسيط SOCKS. سنستخدم خادوم أوبنتو 14.04 كالوسيط، ومتصفح فَيرفُكس كتطبيق العميل. وعندما ننتهي ينبغي أن تكون قادرًا على تصفح المواقع بشكلٍ آمن عبر النفق. المتطلبات كما ذُكر بالأعلى، أول شيء نحتاجه هو خادوم يعمل بأي توزيعة لينكس، مثل أوبنتو 14.04، بوصول SSH. أنشئ خادوما (هذا المثال يستخدم أوبنتو 14.04) مطلوب تثبيت بعض البرمجيات على حاسوبك المحلي. لهذا ستحتاج أن تُنزل برنامجًا أو اثنين. متصفح فَيرفُكس (للجميع) PuTTY (مستخدمي ويندوز) يُمَكننا فَيرفُكس من إعداد الوسيط لفَيرفُكس فقط بدلًا من إعداد الوسيط لكامل النظام. يُستخدم PuTTY لإعداد نفق الوسيط لمستخدمي ويندوز. لدى مستخدمي Mac OS X أو لينكس الأدوات اللازمة لإعداد النفق مُثبتة مسبقًا. الخطوة الأولى (Mac OS X/لينكس) - إعداد النفق أنشئ مفتاح SSH على حاسوبك المحلي. إذا كان لديك مفتاح SSH، فيمكنك استخدامه. على الرغم من أن تحديد كلمة مرور لمفتاح SSH هي عادة جيدة، سنترك كلمة المرور فارغة الآن لنتجنب مشاكل لاحقة. وأنت تَعُدّ المفتاح، تأكد أن تُضيفه للمفاتيح المخولة لمستخدم sudo على الخادوم (في هذا المثال، هذا هو المستخدم sammy). افتح برنامج الطرفية على حاسوبك. على Mac OS X، تجد الطرفية Terminal في Applications > Utilities. أنشئ النفق بهذا الأمر: $ ssh -D 8123 -f -C -q -N sammy@example.com شرح المعاملات D-: يُخبر SSH بأننا نريد نفق SOCKS على رقم المنفذ المُحدد (اختر رقم بين 1025-65536) f-: يضع العملية في الخلفية C-: يضغط البيانات قبل إرسالها q-: يستخدم الوضع الصامت N-: يُخبر SSH بأنه لا يوجد أي أمر سيُرسَل بمجرد فتح النفق تأكد من استبدال sammy@example.com بمستخدم sudo الخاص بك وعنوان IP أو اسم نطاق الخادوم. بمجرد أن تُدخل الأمر، ستعود إلى مِحث سطر الأوامر مرة أخرى بدون أي إشارة على النجاح أو الفشل؛ هذا طبيعي. تحقق من أن النفق يعمل بالأمر: $ ps aux | grep ssh ينبغي أن ترى سطرًا في المُخرجات مثل: sammy 14345 0.0 0.0 2462228 452 ?? Ss 6:43AM 0:00.00 ssh -D 8123 -f -C -q -N sammy@example.com يمكنك إغلاق تطبيق الطرفية وسيظل النفق يعمل. هذا لأننا استخدمنا الخيار f- الذي يضع جلسة SSH في الخلفية. ملاحظة: إذا أردت أن تُنهى النفق سيتوجب عليك معرفة PID الجلسة عبر ps واستخدام الأمر kill، وهذا ما سنُريك كيفية القيام به لاحقًا. الخطوة الأولى (ويندوز) - إعداد النفق افتح PuTTY. إذا لم تُثبته بعد، نزل PuTTY واحفظه بالمكان الذي تُحب. لا يحتاج PuTTY صلاحيات المُدير لتثبيته؛ حمل الملف التنفيذي exe. وشغلهُ فقط. أكمل الخطوات التالية لإعداد النفق: من قسم Session، أضف اسم مُضيف (أو عنوان IP) Host Name (or IP address) خادومك، ومنفذ Port SSH (عادة يكون المنفذ رقم 22) على الجانب الأيسر، انتقل إلى: Connection > SSH > Tunnels ادخل رقم أي منفذ مصدري source port بين 1025-65536. استخدمنا في هذا المثال المنفذ رقم 1337 اختر Dynamic اضغط Add ارجع إلى Session على الجانب الأيسر. اضف اسم اسفل Saved Sessions واضغط زر Save الآن اضغط Open لتفتح الاتصال ادخل اسم مُستخدم sudo وكلمة سر الخادوم للدخول. يمكنك تصغير نافذة PuTTY الآن، لكن لا تُغلقها. ينبغي أن يفتح اتصال SSH. تلميحة: يمكنك حفظ اسم مُستخدم sudo ومفتاح SSH للجلسة الحالية باتباع تعليمات مفتاح SSH الخاص ببرنامج PuTTY. وهكذا لن تَضطرّ إلى إدخال اسم المُستخدم وكلمة السر كل مرة تفتح الاتصال. الخطوة الثانية - ضبط متصفح فَيرفُكس Firefox ليستخدم النفق الآن بما أنه أصبح لدينا نفق SSH، فقد حان الوقت لضبط فَيرفُكس ليستخدم هذا النفق. تذكر لكي يعمل نفق SOCKS 5، يجب أن تستخدم تطبيق محلي يُمكنهُ استغلال النفق؛ فَيرفُكس يقوم بهذا. هذه الخطوة متشابهة لمُستخدمي ويندوز، Mac OS X ولينكس. تأكد أن لديك رقم المنفذ الذي استخدمته في أمر SSH أو في PuTTY. لقد استخدمنا 8123 في مثال OS X / لينكس و 1337 في مثال ويندوز حتى الآن، أو قد تكون استخدمت منفذًا مُختلفًا. نُفذَت الخطوات التالية على نُسخة فَيرفُكس 39 وينبغي أن تعمل على النُسخ الأخرى، على الرغم من احتمال اختلاف أماكن الخيارات. اضغط على أيقونة الهامبرجر في أعلى الركن الأيمن للوصول إلى قائمة فَيرفُكس: اضغط على أيقونة Preferences أو Options انتقل لقسم Advanced اضغط على تبويب Network اضغط على Settings أسفل العنوان Connection. ستفتح نافذة جديدة. اختر Manual proxy configuration: اكتب localhost أمام SOCKS HOST ادخل نفس رقم المنفذ Port من اتصال SSH الخاص بك؛ ترى في الصورة أننا أدخلنا 1337 ليُطابق تعليمات ويندوز. اضغط OK لحفظ وإغلاق ضبطك. الآن، افتح تبويبًا آخر في فَيرفُكس وتصفح الإنترنت. ينبغي أن يكون كل شيء جاهز للتصفح الآمن عبر نفق SSH الخاصة بك. اختياري: لتتأكد أنك تستخدم الوسيط، ارجع إلى إعدادات الشبكة Network في فَيرفُكس. أدخل رقم منفذ مُختلف. اضغط OK لحفظ الإعدادات. الآن إذا جربت تصفح الإنترنت، ينبغي أن ترى رسالة الخطأ The proxy server is refusing connections. هذا يؤكد أن فَيرفُكس يستخدم الوسيط وليس الاتصال الافتراضي. عُد إلى رقم المنفذ الصحيح، وينغي أن تكون قادر على التصفح مرة أخرى. العودة إلى التصفح العادي غير الآمن في فَيرفُكس عندما تنتهي حاجتك لخصوصية نفق SSH، ارجع إلى إعدادات وسيط الشبكة (Preferences > Advanced > Network > Settings) في فَيرفُكس. اختر Use system proxy settings واضغط OK. سيستخدم فَيرفُكس الآن إعدادات اتصالك العادي، ومن المرجح أن يكون غير آمن. إذا انتهيت من استخدام النفق يجب أن تُغلق النفق أيضًا، وهذا ما سنُغطيه في الخطوة التالية. إذا كنت تنوي استخدام النفق كثيرًا، فاتركه مفتوحًا للاستخدام لاحقًا، لكن لاحظ أنه قد يُغلق من تلقاء نفسه إذا بقي خاملًا (غير مُستخدم) لمدة طويلة، أو إذا سَكَن (sleep) حاسوبك. الخطوة الثالثة (Mac OS X/لينكس) - إغلاق النفق سيوقف إغلاق النفق قدرة فَيرفُكس على التصفح بالوسيط. أُرسل النفق الذي أنشأناه سابقًا على حاسوبنا المحلي إلى الخلفية، لذا لن يُنهيه إغلاق نافذة الطرفية التي استخدمناها لفتح النفق. لإنهاء النفق نحتاج أن نُحدد مُعَرف العملية (PID) باستخدام الأمر ps، ثم قتله باستخدام الأمر kill. فلنبحث عن كل عمليات ssh على حاسوبنا: $ ps aux | grep ssh جد السطر الذي يبدو كالأمر الذي أدخلته سابقًا لإنشاء النفق. هذا مثال على المخرجات: sammy 14345 0.0 0.0 2462228 452 ?? Ss 6:43AM 0:00.00 ssh -D 8123 -f -C -q -N sammy@example.com من بداية السطر، في واحد من العمودين الأولين، هناك رقم مكون من ثلاثة إلى خمسة أعداد. هذا هو رقم PID. وفي المخرجات السابقة هو الرقم 14345. بعد أن عرفنا رقم PID، يُمكننا استخدام الأمر kill لنُغلق النفق. استخدم رقم PID الخاص بك عندما تقتل العملية. $ sudo kill 14345 إذا أردت أتمتت عملية الاتصال، اذهب للخطوة الرابعة. الخطوة الثالثة (ويندوز) - إغلاق النفق سيوقف إغلاق النفق قدرة فَيرفُكس على التصفح بالوسيط. اغلق نافذة PuTTY التي استخدمتها لإنشاء النفق فقط. لا يوجد في ويندوز طريقة سهلة لأتمتة عملية الاتصال، لكن PuTTY وفَيرفُكس يمكنهما حفظ الإعدادات التي أدخلتها سابقًا، لذا افتح الاتصالات فقط مرة أخرى لتستخدم النفق مجددًا. الخطوة الرابعة (Mac OS X/لينكس) - إنشاء اختصارات للاستخدام المتكرر يمكننا إنشاء أمر بديل أو سكربت في أنظمة لينكس أو OS X لكي يُنشئ النفق سريعًا من اجلنا. سنعرض طريقتين لأتمتة عملية إنشاء النفق. ملاحظة: طريقتي الاختصار كلاهما تَتَطلبان مفتاح SSH بلا كلمة سر للوصول إلى الخادوم. 1. سكربت BASH قابل للنقر إذا أردت أيقونة لتضغط عليها مرتين فيبدأ النفق، يمكن أن نُنشئ سكربت BASH بسيط للقيام بهذه المهمة. سنجعل السكربت يقوم بإعداد النفق وتشغيل فَيرفُكس، على الرغم من أنك ستظل في حاجة إلى إضافة إعدادات الوسيط يدويًا بالمرة الأولى في فَيرفُكس. ملف فَيرفُكس الثُنائي على OS X الذي يمكننا تشغيله من سطر الأوامر هو داخل Firefox.app. بافتراض أن التطبيق في مُجلّد التطبيقات Applications، سنجد الملف الثُنائي في Applications/Firefox.app/Contents/MacOS/firefox/. على أنظمة لينكس، إذا ثبتّت فَيرفُكس عبر مستودع أو كان مُثبت مسبقًا، فينبغي أن تجده في usr/bin/firefox/. يمكنك دائمًا استخدام الأمر which firefox لمعرفة موقعه على نظامك. استبدل في السكربت الذي بالأسفل مسار فَيرفُكس بالمسار المناسب لنظامك. باستخدام مُحرر نصوص مثل nano أنشئ ملف جديد: $ nano ~/socks5.sh وأضف السطور التالية إليه: #!/bin/bash ssh -D 8123 -f -C -q -N sammy@example.com /Applications/Firefox.app/Contents/MacOS/firefox & استبدل 8123 برقم المنفذ الذي تريده، يجب أن يُطابق ما وضعته في فَيرفُكس استبدل sammy@example.com بمُستخدم SSH الخاص بك واسم المُضيف أو عنوان IP استبدل Applications/Firefox.app/Contents/MacOS/firefox/ بمسار ملف فَيرفُكس الثُنائي احفظ السكربت. تقوم بهذا في nano بالضغط على Ctrl-o، ثم اخرج بالضغط على Ctrl-x. اجعل السكربت قابلًا للتنفيذ، لكي يتم تنفيذه عندما تضغط عليه مرتين. ادخل هذا الأمر في سطر الأوامر لتُضيف صلاحيات التنفيذ، باستخدام مسار السكربت الخاص بك: $ chmod +x /path/to/socks5.sh قد تحتاج في OS X القيام بخطوات إضافية لتُخبر Mac OS X أن ملف بلاحقة .sh يجب أن يُنَفَذ كبرنامج وألا يتم فتحه في مُحرر. لتقوم بهذا، اضغط بزر الفأرة الأيمن على ملف socks5.sh واختر Get Info. جد القسم Open with: وإذا لم يُشر سهم الكشف إلى الأسفل، اضغط عليه لكي ترى القائمة المُندسلة. قد تجد Xcode مضبوطًا كالتطبيق الافتراضي. غيره إلى Terminal.app. إذا لم تجد Terminal.app بالقائمة، اختر Other، ثم انتقل إلى Applications > Utilities > Terminal.app. اضغط مرتين على ملف socks.sh لتفتح وسيط SOCKS الخاص بك الآن. ملاحظة: بعد التنفيذ، لن يطلب السكربت كلمة سر، ولذلك سيفشل بصمت إذا أعددت مفتاح SSH مُسبقًا ليطلب كلمة مرور. سوف يفتح السكربت نافذة الطرفية، يبدأ اتصال SSH ويُشغل فَيرفُكس. لا تخش من إغلاق نافذة الطرفية. يمكنك الآن أن تبدأ التصفح في اتصالك الآمن، طالما أنك تحتفظ بإعدادات الوسيط في فَيرفُكس. 2. إنشاء Alias إذا وجدت أنك تستخدم سطر الأوامر كثيرًا وتُريد تشغيل النفق، يمكنك إنشاء Alias ليقوم بالمهمة من أجلك. الجزء الأصعب في إنشاء Alias هو أين تحفظه. تحفظ توزيعات لينكس وإصدارات OS X المختلفة الـ aliases في أماكن مختلفة. أفضل طريقة هي البحث عن أحد الملفات التالية وتبحث بداخله عن الكلمة alias لترى أين تُحفظ الأوامر البديلة الأخرى حاليًا. ~/.bashrc ~/.bash_aliases ~/.bash_profile ~/.profile بمجرد إيجاد الملف الصحيح، أضف هذا السطر التّالي أسفل Aliases موجودة لديك، أو فقط بنهاية الملف. alias socks5=’ssh -D 8123 -f -C -q -N sammy@example.com && /Applications/Firefox.app/Contents/MacOS/firefox &’ استبدل 8123 برقم المنفذ الذي تريده، يجب أن يُطابق ما وضعته في فَيرفُكس استبدل sammy@example.com بمُستخدم SSH الخاص بك واسم المُضيف أو عنوان IP استبدل Applications/Firefox.app/Contents/MacOS/firefox/ بمسار ملف فَيرفُكس الثُنائي يتم تحميل الـ aliases فقط عندما تبدأ صدفة جديدة، لذا أغلق جلسة طرفيتك وابدأ واحدة جديدة. الآن عندما تكتب: $ socks5 هذا الأمر يقوم بإنشاء نفقك، ثم يُشغل فَيرفُكس ويُعيدك إلى مِحث الأوامر. تأكد أن فَيرفُكس مضبوط ليستخدم الوسيط (proxy). يمكنك الآن التصفح بشكلٍ آمن. الخطوة الخامسة (اختياري) - استكشاف الأخطاء وإصلاحها: المرور عبر الجدران النارية إذا كان اتصالك يعمل، فلا حاجة لك لقراءة هذا القسم. ومع ذلك، إذا اكتشفت أنه لا يمكنك إنشاء اتصال SSH بسبب جدار ناري تقييدي، فالمرجح أن المنفذ 22، وهو المطلوب لإنشاء النفق، محجوب. إذا كان بإمكانك التحكم في إعدادات خادوم وسيط SSH، يمكنك إعداد SSH للإنصات إلى منفذ آخر غير 22. ما المنفذ غير المحجوب الذي يمكنك استخدامه؟ بجانب الخطة المشكوك بها لفحص المنافذ باستخدام أداة مثل ShieldsUP، مشكوك بها لأن شبكتك المحلية قد تُفسر هذا كهجوم، فالأفضل تجربة منافذ تُترك مفتوحة عادة. المنافذ المتروكة مفتوحة عادةً تكون 80 (لحركة مرور الويب العامة) و 443 (لحركة مرور SSL). إذا لم يكن خادوم SSH الخاص بك يخدم محتوى ويب، يمكننا أن نخبر SSH ليستخدم أحد هذين المنفذين ليتصل عبره بدلا من المنفذ الافتراضي 22. المنفذ 433 هو أفضل اختيار لأنه مُتَوقع أن يكون هناك حركة مرور مُشفرة على هذا المنفذ، وحركة مرور SSH الخاصة بنا ستكون مُشفرة. ابدأ اتصال SSH لخادومك من مكان غير محمي بجدار ناري، ثم حرّر ملف إعدادات SSH: $ sudo nano /etc/ssh/sshd_config ابحث عن السطر Port 22. يمكننا إما استبدال 22 كُليًا، وهي فكرة جيدة لزيادة أمان SSH، أو إضافة منفذ آخر ليُنصت SSH إليه. سنختار انصات SSH إلى منافذ متعددة، لذا سنُضيف سطر جديد أسفل Port 22 الذي يُقرأ Port 443. وإليك مثال لملف sshd_config: ... Port 22 Port 443 ... أعد تشغيل SSH لكي يُعيد تحميل ضبط SSH الذي أدخلته. قد يختلف اسم عفريت خادوم SSH بالاعتماد على توزيعتك، لكن من المرجح أن يكون اسمه ssh أو sshd. إذا لم يعمل أحدهما جرّب الآخر. $ sudo service ssh restart لتتحقق من أن منفذ SSH يعمل، افتح صدفة جديدة، لا تُغلق الجلسة الحالية بعد، فقد تحتاجها في حالة أغلقت الباب على نفسك وأنت خارج الخادوم بدون قصد، وابدأ اتصال SSH باستخدام المنفذ الجديد. $ ssh sammy@example.com -p 443 إذا نجحت بالاتصال، فيُمكنك الخروج الآن من الصدفتين وفتح نفق SSH باستخدام المنفذ الجديد. $ ssh -D 8123 -f -C -q -N sammy@example.com -p 443 ستكون إعدادات فَيرفُكس هي نفسها لأنه لا يعتمد على منفذ SSH، وإنما منفذ النفق (8123 كما بالأمر السابق). خاتمة افتح نفق SOCKS 5 للتصفح من خلال نفق SSH آمن كلما أردت طريقة خفيفة للوصول للويب بمأمن من أعين المُتطفلين. ترجمة -وبتصرّف- للمقال How To Route Web Traffic Securely Without a VPN Using a SOCKS Tunnel لصاحبه Michael Holley.

في حين أنه من الممكن إدارة خواديمك باستخدام تسجيلات الدخول القائمة على كلمات المرور إلا أنه غالبا يكون إنشاء واستخدام زوج مفاتيح SSH فكرة أفضل، لأن هذه المفاتيح أكثر أمانا من كلمات المرور ويمكنها مساعدتك على تسجيل الدخول دون الحاجة إلى تذكر كلمات المرور الطويلة. على Digital Ocean، يمكنك رفع مفتاحك ليكون جزءا من خواديمك عند إنشائها وهذا سيسمح لك بتسجيل دخولك إلى الخواديم بدون كلمات مرور بينما تظل آمنة للغاية. في العادة، يستعمل مستخدمو ويندوز برنامج PuTTY لإنشاء جلسات Session SSH والتي ستسمح لك بالاتصال بخادومك، كما يوفر لك هذا البرنامج إمكانية إنشاء مفاتيح SSH وتذكر مفتاح كل خادوم. في هذا الدّرس، ستتعلم كيف تستخدم PuTTY لإنشاء زوج مفاتيح SSH، وكيف ترفع مفتاحك العام (public key) إلى واجهة الويب الخاصة بـDigital Ocean، وكيف تنشئ droplets جديدة (VPS) مع تضمين مفتاحك العام، وفي النهاية سنريك كيف تتصل بخواديمك بدون استخدام كلمة مرور باستخدام مفتاحك الخاص. كيف يعمل زوج مفاتيح SSH نستخدم زوجًا من مفاتيح SSH كطريقة للاستيثاق (authentication method) وذلك عن طريق إنشاء مفتاحين مرتبطين. المفتاح الأول يدعى بالمفتاح الخاص (private key) وهذا المفتاح سري ويجب على من أنشأه أن يحتفظ به في مكان آمن، لأنه يُستخدم للتعرف عليك بطريقة تشبه شمع الأختام التي كانت تُستخدم لإغلاق الرسائل في الماضي، فهو يُستعمل لإثبات أن الاتصال قادم منك. يجب ألا تسمح بأي شخص أن يحصل على مفتاحك الخاص، لأنه سيتمكن من تسجيل الدخول إلى أي حساب مرتبط بهذا المفتاح، وإذا أردت مشاركة الوصول معه، فتوجد طرق أفضل لفعل ذلك. أما المفتاح الآخر فيدعى بالمفتاح العام (public key)، هذا المفتاح يرتبط بشكل حقيقي مع المفتاح الخاص، الفرق أنه يمكنك مشاركة هذا المفتاح بحرية مع أي شخص على الإنترنت. الشيء الوحيد الذي يمكن لشخص آخر أن يفعله بهذا المفتاح هو أن يسمح لك بتسجيل الدخول إلى جهازه، وهذا ما سنقوم بإعداده في هذا الدّرس، بإنشاء خواديم جديدة متضمنة مفاتيحنا العامة. تنزيل وتثبيت PuTTY و PuTTYgen بداية، سنحتاج إلى تنزيل وتثبيت كل من PuTTY وهي أداة للاتصال بخواديم بعيدة عن طريق SSH (صدفة آمنة - secure shell) و PuTTygen وهي أداة تُستخدم لإنشاء مفاتيح SSH. يمكنك إيجاد روابط تحميل كلا الأداتين على موقع المشروع. أسهل طريقة للحصول على جميع الأدوات الضرورية هي عن طريق زيارة الرابط أعلاه ومن ثم الضغط على رابط بعنوان “A Windows installer for everything except PuTTYtel" كما في الصورة التالية: نزّل التّطبيق ونصّبه، بإمكانك الإبقاء على الخيارات الافتراضية (في عملية التّنصيب) أو التّعديل عليها كيفما شئت. إنشاء زوج مفاتيح SSH سنبدأ بإنشاء زوج مفاتيح SSH. سنبدأ بتشغيل PuTTYgen وذلك عن طريق استخدام قائمة ابدأ أو بالضغط على مفتاح ويندوز وكتابة "PuTTYgen" والذي سيشغل برنامج مولد المفاتيح وسيبدو كما في الصورة التالية: لإنشاء مفتاح جديد، يمكنك اختيار المعاملات الموجودة في الأسفل حسبت متطلباتك: تقريبا في أغلب الحالات، ستكون القيم الافتراضية خيارًا جيّدًا، لذلك يمكنك إبقاؤها كما هي. عندما تنتهي، اضغط على زر "Generate" الموجود على الجانب الأيمن: يتم إنشاء مفاتيح SSH باستخدام بيانات عشوائية لأسباب أمنية، لذلك ستحتاج إلى توليد بعض البيانات العشوائية من خلال تحريك الفأرة في النافذة، هذه العشوائية والتي تدعى أيضا بـ "entropy" تُستخدم لإنشاء مفاتيح بطريقة آمنة حتى لا يتمكن الآخرين من تقليدها. عندما يستقبل نظام التشغيل عددًَا كافيًا من البيانات العشوائية سيوّلد زوج مفاتيح، وستظهر مخرجات مفتاح العام في صندوق نصي على الشاشة. يمكنك استخدام هذه المعلومات عن طريق نسخها ولصقها من صندوق النصوص، لكننا سنحفظها لاستخدامها لاحقا عن طريق الواجهة المتوفرة. اضغط على كل من زر حفظ المفتاح العام "Save public key" والخاص "Save private key" واختر مكانًا آمنًا لحفظها: يمكنك تسمية مفاتيحك بأي اسم تريده، وبشكل افتراضي سيتم إعطاء مفتاح الخاص امتداد ppk. أما بالنسبة للمفتاح العام فأنصحك باختيار امتداد مثل txt. حتى تتمكن من فتحه لاحقا باستخدام محرر نصوص عادي، فستحتاج فيما بعد إلى قراءة البيانات الموجودة في هذا الملف. قمنا الآن بتوليد زوج مفاتيح وحفظناه على الجهاز وهو الآن جاهزة للاستخدام. رفع مفتاحك العام إلى حساب Digital Ocean كما ذكرنا سابقا، يمكنك نشر مفتاحك العام بحرية لأنه يمكن أن يُستخدم لتأكيد المستخدم الذي يملك المفتاح الخاص المرتبط به، بالإضافة إلى أنه لا يمكن استخدامه لإعادة إنشاء مفتاح خاص لذلك سيكون من الآمن رفعه. داخل حساب Digital Ocean الخاص بك، اضغط على رابط "SSH Keys" الموجود على قائمة التصفح على اليسار: سيتم نقلك إلى صفحة إدارة مفاتيح SSH. في الجانب الأيمن العلوي اضغط على زر "Add SSH Key": ستظهر لك شاشة جديدة وسيطلب منك تحديد اسم لهذا المفتاح الذي ستنشئه، اختر اسمًا سهلًا لتتمكن من التعرف عليه لاحقا. بعد ذلك، يجب عليك لصق محتويات المفتاح العام الخاص بك في المساحة الموجودة في الأسفل، إذا أغلقت جلسة أداة PuTTYgen فيجب عليك في هذه الحالة فتح الملف المحتوي على المفتاح العام الخاص بك باستخدام محرر نصي (مثل Notepad)، ومن ثم اختيار كامل النص الموجودة في الملف ومن ثم لصقه في الحقل الموجود على الموقع، وسيبدو كما في المثال التالي: عندما تنتهي، اضغط على زر "Create SSH Key"، وسيكون المفتاح متوفرًا في لوحة تحكم Digital Ocean. نحتاج الآن فقط إلى إنشاء خادوم جديد باستخدام هذا المفتاح. إنشاء خادوم VPS يتضمن مفتاح SSH العام والآن، بعد أن حصلنا على مفتاحنا العام في واجهتنا، يمكننا تضمينه في خواديمنا الجديدة، وهذا سيسمح لنا بالاستيثاق وتسجيل الدخول إلى خادومنا الجديد باستخدام المفتاح الخاص بدون الحصول على كلمة مرور إضافية. لإنشاء خادوم جديد، اضغط على زر "Create" في الجانب الأيسر العلوي من لوحة التحكم: اختر اسمًا لـ Droplet الخاصة بك، ومن ثم املأ بقية المعلومات مثل الحجم وموقع البيانات كالمعتاد. في الأسفل، يوجد قسم بعنوان "Add optional SSH Keys" وستجد داخله أزرار لكل مفاتيح SSH التي رفعتها إلى الواجهة. يمكنك اختيار مفتاح واحد أو أكثر لتضمينها مع خادومك: إذا كنت معتادا على إنشاء الخواديم عن طريق Digital Ocean، فأنت متعود على استقبال رسالة عند الإنشاء بها معلومات التوثيق وكلمة المرور، وعند اختيار تضمين مفتاح SSH إلى خادومك لجديد، لن تُرسل لك هذه الرسالة. بدلا من ذلك، يجب استخدام مفتاحك الخاص لتسجيل الدخول، والتي لا تحتاج إلى كلمة مرور. إعداد جلسة SSH مع مفاتيح SSH في PuTTY نملك الآن droplet تتضمن مفتاحًا عامًا، ويمكننا استخدام PuTTY للاتصال بها، وسنفعل ذلك بإعداد وحفظ الجلسة، وبهذه الطريقة يمكننا إعادة الاتصال لاحقا بسرعة مع حفظ جميع إعداداتنا. افتح برنامج PuTTY الرئيسي وذلك عن طريق الضغط المزدوج، أو بالضغط على مفتاح ويندوز وكتابة PuTTY. ستُفتح لك شاشة الجلسة الرئيسية. الخطوة الأول هي إدخال عنوان IP للـ droplet الخاصة بك إلى صفحة الجلسة. يمكننك الحصول على هذا العنوان من خلال لوحة تحكم Digital Ocean: بشكل افتراضي، يستخدم SSH منفذ 22، ويجب اختيار SSH كنوع اتصال، وهذه كل القيم التي نحتاجها. بعد ذلك، نحتاج إلى الذّهاب إلى "Data" في قسم "Connection" في الجانب الأيسر من قائمة التصفح: هنا، سندخل اسم المستخدم للخادوم، وسيكون "root" للإعداد الأولي والذي هو المُستخدم الجذر لخادومك، وهذا هو الحساب الذي تم إعداده مع مفتاحك العام، أدخل "root" في الحقل Auto-login username: بعد ذلك، نحتاج إلى الضغط على تصنيف SSH في قائمة التصفح: داخل هذا التصنيف، اضغط على التصنيف الفرعي "Auth". ستجد حقل في الشاشة يطلب منك إدخال المفتاح الخاص من أجل الاستيثاق "Private key file for authentication"، اضغط على زر "Browse": ابحث عن ملف المفتاح الخاص الذي حفظته، هذا المفتاح الذي ينتهي بـ ppk.، جدْه ثم اضغط على "Open" في نافذة الملف: الآن، في نافذة التصفح، نحتاج إلى الرجوع نحو شاشة "Session" التي بدئنا بها. هذه المرة، نحتاج إلى اسم الجلسة التي سنحفظها، ويمكنك تسميتها بأي اسم تريده، لذلك اختر اسمًا سهلًا لكي تستطيع تذكره لاحقا. عندما تنتهي، اضغط على زر "Save". الآن، لقد حفظت جميع بيانات الإعداد التي تحتاجها للاتصال بخادومك. الاتصال بخادومك باستخدام جلسة PuTTY مسجلة الآن، بعد أن حفظت جلستك، يمكنك استدعاء هذه القيم في أي وقت بالعودة إلى شاشة "Session"، واختيار الشاشة التي ترغب باستخدامها في جزء "Saved Session"، ومن ثم الضغط على "Load" لاستعادة جميع الإعدادات، وهذا سيملأ جميع الحقول بالخيارات التي اخترتها سابقا. عندما ترغب بالاتصال بخادومك، اضغط على زر "Open" في شاشة "Sessions" بعد أن تُحمّل جلستك: في المرة الأولى التي تتصل بها بمضيفك عن بعد (remote host)، سيطلب منك التأكد من هوية الخادوم البعيد (remote server)، وهذا الإجراء عادي متوقع في المرة الأولى التي تتصل بها بخادوم جديد، لذلك اختر "Yes" للاستمرار. بعد ذلك، ستجد أنه قد قام بتسجيل دخولك إلى خادومك بدون أن يسأل على كلمة المرور: وبهذا، نجحت في إعداد مفاتيح SSH مع Digital Ocean. الخاتمة يمكنك الآن إنشاء خواديم على Digital Ocean باستخدام مفتاح SSH العام بكل سهولة، ويمكنك استخدام مفاتيح SSH التي أنشئاها على العديد من الخواديم كما تشاء. ترجمة -وبتصرف- للمقال: How To Use SSH Keys with PuTTY on DigitalOcean Droplets for Windows users لصاحبه Justin Ellingwood.

تتوفّر على توزيعات لينكس برامج تحظُر إنشاء كلمات سر يسهُل تخمينها؛ فالوصول إلى الكثير من بيانات المستخدم وبرامجه يتطلّب تجاوز مرحلة إدخال كلمة السرّ ، الأمر الذي يجعل من كلمات السر نقطة حرجة في سبيل تأمين النظام والمستخدم على حدّ السواء ويجب بالتالي الحرص دائما على أن تكون محدَّثة. توجد الكثير من طرق تعمية البيانات ولكلّ منها خصوصيّاته. تستخدم أغلب توزيعات لينكس خوارزميّة تعمية تُسمّى معيار تعميّة البيانات Data Encryption Standard, DES لتعميّة كلمات السّر. تُخزّن كلمات السرّ المعمّاة في ملف etc/passwd/ أو etc/shadow/. عندما يحاول المستخدم الولوج إلى النظام فإن كلمة السّر التي يُدخِلها تُعمَّى ثم تقارن بحقل كلمة السّر المعمّاة في الملف، فإن حصل تطابق فهذا يعني أنها نفس كلمة السّر وبالتالي يُسمح له بالولوج. تستخدم أغلب توزيعات لينكس نسخة من DES لا تعمل إلا في اتجاه واحد؛ بمعنى أنه يمكن استخدامها لتعميّة كلمة سر ولكن لا يمكن استخدامها لفك تعميّة كلمات السر في ملفّي etc/passwd/ وetc/shadow/. يمكن لبرامج هجمات القوة العمياء Brute force attacks مثل John the Ripper وCrack تخمين كلمات السر التي لا تحترم حدًّا أدنى من العشوائية؛ وبإمكان مديري النّظم استخدامها لصالحهم في طريقة استباقية بتنفيذها على كلمات سرّ مستخدميهم للعثور على كلمات السّر غير الآمنة ثم الطلب من هؤلاء تغييرها إلى أخرى آمَن. التعمية بالمفاتيح العمومية تستخدم التعمية بالمفاتيح العمومية Public-Key Cryptography مفتاحا (سلسلة محارف) للتعمية وآخر لفكّها، على عكس طرق تعمية أخرى تستخدم نفس المفتاح للمهمتيْن. يهدف استخدام مفتاح خاصّ للتعميّة (المفتاح العموميّ) وآخر لفكّها (المفتاح الخصوصيّ) إلى تجاوز ضرورة تأمين نقل المفتاح الوحيد أثناء تبادل الرسائل المعمّاة. يتوفّر المفتاح العمومي لكلّ شخص للجميع دون استثناء بينما يقى المفتاح الخصوصي سرًّا خاصًّا به. مثلا، عندما يريد محمّد إرسال بريد معمّى إلى عمر فإنه يستخدم المفتاح العموميّ لعمر لتعمية البريد، عند وصول البريد إلى عمر فإنه يستخدم مفتاحه الخصوصي الذي لا يعرفه غيره لفك تعميّة الرسالة والاطّلاع عليها. بهذه الطريقة لن يعرف فحوى الرسالة غيرهما، محمّد لأنه كتب الأصل غير المعمَّى، وعمر لأنه الوحيد الذي يمكنه فك تعميتها. برنامج PGP يتبنّى برنامج PGP (اختصار لـ Pretty Good Privacy) مبدأ التعمية بالمفاتيح العمومية ويمكن استخدامه لتوقيع البيانات وتعميّتها: التوقيع للتأكد من المصدر والحؤول دون انتحال الشخصيّة، والتعمية للحفاظ على خصوصية البيانات. يجب الانتباه قبل استخدام البرنامج إلى التقييدات القانونية في استخدامه. يُحظَر في بعض الدوّل توجيه رسائل بتعميّة قويّة إلى خارج البلد. بروتوكول TLS يُستخدَم بروتوكول TLS (والإصدار السابق منه SSL) كثيرا لتأمين الاتصالات في شبكة حواسيب. يهدف البروتوكول إلى الحفاظ على خصوصية البيانات المنقولة عبر الاتصال بتعميتها، الاستيثاق من هويّات المتخاطبين باستخدام تعمية بالمفاتيح العمومية والتأكد من سلامة البيانات عن طريق جمع تحقق Checksum لكلّ حزمة بيانات. التنفيذ الأكثر شهرة على أنظمة لينكس لهذا المعيار هو مكتبة OpenSSL التي تدعم خوارزميات تعمية من بينها DES، Blowfish وIDEA. بروتوكول HTTPS وهو تطوير لبروتوكول HTTP بتضمينه داخل اتّصال يؤمّنه بروتوكول TLS (أو SSL). الأغراض الأساسية من استخدام HTTPS على مواقع الويب هي الاستيثاق، حماية الخصوصية والتحقق من سلامة البيانات المتبادلة. بروتوكول S/MIME يأتي الاسم اختصارا لـ Secure Multipurpose Internet Mail Extension (امتداد البريد الإلكتروني الآمن متعدّد الأغراض)، وهو معيار مفتوح يعتمد على التعميّة بالمفاتيح العمومية لتأمين البريد الإلكتروني وغيره من أنواع المراسلات على الشبكة. الشبكات الخاصة الافتراضية Virtual Private Network توجد تنفيذات عدّة لمعيار بروتوكول الإنترنت الآمن على لينكس. معيار IPSEC (اختصار لـ Internet Protocol Security؛ أمان بروتوكول الإنترنت) هو مجهود تقف خلفه قوة مهمات هندسة الإنتنرت IETF ويهدف إلى إنشاء اتصالات معمّاة على مستوى الشبكة (الطبقة الثالثة) وتوفير سبُل للتحقق من سلامة البيانات، التحكم في الوصول، الاستيثاق والسريّة. من الأمثلة على تطبيقات هذا البروتوكول في لينكس LibreSwan الذي يسمح للمستخدم ببناء نفق اتصالات آمن عبر شبكات غير موثوقة. يُعمَّى كل ما يمر إلى الشبكة غير الموثوقة قبل إرساله ليعمل الطرف الآخر عند استلامه على فك التعمية، تنتُج عن هذه العملية شبكة خاصّة افتراضية Virtual Private Network, VPN والتي هي شبكة اتصالات خاصّة على الرغم من أن الأجهزة فيها تتصل عن طريق شبكة غير موثوقة. لا تقتصر طُرُق إنشاء شبكات خاصة افتراضية في لينكس على IPSEC، بل توجد برامج خاصّة لهذا الغرض مثل OpenVPN التي تستخدم كثيرا مكتبات OpenSSL. بروتوكول SSH توجد عدّة حزم برمجية على لينكس لاستخدام SSH أبرزها OpenSSH. صُمِّم بروتوكول SSH ليحلّ مكان بروتوكولات الاتصال عن بعد غير الآمنة مثل rlogin، rsh وrexecالتي كانت ترسل البيانات دون احتياطات أمنية تُذكر. تعتمد حزمة برامج OpenSSH على التعمية بالمفاتيح العمومية لتعميّة الاتصالات بين مضيفين Hosts، وللاستيثاق من المستخدمين. كما يمكن استخدامها للولوج إلى خادوم بعيد أو لنسخ البيانات بين مضيفين مع الحماية من هجمات رجل في الوسط Man in the middle وهجمات أخرى. وحدات الاستيثاق سريعة التفعيل Pluggable Authentication Modules تأتي الإصدارات الحديثة من توزيعات لينكس محمّلة بآلية استيثاق موحدة تُسمّى Pluggable Authentication Modules, PAM تسمح للتطبيقات التي تعمل في فضاء المستخدم بتغيير متطلبات الاستيثاق الخاصّة بها وطريقته حسب الحاجة. يمكن باستخدام هذه الآلية من بين أمور أخرى: تحديد أمكنة وأوقات معيّنة لمستخدمين لا يمكنهم الولوج خارجها إلى النظام. تعيين سقف لاستخدام الموارد لكل مستخدِم. استعمال خوارزميات تعميّة أخرى غير DES لجعل فك التعمية بهجمات القوة العمياء أصعب. تفعيل كلمات السّر في ملف shadow حسب الحاجة. ملف Shadow لتأمين كلمات سر المستخدمين تستخدم الإصدارات الحديثة من توزيعات لينكس ملف etc/shadow/ لجعل كلمات سر المستخدم المعمّاة في مأمن من بقية المستخدمين على نفس النظام. كانت كلمات السر المعمّاة تخزّن في الإصدارات القديمة داخل ملف etc/passwd/ مبدئيا، ويمكن لجميع المستخدمين رؤيتها وبالتالي تنفيذ هجمات القوة العمياء عليها لمحاولة فك تعميتها. يعني اللجوء إلى ملف etc/shadow/ أن المستخدمين الإداريين فقط هم من يمكنهم رؤية كلمات السّر المعمّاة. التأكد من أمان كلمات مرور المستخدمين يحتاج مدير النظام أحيانا إلى التأكد من أن كلمات مرور المستخدمين جيّدة كفاية، لكي لا تكون بابا قد يؤدي فتحه إلى مشاكل أمنية أخرى، تُستخدم برامج مثل Jone the Ripper وCrack لهذا الغرض. تقوم فكرة هذه البرامج على توليد كلمات مرور معمّاة إما حسب نمط معرَّف مسبقا أو بالاعتماد على قاموس ألفاظ ثم مقارنتها بكلمات المرور المعمّاة الخاصّة بالمستخدمين، فإن وُجد تطابق عُرِفت كلمة السر. الجدير بالذكر أن مثل هذه البرامج تأخذ الكثير من الوقت وموارد الجهاز للعمل؛ وكلما كانت كلمات السّر معقدة كل ما كانت المهمة أصعب. في سيناريو هجمة حقيقية سيحتاج المخترق أولا إلى الحصول على ملف كلمات سر المستخدمين وهو أمر يحتاج لثغرات أمنية قد لا تكون موجودة؛ إلا أن الحيطة واجبة على الدوام. ترجمة - وبتصرّف - لمقال Encryption Methods in Linux لصاحبه M.el Khamlichi. حقوق الصورة البارزة: Designed by Freepik.

هذا الدّرس هو جزء من سلسلة دروس حول نشر تطبيقات PHP باستخدام Ansible على Ubuntu، تحدّثنا في الجزئين السّابقين عن تثبيت Ansible وإعداده ومن ثم عن إعداد Laravel وNginx. سنغطّي في هذا الدّرس إعداد مفاتيح SSH لتدعم أدوات نشر وتوزيع الشيفرة، وإعداد الجدار الناري للنظام، هدفنا في النهاية هو الحصول على خادوم يعمل عليه تطبيق PHP بشكل كامل مع الإعدادات المذكورة آنفًا. المتطلبات الأساسيةيبدأ هذا الدّرس مباشرة من حيث انتهى الجزء السّابق من هذه السلسلة، ونحتاج كافّة الملفّات والإعدادات التي تم الحصول عليها في ذلك الجزء، إن لم تقم بإكمال أول قسمين من هذه السلسلة فنرجو أن تفعل ذلك قبل متابعة هذا الدّرس. الخطوة الأولى – تبديل مستودع التطبيقسنقوم في هذه الخطوة بتحديث مستودع Git إلى مثال عن مستودع مُخصَّص قليلًا. بما أنّ تثبيت Laravel الافتراضي لا يتطلّب الميّزات المتقدمة التي سنقوم بإعدادها في هذا الدّرس فسنقوم بتبديل المستودع الموجود حاليًّا إلى مثال عن مستودع مع إضافة شيفرة للتنقيح debugging code فقط من أجل أن نظهر متى يعمل كل شيء، يُوجد المستودع الذي سنستخدمه على الرابط https://github.com/do-community/do-ansible-adv-php. نقوم بتغيير الدليل إلى ansible-php: cd ~/ansible-php/ نفتح playbook الموجودة حاليًّا من أجل تحريرها: nano php.yml نقوم بإيجاد وتحديث المهمّة “Clone git repository” بحيث تبدو كما يلي: Updated Ansible task - name: Clone git repository git: > dest=/var/www/laravel repo=https://github.com/do-community/do-ansible-adv-php update=yes version=example sudo: yes sudo_user: www-data register: cloned نحفظ ونشغل الـ playbook: ansible-playbook php.yml --ask-sudo-pass وبعد أن يتم تشغيلها نزور خادومنا في متصفح الويب لدينا (على الرابط http://your_server-ip بعد وضع عنوان خادومك)، ينبغي أن نشاهد رسالة تقول لم يتم العثور على التعريف "could not find driver". يعني هذا أنّنا نجحنا في استبدال المستودع الافتراضي بمثال مستودعنا، ولكن لا يستطيع التطبيق الاتصال بقاعدة البيانات، وهو ما نتوقع مشاهدته هنا، وسنقوم بتثبيت وإعداد قاعدة البيانات لاحقًا في هذا الدّرس. الخطوة الثانية – إعداد مفاتيح SSH من أجل النشرسنقوم في هذه الخطوة بإعداد مفاتيح SSH والتي يُمكن استخدامها من أجل نشر شيفرة التطبيق. ومع أنّ Ansible رائعة من أجل المحافظة على الإعدادات وإعداد الخواديم والتطبيقات، فيتم عادةً استخدام أدوات مثل Envoy و Rocketeer من أجل دفع تغييرات الشيفرة إلى الخادوم وتنفيذ أوامر التطبيق عن بُعد، تتطلّب أغلب هذه الأدوات اتصال SSH يتمكن من النفاذ إلى تثبيت التطبيق بشكل مباشر، يعني هذا في حالتنا أنّنا نحتاج إلى إعداد مفاتيح SSH من أجل المستخدم www-data. سنحتاج إلى ملف مفتاح عام من أجل المستخدم الذي نرغب بدفع الشيفرة منه، يُوجد هذا الملف بشكل نموذج في المسار ssh/id_rsa.pub./~، ننسخ هذا الملف إلى الدليل ansible-php: cp ~/.ssh/id_rsa.pub ~/ansible-php/deploykey.pubبإمكاننا استخدام الوحدة authorized_key لـ Ansible من أجل تثبيت مفتاحنا العام داخل var/www/.ssh/authorized_keys/ والذي سيسمح لأدوات النشر بالاتصال والنفاذ إلى تطبيقنا، تحتاج الإعدادات فقط إلى معرفة مكان المفتاح، باستخدام lookup، وإلى معرفة المستخدم الذي سيتم تثبيت المفتاح لأجله (www-data في حالتنا). New Ansible task - name: Copy public key into /var/www authorized_key: user=www-data key="{{ lookup('file', 'deploykey.pub') }}" نحتاج أيضًا لإعداد صدفة shell المستخدم www-data كي نستطيع فعليًّا تسجيل الدخول، وإلّا سيسمح SSH بالاتصال ولكن لن يتم عرض صدفة shell للمستخدم، يُمكن عمل هذا باستخدام الوحدة user وتعيين الصدفة إلى /bin/bash (أو الصدفة المفضلة لديك): New Ansible task - name: Set www-data user shell user: name=www-data shell=/bin/bash نفتح الآن الـ playbook لتحريرها من أجل إضافة المهام الجديدة: nano php.yml نضيف المهام السابقة إلى الـ playbook التي تُدعى php.yml، يجب أن تبدو نهاية الملف متطابقة مع التالي: Updated php.yml . . . - name: Configure nginx template: src=nginx.conf dest=/etc/nginx/sites-available/default notify: - restart php5-fpm - restart nginx - name: Copy public key into /var/www authorized_key: user=www-data key="{{ lookup('file', 'deploykey.pub') }}" - name: Set www-data user shell user: name=www-data shell=/bin/bash handlers: . . . نقوم بحفظ وتشغيل الـ playbook: ansible-playbook php.yml --ask-sudo-pass عندما تنتهي Ansible من ذلك ينبغي أن نكون قادرين على الدخول باستخدام SSH عن طريق المستخدم www-data: ssh www-data@your_server_ip إن استطعنا تسجيل الدخول بنجاح فهي تعمل بشكل صحيح، بإمكاننا الآن تسجيل الخروج عن طريق إدخال logout أو ضغط CTRL+D. لن نحتاج إلى استخدام هذا الاتصال في أي خطوات لاحقة، ولكن يبقى مفيدًا إن قمنا بإعداد أدوات أخرى، كما أشرنا سابقًا، أو من أجل التنقيح العام general debugging وصيانة التطبيق كما هو مطلوب. الخطوة الثالثة – إعداد الجدار الناريسنقوم في هذه الخطوة بإعداد الجدار الناري على الخادوم للسماح فقط بالاتصالات من أجل HTTP وSSH. يأتي Ubuntu مع جدار ناري يُدعى UFW (الجدار الناري غير المعقد Uncomplicated Firewall) مُثبَّت عليه بشكل افتراضي، وتدعمه Ansible بالوحدة ufw، يمتلك عدد من الميزات القوية وتمّ تصميمه ليكون بسيطًا قدر الإمكان وهو ملائم بشكل مثالي لخواديم الويب المحتواة ذاتيًّا والتي تحتاج فقط إلى عدة منافذ مفتوحة، نرغب في حالتنا بأن يكون المنفذ 80 (من أجل HTTP) والمنفذ 22 (من أجل SSH) مفتوحًا، وربّما قد تريد المنفذ 443 مفتوحًا من أجل HTTPS. تمتلك الوحدة ufw عددًا من الخيارات المختلفة تقوم بتنفيذ مهام مختلفة، وهذه المهام التي نريد تنفيذها هي: تمكين UFW ورفض كامل حركة مرور البيانات traffic القادمة افتراضيًّا.فتح منفذ SSH ولكن مع تحديده لمنع هجمات القوة القاسية brute force attacks.فتح منفذ HTTP.يُمكِن فعل هذا باستخدام المهام التالية على الترتيب: New Ansible tasks - name: Enable UFW ufw: direction=incoming policy=deny state=enabled - name: UFW limit SSH ufw: rule=limit port=ssh - name: UFW open HTTP ufw: rule=allow port=http </code>نفتح الملف php.yml من أجل تحريره: nano php.ymlنضيف المهام السابقة إلى الـ playbook، ينبغي أن تتطابق نهاية الملف مع التالي: Updated php.yml . . . - name: Copy public key into /var/www authorized_key: user=www-data key="{{ lookup('file', 'deploykey.pub') }}" - name: Set www-data user shell user: name=www-data shell=/bin/bash - name: Enable UFW ufw: direction=incoming policy=deny state=enabled - name: UFW limit SSH ufw: rule=limit port=ssh - name: UFW open HTTP ufw: rule=allow port=http handlers: . . . نقوم بحفظ وتشغيل الـ playbook: ansible-playbook php.yml --ask-sudo-pass بعد أن يتم هذا بنجاح يجب أن نكون قادرين على الاتصال عبر SSH (باستخدام Ansible) أو HTTP إلى خادومنا، ستكون المنافذ الأخرى مقفلة الآن. نستطيع التحقّق من حالة UFW في أي وقت عن طريق تنفيذ هذا الأمر: ansible php --sudo --ask-sudo-pass -m shell -a "ufw status verbose" وبتقسيم أمر Ansible السابق من أجل فهمه نجد: ansible: تقوم بتنفيذ مهمّة Ansible خام بدون playbook.php: تقوم بتنفيذ المهمّة على المضيفين في هذه المجموعة.--sudo: تنفّذ الأمر كـ sudo.--ask-sudo-pass: تقوم بالحث prompt من أجل كلمة سر sudo.-m shell: تقوم بتشغيل وحدة الصدفة shell.-a "ufw status verbose“: الخيارات التي يجب تمريرها إلى الوحدة، وبما أنّها أمر shell نقوم بتمرير الأمر الخام raw (أي ufw status verbose) مباشرة بدون أي خيارات key=value.يجب أن يُعيد شيئًا مشابهًا لهذا: UFW status output your_server_ip | success | rc=0 >> Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22 LIMIT IN Anywhere 80 ALLOW IN Anywhere 22 (v6) LIMIT IN Anywhere (v6) 80 (v6) ALLOW IN Anywhere (v6) ترجمة -وبتصرّف- لـ How To Deploy an Advanced PHP Application Using Ansible on Ubuntu 14.04 لصاحبه Stephen Rees-Carter.

سنقدم في هذا الدرس من دليل إدارة خواديم أوبنتو مجموعة أدوات فعّالة للتحكم البعيد ونقل الملفات بين الحواسيب المتصلة بالشبكة تسمى «OpenSSH»، سنتعلم أيضًا مجموعةً من إعدادات الضبط الممكنة مع خادوم OpenSSH ونتعلم كيف نغيرها في نظام أوبنتو الخاص بك. إن OpenSSH هو إصدار مجاني وحر من مجموعة أدوات بروتوكول «الصدفة الآمنة» (Secure Shell ‏[SSH]) للتحكم البعيد أو نقل الملفات بين الحواسيب؛ الأدوات التقليدية التي كانت مستخدمةً لإنجاز هذه المهام -مثل telnet أو rcp- لم تكن آمنةً حيث كانت تنقل كلمة مرور المستخدم بنصٍ واضح عند استخدامها؛ أما OpenSSH، فيُوفِّر عفريتًا وأدوات للعميل لإنشاء عمليات تحكم عن بعد أو نقل الملفات آمنة ومشفرة؛ ويستبدل الأدوات القديمة استبدالًا فعالًا. مكونة خادوم OpenSSH المسماة sshd «تستمع» (listens) باستمرار لاتصالات العميل، وعندما يحدث طلب اتصال، فإن sshd ينُشِئ نوع الاتصال الصحيح اعتمادًا على نوع أداة العميل التي تجري الاتصال؛ على سبيل المثال، لو أن الحاسوب البعيد يتصل باستخدام برمجية عميل ssh، فإن خادوم OpenSSH يهيّء جلسة تحكم عن بُعد بَعد الاستيثاق؛ وإذا اتصل المستخدم البعيد مع خادوم OpenSSH باستخدام scp، فسيُهيّء عفريت خادوم OpenSSH نقلًا آمنًا للملفات بين الخادوم والعميل بعد الاستيثاق؛ ويمكن أن يَستخدِم OpenSSH عدَّة طرق للاستيثاق، منها كلمة المرور العادية، والمفتاح العمومي (public key)، وبطاقات Kerberos للدخول. التثبيتإن عملية تثبيت خادوم وعميل OpenSSH هي عمليةٌ بسيطة؛ استخدم هذا الأمر من مِحَث الطرفية لتثبيت عميل OpenSSH على نظام أوبنتو: sudo apt-get install openssh-clientاستخدم هذا الأمر في سطر الأوامر لتثبيت خادوم OpenSSH، وملفات الدعم المتعلقة به: sudo apt-get install openssh-serverيمكن أيضًا تحديد حزمة openssh-server للتثبيت أثناء عملية تثبيت نسخة الخادوم من أوبنتو. الضبطيمكنك ضبط السلوك الافتراضي لتطبيق خادوم OpenSSH‏ (sshd) بتعديل الملف ‎/etc/ssh/sshd_config، للمزيد من المعلومات حول الضبط المستخدم في هذا الملف، تستطيع مراجعة صفحة الدليل الملائمة بإدخال الأمر الآتي في الطرفية: man sshd_configهنالك تعليمات كثيرة في ملف ضبط sshd تتحكم بأشياء مثل إعدادات الاتصالات وأنماط الاستيثاق؛ يمكن أن تُعدَّل ما سنشرحه من تعليمات الضبط بتعديل ملف ‎/etc/ssh/sshd_config. تنويه: قبل تعديل ملف الضبط، عليك أخذ نسخة من الملف الأصلي وحفظها من الكتابة عليها لكي تحصل على نسخة من الضبط الافتراضي كمرجع، ولإعادة استخدامها وقت الحاجة. انسخ ملف ‎/etc/ssh/sshd_config واحمهِ من الكتابة باستخدام الأوامر الآتية: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original sudo chmod a-w /etc/ssh/sshd_config.originalما يلي هو أمثلة عن تعليمات الضبط التي قد ترغب في تعديلها: لضبط OpenSSH لكي يستمع على منفذ TCP ذي الرقم 2222 بدلًا من منفذ TCP الافتراضي 22، فغيِّر تعليمة المنفذ كما يلي: Port 2222لكي تجعل sshd يسمح باستخدام الاستيثاق المبني على المفتاح العمومي، فأضف أو عدِّل السطر: PubkeyAuthentication yesإذا كان السطر موجودًا مسبقًا، فتأكد من عدم وجود رمز التعليق قبله. لجعل خادوم OpenSSH يعرض محتويات ملف ‎/etc/issue.net كلافتة قبل تسجيل الدخول، فأضف أو عدِّل السطر الآتي: Banner /etc/issue.netفي ملف ‎./‎etc/ssh/sshd_config بعد إجراء التعديلات على ملف ‎/etc/ssh/sshd_config، فاحفظ الملف ثم أعد تشغيل خادوم sshd لتأخذ التغيرات مفعولها، وذلك بإدخال الأمر الآتي في مِحَث الطرفية: sudo service ssh restartتحذير: تتوفر المزيد من تعليمات الضبط لخادوم sshd لتعديل سلوك الخادوم لكي يلائم احتياجاتك، لكن يجب التنويه أنه إذا كانت الطريقة الوحيدة للوصول إلى الخادوم هي ssh، وارتكبت خطأً في ضبط sshd عبر ملف ‎/etc/ssh/sshd_config، فستجد نفسك غير قادرٍ على الوصول إلى الخادوم بعد إعادة تشغيل خدمة sshd؛ بالإضافة إلى أنك إذا وضعت تعليمة ضبط خاطئة، فسيرفض خادوم sshd أن يعمل؛ لذلك كن حذرًا جدًا عند تعديل هذا الملف على خادوم بعيد. مفاتيح SSHتسمح مفاتيح SSH بالاستيثاق بين جهازين دون الحاجة إلى كلمة مرور، يَستخدم الاستيثاق بواسطة مفتاح SSH مفتاحين: مفتاح خاص (private) ومفتاح عام (public). أدخِل الأمر الآتي في الطرفية لتوليد المفاتيح: ssh-keygen -t dsaسيولد الأمر السابق المفاتيح باستخدام خوارزمية التوقيع الرقمية (Digital Signature Algorithm‏ [DSA])، ستُطلَب منك كلمة المرور أثناء العملية، بعد ذلك اضغط ببساطة على Enter لإنشاء المفتاح. افتراضيًا، يُحفَظ المفتاح العام في الملف ‎~/.ssh/id_dsa.pub، بينما يكون ملف ‎~/.ssh/id_dsa هو المفتاح الخاص، انسخ ملف id_dsa.pub إلى المضيف البعيد، ثم أضفه إلى نهاية ملف ‎~/.ssh/authorized_keys باستخدام الأمر: ssh-copy-id username@remotehostفي النهاية، تأكد من الأذونات على ملف authorized_keys، حيث يجب أن يملك المستخدم الموثوق فقط إذن القراءة والكتابة؛ إذا لم تكون الأذونات صحيحة، فعدلها بالأمر: chmod 600 .ssh/authorized_keysيجب أن تصبح الآن قادرًا على الدخول إلى SSH على المضيف البعيد دون طلب كلمة المرور. مصادرصفحة ويكي أوبنتو «SSH».موقع «OpenSSH».صفحة الويكي «Advanced OpenSSH».ترجمة -وبتصرف- للمقال Ubuntu Server Guide: OpenSSH Server.

إنّ عامل الاستيثاق authentication factor هو جزء من المعلومات يُستخدَم لإثبات أنّه لدينا الحق لتنفيذ إجراء ما، مثل تسجيل الدخول إلى النّظام، وقناة الاستيثاق authentication channel هي الطّريقة التي يُوصِل بها نظام الاستيثاق عاملًا factor للمستخدم أو الطّريقة التي يطلب بها من المستخدم الرّد، من الأمثلة على عوامل الاستيثاق نجد كلمات السّر ورموز الأمان security tokens، ومن الأمثلة على قنوات الاستيثاق نجد الحواسيب والهواتف المحمولة. تستخدم SSH افتراضيًّا كلمات السّر من أجل الاستيثاق، وتُوصي تعليمات SSH باستخدام مفتاح SSH key بدلًا من ذلك، على أيّة حال يبقى هذا عاملًا واحدًا فقط، فإن تمّ تهديد الحاسوب لدينا من قبل شخص ما، فبإمكانه استخدام مفتاحنا لتهديد خواديمنا أيضًا. لمكافحة هذا سنقوم في هذا الدّرس بإعداد استيثاق مُتعدِّد العوامل (Multi-factor authentication (MFA، والذي يتطلّب أكثر من عامل من أجل الاستيثاق أو تسجيل الدّخول، وهذا يعني أنّه يجب على المُخترِق أن يُهدِّد عدّة أشياء، مثل حاسوبنا وهاتفنا المحمول معًا لكي يستطيع الدخول، يتم عادةً تلخيص أنواع العوامل المختلفة كما يلي: شيء نعرفه، مثل كلمة سر أو سؤال أمانشيء نملكه، مثل تطبيق استيثاق أو رمز أمان security tokenشيء نكون نحن عليه، مثل بصمة الأصابع أو الصوتمن العوامل الشائعة تطبيق OATH-TOTP مثل Google Authenticator، إنّ (OATH-TOTP (Open Authentication Time-Based One-Time Password الاستيثاق المفتوح لكلمة سر لمرّة واحد مُعتمِدة على الزمن هو عبارة عن ميثاق protocol مفتوح يقوم بتوليد كلمة سر صالحة للاستخدام لمرّة واحدة تكون عادةً عددًا من 6 أرقام يتم تجديده كل 30 ثانية. سيشرح هذا الدّرس كيفيّة تمكين استيثاق SSH باستخدام تطبيق OATH-TOTP بالإضافة لمفتاح SSH ، حيث سيتطلّب تسجيل الدخول إلى خادومنا عبر SSH عاملين اثنين عبر قناتين ممّا يجعله أكثر أمانًا من كلمة السّر أو مفتاح SSH لوحدهما. المتطلبات الأساسيةسنحتاج لمتابعة هذا الدّرس إلى: خادوم Ubuntu 14.04.مستخدم sudo غير جذري non-root مع إضافة مفتاح SSH، والذي نستطيع إعداده باتّباع درس الإعداد الابتدائي لخادوم أوبنتو 14.04.هاتف ذكي أو لوحي tablet مُثبَّت عليه تطبيق OATH-TOTP مثل Google Authenticator (روابط تنزيله من أجل Android و iOS).الخطوة الأولى – تثبيت libpam-google-authenticatorسنقوم في هذه الخطوة بتثبيت وإعداد PAM الخاصّة بـ Google. إنّ PAM، والتي ترمز إلى وحدة الاستيثاق القابلة للإضافة Pluggable Authentication Module، هي عبارة عن بنية تحتيّة للاستيثاق تُستَخدم على أنظمة لينِكس من أجل استيثاق المستخدمين، ولأنّ Google صنعت تطبيق OATH-TOTP فقد قامت أيضًا بإنشاء PAM تقوم بتوليد TOTPs ومتوافقة بشكل كامل مع أي تطبيق OATH-TOTP. نقوم في البداية بتحديث الذاكرة المؤقتة cache لمستودع Ubuntu: sudo apt-get updateنُثبِّت بعدها PAM: sudo apt-get install libpam-google-authenticatorوبعد تثبيت PAM سنستخدم تطبيق مُساعِد يتم تثبيته مع PAM لتوليد مفتاح TOTP للمستخدم الذي نرغب بإضافة عامل ثانٍ له، يتم توليد هذا المفتاح للمستخدم على أساس المستخدم وليس على أساس النّظام، ويعني هذا أنّ كل مستخدم يريد استعمال تطبيق استيثاق TOTP سيحتاج لتسجيل الدخول وتشغيل التطبيق المُساعِد للحصول على المفتاح الخاص به: google-authenticatorبعد تنفيذ الأمر سيتم سؤالنا عدّة أسئلة، يطلب السؤال الأول معرفة إذا ما كان يجب أن تكون رموز الاستيثاق authentication tokens على أساس زمني. يسمح PAM هذا برموز على أساس زمني time-based أو على أساس تتابعي sequential-based، يعني استخدام رموز على أساس تتابعي أنّ الشيفرة code تبدأ في نقطة مُعيّنة وبعدها تقوم بزيادة الشيفرة بعد كل استخدام، ويعني استخدام رموز على أساس زمني أنّ الشيفرة تتغير بشكل عشوائي بعد انقضاء وقت مُحدّد، سنختار الرموز على أساس زمني لأنّ هذا ما تتوقعه تطبيقات مثل Google Authenticator، لذا نجيبه بنعم: Do you want authentication tokens to be time-based (y/n) yبعد الإجابة على هذا السؤال سيتم تمرير الكثير من الخَرْج output، ومن ضمنه شيفرة QR كبيرة، تأكّد من تسجيلك للمفتاح السّري secret key، شيفرة التحقيق verification code، وشيفرات البداية في حالات الطوارئ emergency scratch codes في مكان آمن مثل مُدير كلمات السّر. عند هذه النقطة نستخدم تطبيق الاستيثاق authenticator الموجود على هاتفنا لمسح scan شيفرة QR أو نكتب يدويًّا المفتاح السّري، إن كانت شيفرة QR كبيرة جدًّا لمسحها نستطيع استخدام الرابط الموجود أعلاها للحصول على نسخة أصغر منها، حالما تتم إضافتها سنرى رمزًا مُكوَّنًا من 6 أرقام يتغيّر كل 30 ثانية في تطبيقنا. تقوم بقيّة الأسئلة بإعلام PAM كيف يعمل، سنمر عليها واحدًا تلو الآخر: Do you want me to update your "~/.google_authenticator" file (y/n) yيقوم هذا بشكل أساسي بكتابة المفتاح والخيارات إلى الملف google_authenticator.، إن قلنا "لا" سيخرج البرنامج ولن تتم كتابة أي شيء، والذي يعني أنّ تطبيق الاستيثاق authenticator لن يعمل. Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) yنمنع عندما نجيب على هذا السؤال بنعم هجمات الإعادة replay attack بأن نجعل كل رمز تنتهي صلاحيّته مباشرة بعد استخدامه، وهذا يمنع المُهاجِم من التقاط الرّمز الذي استخدمناه للتو وتسجيل الدخول به. By default, tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n) nتسمح إجابة نعم هنا بثمانية رموز صالحة خلال فترة 4 دقائق، وبإجابتنا "لا" نقوم بتحديدها إلى 3 رموز صالحة خلال فترة 1:30 دقيقة، إن لم تكن لديك مشكلة مع هذه الفترة فالإجابة "لا" هنا هي الخيارة الأكثر أمانًا. If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) yيعني تحديد المُعدَّل Rate limiting أنّ المُهاجِم البعيد يستطيع فقط أن يحاول عدد مُحدَّد من التخمينات قبل أن يتم حظره، إن لم نقم مُسبقًا بإعداد تحديد المُعدَّل بشكل مباشر داخل SSH فإنّ فعل هذا هنا هو تقنية رائعة. الخطوة الثانية – إعداد OpenSSHإنّ الخطوة التالية الآن هي إعداد SSH لاستخدام مفتاح TOTP لدينا، سنحتاج أن نخبر SSH عن PAM ومن ثم نقوم بإعداد SSH لاستخدامه. نفتح أولًا ملف الإعدادات sshd لتحرير باستخدام nano أو مُحرِّر النصوص المُفضَّل لدينا: sudo nano /etc/pam.d/sshdنضيف السطر التالي إلى نهاية الملف: . . \# Standard Un*x password updating. @include common-password auth required pam_google_authenticator.so nullokتُخبِر الكلمة "nullok" الموجودة في النهاية PAM أنّ طريقة الاستيثاق هذه اختياريّة، فيسمح هذا للمستخدمين الذين لا يملكون مفتاح OATH-TOTP أن يظلّوا قادرين على تسجيل الدخول باستخدام مفتاح SSH الخاص بهم، أمّا إن كان جميع المستخدمين يملكون مفتاح OATH-TOTP فنستطيع حذف "nullok" من هذا السّطر لجعل الاستيثاق مُتعدِّد العوامل MFA إجباريًّا. نحفظ ونغلق الملف. نقوم بعدها بإعداد SSH ليدعم هذا النوع من الاستيثاق، نفتح ملف إعدادات SSH لتحريره: sudo nano /etc/ssh/sshd_configنبحث عن ChallengeResponseAuthentication ونعيّن قيمتها إلى yes: . . . \# Change to yes to enable challenge-response passwords (beware issues with \# some PAM modules and threads) ChallengeResponseAuthentication yes . . .نحفظ ونغلق الملف، ونعيد تشغيل SSH لإعادة تحميل ملفّات الإعدادات: sudo service ssh restartالخطوة الثالثة – جعل SSH على علم بالاستيثاق مُتعدد العوامل MFAسنختبر في هذه الخطوة إذا ما كان مفتاح SSH يعمل. نفتح أولًا طرفيّة terminal أخرى ونحاول الدخول عبر SSH إلى الخادوم، سنلاحظ أنّنا سجلّنا الدخول إلى هذه الجلسة الثانية باستخدام مفتاح SSH الخاص بنا بدون إدخال شيفرة التحقيق أو كلمة السّر، حدث هذا لأنّ مفتاح SSH يقوم بشكل افتراضي بتجاوز جميع خيارات الاستيثاق الأخرى، نحتاج أن نُخبِر SSH أن يستخدم شيفرة TOTP ومفتاح SSH بدلًا من كلمة السر. نفتح الآن ملف الإعدادات sshd مرّة أخرى: sudo nano /etc/ssh/sshd_configنبحث عن السطر PasswordAuthentication ونزيل التعليق عنه بحذف الحرف # في بداية السّطر ونقوم بتحديث قيمته إلى no، يُخبِر هذا SSH ألّا يقوم بالسؤال عن كلمة السّر. . . . \# Change to no to disable tunnelled clear text passwords PasswordAuthentication no . . .نضيف بعد ذلك السطر التالي إلى أسفل الملف، والذي يُخبِر SSH ما هي طرق الاستيثاق المطلوبة: . . . UsePAM yes AuthenticationMethods publickey,keyboard-interactiveنحفظ ونغلق الملف. نفتح بعدها ملف إعدادات PAM sshd: sudo nano /etc/pam.d/sshdنقوم بإيجاد السطر include common-auth@ وجعله كتعليق بإضافة الحرف # كالحرف الأول في هذا السطر، يُخبِر هذا PAM ألّا تسأل عن كلمة السر، وقد قمنا سابقًا بإخبار SSH ألّا تفعل هذا في sshd_config: . . . # Standard Un*x authentication. #@include common-auth . . .نحفظ ونغلق الملف ومن ثم نعيد تشغيل SSH: sudo service ssh restartنحاول الآن تسجيل الدخول إلى الخادوم مرّة أخرى، ينبغي أن نرى أنّنا قمنا بالاستيثاق بشكل جزئي باستخدام مفتاح SSH الخاص بنا ومن ثمّ حصلنا على مُحِث prompt من أجل شيفرة التحقيق verification code، والذي سيبدو مشابهًا لما يلي: ssh sammy@your_server_ip Authenticated with partial success. Verification code:نُدخِل شيفرة التحقيق من تطبيق OAUTH-TOTP لدينا، وسيتم تسجيل دخولنا إلى الخادوم، نمتلك الآن الاستيثاق مُتعدِّد العوامل MFA مُمكَّنًا من أجل SSH. الخاتمةوكما يحدث مع أي نظام نقوم بتمنيعه وتأمينه سنصبح مسؤولين عن إدارة هذا الأمان، ويعني هذا في هذه الحالة عدم فقدان مفتاح SSH الخاص بنا أو مفتاح أمان TOTP، ومع ذلك قد يحدث هذا في بعض الأحيان ونفقد التحكّم بالمفاتيح التي تجعلنا نُسجِّل الدخول. نجد هنا بعض الاقتراحات لاستعادة النفاذ إلى خادومنا: إن فقدنا تطبيق TOTP أو لم نعد نملك نفاذًا إليه، نستخدم شيفرات الاستعادة recovery codes كشيفرة للتحقيق، قد يحدث هذا إن اشترينا هاتفًا جديدًا ونسينا تصدير مفاتيحنا من الهاتف القديم، أو نفذت بطارية هاتفنا.إن فقدنا مفتاح الأمان secret key والنسخة الاحتياطية، نقوم بإعادة تسمية أو حذف الملف google_authenticator./~، حيث يحرص هذا ألّا تعود PAM على معرفة بإعداداتنا وألّا تطلب منّا الرمز، تأكّد من أنّ الملف etc/pam.d/sshd/ لا زال يملك "nullok" في آخره، مثل الخطوة الثانية، وإن غيّرنا هذا نقوم بإعادة تشغيل SSH.إن فقدنا مفتاح SSH الخاص بنا، نقوم بإزالة المفتاح العام القديم من ssh/authorized_hosts./~، ونستبدله بمفتاح جديد.بامتلاك عاملين (مفتاح SSH+رمز MFA token) عبر قناتين اثنتين (حاسوبنا+هاتفنا المحمول) جعلنا من المستحيل تقريبًا لأي عميل خارجي أن يشقّ طريقه بالقوة القاسية brute force إلى داخل جهازنا عبر SSH وقمنا بزيادة أمان جهازنا بشكل رائع. ترجمة -وبتصرّف- لـ How To Set Up Multi-Factor Authentication for SSH on Ubuntu 14.04 لصاحبه Michael Holley.

بالرّغم من أنّ الاتصال إلى الخادوم عبر SSH آمن جدًّا، فإنّ SSH daemon (وهو عمليّة تعمل في خلفيّة النّظام بشكل دائم) بحدّ ذاتها هي خدمة يجب تعريضها إلى الإنترنت لتعمل بشكل صحيح، ويأتي هذا مع بعض المخاطر الكامنة ويخلق ناقلات للهجوم لأي مهاجمين مُحتَملين. إنّ أي خدمة مُعرّضة إلى الشّبكة هي هدف مُحتمل بهذه الطريقة، فإذا ألقينا انتباهنا إلى سجلّات التطبيق لهذه الخدمات سنجد محاولات مُنظّمة ومتكرّرة لتسجيل الدخول والتي تُمثّل هجمات بالقوّة القاسية Brute force attacks عن طريق مستخدمين أو روبوتات bots على حدٍّ سواء. يُمكن الحد من هذه المشكلة عن طريق خدمة تُدعى fail2ban والتي تقوم بإنشاء قواعد تستطيع تبديل إعدادات جدار حماية iptables بناءً على عدد معرّف مُسبقًا من محاولات تسجيل الدخول غير النّاجحة، يسمح هذا لخادومنا بالاستجابة لمحاولات النّفاذ غير الشّرعية من دون أي تدخّل منّا. سنغطّي في هذا الدّرس كيفيّة تثبيت واستخدام fail2ban على خادوم Ubuntu. تثبيت Fail2Ban على Ubuntuإنّ عمليّة التثبيت لهذه الأداة بسيطة لأنّ فريق تحزيم Ubuntu يُحافِظ على الحِزمة Package في المستودعات الافتراضيّة default repositories. نحتاج في البداية لتحديث دليل الحِزَم المحلّي local package index لدينا، وبعدها نستطيع استخدام apt لتنزيل وتثبيت الحِزمة: sudo apt-get update sudo apt-get install fail2banإنّ عملية التثبيت بديهيّة كما نرى، نستطيع الآن البدء بإعداد الأداة لاستخدامنا الشّخصي. إعداد Fail2Ban مع إعدادات الخدمة الخاصة بناتحتفظ خدمة fail2ban بملفّات إعداداتها في الدّليل etc/fail2ban/، يوجد ملف مع إعدادات افتراضيّة يُدعى jail.conf. ولأنّه يُمكن أن يتم تعديل هذا الملف عن طريق ترقية الحِزَم لذلك لا ينبغي علينا تحرير هذا الملف في مكانه، بل من الأفضل أن نقوم بنسخه حتى نستطيع القيام بتغييراتنا بأمان. نحتاج لنسخه إلى ملف يُدعى jail.local حتى يستطيع fail2ban إيجاده: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localحالما يتم نسخ الملف بإمكاننا فتحه للتحرير لنرى كيف يعمل كل شيء: sudo nano /etc/fail2ban/jail.localيوجد في هذا الملف القليل من الإعدادات التي قد نرغب بضبطها، يتم تطبيق هذه الإعدادات الموجودة تحت قسم [DEFAULT] على جميع الخدمات المُمَكَّنة enabled من أجل fail2ban الذي لا يتم تجاوزه في القسم الخاص بالخدمة: ignoreip = 127.0.0.1/8نستطيع ضبط مصدر العناوين التي يتجاهلها fail2ban عن طريق إضافة قيمة إلى المُعامِل parameter ignoreip. يتم ضبطه افتراضيًّا بأن لا يقوم بمنع أي نقل للبيانات traffic قادم من الجهاز المحلّي، نستطيع إضافة المزيد من العناوين التي نريد تجاهلها عن طريق إلحاقها بنهاية هذا المُعامِل مع الفصل بينها بفراغ Space. bantime = 600يقوم المُعامِل bantime بتعيين المُدّة الزمنيّة التي سيتم خلالها حظر العميل عندما يفشل بالاستيثاق authenticate بشكلٍ صحيح، يتم قياس هذا المُعامِل بالثّواني، وقيمته الافتراضيّة هي 600 ثانية أي 10 دقائق. findtime = 600 maxretry = 3ومن المُعامِلات التي نرغب أن نلقي لها انتباهًا نجد المُعامِلَين findtime و maxretry، وهما يعملان معًا لتأسيس الشّروط التي نستطيع بناءً عليها اعتبار عميل ما مستخدمًا غير قانونيٍ يجب علينا حظره. يقوم المُتغيّر maxretry بتعيين عدد المحاولات التي يجب خلالها أن يقوم العميل بالاستيثاق خلال فترة زمنيّة مُعرّفة بـ findtime وذلك قبل أن يتمّ حظره، تقوم الإعدادات الافتراضيّة لخدمة fail2ban بحظر العميل الذي يقوم بثلاث محاولات غير ناجحة لتسجيل الدخول خلال فترة 10 دقائق. destemail = root@localhost sendername = Fail2Ban mta = sendmailومن بعض الإعدادات الأخرى التي قد نرغب بتعديلها نجد الإعدادات destemail، sendername، و mta إن أردنا ضبط تنبيهات alerts البريد الإلكتروني، يقوم المُعامِل destemail بتعيين عنوان البريد الإلكتروني الذي سيستقبل رسائل الحظر، يقوم المُعامِل sendername بتعيين قيمة الحقل From في البريد الإلكتروني، يُحدّد المُعامِل mta خدمة البريد الإلكتروني التي سيتم استخدامها لإرسال البريد. action = $(action_)sيضبط هذا المُعامل الإجراءات التي يتّخذها fail2ban عندما يريد إقامة حظر، إنّ القيمة _action مُعرَّفة في الملف قبل هذا المُعامِل بقليل، الإجراء الافتراضي هو ببساطة أن يتم ضبط الجّدار النّاري firewall لكي يرفض نقل البيانات من المُضيف Host المُهاجِم حتى تنتهي مُدّة الحظر. إن أردنا ضبط تنبيهات البريد الإلكتروني نستطيع تغيير القيمة من _action إلى action_mw، وإن كُنّا نرغب أن يقوم البريد الإلكتروني بتضمين سطور السّجلات المُتعلّقة بذلك نستطيع تغييرها إلى action_mwl، يجب أن نتأكّد من أنّه يتم ضبط إعدادات البريد المُناسبة إن اخترنا استخدام تنبيهات البريد. 1. إعدادات Jail الفرديةلقد وصلنا أخيرًا إلى الجزء من ملف الإعدادات الذي يتعامل مع الخدمات الفرديّة، والتي يتم تحديدها في القسم headers مثل [SSH]. نستطيع تمكين كل واحد من هذه الأقسام عن طريق تعديل أو إضافة السّطر enabled وتعيينه إلى true: enabled = trueنجد بشكل افتراضي أنّ خدمة SSH مُمكّنة وباقي الخدمات مُعطّلة. تعمل هذه الأقسام عن طريق استخدام القيم الافتراضيّة التي عرّفناها مُسبقًا، وإن أردنا تجاوز override أي قيم نستطيع فعل ذلك في قسم الخدمات، أمّا إن أردنا استخدام القيم الافتراضيّة فلا داعي لإضافة أي شيء. ومن الإعدادات الأخرى التي يُمكن تعيينها هنا هي filter والذي يستخدم ليحدّد إذا ما كان السطر في ملف السّجل يشير إلى استيثاق فاشل، وlogpath الذي يُخبِر fail2ban أين توجد السّجلات لتلك الخدمة بالتحديد. إنّ قيمة filter هي في الواقع إشارة reference إلى ملف يتوضّع في الدّليل etc/fail2ban/filter.d/ مع إزالة لاحقته conf.، يحتوي هذا الملف على التّعابير النمطيّة regular expressions التي تُحدّد إذا ما كان السّطر في ملف السّجل سيّئًا، لن نقوم بالتّحدث بالتفصيل عن هذا الملف في هذا الدّرس، لأنّه مُعقّد إلى حدٍ ما، والإعدادات المُعرّفة مُسبقًا تتوافق مع السطور المُلائمة لها بشكل جيّد. بإمكاننا على أيّة حال أن نرى أنواع المُرشّحات filters المتوفرة من خلال النّظر إلى هذا الدّليل: ls /etc/fail2ban/filter.dعندما نجد ملفًّا مرتبطًا بالخدمة التي نستخدمها ينبغي أن نفتحه باستخدام مُحرّر نصوص. مُعظم هذه الملفّات تحتوي على تعليقات للشرح بشكل جيّد ويجب أن نكون قادرين على الأقل أن نعرف ما هو نوع الشّروط التي تم تصميم الـ script من أجل الحماية ضدّها، تملك أغلب هذه المُرشّحات أقسام (مُعطّلة) مناسبة في ملف jail.local والتي نستطيع تمكينها عند الرغبة بذلك. فلنفترض على سبيل المثال أنّنا نقوم بتخديم موقع باستخدام nginx وأدركنا أنّ قسم منه محمي بكلمة مرور يتعرّض لمحاولات تسجيل دخول، نستطيع إخبار fail2ban أن يستخدم الملف nginx-http-auth.conf لكي يفحص هذا الشّرط من خلال الملف var/log/nginx/error.log/. هذا الشّرط مُعَد مُسبقًا في الواقع ضمن قسم يُدعى [nginx-http-auth] في الملف etc/fail2ban/jail.local/، نحتاج فقط إلى قلب المُعامِل enabled إلى true لحماية الخدمة الخاصّة بنا: [nginx-http-auth] enabled = true filter = nginx-http-auth port = http,https logpath = /var/log/nginx/error.logإن قمنا بتفعيلها نحتاج إلى إعادة تشغيل خدمة fail2ban للتأكّد من أنّ قواعدنا مبنيّة بشكل صحيح. وضع كل ذلك معاالآن وقد فهمنا الفكرة الأساسيّة من وراء fail2ban، فلنقم بتشغيل إعداد أساسي. سنقوم بإعداد سياسة حظر تلقائي من أجل SSH وNginx تمامًا كما وصفنا سابقًا، نريد من fail2ban أن يقوم بإرسال بريد إلكتروني لنا عندما يتم حظر عنوان IP. فلنقم في البداية بتثبيت جميع البرمجيّات المتعلقّة بذلك. إن كُنّا لا نملك nginx يجب علينا تثبيته، لأنّنا سنقوم بمراقبة سجلّاته، سنحتاج أيضًا sendmail لكي يرسل التّنبيهات إلينا، سنقوم بتثبيت iptables-persistent لكي يسمح للخادوم بإعداد قواعد الجّدار النّاري تلقائيًّا عند الإقلاع boot، نستطيع الحصول على كل هذا من مستودعات Ubuntu الافتراضيّة: sudo apt-get update sudo apt-get install nginx sendmail iptables-persistent 1. إنشاء جدار ناري أساسيينبغي علينا بعد الانتهاء من كل هذا إنشاء جدار ناري افتراضي، تستطيع تعلّم كيفيّة إعداد iptables للجدار الناري على Ubuntu من هنا، سنقوم في هذا الدّرس فقط بإنشاء جدار ناري أساسي. سنخبر الجّدار النّاري بالسّماح للاتصالات التي تمّ تأسيسها، نقل البيانات traffic الذي يتم توليده من قبل الخادوم نفسه، مقدار نقل البيانات من أجل SSH لدينا، ومنافذ ports خادوم الوِب، وسنقوم باستبعاد أي نقل بيانات آخر، نستطيع إعداد هذا الجّدار النّاري الأساسي عن طريق كتابة: sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT sudo iptables -A INPUT -j DROPستقوم هذه الأوامر بتنفيذ السّياسة السّابقة، وبإمكاننا رؤية قواعد الجّدار النّاري الحاليّة عن طريق كتابة: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-ssh -j RETURN حصلنا هنا على سياستنا الافتراضيّة لكل واحدة من السلاسل لدينا، ومن ثمّ القواعد الخمس التي أنشأناها للتو، إنّ الأسطر التي تحتوي على: -N fail2ban-ssh و -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-sshو -A fail2ban-ssh -j RETURN هي عبارة عن البُنية الافتراضيّة المُعدّة من قبل fail2ban حيث أنّه يقوم مُسبقًا بتنفيذ سياسات حظر SSH بشكل افتراضي. 2. ضبط إعدادات Fail2banنحتاج الآن لضبط إعدادات fail2ban باختيار الإعدادات التي نرغب بها، فلنقم بفتح الملف jail.local: sudo nano /etc/fail2ban/jail.localنستطيع هنا تعيين زمن للحظر أشد طولًا، فلنقم بتغيير الإعداد bantime الموجود تحت الترويسة الافتراضيّة بحيث تقوم خدمتنا بحظر العملاء لمدة نصف ساعة: bantime = 1800نحتاج أيضًا لضبط معلومات تنبيهات البريد الإلكتروني، نقوم في البداية بإيجاد المُعامِل destemail ونضع بداخله عنوان البريد الإلكتروني الذي نرغب باستخدامه لجمع هذه الرسائل: destemail = admin@example.comنستطيع تعيين sendername إلى قيمة أخرى إن أردنا ذلك، على الرغم من أنّه من المفيد أن يكون لها قيمة يُمكن تصفيتها بسهولة باستخدام خدمة البريد الإلكتروني الخاصّة بنا، وإلّا امتلأ صندوق الوارد بالتنبيهات إن كانت هناك الكثير من محاولات الاختراق من أماكن متعدّدة. بالانتقال للأسفل نحتاج لضبط المُعامِل action إلى أحد الإجراءات التي ترسل لنا بريد إلكتروني، الخيارات محصورة بين action_mw والذي يُنشِئ الحظر ومن ثمّ يرسل لنا بريدًا إلكترونيًّا يحتوي على تقرير whois حول المُضيف المخالف، أو action_mwl والذي يقوم بما سبق ولكن يرسل لنا أيضًا سطور السجل المتعلّقة بذلك. سوف نختار action_mwl لأنّ سطور السّجلات ستساعدنا على استكشاف الأخطاء وجمع المزيد من المعلومات إن كانت توجد مشاكل: action = %(action_mwl)sوبالانتقال إلى قسم SSH لدينا، إن أردنا ضبط عدد المحاولات غير الناجحة التي ينبغي أن نسمح بها قبل إنشاء حظر نستطيع تعديل الإدخال maxretry، وإن كُنّا نستخدم منفذ غير 22 سنحتاج لضبط المُعامِل port بشكلٍ مُناسِب، وكما قلنا سابقًا فإنّ هذه الخدمة مُمكّنة مُسبقًا لذلك لا حاجة لتعديل ذلك. فلنبحث بعد ذلك عن القسم nginx-http-auth ونُغيّر المُعامِل enabled ليصبح true: [nginx-http-auth] enabled = true . . .هذا هو كل ما ينبغي علينا فعله في هذا القسم ما لم يكن يعمل خادوم الوِب لدينا على منافذ غير معياريّة أو قمنا بنقل المسار الافتراضي لسجلّات الأخطاء. 3. إعادة تشغيل خدمة Fail2banبعد الانتهاء مما سبق نقوم بحفظ وإغلاق الملف. نقوم الآن ببدء تشغيل أو إعادة تشغيل خدمة fail2ban، من الأفضل أحيانًا إيقاف تشغيل الخدمة بشكلٍ تام ومن ثم تشغيلها مرة أخرى: sudo service fail2ban stopنستطيع الآن إعادة تشغيلها بكتابة ما يلي: sudo service fail2ban startقد تستغرق بضع لحظات لكي يتم ملء جميع قواعد الجّدار النّاري لدينا، على أيّة حال نستطيع بعد ذلك التأكّد من القواعد الجديدة بكتابة: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -j RETURNإن الأسطر التي قامت بإنشائها سياسات fail2ban لدينا هي: -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -j RETURN تقوم هذه الأسطر الآن بتوجيه نقل البيانات إلى سلاسل جديدة وفارغة تقريبًا ومن ثمّ تسمح لنقل البيانات بالتدفق والعودة إلى سلسلة الدّخل INPUT. على أيّة حال هذه السلاسل الجديدة هي حيث يتم إضافة قواعد الحظر الجّديدة. 4. اختبار سياسات الحظرنستطيع اختبار القواعد من خادوم آخر -خادوم لا نحتاج له للدخول إلى خادوم fail2ban- عن طريق جعل هذا الخادوم الثاني ينحظر. بعد الدخول إلى الخادوم الثاني نقوم بمحاولة الدخول عن طريق SSH إلى خادوم fail2ban، نستطيع على سبيل المثال محاولة الاتصال باستخدام اسم غير موجود: ssh blah@fail2ban_server_IPفلنقم بإدخال أحرف عشوائيّة في النّافذة التي تطلب منّا كلمة مرور، ومن ثمّ نعيد هذه الخطوة عدّة مرات، سيقوم خادوم fail2ban في نقطة ما بإيقاف الاستجابة مع رسالة تم رفض الإذن Permission denied، وهذا يشير إلى أنه تم حظر الخادوم الثاني من قبل خادوم fail2ban. نستطيع على خادوم fail2ban مشاهدة القواعد الجديدة عن طريق التّحقق مرة أخرى من iptables لدينا: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -s 11.111.111.11/32 -j REJECT --reject-with icmp-port-unreachable -A fail2ban-ssh -j RETURNوكما نرى في السّطر: -A fail2ban-ssh -s 11.111.111.11/32 -j REJECT --reject-with icmp-port-unreachableنملك الآن قاعدة جديدة في إعداداتنا ترفض نقل البيانات القادمة من عنوان IP خادومنا الثاني عبر منفذ SSH، ينبغي أيضًا أن نكون قد حصلنا على بريد إلكتروني حول هذا الحظر في الحساب الذي قمنا بإعداده. خاتمةينبغي أن نكون قادرين الآن على إعداد بعض سياسات الحظر الأساسيّة لخدماتنا، من السّهل جدًّا إعداد Fail2ban وهو طريقة رائعة لحماية أي نوع من الخدمات تستخدم الاستيثاق. إن أردت تعلّم المزيد حول كيفيّة عمل fail2ban بإمكانك تفحّص هذا الدّرس التعليمي حول كيفيّة عمل قواعد وملفّات fail2ban. ترجمة -وبتصرّف- للمقال How To Protect SSH with Fail2Ban on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.

يُعتبر FreeBSD نظام تشغيل آمن، عالي الأداء، ومناسب لمجموعة متنوعة من وظائف الخوادم الشائعة. نغطي في هذا الدرس المعلومات الأساسية التي تحتاجها لتنطلق مع خوادم FreeBSD. الخطوة الأولى: الولوج عبر SSHالخطوة الأولى التي نحتاجها للبدء في ضبط وإعداد خادوم FreeBSD هي تسجيل الدخول من خلاله. تُزوّدك معظم الشركات بمفتاح SSH العمومي عند إنشاء خادوم FreeBSD، بحيث يمكنك تسجيل الدخول بشكلٍ آمن من حاسوبك المنزلي إلى خادومك عبر مفتاح SSH الخاص المرتبط به. لمعرفة المزيد حول كيفية استخدام مفاتيح SSH يمكنك قراءة مقال العمل مع خواديم ssh، العملاء والمفاتيح من أكاديمية حسوب. لتسجيل الدخول إلى الخادوم الخاص بك تحتاج أولًا إلى معرفة عنوان IP العام له، والذي يمكنك إيجاده عادة من لوحة التحكم، بالإضافة إلى اسم المستخدم الرئيسي لخادوم FreeBSD (سنستخدم لهذا الدرس الاسم freebsd لغرض تعليمي)، كما تختلف الإعدادات الافتراضية بين الشركات حول صلاحيات هذا المستخدم، وسنفترض هنا حصوله على أذونات استعمال sudo لإتمام المهام الإدارية. لتسجيل الدخول إلى خادوم FreeBSD استخدم الأمر ssh مع تحديد عنوان IP العام للخادوم إضافة لاسم المستخدم : ssh freebsd@server_IP_addressيُفترض أن تتم المصادقة تلقائيًا وينجح تسجيل الدخول لتكون أمام سطر الأوامر الخاص بخادومك. تغيير موجه صدفة tcsh والإعدادات الافتراضية (اختياري)بعد تسجيل الدخول ستجد نفسك أمام موجّه أوامر بسيط يبدو بالشكل: >وهو الموجّه الافتراضي في tcsh صدفة سطر الأوامر القياسيّة في FreeBSD، لنُدخل الآن بعض التعديلات المفيدة على ملف ضبط الصدفة بهدف جعلها أكثر فائدة، مثل توضيح مسار الطرفية قبل إشارة المحث. إحدى أمثلة ملف الضبط موجودة في نظام الملفات لدينا، وكل ما علينا فعله هو نسخها إلى دليل المنزل لإجراء التعديلات التي نرغب بها: cp /usr/share/skel/dot.cshrc ~/.cshrcبعد نسخ الملف السابق إلى مجلد المنزل لنحرّره باستخدام الأداة vi المدمجة مع FreeBSD، أما إذا كنت ترغب باستعمال شيء أبسط فيمكنك تجريب المحرّر ee: vi ~/.cshrcيتضمّن هذا الملف بعض القيم الافتراضية المعقولة بما في ذلك موجّه أكثر وظيفيّة، إحدى الأجزاء التي قد ترغب بتعديلها هي مُدخلات setenv: . . . setenv EDITOR vi setenv PAGER more . . .إذا لم تألف التعامل مع المحرّر vi وترغب باعتماد بيئة تحرير أكثر سهولة، فعليك تغيير قيمة متغيّر البيئة EDITOR إلى شيء مثل ee. كما يميل معظم المستخدمين إلى تعديل قيمة PAGER إلى less بدلًا من more وهذا ما يسمح بالانتقال إلى أعلى وأسفل ضمن ملفات أدلة البرامج man بدون مغادرة pager: setenv EDITOR ee setenv PAGER lessنحتاج أيضًا إضافة الشيفرة التالية إلى آخر ملف الضبط السابق وذلك لتصحيح مواضع بعض أزرار لوحة المفاتيح لدينا داخل جلسة tcsh، وإلا فلن تعمل بعض الأزرار بوظائفها المتوقعة مثل زر Delete، ما عليك فعله هو نسخ هذه الأسطر وإضافتها أسفل الملف: if ($term == "xterm" || $term == "vt100" || $term == "vt102" || $term !~ "con*") then # bind keypad keys for console, vt100, vt102, xterm bindkey "\e[1~" beginning-of-line # Home bindkey "\e[7~" beginning-of-line # Home rxvt bindkey "\e[2~" overwrite-mode # Ins bindkey "\e[3~" delete-char # Delete bindkey "\e[4~" end-of-line # End bindkey "\e[8~" end-of-line # End rxvt endifعند الانتهاء احفظ الملف واخرج من المُحرّر. لوضع التعديلات الجديدة موضع التنفيذ في الجلسة الحالية يمكننا إعادة تحميل ملف الضبط السابق: source ~/.cshrc ستلاحظ في الحال تغيّر هيئة موجّه الأوامر لديك إلى شيء يشبه: freebsd@hostname:~ % كما ستعمل أزرار "Home" ،"Insert" ،"Delete" و"End" بوظائفها المعتادة بدءًا من الآن. شيء آخر بقي أن أشير إليه هنا؛ في حال كنت تستخدم صدفة tcsh الافتراضية أو csh فأنت بحاجة إلى تنفيذ الأمر rehash كلما أجريت تعديلًا قد يؤثّر على مسار الملفات التنفيذيّة. أحد الأمثلة الشائعة على ذلك تثبيت أو إزالة تثبيت تطبيق ما. بعبارة أخرى بعد تركيب برنامج جديد يتوجب عليك تنفيذ الأمر التالي لتتمكّن الصدفة من التعرّف على ملفات البرنامج الجديد: rehashتغيير الصدفة الافتراضية (اختياري)تمنحك التعديلات السابقة إلفة أكثر مع بيئة tcsh أما إذا كنت لا تزال ترغب باعتماد صدفة bash كصدفة افتراضية لخادوم FreeBSD الخاص بك فعليك اتباع التعليمات التالية: في البداية يتوجب عليك تثبيت صدفة bash عن طريق كتابة: sudo pkg install bashبعد انتهاء التثبيت سنضيف السطر التالي إلى ملف etc/fstab/ لربط الملف الواصف لنظام الملفات، والذي تحتاجه صدفة bash: fdesc /dev/fd fdescfs rw 0 0لإضافة السطر السابق بسهولة إلى آخر ملف etc/fstab/ يمكنك تنفيذ الأمر التالي: sudo sh -c 'echo "fdesc /dev/fd fdescfs rw 0 0" >> /etc/fstab'بعد ذلك يمكننا ربط نظام الملفات من خلال: sudo mount -aهكذا سيكون نظام الملفات جاهز لتشغيل bash، ولتشغيلها نفّذ الأمر التالي: bashلتعديل الصدفة الافتراضية إلى bash يمكنك كتابة: sudo chsh -s /usr/local/bin/bash freebsdفي المرة التالية التي تُسجّل بها دخولك إلى الخادوم ستبدأ مع صدفة bash بدلًا من tcsh. إذا كنتَ ترغب بتعديل المحرّر الافتراضي أو قيمة pager في صدفة bash ستحتاج أولًا إلى إنشاء الملف التالي في دليل المنزل: vi ~/.bash_profileيمكنك الآن إجراء التعديلات التي ترغب بها داخل هذا الملف، سأضع هنا اختياراتي المُفضّلة: export PAGER=less export EDITOR=vi احفظ الملف واخرج من المحرّر عندما تنتهي من التعديل. لوضع التغييرات الأخيرة موضع التنفيذ الفوري أعد تحميل ملف الضبط السابق: source ~/.bash_profileتعيين كلمة مرور الجذر (اختياري)بشكلٍ افتراضي لا تتيح خوادم FreeBSD الولوج كمستخدم جذر عبر ssh، ورغم ذلك فإنه من الآمن تعيين كلمة مرور root يتم طلبها عند رغبتك استخدام حساب الجذر من خلال طرفية لوحة تحكم الوِيب لخادومك. لتعيين كلمة مرور root اكتب: sudo passwdستسألك الطرفية إدخال وتأكيد كلمة مرور الجذر. وكما ذكرنا أعلاه فإن هذا لن يتيح لك استعمال ssh لتسجيل الدخول بحساب root (لأغراض أمنية) أما لتنفيذ المهام الإدارية فعليك استعمال طرفية لوحة تحكّم الوِيب. الخلاصةتعلمنا إلى الآن كيفية تسجيل الدخول إلى خادوم FreeBSD، وتعديل بيئة الصدفة بشكل مناسب، وحالما تألف التعامل مع FreeBSD وتضبطه بما يتلاءم واحتياجاتك سوف تكون قادر على الاستفادة من مرونته، أمانه، وأدائه العالي. ترجمة -وبتصرف- للمقال: How To Get Started with FreeBSD 10.1 لصاحبه: Justin Ellingwood.

تنفيق النقل (أي نقله) عبر نفق SSH آمن (SSH Tunnel)، هو طريقة ممتازة للعمل حول إعدادات جدار ناري تقييدي خاص بـ SSH. ويُعتبر أيضا طريقة رائعة لتشفير أو فك تشفير نقل الشّبكة (network traffic). ضبط تنفيق محلي إلى خادوميُمكن استخدام اتّصالات SSH لتنفيق النقل (أي نقل البيانات عبر أنفاق) من المنافذ على المُضيف المحلي إلى منافذ أخرى على مُضيف بعيد. أوّلاً، يُؤسَّس اتّصال SSH مع المُضيف البعيد. أمّا على الخادوم البعيد، يتم إنشاء اتّصال إلى عنوان شبكة خارجيّة (أو داخليّة) مُقدّم من المُستخدم، والنّقل إلى هذا الموقع يُنفّق (أي يستخدم نفقا) إلى الحاسوب المحلي على منفذ مُحدّد. هذا الأمر يُستخدم عادة للتنفيق نحو بيئة شبكية أقل تقييدا لتجاوز جدار ناري (الأمر أشبه بـآلية عمل VPN)، أي أن هناك طرفا ثالثا (كالبروكسي أو خادوم في منتصف الطريق يمر عليه نقل الشبكة Network traffic). ويُستعمل أيضا بشكل شائع للوصول إلى واجهة ويب من نوع 'مُضيف محلي فقط' من مكان بعيد. لإنشاء نفق محلي نحو الخادوم البعيد، ستحتاج إلى استخدام مُعامل L- عند الاتّصال ويجب عليك توفير 3 معلومات إضافية: المنفذ المحلي الذي ترغب في الوصول إلى الاتّصال المُنفّق منه.المُضيف الذي ترغب في أن يتصل به المُضيف البعيد.المنفذ الذي تريد أن يتصل منه المُضيف البعيد. وهي مُعطاة بالترتيب أعلاه (مُفرّقة بنقطتين بين كل منها) كقيم للمعامل L-. وسنستخدم أيضا المُعامل f- الذي يُحيل SSH للعمل في الخلفيّة قبل التشغيل، وكذلك المُعامل N-، الذي لا يفتح شلّا أو يُنفذ برنامجا على الجهة البعيدة. على سبيل المثال، للاتّصال بـ example.com على المنفذ رقم 80 على المُضيف البعيد، متيحا الاتّصال على جهازك المحلي عبر المنفذ رقم 8888، يُمكنك أن تكتب الآتي: ssh -f -N -L 8888:example.com:80 username@remote_host إذا قمت بالدّخول إلى 127.0.0.1:8888 على مُتصفّحك المحلي، ستحصل على محتوي example.com من المنفذ رقم 80. تركيب جملة أعمّ يُمكن أن يكون كالتّالي: ssh -L your_port:site_or_IP_to_access:site_port username@host بما أنّ الاتّصال يتم في الخلفّية يجب عليك إيجاد رقم PID لقتله (إغلاقه)، يُمكنك فعلُ ذلك بالبحث عن المنفذ الذي وضّفته: ps aux | grep 8888 1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -L 8888:example.com:80 username@remote_host 1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888 يُمكنك بعدها قتلُ العمليّة باستهداف رقم PID، وهو الرقم على العمود الثّاني الذّي يُوافق أمر SSH : kill 5965 هناك خيّار آخر وهو بدء الاتّصال بدون المُعامل f-. الأمر الذي سيُبقي الاتّصال في الواجهة، مانعاً استخدام نافذة الطّرفية كامل مدّة الإحالة. والإفادة هنا هي إمكانية إيقاف النّفق بالضّغط على "CTRL-C”. ضبط تنفيق بعيد إلى خادوميُمكن استعمال اتّصالات SSH لتنفيق النّقل من منافذ على المُضيف المحليّ إلى منافذ على المُضيف البعيد. الاتّصال يُخلق نحو مُضيف بعيد على النفق البعيد، خلال إنشاء النّفق يُحدّد رقم منفذ بعيد. هذا المنفذ على المُضيف البعيد سيُنفّق نحو مُضيف ومنفذ مربوطين من الجهاز المحليّ. هذا سيُخوّل الحاسوب البعيد للوصول إلى مُضيف عبر جهازك المحليّ. يُمكنُ لهذا أن يكونَ مُفيداً إذا احتجتَ للسّماح بالوصول إلى شبكة داخليّة مُغلقة نحو اتّصالات خارجيّة. إذا كان الجدار النّاري يسمح بالاتّصالات خارج الشّبكة فإنّ هذا سيُخولُ لك الاتّصال إلى جهاز بعيد ونفق نقل من ذلك الجهاز نحو مكان على الشبكة الدّاخليّة. لإنشاء نفق بعيد نحو خادومك البعيد، ستحتاج إلى تمرير المعامل R- عند الاتّصال ويجب عليك توفير 3 معلومات إضافيّة: رقم المنفذ الذي يُمكن للمُضيف البعيد أن يصل إلى الاتّصال المُنفّق منه.المُضيف الذي ترغب في أن يتّصل به جهازك المحلي.المنفذ الذي ترغب في أن يتّصل منه جهازك المحليّ. وهي مُعطاة بالترتيب أعلاه (مُفرّقة بنقطتين بين كل منها) كقيم للمعامل R-. وسنستخدم أيضا المُعامل f- الذي يُحيل SSH للعمل في الخلفيّة قبل التشغيل، وكذلك المُعامل N-، الذي لا يفتح شلّا (shell) أو يُنفذ برنامجا على الجهة البعيدة. على سبيل المثال، للاتّصال ب example.com على المنفذ رقم 80 على المُضيف المحليّ، متيحا الاتّصال على الجهاز البعيد عبر المنفذ رقم 8888، يُمكنك أن تكتب الآتي: ssh -f -N -R 8888:example.com:80 username@remote_host إذا قمت بالدّخول إلى 127.0.0.1:8888 على مُتصفّح الخادوم، ستحصل على محتوي example.com من المنفذ رقم 80. تركيب جملة أعمّ يُمكن أن يكون كالتّالي: ssh -R your_port:site_or_IP_to_access:site_port username@host بما أنّ الاتّصال يتم في الخلفّية يجب عليك إيجاد رقم PID لقتله (إغلاقه)، يُمكنك فعلُ ذلك بالبحث عن المنفذ الذي وضّفته: ps aux | grep 8888 1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -L 8888:example.com:80 username@remote_host 1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888 يُمكنك بعدها قتلُ العمليّة باستهداف رقم PID، وهو الرقم على العمود الثّاني الذّي يُوافق أمر SSH : kill 5965 هناك خيّار آخر وهو بدء الاتّصال بدون المُعامل f-. الأمر الذي سيُبقي الاتّصال في الواجهة، مانعاً استخدام نافذة الطّرفية كامل مدّة الإحالة. والإفادة هنا هي إمكانية إيقاف النّفق بالضّغط على "CTRL-C”. ضبط تنفيق ديناميكي نحو خادوم بعيديُمكن استعمال اتّصالات SSH لتنفيق النّقل من منافذ على المُضيف المحليّ إلى منافذ على المُضيف البعيد. النّفق الديناميكي مُماثل للنّفق المحليّ من حيث أنّه يُخول الجهاز المحلي للاتّصال بموارد أخرى عبر مُضيف بعيد. يقوم النّفق الديناميكي بهذا ببساطة عبر تحديد منفذ محلي واحد. التطبيقات التي ترغب في أن تستغلّ الفرصة للتنفيق من هذا المنفذ يجب أن تكون قادرة على التواصل باستخدام بروتوكول SOCKS ليُعاد توجيه الحزم بنجاح على الجانب الآخر من النّفق. النّقلُ المُمَرّر نحو المنفذ المحلي سيُرسَلُ إلى المُضيف البعيد. من هناك سيُترجم بروتوكول SOCKS لإنشاء اتّصالٍ نحو النهاية المرغوبة. هذا الضّبط يسمح لتطبيق من نوع SOCKS-capable بالاتّصال بأي عدد من الأماكن عبر خادوم بعيد بدون أنفاق ساكنة مُتعدد لإنشاء الاتّصال. سنُمرّر المُعامل D- مع رقم المنفذ المحلي الذي نرغب أن نصل إلى النّفق منه. وسنستخدم أيضا المُعامل f- الذي يُحيل SSH للعمل في الخلفيّة قبل التشغيل، وكذلك المُعامل N-، الذي لا يفتح شلّا أو يُنفذ برنامجا على الجهة البعيدة. على سبيل المثال، لإنشاء اتّصال مع نفق على المنفذ "7777” سنكتب الأمر: ssh -f -N -D 7777 username@remote_host يُمكنك الآن أن تبدأ توجيه تطبيق SOCKS-aware (كمُتصفح الويب)، نحو المنفذ الذي اخترته سيرسل التّطبيق معلوماته إلى المقبس المربوط مع المنفذ. طريقة توجيه النّقل نحو منفذ SOCKS تختلف حسب التّطبيق، في فايرفوكس Firefox على سبيل المثال الموقع العام هو: Preferences > Advanced > Settings > Manual proxy configurations أما في Chrome فتستطيع تشغيل التطبيق مع تحديد مُعامل –proxy-server= . سترغب في استخدام واجهة المُضيف المحلي (localhost interface ) ورقم المنفذ الذي أحَلْتَه. بما أنّ الاتّصال يتم في الخلفّية يجب عليك إيجاد رقم PID لقتله (إغلاقه)، يُمكنك فعلُ ذلك بالبحث عن المنفذ الذي وضّفته: ps aux | grep 8888 1001 5965 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -D 7777 username@remote_host 1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888 يُمكنك بعدها قتلُ العمليّة باستهداف رقم PID، وهو الرقم على العمود الثّاني الذّي يُوافق أمر SSH : kill 5965 هناك خيّار آخر وهو بدء الاتّصال بدون المُعامل f-. الأمر الذي سيُبقي الاتّصال في الواجهة، مانعاً استخدام نافذة الطّرفية كامل مدّة الإحالة. والإفادة هنا هي إمكانية إيقاف النّفق بالضّغط على "CTRL-C”. استعمال شيفرات الإلغاء للتحكم بالاتّصالاتحتى عند إنشاء جلسة SSH، يُمكن التحكم في الاتّصال من داخل الطرفيّة. يُمكن القيام بهذا مع شيء اسمه "شيفرات الإلغاء (SSH escape codes)” والتي تُخوّل لنا التّفاعل مع تطبيق SSH المحلي من داخل الجلسة. إجبار إلغاء الاتّصال من جهة العميل (كيف تخرج من جلسة مُتجمّدة لا تقبل الإجابة)تعتبر إمكانيّة التحكم في جوانب مُعيّنة من الجلسة بالدّاخل من أهم مُميّزات OpenSSH التي غالبا ما لا يُلاحظها الكثيرون. يُمكن تشغيل هذه الأوامر بتقديمها برمز التحكم "~" داخل جلسة SSH. ستُفسّرُ أوامر التحكم فقط إذا كانت أول شيء مكتوب بعد سطر جديد، لذلك اضغط دائما على ENTER مرّة أو مرّتين كإجراء احتياطي. من أكثر الإمكانيات التي يُتيحها التحكم قوة هي إمكانية إلغاء الاتّصال من جهة العميل. اتّصالات SSH عادة ما تُغلق من طرف الخادوم، لكنّ هذا يُمكن أن يكون مُشكلة إذا كانت هناك مشاكل في الخادوم أو إذا قُطع الاتّصال. يُمكن أن تُغلق الاتصال بشكل نظيف من جهة العميل. لإغلاق اتّصال من العميل، استخدم رمز التحكم "~”، مع إضافة نقطة "." . إذا كانت هناك مشاكل في الاتّصال في الغالب ستجد نفسك مع جلسة طرفيّة مُتجمّدة. اكتب الأمر ولو لم تشعر بأنك تكتب شيئا: [ENTER] ~. يجب على الاتّصال أن يُغلق فورا، وسيرجعك إلى جلسة الشل المحليّة. وضع جلسة SSH في الخلفيّةتعتبر إمكانيّة التحكم في جوانب مُعيّنة من الجلسة بالدّاخل من أهم مُميّزات OpenSSH التي غالبا ما لا يُلاحظها الكثيرون. يُمكن تشغيل هذه الأوامر بتقديمها برمز التحكم "~" داخل جلسة SSH. ستُفسّرُ أوامر التحكم فقط إذا كانت أول شيء مكتوب بعد سطر جديد، لذلك اضغط دائما على ENTER مرّة أو مرّتين كإجراء احتياطي. يُعطينا التحكم إمكانية وضع جلسة SSH لتعمل في الخلفيّة. وللقيّام بذلك سنحتاج إلى كتابة رمز التحكم "~" وننفّذ بعده اختصار لوحة المفاتيح (CTRL-Z) لوضع العمليّة في الخلفيّة : [ENTER] ~[CTRL-Z] ما قمنا به سينقل الاتّصال ليعمل في الخلفيّة، وسيرجعنا إلى جلسة الشل المحليّة. للرجوع إلى جلسة SSH يُمكنك استعمال آليّة التّحكم. يُمكنك إعادة تفعيل آخر عمليّة محالة إلى الخلفية بكتابة: fg إذا كنت تملك أكثر من عمليّة في الخلفيّة، يُمكنك رؤية العمليّات المتاحة بكتابة: jobs [1]+ Stopped ssh username@some_host [2] Stopped ssh username@another_host يُمكنك بعد ذلك جلب أي عمليّة إلى الأمام باستعمال الدليل في العمود الأول مع رمز % : fg %2تعديل إعدادات إحالة منفذ على اتّصال SSH موجودتعتبر إمكانيّة التحكم في جوانب مُعيّنة من الجلسة بالدّاخل من أهم مُميّزات OpenSSH التي غالبا ما لا يُلاحظها الكثيرون. يُمكن تشغيل هذه الأوامر بتقديمها برمز التحكم "~" داخل جلسة SSH. ستُفسّرُ أوامر التحكم فقط إذا كانت أول شيء مكتوب بعد سطر جديد، لذلك اضغط دائما على ENTER مرّة أو مرّتين كإجراء احتياطي. هذه الميّزة تسمح لنا بالتعديل على إعدادات إحالة المنفذ بعد أن يؤسّس بالفعل اتّصال مُسبق، ويُخوّل لك إنشاء أو هدم قواعد إحالة منفذ في الوقت الفعلي. هذه القدرات جزء من واجهة سطر أوامر SSH، ويُمكن الوصول إليها خلال الجلسة باستخدام رمز التّحكم (~) و"C" : [ENTER] ~C ssh> سوف تُمنَح موجه أوامر خاص بSSH، موجه الأوامر هذا يتيح مجموعة محدودة جدّا من الأوامر، يمكنك كتابة h- من الموجه لرؤية الخيّارات المتاحة. إذا كانت المُخرجات خاليّة، سيجب عليك زيادة إسهاب (verbosity) مخرجات SSH باستخدام v~ عدّة مرّات: [ENTER] ~v ~v ~v ~C -hCommands: -L[bind_address:]port:host:hostport Request local forward -R[bind_address:]port:host:hostport Request remote forward -D[bind_address:]port Request dynamic forward -KL[bind_address:]port Cancel local forward -KR[bind_address:]port Cancel remote forward -KD[bind_address:]port Cancel dynamic forwardوكما ترى، يُمكنك بسهولة تنفيذ أي من الخيارات باستخدام الخيّار المناسب (اُنظر قسم الإحالة لمزيد من المعلومات). يُمكنك أيضا هدم نفق مع الأمر K- قبل رمز نوع الإحالة. على سبيل المثال، لإغلاق إحالة محليّة (L-)، يمكنك أن تستعمل الأمر KL-. وستحتاج إلى توفير رقم المنفذ. لضبط إحالة منفذ محلي، يمكنك استعمال: [ENTER] ~C -L 8888:127.0.0.1:80 يستطيع المنفذ 8888 على جهازك المحلي الآن التواصل مع خادوم الويب على المُضيف الذي تتصلُ به. عندما تنتهي، يُمكنك أن تهدم الإحالة بكتابة: [ENTER] ~C -KL 8888خاتمةالتعليمات أعلاه يجب أن تغطي مُعظم ما يحتاجه المستخدمون عن SSH. إذا كان لديك أي نصائح أخرى أو إذا رغبت في نشر الإعدادات والطّرق المُفضّلة لديك، خذ راحتك ولا تتردد في استخدام التعليقات أدناه. ترجمة -مع شيءٍ من التصرّف- للقسم الثالث والأخير من مقال: SSH Essentials: Working with SSH Servers, Clients, and Keys. حقوق الصورة البارزة: Designed by Freepik.

هذا القسم سيُغطّي بعضاً من أساسيّات الاتّصال بخادوم مع SSH، وهو تكملة لسلسلة "مدخل إلى ssh"، بعد أن تكلمنا في الدرس الأول منها عن العملاء والمفاتيح. الاتصال بخادوم عن بعدللاتّصال بخادوم عن بعد وفتح جلسة طرفية هناك، يمكنك استعمال أمر ssh. أبسط طريقة تفترض أنّ اسم المُستخدم الخاصّ بك هو نفسه اسم المُستخدم على الخادوم، إذا كان هذا صحيحاً، يُمكنك الاتّصال باستخدام: ssh remote_host إذا كان اسم المُستخدم مختلفاً على الخادوم، ستحتاج إلى تمرير اسم مستخدم الخادوم كالتالي: ssh username@remote_host في المرة الأولى التّي تتصل بمُضيف جديد، سترى رسالة تبدو كالتّالي: The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yesاكتب yes لإكمال الاتّصال بالمُضيف. إذا كنت تستخدم فحص لكلمة المرور، سيُطلب منك إدخالها هنا. إذا كنت تستخدم مفاتيح SSH، سيُطلب منك إدخال كلمة المُرور لمفتاحك الخاصّ إذا كنت قد عيّنتها من قبل، إذا كان الأمر غير ذلك فستدخل آلياً إلى الخادوم. تشغيل أمر واحد على الخادوم البعيدلتشغيل أمر واحد على الخادوم عن بعد عوضا عن فتح جلسة طرفية، يُمكنك إضافة الأمر بعد معلومات الاتّصال: ssh username@remotehost الأمرالمُراد_تشغيله هذا الأمر سيقوم بالاتصال بالخادوم، ثم يستثيق باستخدام المعلومات وينفّذ الأمر الذي حدّدته. وسيُغلق الاتّصال مُباشرة بعد ذلك. الدخول إلى خادوم من منفذ آخريقوم عفريت SSH (بالانجليزية: ssh daemon وهو برنامج يعمل في الخلف بشكل دائم على النظام) بالدّخول إلى الخادوم من المنفذ رقم 22 تلقائيّاً. عميل SSH الخاص بك سيفترض أن هذه هي الحالة عند مُحاولة الاتّصال. إذا كان خادوم SSH يستمع من منفذ غير معياريّ (سيُشرح الأمر لاحقا في قسم آخر)، سيجب عليك تحديد رقم المنفذ الجديد عند محاولة الدّخول. يُمكنك فعل هذا بتحديد رقم المنفذ مع خيّار p-: ssh -p رقم_المنفذ username@remote_host لتجنّب فعل هذا في كلّ مرة تدخلُ إلى الخادوم، يُمكنك إنشاء أو تعديل ملفّ إعدادات في مُجلّد ssh./~ داخل مُجلّد المنزل في جهازك المحليّ. عدّل أو أنشئ الملفّ بكتابة: nano ~/.ssh/config يُمكنك هنا تحديد إعدادات خيارات المُضيف. لتحديد منفذ جديد، استخدم نموذجاً كالتّالي: Host remote_alias HostName remote_host Port port_num هذا سيُمكّنك من الدّخول إلى الخادوم بدون تحديد رقم المنفذ كلّ مرة من سطر الأوامر. إضافة مفاتيح SSH إلى عميل SSH لتجنب كتابة كلمة المرورإذا كنت تمتلك جملة مرور على المفتاح الخاص، سيُطلب منك كتابتها في كلّ مرة تحاول الاتّصال بالمُضيف. لتجنّب الأمر، يُمكنك تشغيل عميل SSH. وهو أداة صغيرة تُخزّن مفتاحك الخاص بعد كتابة كلمة المرور للمرّة الأولى. وستكون مُتاحة طوال مدة جلسة الطّرفيّة، وستخوّل لك الاتصال بدون إعادة كتابة كلمة المرور في المستقبل. هذا الأمر مهم أيضا إذا كنت تريد إحالة معلومات SSH الخاصّة بك (مُبيّنٌ أدناه). لتشغيل عميل SSH، اكتب في جلسة طرفيّة جهازك المحلي: eval $(ssh-agent)هذا الأمر سيُشغّل عميل SSH في الخلفيّة. الآن عليك أن تُضيف مفتاحك الخاصّ إلى العميل لكي يتمكن من إدارتها: ssh-add Enter passphrase for /home/demo/.ssh/id_rsa: Identity added: /home/demo/.ssh/id_rsa (/home/demo/.ssh/id_rsa) سيتوجب عليك كتابة كلمة المرور (في حال عيّنتها). بعدئذٍ ملف الهوية الخاص بك سيُضاف إلى العميل متيحا لك استخدام مفتاحك بدون إعادة إدخال كلمة المرور مُجدّداً. إحالة معلومات SSH الخاصة بك لاستخدامها على خادومإذا كنت ترغب في أن تكون قادراً على الاتّصال بدون كلمة مرور من خادوم إلى آخر، سيتوجب عليك إحالة معلومات SSH الخاصّة بك. ما يخوّلك للاتّصال بخادوم آخر من الخادوم الذي تتّصل به، باستخدام المعلومات على جهازك المحلي. للبدء يجب عليك أن تمتلك عميل SSH مُشغلا ومضافٌ إليه مفتاح SSH الخاص بك (انظر أعلاه). بعد الانتهاء من هذا، ستحتاج إلى الاتّصال بالخادوم الأول باستعمال خيّار A-. هذا الأمر يحيل معلوماتك إلى الخادوم للجلسة الحالية: ssh -A username@remote_host من الآن يُمكنك الاتصال بمُضيف جديد مُخوّل له الوصول من مفتاح SSH وسوف تدخل كما لو أن مفتاحك الخاص موجود على الخادوم. إعدادات جهة الخادوم Server-Sideهذا القسم يحتوي على بعض من أشهر خيارات إعدادات جهة الخادوم التي يمكن لها تشكيل طريقة استجابة الخادوم وأي من أنواع الاتّصال المسموح بها. تعطيل فحص كلمة مرورإذا كنت قد ضبطت مفاتيح SSH واختبرتها وتعاملت بها بشكل جيّد، يعتبر تعطيل الفحص بكلمة المرور فكرة جيّدة، هذا سيمنع أي مُستخدم من الاتصال باستخدام SSH مع كلمة مرور. لفعل هذا، اتصل بخادومك وافتح ملفّ etc/ssh/sshd_config/ بصلاحيّات الجذر: sudo nano /etc/ssh/sshd_config ابحث داخل الملفّ عن PasswordAuthentication إذا كانت تعليقا أزل رمز التعليق واجعلها no لتعطيل الدخول بكلمة المرور: PasswordAuthentication no بعد أن تقوم بالتغيير، احفظ وأغلق الملف. يجب عليك إعادة تشغيل خدمة SSH لتطبيق التغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا / CentOS: sudo service sshd restart الآن جميع الحسابات على النظام ستمنع من الدّخول باستخدام كلمة مرور. تغيير منفذ عفريت SSH (بالانجليزية: ssh daemon)ينصح بعض الإداريين بتغيير منفذ SSH الافتراضي، يمكن لهذا أن يعين في تقليل عدد محاولات الاتّصال إلى خادومك من قبل البرمجيات الخبيثة. لتغيير المنفذ، سيتوجب عليك الدخول إلى الخادوم الخاص بك. ثم افتح ملفّ sshd_config على الخادوم بصلاحيات الجذر: sudo nano /etc/ssh/sshd_config عندما تدخل، يمكنك تغيير المنفذ الذي يشتغل منه SSH بإيجاد مواصفة Port 22 وتغييرها إلى رقم المنفذ الذي تريد استخدامه. مثلاً لتغيير المنفذ إلى 4444، ضع هذا في ملفّك: Port 4444 احفظ وأغلق الملفّ عندما تنتهي. يجب عليك إعادة تشغيل SSH لتطبيق التغييرات: على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart بعد إعادة التّشغيل ستحتاج إلى إلى الفحص بتحديد رقم المنفذ (شُرح سابقاً) تحديد المستخدمين الذين يمكن لهم الاتّصال عبر SSHيُمكنك اتّخاذ خذ بعض الإجراءات لتحديد المُستخدمين الذين يمكنهم الاتّصال عبر SSH، ويمكن ذلك عبر تعديل ملفّ إعدادات SSH. افتح هذا الملف على الخادوم بصلاحيات الجذر: sudo nano /etc/ssh/sshd_config الطريقة الأولى لتحديد المستخدمين الذين يمكن لهم الاتّصال هي عبر خاصّية AllowUsers . ابحث عن AllowUsers في الملفّ. إذا لم يكن السّطر موجودا فأنشئه في أي مكان. أدرج بعدها اسماء المستخدمين المرغوب في السّماح لهم بالاتّصال عبر SSH: AllowUsers user1 user2 احفظ وأغلق الملفّ. أعد تشغيل SSH لتطبيق التغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart إذا كنت مرتاحا مع إدارة المجموعات أكثر، يُمكنك استعمال AllowGroups . في حال كنت ترغب في ذلك أضف المجموعة التي سيُسمح لها بالاتصال (سوف ننشئ هذه المجموعة وسنضيف إليها الأعضاء بعد قليل): AllowGroups sshmembers احفظ وأغلق الملفّ. يُمكنك الآن إنشاء مجموعة (بدون مجلد منزل) توافق المجموعة التّي حدّدتها بكتابة: sudo groupadd -r sshmembersتأكّد من أنّك أضفت حساب المستخدم الذي تريد إلى هذه المجموعة. يُمكن القيام بالأمر كالتالي: sudo usermod -a -G sshmembers user1 sudo usermod -a -G sshmembers user2 أعد تشغيل SSH لتطبيق التّغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart تعطيل ولوج الجذر rootيعد تعطيل ولوج الجذر عبر SSH منصوحا به بعد أن تضبط حساب مستخدم بميزة sudo. لفعل ذلك، افتح على الخادوم ملف إعدادات SSH باستخدام الجذر أو مع sudo . sudo nano /etc/ssh/sshd_configابحث عن PermitRootLogin إذا كانت تعليقا أزل رمز التعليق واجعلها no: PermitRootLogin noاحفظ الملف وأغلق الملف وأعد تشغيل SSH لتطبيق التّغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart إتاحة وصول الجذر لأوامر معينةهناك بعض الحالات التي قد ترغب فيها بتعطيل وصول الجذر عامّة، والسّماح لبرمجيّات معيّنة للوصول إليه لتعمل بشكل صحيح، ويُمكنك أن تأخذ النّسخ الاحتياطي كمثال. يُمكن القيّام بهذه العملية عبر ملف authorized_keys الخاصّ بمستخدم الجذر، الذي يحتوي على المفاتيح المُخوّلِ لها استخدام الحساب. أضف المفتاح الذي ترغب في استعماله من جهازك المحلي (يُنصح بإنشاء مفتاح جديد لكل عملية تلقائيّة ) إلى ملفّ authorized_keys الخاصّ بمستخدم الجذر على الخادوم. سنشرح مع أمر ssh-copy-id هنا، لكنك تستطيع أي طريقة أخرى للنسخ المفاتيح (ستُشرح في قسم آخر): ssh-copy-id root@remote_host ادخل الآن إلى الخادوم البعيد، سنحتاج إلى ضبط الدّخول على ملفّ authorized_keys لذلك افتحه باستخدام الجذر أو مع sudo. sudo nano /root/.ssh/authorized_keys في بداية سطر المفتاح الذي نسخته، أضف =command لكي تُعرّف الأمر الذي يصلح له المفتاح. يجب أن يتضمن مسار الملف القابل للتنفيذ مع أي معامل: command="/path/to/command arg1 arg2" ssh-rsa احفظ وأغلق الملفّ عندما تنتهي. افتح ملفّ sshd_config باستخدام الجذر أو مع sudo: sudo nano /etc/ssh/sshd_config ابحث عن PermitRootLogin وغيّر القيمة إلى forced-commands-only.هذه العمليّة ستسمح للمفاتيح باستخدام الجذر فقط عند تحديد أمر للمفتاح: PermitRootLogin forced-commands-onlyاحفظ الملف وأغلق الملف وأعد تشغيل SSH لتطبيق التّغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart إحالة تطبيق X لعرضه للعميليُمكن ضبط SSH لإحالة تطبيقات X وعرضها على الجهاز المحلي تلقائيّاً. لينجح الأمر يجب على العميل امتلاك مدير نوافذ X مضبوط ومتاح. لاتاحة هذه الوظيفة ادخل إلى الخادوم البعيد وعدّل ملفّ sshd_config باستخدام حساب الجذر أو مع sudo: sudo nano /etc/ssh/sshd_config ابحث عن X11Forwarding إذا كانت تعليقا أزل رمز التعليق ومرّر القيمة yes: X11Forwarding yes احفظ الملف وأغلق الملف وأعد تشغيل SSH لتطبيق التّغييرات. على أبنتو/دبيان: sudo service ssh restart على فيدورا/سنت أو إس: sudo service sshd restart للاتّصال بالخادوم وإحالة عرض تطبيق ما، يجب عليك تمرير مُعامل X- من جهة العميل عند الاتصال: ssh -X username@remote_host التطبيقات الرسوميّة المفتوحة على الخادوم في الجلسة الحاليّة يجبُ أن تُعرض على الجهاز المحلي. يُمكن أن يكون الأداء بطيئا قليلاً، لكنّه جيد ومجدي في بعض الحالات. خيارات إعدادات جهة العميلفي هذا القسم، سنركّز على بعض التعديلات التي يُمكنك القيّام بها على جهة العميل من الاتّصال. تحديد خصائص معلومات الاتّصال بالخادوميُمكنك تحديد إعدادات على جهازك المحلي لبعض أو لجميع الخوادم التي تتصل بها. ويُمكن تخزينُ هذه الإعدادات على ملفّ ssh/config./~ والذي يُمكن قراءته من طرف عميل SSH في كل مرة يُستدعى فيها. أنشئ أو افتح الملفّ بمحرّر نصوص على جهازك المحليّ: nano ~/.ssh/config يُمكنك تحديد الإعدادات التي ترغب فيها بداخل هذا الملف بتقديم كل منها مع كلمة Host متبوعة بكنية (alias). وتحت السّطر يُمكنك تحديد أي من التّعليمات الموجودة على صفحة man ssh_config بشرط أن تكون بمسافة بادئة: man ssh_config كمثال عن الإعدادات: Host testhost HostName example.com Port 4444 User demo يُمكنك بعد ذلك الاتّصال ب example.com على المنفذ 4444 باستخدام اسم المُستخدم “demo” بكتابة: ssh testhostيُمكنك أيضاً استخدام حروف البدل (wildcards) لموافقة أكثر من مُضيف. تذكّر أن الموافقات اللاحقة يُمكنها الكتابة فوق السّابقة، لذلك يجب عليك أن تضع الموافقات العامّة في الأعلى. على سبيل المثال، يمكنك أن تعطل إحالة X بشكل افتراضي لجميع الاتصالات، بوضع التالي في ملفّك: Host * ForwardX11 no Host testhost HostName example.com ForwardX11 yes Port 4444 User demo احفظ وأغلق الملفّ عندما تنتهي. إبقاء الاتّصالات حيّة لتجنّب نفاذ الوقت (Timeout)إذا وجدت نفسك خارج جلسة SSH قبل أن تكون جاهزا لذلك، من المُحتمل أنّ وقت الاتّصال ينفذ. يُمكنك ضبط العميل لإرسال حزمة إلى الخادوم بين الحين والآخر لتجنّب هذه المسألة: يُمكنك ضبط هذا على جهازك المحليّ لكل اتّصال بتعديل ملفّ ssh/config./~. افتح الآن: nano ~/.ssh/config إذا لم تملك سطرا يوافق جميع المضيفين أعلى الملفّ فقم بإضافته. ثم أضف ServerAliveInterval بقيمة "120” لإرسال حزمة إلى الخادوم كلّ دقيقتين. هذا كافٍ لإبلاغ الخادوم بعدم إغلاق الاتّصال: Host * ServerAliveInterval 120 احفظ وأغلق الملفّ عندما تنتهي. تعطيل التحقق من المضيففي الحالة الافتراضية، كلّما اتّصلتَ بخادومٍ جديد، ستُعرضُ لك بصمة مفتاح: SSH. The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes هذا الأمر مضبوط لكي تتأكد من الفحص المُضيف الذي تُحاول الاتّصال به وتجنب إمكانية أن يتنكر مستخدم خبيث في هيئة المُضيف البعيد. قد ترغب في تعطيل هذه الميزة في بعض الحالات. ملاحظة: هذا الأمر يمكن أن يكون خطيرا جدّا أمنيا، لذلك تأكد من أنك تعرف ما تفعله إذا قُمت بضبط النظام هكذا. للقيّام بالأمر، افتح ملفّ ssh/config./~ على جهازك المحليّ: nano ~/.ssh/config إذا لم تملك سطرا يوافق جميع المضيفين أعلى الملفّ فقم بإضافته. ثم أضف StrictHostKeyChecking بقيمة no لإضافة مضيفين جدد تلقائيّا إلى ملفّ known_hosts، وأضف UserKnownHostsFile بقيمة /dev/null/ لعدم التحذير على مُضيف جديد أو مُضيف معدّل: Host StrictHostKeyChecking no UserKnownHostsFile /dev/nullيُمكنك تشغيل التحقق لكل حالة على حدة بعكس هذه الخيّارات لمضيفين آخرين. القيمة الافتراضية ل StrictHostKeyChecking هي "ask”: Host testhost HostName example.com StrictHostKeyChecking ask UserKnownHostsFile /home/demo/.ssh/known_hostsمضاعفة SSH خلال اتصال TCP واحدهناك بعض الحالات التي يُمكن أن يأخذ فيها إنشاء اتّصال TCP وقتا أطول من المعتاد. إذا كنت تقوم باتّصالات متعدّدة إلى نفس الجهاز، يُمكنك استغلال ميّزة المُضاعفة. مُضاعفة SSH تقوم بإعادة استخدام نفس اتّصال TCP لجلسات SSH مُتعدّدة. وبهذا يتجنّب بعض العمل الضروري لإنشاء جلسة جديدة الشيء الذي يسرع الأمر، الحد من عدد الاتّصالات قد يكون مُجديّا أيضا لأسباب أخرى. لإعداد المُضاعفة، يُمكنك إعداد الاتّصالات، أو يُمكنك ضبط العميل لاستعمال المُضاعفة عندما تكون متاحة. سنشرح الخيار الثاني هنا. لإعداد المُضاعفة، عدّل ملف إعدادات عميل SSH على الحاسوب المحلي: nano ~/.ssh/config إذا لم تملك سطرا يوافق جميع المضيفين أعلى الملفّ فقم بإضافته الآن (مثل Host *). سنضبط القيم ControlMaster , ControlPath و ControlPersist لإنشاء إعدادات المُضاعفة. يجب أن يكون ControlMaster بقيمة auto لتخويل المُضاعفة تلقائيّا عندما تكون متاحة. ControlPath سيكون مسار تحكم المقبس. الجلسة الأولى ستنشئ هذا المقبس وستكون الجلسات اللاحقة قادرة على إيجاده لأنه موسوم من طرف المُستخدم، المُضيف والمنفذ. ضبط خيّار ControlPersist مع القيمة 1 ستُخوّلُ اتّصال الرئيس الأولي( initial master) ليعمل في الخلفية. 1 تعني أن اتّصال TCP يجب أن ينتهي بعد ثانية واحدة من إغلاق آخر جلسة SSH: Host * ControlMaster auto ControlPath ~/.ssh/multiplex/%r@%h:%p ControlPersist 1احفظ وأغلق الملفّ عندما تنتهي. نحتاج الآن لإنشاء المجلّد الذي حدّدناه في مسار التحكم: mkdir ~/.ssh/multiplexأي جلسة تُنشئ الآن مع نفس الجهاز ستُحاول استعمال المقبس الموجود واتّصال TCP. عندما تكون آخر جلسة موجودة، سيُهدمُ الاتّصال بعد ثانيّة واحدة. إذا كنت تريد تجنب إعدادات المُضاعفة لسبب ما مؤقتا، يُمكنك فعلُ ذلك بتمرير مُعامل S- مع قيمة none: ssh -S none username@remote_host تحدثنا في هذا الدرس عن كيفية إنشاء إتصال بخادوم بعيد بشكل آمن وبخيارات متعددة سواءً من جهة الخادوم أو من جهة العميل (المستخدم)، سنتحدث في المقال القادم إن شاء الله عن أنفاق ssh، ماهيتها، وكيفية إعدادها. ترجمة -مع شيءٍ من التصرّف- للقسم الثاني من مقال: SSH Essentials: Working with SSH Servers, Clients, and Keys. حقوق الصورة البارزة: Designed by Freepik.

قدمنا في الجزء الأول من هذا الدليل الخطة التي نعمل على إعدادها من أجل ضبط آلية للطرق على المنافذ تعتمد حصرا على جدار iptables الناري. نستكمل في هذا الجزء ما بدأناه بتنفذ الآلية المشروحة في الجزء السابق. إعداد إطار عمل نظامي للجدار النارينبدأ بوضع إطار أساسي للاتصالات في الخادوم. ستتولى سلسلة INPUT التعامل مع جميع الاتصالات القادمة. سنزيل جميع قواعد الجدار الناري المطبقة حاليا من أجل بدء الإعداد من الصفر. لكن قبل ذلك يجب أن نتأكد من أن السياسات الافتراضية مضبوطة على ACCEPT للاستمرار في الاتصال الجاري: sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT sudo iptables -Fبهذه الطريقة نبدأ مع جدار ناري مفتوح تماما. قبل تقييد الاتصالات ننفذ أوامر إضافة السلاسل الجديدة: sudo iptables -N KNOCKING sudo iptables -N GATE1 sudo iptables -N GATE2 sudo iptables -N GATE3 sudo iptables -N PASSEDنتوفر الآن على ثماني سلاسل. سنستخدمها كلَّها ما عدا سلسلتيْ OUTPUT وFORWARD اللتان لا تعنياننا هنا. نبدأ بالتعامل مع الاتصالات التي لا تحتاج للطرق على المنافذ لفتحها، فنضيف قاعدة إلى سلسلة INPUT للسماح للاتصالات الجارية كافةً بالاستمرار: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTوأخرى لقبول جميع الاتصالات من الجهاز المحلي: sudo iptables -A INPUT -i lo -j ACCEPTإذا كانت لديك خدمات موجَّهة للعموم، مثل خادوم ويب، فأضف قاعدة على النحو التالي حتى يمكن الاتصال بها: sudo iptables -A INPUT -p protocol --dport port -j ACCEPTمثال لقاعدة تتيح الوصول إلى خادوم الويب: sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPTأنهينا الآن إعداد قواعد الاتصالات المسموح بها. نمرّر جميع الاتصالات التي لا تنطبق عليها إحدى القواعد السابقة إلى سلسلة KNOCKING من أجل التنفيذ الفعلي لآلية الطرْق: sudo iptables -A INPUT -j KNOCKINGإعداد البوابة الأولىسنُلحِق “البوابات” بعد اكتمال إعدادها بسلسلة KNOCKING لتمرير حركة البيانات عبر الاختبارات المشروحة في الجزء الأول من هذا الدليل. لكن قبل ذلك يجب وضع أساس كل اختبار على انفراد. نبدأ بتعريف أول اختبار طرْق. عندما يحاول عميل الاتصال فإننا ننظر في المنفذ الذي يرسل إليه الطلب؛ إن كان يوافق المنفذ الأول لدينا في متتالية الطرْق نشير إلى أن العميل تجاوز الاختبار الأول بنجاح؛ وإلا نتجاهل الطلب. نضع علامة على العميل عند محاولة الاتصال بالمنفذ الصحيح: sudo iptables -A GATE1 -p tcp --dport 1111 -m recent --name AUTH1 --set -j DROPيؤدي السطر أعلاه مهام عدة؛ يضيف قاعدة جديدة إلى سلسلة GATE1. شروط تنفيذ القاعدة هي أن يكون البروتوكول المستخدَم هو tcp والمنفذ المطلوب هو1111، أي المنفذ اﻷول في سلسلة الطرق. عند تحقق الشروط نستدعي وِحدة recent (باستخدام خيار m-) ونضع علامة AUTH1 (باستخدام name AUTH1 --set--). ستُستعمَل هذه العلامة عند اختبار إصابة المنفذ الثاني. أخيرا، وبعد تعيين العلامة، نتجاهل الحزمة لكي لا يعرف العميل مالذي يحدث. ثم نتجاهل جميع حزم البيانات الأخرى، لأن أي معلومة تُرسَل إلى هذه السلسلة تبحث فقط عن موافقة أول حزمة: sudo iptables -A GATE1 -j DROP أنجزنا الآن ما يتعلق بالمنفذ الأول من متتالية الطرْق: إما أن توافق الحزمة المنفذ المطلوب أو تُتَجاهَل. إذا وافقت المنفذ توضع عليها علامة AUTH1. إعداد البوابة الثانيةتُضبط البوابة الثانية بطريقة مشابهة إلا أنها أكثر تعقيدا. أول ما يجب الانتباه إليه هو أن قرار توجيه محاولات الاتصال إلى هذه السلسلة سيكون ضمن السلسلة الأم KNOCKING. لن تحتاج سلسلة GATE2 إلى التأكد من مطابقة محاولة الاتصال للبوابة الأولى، لأن هذا الاختبار جرى سلفا. مع ذلك يجب أن تحذف أي علامات قد تكون وُضعت على العميل قبل البدء في التعامل مع محاولة الاتصال. عدم إزالة العلامات السابقة قد ينتج عنه وضع علامات عدة على عنوان العميل ممّا قد يؤدي إلى نجاح الطرق على المنفذ بمجرد فحص المنافذ ثلاث مرات. طبعا هذا أمر لا نرغب فيه. نستخدم وحدة recent مرة أخرى لحذف الاسم (العلامة): sudo iptables -A GATE2 -m recent --name AUTH1 --removeلا تتخذ القاعدة أعلاه أي قرارات أو إعادة توجيه؛ كل ما تفعله هو حذف العلامة الحالية (وهي تلك التي سمحت بتوجيه الاتصال إلى هذه السلسلة) وتوجيه البيانات إلى القاعدة الموالية. يصبح العنوان - بعد تجاوز القاعدة الأولى من السلسلة - خاليا من أي علامات. نتحقق من المنفذ الذي يطلبه العنوان ومن مطابقته للمنفذ الثاني في متتالية الطرْق (2222): sudo iptables -A GATE2 -p tcp --dport 2222 -m recent --name AUTH2 --set -j DROPنفس ما فعلناه مع البوابة الأولى. نضع علامة AUTH2 للإشارة إلى أن عنوان الطلب تجاوز الاختبار الثاني إذا كان العميل يحاول الاتصال عبر المنفذ المطلوب، ثم نتجاهل الحزمة لكي لا يعرف العميل مالذي نفعله. قد تبدو القاعدة التالية غريبة لأول وهلة: sudo iptables -A GATE2 -j GATE1قد تظن أن تجاهل الحزمة بعد وضع علامة AUTH2 هو - منطقيا - الخطوة التالية. إلا أن فعل ذلك سيجعلنا في وضع حرج أثناء حالة خاصة. لو كانت لدينا قاعدة drop all هنا وكانت الحزمة المرسلة في هذه الأثناء توافق المنفذ الأول في سلسلة الطرْق، فلن تسجَّل على أنها بداية لمتتالية الطرق. نفرض على سبيل المثال أن العميل أرسل - عن طريق الخطأ - محاولتي اتصال إلى المنفذ الأول. في هذه الحالة لن يعُدّ الجدار الناري محاولة الاتصال الثانية صحيحة لأنه سيرى المتتالية كما يلي: محاولة اتصال عبر المنفذ الأول. سيحسب الجدار الناري أن الاختبار الأول تُجووِز بنجاح.محاولة الاتصال عبر المنفذ الأول. فشل في الاختبار الثاني. يُعاد تعيين المتتالية.محاولة الاتصال عبر المنفذ الثاني. فشل في الاختبار الأول (يطبَّق الاختبار الأول لأن المتتالية أعيد تعيينها في الخطوة السابقة). يُعاد تعيين المتتالية.محاولة الاتصال عبر المنفذ الثالث. فشل في الاختبار الأول (يُطبق الاختبار الأول لأن المتتالية أعيد تعيينها في الخطوة السابقة). يُعاد تعيين المتتالية.نجد أن العميل في الافتراض السابق أرسل المتتالية الصحيحة، إلا أن الجدار الناري لم يعتمدها لأنه حصل تشويش لديه في أي قاعدة يجب عليه أن يطبق. يجب إذن على العميل، إذا أخطأ، إرسال طلب وهمي من أجل إعادة تعيين السلسلة، قبل البدء في إرسال المتتالية. لتجنب الوقوع في هذه الحالة لن نتجاهل الحزمة بل سنوجّهها - بدلا من ذلك - إلى سلسلة GATE1 التي أعددناها سابقا. نرسل جميع حزم البيانات التي لم تُصِب المنفذ الثاني إلى البوابة الأولى من جديد: sudo iptables -A GATE2 -j GATE1نكون هنا أمام خيارين: إما أن يكون الطلب موجَّها إلى المنفذ الأول، هنا نبدأ من جديد في المتتالية؛ وإلا فإن الجدار الناري سيتجاهل الطلب حسب العادة. أي أننا تجنبنا الوقوع في الحالة المعروضة آنفا. إعداد البوابة الثالثةننفذ البوابة الثالثة بنفس طريقة تنفيذ البوابة الثانية تماما. نمسح أولا جميع العلامات التي وُضعت على العنوان مثل ما فعلنا في إعداد البوابة الثانية ولنفس الأسباب: sudo iptables -A GATE3 -m recent --name AUTH2 --removeثم نختبر هل أصابت محاولة الاتصال المنفذ الثالث في متتالية الطرق، فإن فعلت نضع علامة AUTH3 التي تشير إلى أن العميل نجح في طرق المنافذ المطلوبة حسب المرجو؛ ثم نتجاهل - مثل ما هي العادة - الحزمة: sudo iptables -A GATE3 -p tcp --dport 3333 -m recent --name AUTH3 --set -j DROPإن لم تفلح محاولة الاتصال في إصابة المنفذ المطلوب نعيد توجيهها إلى البوابة الأولى لترى هل أصابت المنفذ الأول في المتتالية لبدء المسار من جديد: sudo iptables -A GATE3 -j GATE1بالوصول إلى هذه النقطة يكون العملاء الذي نجحوا في طرق المنافذ المطلوبة حسب الترتيب المفروض قد حصلوا على علامة AUTH3 التي تمكننا من فتح خدمة SSH لهم ضمن سلسلة PASSED. إعداد سلسلة PASSEDتُستخدَم هذه السلسلة لفتح منفذ SSH لمدة ثلاثين ثانية للعميل الذي نجح في طرق المتتالية الصحيحة. لن يُفتَح منفذ SSH إلا إذا كانت محاولة الاتصال الموالية من العميل تطلب السماح لها بعبوره. تفرض هذه القاعدة على من يحاول عشوائيا طرق المنافذ تجربة الاتصال بSSH بعد كل محاولة، الأمر الذي يصعِّب من معرفة متتالية الطرق. نبدأ - حسب العادة - بإعادة تعيين العلامات: sudo iptables -A PASSED -m recent --name AUTH3 --removeنقبل الاتصال عبر SSH من المستخدمين الذين وصلوا إلى هذه السلسلة: sudo iptables -A PASSED -p tcp --dport 22 -j ACCEPTبالنسبة للمستخدمين الذي لم يحاولوا الاتصال عبر SSH فإننا نعيدهم إلى البوابة الأولى: sudo iptables -A PASSED -j GATE1أكملنا الآن إعداد جميع السلاسل المتفرعة عن سلسلة KNOCKING. بقي إعداد السلسلة العامة التي ستمرر حركة البيانات إلى السلاسل الفرعية. إعداد سلسلة KNOCKINGيمكننا الآن بعد إعداد السلاسل الفرعية منفردةً إلحاقها بالسلسلة العامة KNOCKING وبالتالي تنفيذ خطة عملنا. نبدأ أولا بتوجيه اتصالات العملاء الذين نجحوا في اختبارات الطرْق مباشرة إلى سلسلة PASSED. تمكننا إضافة خيارات هنا. سنقيد الفترة الزمنية التي يمكن للعميل الاتصال فيها بخدمة SSH بعد تجاوزه لاختبارات الطرق، ولتكن ثلاثين ثانية. بعد هذه المهلة لن يكون بمقدوره الاتصال ويجب عليه إرسال متتالية الطرق مرة أخرى. sudo iptables -A KNOCKING -m recent --rcheck --seconds 30 --name AUTH3 -j PASSEDثم نختبر العلامات الأخرى بدءا بالأكثر تقييدا. تمكننا إضافة عشر ثوان لتحديد مهلة لانتهاء صلاحية الطَّرْقات؛ يعني هذا أنه يتوجب على العملاء ألايفصلوا بين كل طرْقتين بأكثر من عشر ثوان. sudo iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH2 -j GATE3 sudo iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH1 -j GATE2نعيد توجيه جميع محاولات الاتصال التي لم توافق أيا من القواعد السابقة إلى البوابة الأولى: sudo iptables -A KNOCKING -j GATE1بهذا تأخذ جميع سلاسل الجدار الناري مكانها. تُلحَق سلسلة KNOCKING كاملة مع السلاسل التابعة لها بسلسلة INPUT الاعتيادية. أعددنا لآن آلية الطرق. حان الوقت لاختبارها. اختبار الطرق على المنافذتوجد الكثير من الأدوات التي يمكن استخدامها لإنشاء حزم بيانات تستخدم بروتوكول TCP المطلوبة في إعدادات الطرْق على المنافذ. سنستخدم أداة nmap نظرا لوجودها افتراضيا على أغلب توزيعات لينكس. يستخدم nmap افتراضيا حزم بيانات TCP. لذا يجب أن نطلب منه تجاهل استكشاف المستضيف الموجود في سلوكه الابتدائي لكي لا يتداخل مع الطرْقات. إضافة لذلك نريد أن تنتهي مهلة محاولة الاتصال بعد ثانية واحدة فقط لنتابع مع الطرقة الموالية. ستبدو كل طرْقة، من هذا المنطلق، على النحو التالي. في المثال أول منفذ نريد طرْقه: nmap -Pn --host_timeout 201 --max-retries 0 -p 1111 your_serverأي أن متتالية الطرق ستصبح على النحو التالي: nmap -Pn --host_timeout 201 --max-retries 0 -p 1111 your_server nmap -Pn --host_timeout 201 --max-retries 0 -p 2222 your_server nmap -Pn --host_timeout 201 --max-retries 0 -p 3333 your_serverستكون لدينا بعدها ثلاثون ثانية للاتصال بخدمة SSH. يمكننا الاستفادة من أساسيات في برمجة Bash لجعل الأمور آليةً أكثر. سنستخدم حلقة for لتنفيذ الأوامر السابقة ضمن حلقة تكرارية ثم تشغيل عميل SSH للاتصال بالخادوم: for x in 1111 2222 3333; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x your_server && sleep 1; done && ssh user@your_serverما نفعله هنا هو الطرْق على المنفذ الأول، انتظار ثانية واحدة، الطرْق على الثاني، وهكذا إلى أن تكتمل المتتالية. ثم نحاول بعدها الاتصال بخدمة SSH على الخادوم. ننشئ ملفا للسكربت لجعل الأمر أكثر أناقة وأيسر للاستخدام. نسمي الملف knock_client: nano knock_clientونضع فيه المحتوى التالي: #!/bin/bah ports="1111# 2222 3333" host="your_server" for x in $ports do nmap -Pn --host_timeout 201 --max-retries 0 -p $x $host sleep 1 done ssh user@${host}احفظ الملف (CTRL + O) ثم أغلقه (CTRL + X). نجعل الملف قابلا للتنفيذ: chmod 755 knock_clientنحاول الاتصال بالخادوم بتنفيذ الأمر: ./knock_clientيمكن الآن، إذا جرى كل شيء على ما يرام، الاتصال بالخادوم عن طريق SSH. بقيت خطوة أخيرة بعد التحقق من عمل الخطة التي نفذناها حسب المُراد. نجعل قواعد الجدار الناري دائمة (لا يُعاد تعيينها بعد إعادة تشغيل الخادوم) بتنزيل وتثبيت حزمة iptables-persistent على الخادوم: sudo apt-get install iptables-persistentوتشغيل خدمة iptables-persistent: sudo service iptables-persistent startخاتمةيكون لديك باكتمال هذا الدليل نظام عملي للطرق على المنافذ يعتمد فقط على الوظائف الموجودة في جدار iptables الناري. توجد مزايا لاعتماد iptables حصرا في هذا الإطار. أولا، ينتشر استخدام iptables ويشيع خضوعه لفحوص بحثا عن ثغرات أمنية قد تمثل خطرا على مستخدميه. يعني هذا أنه ما دامت القواعد التي أنشأتها تؤدي العمل الذي تظن أنها تؤديه فأنت في مأمن. ميزة أخرى لهذا الإعداد في مقابل خدمة منفصلة للطرق على المنافذ هي أنه لا مجال أن تفشل خدمة تنفيذ الطرق في تغيير قواعد الجدار الناري وتدع المنفذ مفتوحا. ترجمة - بتصرف - لمقال How To Configure Port Knocking Using Only IPTables on an Ubuntu VPS. حقوق الصورة البارزة: Shield vector designed by Freepik.

تتعرض الخواديم المتصلة بشبكة الإنترنت لأنواع كثيرة من الهجمات ومحاولات الاختراق التي يقف خلفها متسخدمون خبثاء، سكربتات وبرامج تعمل آليا. قد يكون تأمين الخادوم ضد الهجمات دون التأثير على وصول المستخدمين إلى الخدمات والموارد المتاحة لهم قرارا مؤثرا. تعد أنواع من الخدمات والموارد لتكون مرئية للعموم ومتاحة للجميع على الإنترنت، مثل خادوم الويب؛ إلا أن أنواعا أخرى من الخدمات لا يستخدمها إلا مدير النظام أو أفراد محددون وهي غير موجهة لتكون موردا يتاح للجميع الوصول إليه. يعرَّف الطرق على المنافذ Port kcnocking بأنه وسيلة لحماية العمليات Processes التي ينطبق عليها الوصف الأخير. يعمل الطرق على المنافذ على إخفاء المنافذ المرتبطة بإجراء مّا خلف الجدار الناري إلى أن تُنقل متتالية محدَّدة ومعرَّفة سلفا من حزم البيانات عبر الشبكة؛ حينها تعيد خدمة الطرْق على المنافذ ضبط الجدار الناري من أجل السماح بالوصول إلى التطبيق المحمي. تحدثنا في دروس سابقة عن كيفية تفعيل آلية للطرق على المنافذ عبر خدمة خاصة بهذا الغرض (knockd أو fwknop). سنشرح في هذا الدليل المكون من جزأين طريقة بديلة لإعداد الطرق على المنافذ. لا تعتمد هذه الطريقة على برنامج إضافي لتغيير قواعد الجدار الناري؛ بل تستعين بوِحدة لتتبع الحالة State-tracking module موجودة في جدار iptables الناري، تسمى recent. نفترض في هذا الدليل معرفة أساسيات التعامل مع iptables. ستكون الإعدادات على خادوم خاص افتراضي يعمل بتوزيعة أوبنتو 14.04. يجب أن لا تكون هناك تغييرات كبيرة بالنسبة لبقية توزيعات لينكس. ملحوظة: يغطي هذا الشرح الإصدار الرابع من بروتوكول IP. يفصل لينكس بين تأميني الإصدار الرابع والإصدار السادس. على سبيل المثال، لا تنطبق قواعد iptables إلا على حزم البيانات المنقولة عبر عناوين الإصدار الرابع، غير أنه يوجد مكافئ لها بالنسبة لعناوين الإصدار الرابع وهو ip6tables. نظرة عامة على الطرق على المنافذ في IPTablesأولا، وقبل البدء في ضبط الإعدادات، سنصف كيفية عمل وِحدة recent وكيف تسمح لنا بإنشاء نظام للطرْق على المنفذ. يتيح iptables إمكانية تحميل الوحدات عبر خيار m-. يمكن لوِحدة recent تتبع حالات الاتصال، وهو ما سنستغله لجعل محاولات الاتصال بمنفذ هدف (SSH على سبيل المثال) تمر عبر متتالية من المنافذ حسب ما إذا كان المستخدم أصاب المنفذ المطلوب سابقا في المتتالية. سنحظُر - لأغراض هذا الدرس - الوصول إلى خدمة SSH من الإنترنت، ممثَّلة بالواجهة eth0. ثم نعيد ضبط الجدار الناري ديناميكيا للسماح باتصالات SSH من الجهاز الذي نستخدمه مباشرة بعد الطرْق حسب المتتالية المتفق عليها؛ وهي: 111122223333يجب ألا تستخدم هذه القيم في الإعدادت الحقيقية، لسهولة تخمينها. لكي يُستوثَق من المستخدم بطريقة صحيحة وبالتالي يجعل iptables يعرِض خدمة SSh لعنوان IP الذي يتصل منه فإن عليه طرق منافذ المتتالية بالترتيب، دون أن يرسل أي بيانات أخرى بينها. إن نفذنا هذه الآلية بنجاح فسنحصل على نظام للطرق على المنافذ. خطة إعداد IPTablesسنستخدم بضعة سلاسل IPTables من أجل تطبيق الآلية المشروحة في الفقرة السابقة. أولا؛ نسمح بجميع حركة البيانات التي لا نريد إخضاعها للطرق على المنافذ. يتعلق الأمر بكل الموارد العمومية، مثل خادوم الويب، والاتصالات الجارية أو تلك القادمة من الواجهة المحلية. بعدها مباشرة نوجّه كل الاتصالات التي لا تنطبق عليها القاعدة السابقة إلى سلسلة جديدة تحوي القواعد الأساسية للجدار الناري. من المهم جدا اتباع هذه الطريقة عند تطبيق مجموعة قواعد عريضة ومتحفّظة؛ إذ أنها تتيح وسيلة سهلة لتفعيل ميزة بتمرير الاتصالات إلى السلسلة الجديدة أو تعطيلها بجعلها تتجنبها. سنسمي هذه السلسلة KNOCKING. سنستخدم أيضا سلاسل أخرى. تسمح وحدة recent بتصنيف الاتصالات وبالتالي التحقق ما إذا كان اتصال مّا يطابق تصنيفا معرفا مسبقا. سنعتمد على خاصية تصنيف الاتصالات لوضع علامات على عناوين IP التي أرسَلت طرقة إلى الوجهة (المنفَذ) الأولى؛ ونضيف قاعدة تبحث عن أول عنوان معلَّم وتتحقق من أن حزمة البيانات الثانية أُرسلت إلى الوجهة المطلوبة. إذا كان الأمر كذلك فسننشئ علامة جديدة للدلالة على أننا حصلنا على إجابتين صحيحتين لحد الساعة؛ وإلا فستُلغى الحزمة ويُعاد تعيين العلامة. تعمل السلاسل الموالية بنفس طريقة التحقق من العلامة المطلوبة وتمريرها إن استمرت على المسار المطلوب، أي متتالية الطرق. في النهاية وبعد الحصول على الحزم المطلوبة بالترتيب، تُعرض خدمة SSH برهةً قصيرة لعنوان IP الذي طَرَق بمتتالية صحيحة؛ ثم تُخفى من جديد تلقائيا. يمكن النظر إلى قواعد الطرْق هذه على أنها ثلاث بوابات للدخول إلى الخدمة، بوابة لكل قاعدة. يعني هذا أن أي عنوان IP سيكون في إحدى حالات أربع: الحالة الابتدائية: تبقى جميع عناوين IP في الحالة الابتدائية إلى أن ترسل حزمةً إلى أول وِجهة طرق. لن توجد قاعدة للتعامل مع هذه العناوين ضمن وحدة recent. نستخدم هذه الحالة للتدليل على العملاء الذين لم توضع علامات على عناوينهم بعد. الحالة auth1: توضع علامة auth1 على العناوين أرسلت حزمة إلى أول منفذ ضمن متتالية الطرق. تحدد الحزمة الموالية ما إذا كان العنوان سيُعاد للحالة الابتدائية أو يتقدم إلى الحالة auth2. الحالة auth2: يعني وجود عنوان في هذه الحالة أنه أصاب الهدفيْن الأول والثاني على التوالي. على منوال قاعدة الانتقال السابقة، تحدد الحزمة الموالية من العميل ما إذا كان العنوان سيُعاد للحالة الابتدائية أو يتقدم إلى الحالة auth3. الحالة auth3: العناوين المعلَّمة بauth3 هي تلك التي أصابت المنافذ الثلاثة على الترتيب وضمن الوقت المخصَّص. إذا حاول عميل يوجد في الحالة auth3 الاتصال بالخدمة الآن في الوقت المحدّد فسيُسمَح له بالوصول إليها؛ أما إذا أرسل بيانات مغايرة لتلك المستخدمة في الاتصال بالخدمة فسيرجع إلى الحالة الابتدائية. ستُنشأ لكل واحدة من هذه الحالات سلسلة Chain ضمن قواعد الجدار الناري، إضافة إلى كونها علامات تضبطها وحدة recent. تُلخَّص السلاسل على النحو التالي: GATE1: تحدد هل يجب نقل العميل من الحالة الابتدائية إلى auth1. GATE2: تحدد هل يجب نقل عنوان من الحالة auth1 إلى auth2 أم تجب إعادة تعيينه وإرجاعه إلى الحالة الابتدائية. GATE2: تحدد هل يجب نقل عنوان من الحالة auth2 إلى auth3 من أجل السماح له بالاتصال عن طريق SSH؛ أم تجب إعادة تعيينه وإرجاعه إلى الحالة الابتدائية. PASSED: تستخدَم هذه السلسلة لفتح منفذ SSH خلال مدة قصيرة للعملاء الذين نجحوا في إرسال الطرْقات. إذا أرسل عميل تنطبق عليه هذه السلسلة بيانات غير موجهة للاتصال بSSH فسيُتجاهل وبالتالي يعاد تعيين حالته إلى الحالة الابتدائية. من الواضح أن لدينا نقاط قرار عدة. يجب تجاهل كل محاولات الاتصال من سلسلة KNOCKING والسلاسل المتفرعة عنها (باستثناء الاتصالات القادمة إلى خدمة SSH من عملاء نجحوا في الطرْق)؛ وذلك بغض النظر هل وافقت المنفذ الصحيح أم لا. آلية وضع العلامات أعلاه هي وسيلة داخلية في الجدار الناري لتتبع محاولات الاتصال، وليست معروضة للعميل. هذا الأمر ضروري لنجاح تنفيذ الطرق على المنافذ. يجب ألا يتلقى من يحاول الاتصال أي رد كما لا يجوز أن يعرف الحالة التي يوجد فيها، بل لا يجوز أصلا أن يعرف وجود آلية على الخادوم للطرق على المنافذ. في الجزء الثاني من هذا الدليل سنشرح كيفية العمل على تنفيذ خطة العمل هذه. ترجمة - بتصرف - لمقال How To Configure Port Knocking Using Only IPTables on an Ubuntu VPS. حقوق الصورة البارزة: Shield vector designed by Freepik.

SSH هو الطريقة الأساسية للاتصال بخواديم لينكس والأنظمة الشبيهة بيونكس عبر سطر الأوامر. يوفّر لك هذا اتصالًا آمنًا يمكنك استخدامها لتطبيق الأوامر، التفاعل مع النظام أو حتّى توجيه التدفّق (traffic) عبره. معظم المستخدمين يدركون أساسيات البدء وكيفية الاتصال بخادومٍ بعيد عبر أمرٍ شبيه بـ: ssh username@remote_serverلكن، هناك المزيد من الخيارات المفيدة التي يمكنك استخدامها مع عفريت SSH Daemon) SSH) لتحسين الأمان، إدارة اتصالات المستخدمين.. إلخ. سنشرح بعض هذه الخيارات التي تعطيك تحكّمًا أكبر باتصال SSH الخاصّ بك. سنقوم بتوضيح هذه الأمور على خادوم Ubuntu 12.04، ولكن الأمور نفسها تنطبق على أيّ توزيعة لينكس حديثة. تصفح ملف إعداد SSHDالمصدر الرئيسي لإعدادات عفريت SSH هو بالملف etc/ssh/sshd_config/. لاحظ أنّ هذا الملف مختلفٌ عن ملف ssh_config، والذي يقوم بضبط إعدادات SSH لأجهزة العملاء فقط (clients). افتح الملف بصلاحياتٍ إدارية عبر: sudo nano /etc/ssh/sshd_configسترى ملفًّا مفتوحًا مع بعض خيارات، ولحسن الحظ، فسترى بعض التعليقات كذلك (اعتمادًا على توزيعة لينكس الخاصّة بك). صحيحٌ أنّ معظم توزيعات لينكس تستخدم إعدادات افتراضية جيّدة، ولكن هناك مساحة موجودة كذلك لعمل بعض التخصيص والتحسين. فلنستعرض بعض الخيارات التي تمّ ضبطها بالفعل بملفّنا على Ubuntu 12.04: المنافذ والبروتوكولاتPort 22: يقوم هذا السطر بتحديد المنفذ الذي سيعمل عليه عفريت SSH. افتراضيًا، تعمل معظم الخواديم وأجهزة العملاء على المنفذ 22، ولكن تغيير هذا المنفذ إلى منفذٍ آخر قد يساعد من تقليل محاولات تسجيل الدخول الفاشلة عبر SSH بواسطة المُخترقين.Protocol 2: تمّ تطوير SSH عبر بروتوكولين مختلفين اثنين. باستثناء ما إذا كنتَ تحتاج إلى دعم أجهزة العملاء التي تعمل فقط على البروتوكول 1، فمن المستحسن أن تترك هذا السطر على ما هو عليه.المفاتيح والعزلHostKey /etc/ssh/sshhost…: تقوم هذه السطور بتحديد مفاتيح المستضيف الخاصّة بالخادوم. يتم استخدام هذه المفاتيح للتعرّف على الخادوم للاتصال بأجهزة العملاء. إذا كان جهاز عميلٍ ما قد اتصل من قبل بالخادوم في الماضي، فيمكنه استخدام هذا المفتاح للتحقق من الاتصال الجديد.UsePrivilegeSeparation yes: يسمح هذا الخيار لـSSH بإنشاء عملياتٍ فرعية تمتلك الصلاحيات اللازمة فقط لآداء مهامّها. هذه الميّزة هي ميّزة أمان يتم استخدامها لعزل العمليات الفرعية في حصول اختراقٍ أمني.KeyRegenerationInterval و ServerKeyBits: تقوم هذه الخيارات بالتأثير على مفتاح الخادوم الذي يتم إنشاؤه للبروتوكول 1. لا يجب عليك أن تولي اهتمامًا لهذا طالما أنّك لا تزال تستخدم البروتوكول 2.التسجيل والتقييداتSyslogFacility و LogLevel: تحدد هذه الخيارات كيف سيتم تسجيل النشاط. الخيار الأول هو لتسجيل الرسائل، والخيار الثاني يحدد "درجة التسجيل" أو التفاصيل التي يجب أن يتم تسجيلها بملفّات السجل.LoginGraceTime 120: يحدد هذا الخيار عدد الثواني التي يجب على الخادوم أن ينتظرها قبل أن يقوم بقطع الاتصال عن جهازٍ عميل في حال لم يكن هناك عملية تسجيل دخول ناجحة.PermitRootLogin yes: يسمح هذا الخيار أو يمنع من استخدام SSH لتسجيل الدخول إلى المستخدم الجذر عبر اتصالٍ بعيد. بما أنّ المستخدم الجذر هو مستخدمٌ يعرف المهاجمون أنّه حتمًا موجود على الخادوم، وبما أنّه يمتلك كامل الصلاحيات كذلك، فهو هدفٌ معرّض بشدة للهجمات. لذا فإنّ تغيير هذا الخيار إلى "no" سيكون جيّدا بعد أن تضبط مستخدمًا عاديًا بصلاحيات الإدارة.StrictModes yes: هذا السطر يمنع استخدام أيّ ملفّات إعداد تابعة لـSSH في حال كانت غير مضبوطة على الصلاحيات الصحيحة. مثلًا، إذا كانت ملفّات الإعداد قابلة للكتابة من قبل الجميع، فإنّ هذا الأمر يعتبر خطرًا، ويجب عدم استخدام تلك الملفّات إلى حين إصلاح المشكلة.IgnoreRhosts و RhostsRSAAuthentication: تحدد هذه السطور نمط استيثاق rhost الذي سيتم استخدامه. هذه السطور مصممة للبروتوكول 1 ولا تنطبق على البروتوكول 2.HostbasedAuthentication no: هذا هو إصدار البروتوكول 2 من الخيارين السابقين. يسمح لك هذا الخيار بشكلٍ أساسي بقبول عمليات الاستيثاق بناءً على المستضيف الخاصّ بأجهزة العملاء. عادةً يكون هذا الخيار مقبولًا فقط بالبيئات المعزولة، لأنّه يمكن أن يتم عبره محاكاة معلومات المصدر. يمكنك تحديد معلومات المستضيف التي يجب السماح لها بالملف etc/ssh/shosts.equiv/ أو الملف etc/hosts.equiv/، ولن نتحدّث عن هذا الأمر حاليًا.PermitEmptyPasswords no: يقوم هذا الخيار بمنع الوصول عبر SSH إلى حسابات المستخدمين التي لا تمتلك كلمة مرور (وهي كثيرة!)، وهذا أمرٌ خطير ولا يجب عليك تغيير حالته بتاتًا.ChallengeResponseAuthentication: يقوم هذا السطر بتفعيل أو تعطيل الاستياق عبر "التحدّي" حيث يمكن ضبطه باستخدام PAM، وهو خارج نطاق درسنا هذا حاليًا.العرضX11Forwarding yes: يسمح لك هذا بإعادة توجيه واجهة X11 الرسومية الخاصّة بالتطبيقات على الخادوم إلى أجهزة العملاء. هذا يعني أنّه يمكنك تشغيل برنامجٍ رسومي على الخادوم والتفاعل معه من على جهاز العميل. يجب على جهاز العميل أن يمتلك نظام النوافذ X مثبّتًا. يمكنك تثبيت وضبط هذه الأمور على OS X، كما أنّ جميع توزيعات لينكس ستحتوي على هذه الأشياء كذلك.X11DisplayOffset 10: هذا الخيار هو عبارة عن "إزاحة" لرقم عرض sshd لتوجيه X11. تسمح هذه الإزاحة لنوافذ X11 المفتوحة عبر بروتوكول SSH بأن تتفادى التشابك مع خادوم العرض X المحلّي.PrintMotd no: يقوم هذا السطر بجعل عفريت SSH لا يقوم بقراءة وعرض رسالة اليوم. أحيانًا يتم قراءة هذه الرسالة بواسطة الصدفة نفسها، لذا ربما تحتاج إلى تعديل إعدادات الصدفة الخاصّة بك كذلك.PrintLastLog yes: يقوم هذا الخيار بإخبار عفريت SSH بأن يطبع معلوماتٍ عامّة عن آخر عملية تسجيل دخول قمتَ بها.الاتصال والبيئةTCPKeepAlive yes: يحدد هذا السطر ما إذا كان يجب إرسال رسائل الإبقاء على قيد الحياة لبروتوكول TCP إلى جهاز العميل. يمكن لهذا الأمر أن يساعد الخادوم على اكتشاف المشاكل وأن يُعلمه متى سيتم إغلاق الاتصال. إذا كان هذا الخيار معطلًا، فإنّه لن يتم إغلاق الاتصالات عندما يكون هناك عدد قليل من المشاكل مع الشبكة، وهو ما يمكن أن يكون أمرًا جيّدًا، ولكنّه أيضًا يعني أنّ المستخدمين سيكونون قادرين على إلغاء الاتصال ومتابعة حجز مساحة من موارد الخادوم.AcceptEnv LANG LC_*: يسمح لك هذا الخيار بقبول متغيّرات بيئة معيّنة من جهاز العميل. في هذه السطر بالتحديد، سينقوم بقبول متغيرات اللغة، والذي يمكنه أن يساعد جلسة الصدفة على طباعة الرسائل بشكلٍ مخصص لجهاز العميل.Subsystem sftp /usr/lib/openssh/sftp-server: يقوم هذا الخيار بإعداد أنظمة فرعية خارجية يمكن استخدامها مع SSH. وبمثالنا هذا، فإنّه يتم تحديد خادوم STFP والمسار المؤدّي إلى تشغيله.UsePAM yes: يقوم هذا الخيار بتحديد ما إذا كان يجب توفير PAM (وحدات الاستيثاق القابلة للإضافة) للمستخدمين الذين تمّ التحقق منهم بالفعل.ما سبق هو أهمّ الخيارات الافتراضية المفعّلة على خادومنا العامل بـUbuntu 12.04. الآن، سنتحدّث عن بعض الخيارات الأخرى التي يمكن أن تكون مساعدةً لك لتضبطها أو تعدّلها. خيارات SSHD أخرىهناك المزيد من الخيارات التي يمكننا ضبطها لعفريت SSH الخاصّ بنا. بعض هذه الخيارات قد يكون مفيدًا لك وبعضها الآخر قد لا يكون مفيدًا إلّا في حالات معيّنة. لن نتحدّث عن جميع الخيارات هنا بل فقط المهم منها. ترشيح المستخدمين والمجموعاتتسمح لك بعض الخيارات بالتحكّم بشكلٍ دقيق بالمستخدمين الذين تريد السماح لهم فقط بالولوج عبر SSH. تعتبر هذه الخيارات خياراتٍ حصرية; كمثال، يسمح الخيار AllowUsers لمستخدمين معيّنين فقط بتسجيل الدخول بينما يمنع كلّ المستخدمين الآخرين. AllowGroups: يسمح لك هذا الخيار بتحديد أسماء المجموعات الموجودة على الخادوم. سيمتلك المستخدمون الأعضاء في واحدةٍ أو أكثر من هذه المجموعات حقّ الوصول إلى الخادوم فقط.AllowUsers: هذا الخيار شبيه بما سبق، ولكنّه يحدد المستخدمين المخوّلين فقط بالولوج. لن يتمكّن أيّ مستخدم غير مدرج على هذه القائمة من تسجيل الدخول عبر SSH. يمكنك اعتبار هذا الخيار كقائمةٍ بيضاء لأسماء المستخدمين المخوّلين للولوج.DenyGroups: يقوم هذا الخيار بعمل قائمة سوداء للمجموعات الغير مخوّلة بتسجيل الدخول، أيّ مستخدم عضو في واحدٍ من هذه المجموعات لن يمتلك حقّ الوصول إلى الخادوم عبر SSH.DenyUsers: وكالسابق، يقوم هذا الخيار بإنشاء قائمة سوداء للمستخدمين الممنوعين من تسجيل الدخول عبر SSH.بالإضافة إلى ما سبق، هناك بعض الخيارات التي تمكّنك من فرض المزيد من التقييدات. يمكن أن يتم استخدامها بالتوازي مع الخيارات السابقة. Match: يسمح هذا الخيار بالمزيد من التحكّم على المستخدمين القادرين على الاستيثاق تحت شروطٍ معيّنة. يحدد هذا الخيار كذلك مجموعةً مختلفة من الخيارات يمكن استخدامها عندما تتم عملية اتصال مستخدم معيّن أو مستخدمٍ ضمن مجموعة معيّنة. سنناقش هذا بالتفصيل لاحقًا.RevokedKeys: يسمح لك هذا الخيار بتحديد المفاتيح العمومية المُلغاة. سيقوم هذا بمنع المفاتيح المحددة من أن يتم استخدامها لتسجيل الدخول إلى النظام.خيارات منوعةهناك بعض الخيارات التي يمكنك استخدامها كذلك لإعداد التدفّق (traffic) عبر عفريت SSH، ومن بينها: AddressFamily: يحدد هذا الخيار نوع العناوين التي سيتم قبول الاتصالات منها. افتراضيًا، فإنّ الخيار مضبوط ليقبل جميع العناوين، ولكن يمكنك تغييره إلى "inet" لتجعله يقبل عناوين IPv4 فقط، أو "inet6" لعناوين IPv6.ListenAddress: يسمح لك هذا الخيار بأن تخبر عفريت SSH بأن يعمل على منفذٍ وعنوانٍ محددين. افتراضيًا، يعمل العفريت على جميع العناوين الموجودة على الآلة.الخيارات الأخرى المتوفّرة تشمل تلك التي يتم استخدامها لإعداد الاستيثاق عبر الشهادات، خيارات تقييد الاتصال مثل ClientAliveCountMax و ClientAliveInterval، بالإضافة إلى خيارات مثل ChrootDirectory، والذي يمكن استخدامها لقفل تسجيل دخول مستخدمٍ معيّن إلى مسارٍ محدد مضبوط مسبقًا. تقييد تسجيل دخول المستخدمينذكرنا أعلاه بعض الأدوات التي يمكنك استخدامها لتقييد دخول المستخدمين والمجموعات، فلنشرح بعضًا منها هنا بالقليل من التفصيل. الصيغة الأساسية لاستخدام هذه الأدوات هي كالتالي: AllowUsers demouser fakeuser madeupuserكما يمكنك أن ترى، يمكننا تحديد أكثر من مستخدم مفصولين بمسافة ليتم تطبيق الأمر عليهم. يمكننا أيضًا استخدام إشارات النفي لتطبيق قواعد معيّنة. مثلًا، إذا أردنا السماح للجميع بالولوج فيما عدا المستخدم "hanny"، فيمكننا تطبيق شيءٍ كـ: AllowUsers * !hannyيمكننا أن نعبّر عن المثال السابق مع الخيار DenyUsers كالشكل التالي: DenyUsers hannyيمكننا أيضًا استخدام محراف؟ لمطابقة حرفٍ واحد بالضبط. مثلًا: AllowUsers ?imالخيار السابق سيقوم بالسماح لجميع المستخدمين الذين يتكوّن اسمهم من 3 حروف، وينتهي اسمهم بـim، مثل "jim" ،"tim" ،"vim". يمكننا أن نكون أكثر تحديدًا كذلك، يمكننا استخدام الشكل user@hostname بهدف تقييد تسجيل الدخول إلى موقعٍ معيّن فقط من قبل أجهزة العملاء، كمثال، يمكنك كتابة: AllowUsers demouser@host1.com fakeuserسيقوم هذا الخيار بالسماح للمستخدم fakeuser بتسجيل الدخول من أيّ مكان، بينما لن يسمح للمستخدم demouser بأن يقوم بتسجيل الدخول إلّا من مستضيف يدعى host1.com. يمكننا كذلك تقييد عمليات تسجيل الدخول بناءً على اسم المستضيف من خارج ملفّ sshd_config عبر أغلفة TCP Wrappers. يمكن القيام بهذا عبر الملفّين etc/hosts.allow/ و etc/hosts.deny/. كمثال، يمكننا تقييد الوصول عبر SSH بناءً على اسم مستضيفٍ معيّن عبر إضافة السطر التالي إلى ملفّ hosts.allow: sshd: .example.comوبافتراض أننا نمتلك السطر التالي كذلك في ملفّ hosts.deny: sshd: allفإنّه سيتم السماح بعمليات تسجيل الدخول عبر SSH فقط من الاتصالات القادمة من example.com أو من واحدٍ من نطاقاته الفرعية. استخدام خيارات Match لإضافة الاستثناءاتيمكننا التحكّم بخياراتنا بشكلٍ أكبر عبر استخدام خيارات "match". تعمل خيارات Match عبر تحديد نمطٍ معيّن ليكون الفيصل فيما إذا كان خيارٌ ما سيتم تطبيقه أم لا. نبدأ عبر كتابة الخيار Match ومن ثم نقوم بتحديد مجموعة من قيم المفاتيح التي نريد تطبيقها، المفاتيح الموجودة هي "User", "Group", "Host", و "Address". يمكننا الفصل فيما بين كلّ مُدخَلة بمسافة وفصل كلّ نمط (user1, user2) بفاصلة. يمكننا كذلك تطبيق إشارات الاستبعاد (!) مثلًا إن أردنا: Match User !demouser,!fakeuser Group sshusers Host *.example.comيقوم السطر السابق بالمطابقة فقط في حال كان المستخدم ليس demouser أو fakeuser، وكان المستخدم عضوًا في مجموعة sshusers، وكان المستخدم يتصل من مستضيف بعنوان example.com ، إذا تحققت كلّ الشروط السابقة فحينها فقط يتم إرجاع المطابقة بنجاح. يمكن للمعيار “Address” أن يستخدم مجموعة رموز CIDR netmask. الخيار الذي يتبع السطر Match سوف يتم تطبيقه فورًا في حال ما إذا تمّت المطابقة بنجاح. مدى هذه المطابقات الشرطية هو إلى نهاية ملفّ الإعدادات أو إلى بداية المطابقة الشرطية التالية. بسبب هذا، من المنصوح أن تقوم بوضع إعداداتك ومتغيّراتك الافتراضية في بداية الملفّ وأن تضع الاستثناءات في نهايته. بسبب هذه الجمل الشرطية، الخيار الذي يكون تحت جملة match غالبًا ما يتم إزاحته إلى اليمين قليلًا ليشير إلى أنّه تابعٌ لجملة match الشرطية. كمثال، يمكن للشرط أعلاه أن يبدو عند التطبيق كالتالي: Match User !demouser,!fakeuser Group sshusers Host *.example.com AuthorizedKeysFile /sshusers/keys/%u PasswordAuthentication yes X11Forwarding X11DisplayOffset 15تمتلك الوصول إلى مجموعة صغيرة من الخيارات فقط عندما تتعامل مع تقييدات الخيار match. للحصول على قائمةً كاملة، يمكنك مراجعة صفحة man الخاصّة بـsshd_config: man sshd_configابحث عن قسم "Match" لترى قائمة كاملة بالمتغيّرات المتوفّرة. الخاتمةكما ترى، يمكنك ضبط العديد من المتغيّرات الخاصّة بـSSH من طرف الخادوم والتي ستؤثّر على الطريقة التي يقوم المستخدمون من خلالها بتسجيل الدخول. تأكّد من اختبار تغييراتك بحذر قبل أن تقوم بتطبيقها بشكلٍ كامل على كامل الخادوم لتجنّب أيّ إعدادات خاطئة ومشاكل قد تحصل. تعلّم أساسيات إعداد ملفّ etc/ssh/sshd_conf/ هو خطوة ممتازة نحو فهم كيفية التحكّم بحذر بالوصول إلى خادومك، إنّها مهارةٌ ضرورية لأيّ مدير نظام لينكس. ترجمة -وبتصرف- للمقال How To Tune your SSH Daemon Configuration on a Linux VPS لصاحبه Justin Ellingwood.

تحدثنا في الدرس السابق عن الآلية التي تعمل وفقها خدمة fail2ban لحماية خوادم لينكس حيث تحظر أرقام IP المُسيئة التي تحاول اختراق خدمة ما عبر محاولات دخول متكرّرة باستخدام حسابات شائعة. وفصلنا في شرح ملفات الضبط الخاصة بكل من المُرشّح والإجراءات. نشرح في هذا الدرس ما يحدث عندما تبدأ خدمة fail2ban بالعمل. تحميل ملفات الضبط الأولىفي البداية يُقرأ ملف fail2ban.conf الرئيسي لتحديد الشروط التي يجب أن تُنفَّذ العمليّة الرئيسيّة وفقها، ويتم إنشاء كلّ ما يلزم لذلك كالمقابس socket، ملفات السجل log files، وقيم PID. يقرأ fail2ban بعد ذلك الملف jail.conf للحصول على تفاصيل الضبط، وهذا يعني قراءة ملفات الضبط الموجودة ضمن الدليل jail.d والمنتهية باللاحقة conf. تبعًا للترتيب الأبجدي، بحيث تُضاف الإعدادات الموجودة ضمن هذه الملفات إلى الضبط الداخلي وتُكتب القيم الجديدة للخصائص على تلك الموصوفة في ملف jail.conf. يبحث fail2ban بعد ذلك عن ملف jail.local ويكرّر ذلك مُتكيفًا مع القيم الجديدة التي تحملها. أخيرًا فإنه يبحث في الدليل jail.d مرةً أخرى لقراءة الملفات ذات اللاحقة local. حسب الترتيب الأبجدي. وبهذه الطريقة نرى أن fail2ban يملك عددًا كبيرًا من الملفات التي يمكن استخدامها للتحكّم بالسلوك النهائي للبرنامج. وفي حالتنا هذه نحن نملك الملفين jail.conf و jail.local فقط، حيث وضعنا في الملف jail.local القيم التي نحتاج فقط لأن تكون مغايرة عن تلك الموجودة في jail.conf. في المحصلة يملك fail2ban الآن مجموعة من التعليمات التي يمكن تحميلها إلى الذاكرة وتُمثّل مزيجًا مُركبًا من جميع الملفات التي تمكّن من العثور عليها. يفحص البرنامج بعد ذلك كل قسم باحثًا عن عبارة enabled = true، فإذا وجدها في قسمٍ ما فإنّه يقرأ المُعاملات المكتوبة فيه لبناء خطّة عمله وتحديد ما يلزم من الإجراءات، بينما تُستخدم المُعاملات الموجودة في المقطع الافتراضي [DEFAULT] لتلك التي لا تملك تعريفًا خاصًا في أقسام الخدمات. تحليل ملفات الإجراء لتحديد إجراءات البدايةيبحث fail2ban عن action موجِّه لمعرفة سيناريو العمل بهدف تنفيذ سياسات الحظر أو رفعه. فإذا لم يجد واحدًا فإنه يعود إلى الإجراء الافتراضي الموضّح أعلاه. يتكّون الإجراء الموجّه من اسم ملف(ات) الإجراء التي ستُقرأ، فضلًا عن قاموس قيم المفاتيح key-value التي تُمرّر المُعاملات اللازمة لتلك الملفات، وغالبًا ما تأخذ هذه القيم شكل مُعاملات الاستبدال عن طريق الرجوع إلى الإعدادات المضبوطة في قسم الخدمة. ويُمرّر مفتاح name قيمة المتغيّر __name__ التي ستُعيّن كقيمة لترويسة القسم. بعد ذلك يستخدم fail2ban هذه المعلومات للعثور على الملفات المرتبطة بها في الدليل action.d، حيث يبحث في المقام الأوّل عن الملفات ذات اللاحقة conf. ثم يُعدّل المعلومات الموجودة فيها مع الإعدادات المُضمّنة في الملفات ذات اللاحقة local. والموجودة أيضًا في الدليل نفسه. تُحلّل تلك الملفات لتحديد الإجراءات الواجب تنفيذها، حيث تُقرأ قيمة actionstart لمعرفة الإجراءات التي يجب اتخاذها لإعداد بيئة العمل، والتي غالبًا ما تشمل على إنشاء صيغة لجدار الحماية بهدف استيعاب قواعد الحظر. تستخدم الإجراءات المُعرّفة في هذا الملف المُعاملات التي تُمرّر إليها من قبل الإجراء المُوجّه، إذ تُستخدم هذه القيم لإنشاء القواعد المناسبة بشكلٍ حيويّ. وإذا لم يتم تعريف متغيّر ما فإنه يمكن النظر إلى القيم الافتراضية في ملف الإجراء حينها. تحليل ملفات المرشح لتحديد قواعد التصفيةتشمل مُعاملات الخدمة الموجودة في ملفات jail.* مسار ملف السجل، إضافةً إلى آلية الانتخاب التي يجب استخدامها لفحص الملف (والتي تُعرّف بواسطة الخيار backend)، كما تضم المُرشّح filter الذي يجب استعماله لتحديد الأسطر المُمثّلة لحالات فشل المصادقة. يبحث fail2ban في الدليل filter.d عن ملف المُرشّح ذو اللاحقة conf.. يُقرأ هذا الملف لتعريف الأنماط التي يمكن استخدامها لمطابقة الأسطر المُسيئة، ثم يقوم البرنامج بالبحث عن ملف المرشح ذو اللاحقة local. لمعرفة فيما إذا كان أيٍ من المُعاملات الافتراضية قد حصل على قيمة أخرى، تُستخدم في هذه الملفات التعابير النمطيّة المعرّفة. يقوم fail2ban بقراءة ملف سجل الخدمة. حيث يحاول كل سطر failregex مُعرّف في ملفات filter.d مقابلة كل سطر جديد يكتب إلى ملف سجل الخدمة. إذا ضُبط عنوان IP مُسيء عن طريق إرجاع التعبير النمطي لمطابقة فإنّه يتحقق أولًا من مطابقته كذلك مع التعبير النمطي المُعرّف بواسطة ignoreregex، فإذا تمت المطابقة معه أيضًا يتجاهل fail2ban الأمر، وإلا يزداد العداد الداخلي للعميل الذي تسبّب بالمطابقة ويتم إنشاء طابع زمني مرتبط بهذا الحدث. عندما يبلغ الإطار الزمني المُحدد بواسطة المُعامل findtime في ملفات jail.* نهايته (على النحو الذي يُحدّده الطابع الزمني للحدث)، يتم إهمال العدّاد الداخلي مجددًا، ولا يُعتبر هذا الحدث ذو صلة بسياسة الحظر. أما إذا وقعت محاولة ولوج فاشلة إضافية خلال الوقت المُحدّد يزداد العداد الداخلي مرة أخرى، فإذا ما وصل العداد إلى عتبة الفشل المُحدّدة من قبل الخيار maxretry ضمن الإطار الزمني المضبوط يُنفّذ fail2ban خطّة الحظر عبر استدعاء الإجراء actioncheck للخدمة المُعرّفة في ملفات action.d/، وهذا يُحدّد فيما إذا كان إجراء actionstart أعدّ الصيغة اللازمة. وبعد ذلك يُدعى الإجراء actionban لحظر العميل المُسيء مُحدّدا الطابع الزمني لهذا الحدث كذلك. بعد انقضاء الوقت المُحدّد من قبل المُعامل bantime؛ يرفع fail2ban الحظر عن العميل عبر استدعاء الإجراء actionunban. عندما تتوقف خدمة fail2ban فإنها تحذف قواعد جدار الحماية التي تمّ إنشائها من قبل الإجراء actionstop، الأمر الذي يحذف السلسلة الحاوية على قواعد fail2ban ويحذف القواعد من سلسلة INPUT والتي كانت تنقل حركة مرور البيانات إلى تلك السلسلة. خاتمةهكذا نأمل أن تكون قد امتلكت فهمًا عميقًا لآلية عمل fail2ban، وفي العموم فإن التعامل مع هذه الخدمة ليس بالأمر الصعب بالنسبة لأغلب المستخدمين؛ فمعظم مهمات الضبط تكون مُعدّة بشكل مسبق، ومع هذا فإذا أردت التعديل على إعدادات الضبط الافتراضية فسيكون من المفيد لك أن تتعرف على كيفية عمل fail2ban لتسهيل التعديل بما يتلاءم مع احتياجاتك. ترجمة -وبتصرف- للمقال How the Fail2ban Service Processes Configuration Files to Implement Bans لصاحبه Justin Ellingwood.