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

تستغل هجمات حقن SQL البرمجة السيئة للشفرة الخاصّة بالبرمجيات. إنّها هجمات حيث يقوم المهاجمون بإرسال شفرة عبر واحدٍ من مربّعات الإدخال الموجودة على موقعك (أيّ مربّع)، عوضًا عن أن يرسل بياناتٍ عادية كنتَ تنوي استقبالها عبر مربّعات الإدخال تلك. تقوم تلك الشفرة المُدخلة بتنفيذ عمليات الاستعلام على قاعدة البيانات الخاصّة بموقعك بطريقةٍ لم تكن تتوقعها، أو تقوم بتحطيم تطبيق الويب الخاصّ بك وتقوم بتخريب خادومك السحابي. م السهل جدًا عمل هجمات حقن SQL ضدّ المواقع الغير مؤمّنة. وحراسة موقعك ضدّ هذه الهجمات قد يكون من أهمّ ما تقوم به منذ اليوم الأوّل. الخطوة الأولى: تعلم تمييز الشفرة المحتوية على ثغرات تأخذ هجمات SQL دومًا شكل سلسلة نصّية يتم إرسالها من طرف مستخدمٍ تتكون من قسمين. القسم الأول هو عبارة عن تخمين لكيفية تعطيل أمرٍ تحاول شفرتك المصدرية أن تقوم بتنفيذه بأمان; القسم الثاني هو الشفرة الخبيثة التي يريد المهاجم تنفيذها على خادومك. إليك مثالًا على سلسلة نصّية مصممة لاستغلال ثغرة ممكنة في الشفرة المصدرية لديك: x' AND user.email IS NULL; -- يبدو هذا كشيء قمتَ بكتابته بنفسك، وتلك هي النقطة. يأمل المستخدم المُخترِق أن تقوم بأخذ هذا السطر، وتقوم بتنفيذه بعملية استعلام SQL تبدو كالتالي: SELECT email, passwd FROM user WHERE email = 'x' AND user.email IS NULL; --'; لا يبدو أنّ هذا يقوم بالكثير حقًا، ولكن اعتمادًا على الطريقة التي سيستجيب بها تطبيقك إلى ما سبق، يمكن أن يوفّر هذا بعض المعلومات المهمّة للمُخترِق مثل اسم جدول قاعدة البيانات الذي تستعمله. بعد هذا، هناك المزيد من الهجمات التي يمكن للمهاجم أن يستخدمها لجلب المزيد من المعلومات، مثل أسماء المستخدمين وكلمات المرور. الفكرة الرئيسية التي يجب عليك فهمها هي أنّ الشفرة الخبيثة تحاول البحث عن ثغرة بعملية استعلام SQL التي يقوم بها تطبيقك لمحاولة استغلالها لجلب المعلومات أو إدراجها وتعديلها. لا تتطلب جميع هجمات حقن SQL إشارة الاقتباس المغلقة ('). إذا كانت شفرتك المصدرية تنفّذ عملية استعلامٍ متعلّقة برقم، فإنّك لن تقوم بالطبع بوضع تلك البيانات داخل إشارة اقتباس. وهذا يتركك عرضةً لهذا النوع من الهجمات: 2097 OR 1=1 يأمل المهاجم أن يقوم تطبيقك بعملية استعلام مشابهة للتالي: SELECT somedata FROM yourtable WHERE userid = 2097 OR 1=1; غالبًا ما تكون شفرتك البرمجية مصممة لتقوم بعملية الاستعلام السابقة لتعيد البيانات فقط في حال تطابق الـ userid مع المستخدم الصحيح. ولكنّ حقنة الـSQL تجعل عملية الاستعلام تقوم دومًا بإرجاع البيانات. النقطة ليست في سلوكٍ معيّن لأيّ حقنة SQL. الشيء الأكثر أهمّية من هذا كلّه هو القاعدة العامّة لجميع حقن SQL: محاولة لتخمين كيفية حذف جزء معيّن من عملية استعلام، وإضافة جزءٍ آخر إليها لم تكن تتوقعه. هذا هو توقيع جميع هجمات حقن SQL. وهذه هي طريقة محاربتها. الخطوة الثانية: اعثر على مدخلاتك أفضل طريقة لتعقّب جميع نقط إدخال حقن SQL الممكنة في شفرتك البرمجية ليس عبر النظر إلى حقول إدخال HTML. بالطبع يمكنك العثور على العديد من الثغرات الممكنة هناك، ولكن هناك طرقٌ أخرى يمكن من خلالها للمستخدم أن يقوم بإدخال البيانات، مثل عنوان الويب (URL)، أو عبر واحدةٍ من واجهات AJAX الخاصّة بك. أفضل مكان للبحث فيه عن الثغرات هو الشيء الذي يريد المخترقون اختراقه بنفسه; جملة استعلام SQL بنفسها. على الأغلب، فإنّك تقوم بتنفيذ جميع عمليات الاستعلام عن طريق الأمر الأساسي نفسه، وربّما أمران آخران أو أكثر قليلًا. فقط ابحث عن هذه الأوامر في شفرتك البرمجية وستجد جميع الثغرات الممكنة بشكلٍ سريع. كمثال، إذا كانت شفرتك البرمجية مكتوبة بـPerl، فإنّ جميع عمليات استعلام SQL الخاصّة بك ستبدو هكذا: $result = mysql_query($sql) في تلك الحالة، يمكنك العثور بسرعة على جميع الثغرات الممكنة بواسطة سطر الأوامر، عبر استخدام أمر شبيه بالتالي: $ grep -R mysql_query * الخطوة الثالثة: نظف مدخلاتك هناك العديد من التقنيات التي يستخدمها الناس لمنع هجمات حقن SQL، ولكن خطّ دفاعك الأمامي يجب أن يكون تنظيف جميع مُدخلات المستخدم من أيّ شفرة خبيثة مشبوهة. يجب ألّا تعتقد بتاتًا أنّ المستخدم سيقوم بإدخال البيانات بالطريقة التي تريدها. في الواقع، يجب عليك أن تفترض العكس - أنّهم سيقومون بإدخال الشفرات الخبيثة في كلّ مكانٍ ممكن في موقعك. تنظيف المُدخلات يعني أنّه يجب اختبار جميع مُدخلات المستخدم للتأكّد من أنّها تحتوي فقط مُدخلات آمنة، مُدخلات لا يمكن استخدامها بتاتًا في شنّ هجوم. المُدخلات التي سيتم إدخالها من طرف المستخدم إلى خادوم SQL الخاصّ بك ستكون على شكلَين: كرقم، مثل 2097. كسلسلة (string)، مثل اسم المستخدم، كلمة المرور أو البريد الإلكتروني. تتوقّع شفرتك البرمجية دومًا مُدخَلًا واحدًا من هذين الشكلين. في الأمثلة التي ذكرناها ببداية هذا المقال، كان المثال الأوّل عبارة عن سلسلة نصّية، وكان المثال الثاني عبارةً عن رقم. هناك أيضًا طريقتان لتنظيف البيانات: طريقة جيدة وطريقة سيئة. الطريقة السيئة هي التحقق من وجود حقن SQL الممكنة. السبب في كونها سيئة هو لأنّ عدد حقن SQL الممكن كبير جدًا، و"إبداع" المهاجمين واسع كذلك. الطريقة الجيّدة هي تنظيف البيانات للتعرّف على ما يبدو شكل الإدخال الصحيح عليه، وتجاهل كلّ شيء لا يتوافق مع شكل ذلك الإدخال الصحيح. البيانات الرقمية هي الأسهل للتنظيف، لذا سنقوم بتغطية هذا أوّلًا. يمكن للرقم أن يحتوي على إشارة سالبة على يساره، أو أن يكون متبوعا بأرقام أخرى، وربّما يحتوي على فاصلة عشرية. هذا كلّ ما يمكن للبيانات الرقمية أن تبدو عليه، في Perl، ستبدو الشفرة التي تتحقق من البيانات الرقمية كالتالي: if($numericaluserinput !~ /^-?[0-9.]+$/) { # البيانات المُدخلة ليست رقمًا } من الصعب تخيّل أيّ حقنة خبيثة يمكنها أن تتخطى ما سبق. تنظيف المُدخلات النصّية أكثر صعوبة، لأنّه هناك العديد من الطرق لمحاولة إدخالها. يمكن للمهاجم أن يستخدم إشارات الاقتباس وغيرها بطرق "إبداعية" للقيام بالهجمات. في الواقع، محاولة إنشاء قائمة سوداء للحروف المُدخلة هو أمرٌ سيّء، لأنّه من السهل نسيان شيء مهم مثلًا. هناك طريقة أفضل، كما قمنا مع البيانات الرقمية، وهي تقييد مُدخلات المستخدم إلى قائمة بيضاء من الحروف فقط. كمثال، عناوين البريد الإلكتروني لا يجب أن تحتوي على شيء سوى الأرقام والحروف العادية وبعض الإشارات مثل @ و _ وعدا ذلك، يجب منع كلّ الحروف الأخرى. في لغة Perl، ستبدو الشفرة كالتالي: if($useremail ~= /^[0-9a-zA-Z\-_+.\@]$/) { # the user's email address is unacceptable } يمكن العثور على قوائم بيضاء للأنواع الأخرى من المُدخلات كذلك مثل اسم المستخدم وكلمة المرور.. إلخ. قد تكون القوائم البيضاء مصدر إزعاج لبعض المستخدمين. فربّما يكون هناك رموز معيّنة في بعض مربّعات الإدخال تكون غير مقبولة من طرفها مثلًا، ولكنّك بالطبع حرّ لتقوم بتعديل القوائم البيضاء حسب حاجتك، ولكن لا تنسى أن تقوم ببحث عن الرموز والمحارف التي تريد تمكينها للتأكّد من أنّه لا يمكن استخدامها في حقن SQL، فعندما تختار بين حماية الموقع وراحة المستخدم، حماية الموقع تأتي أوّلًا. تنظيف المُدخلات بواسطة القوائم البيضاء جيّد لأنّه سهل. إذا كنتَ مُدركًا بشكل صحيح للرموز والمحارف التي تقوم بتمكينها، فحينها سيكون هذا الحلّ كافيًا للتخليص من هجمات حقن SQL. الخطوة الرابعة: قبول المدخلات الخطيرة لا تنخدع بالعنوان! سنتحدّث فقط عن أهمّية عدم قبول المُدخلات الخطيرة. صحيحٌ أنّ القوائم البيضاء شديدة التقييد جيّدة من أجل الحماية في حال ما إذا كان تطبيقك يستطيع أن يتوافق مع تلك التقييدات على المستخدمين. ولكن في بعض الحالات، قد يكون من المهمّ لنموذجك الربحي الخاصّ بالتطبيق ألّا تقوم بفرض أيّ تقييدات على مُدخلات المستخدمين. في هذه الحالة، غالبًا ما تكون لغة البرمجة التي تستعملها في تطبيقك تحوي على مكتباتٍ تساعدك في تنظيف مُدخلات المستخدمين من الشفرات الخبيثة. كمثال، مكتبة Perl DBI تحوي طُرقًا متعددة لمنع مُدخلات المستخدمين من التعامل مع استعلام SQL بخارج المنطقة المخصصة لها: my $sql = "INSERT INTO user (username, email) VALUES (?, ?)"; my $handle = $dbh->prepare( $sql ); $handle->execute( $untrustedusername, $untrustedemail); في المثال السابق، تمّ استخدام إشارة ؟ كعناصر نائبة (placeholders). تقوم مكتبة Perl DBI باستبدال هذه الإشارات بالمتغيّرات الغير موثوقة والتي تمّ إدخالها من طرف المستخدم. ولكن أثناء القيام بهذا، تقوم مكتبة DBI بتقييد هذه المتغيرات وتجعلها تتعامل فقط مع الحقول المخصصة لها بجدول قاعدة البيانات. هناك مكتبات مشابهة باللغات البرمجية الأخرى، إمّا لتقييد مُدخلات المستخدم، أو لتجاهل البيانات في حال حاولت التعامل مع خارج الحقل المخصص لها. ميّزة هذه التقنية هي أنّك قادرٌ على إعطاء ثقتك بالأشخاص المطورين لتلك المكتبات، حيث أنّهم سيقومون بتطويرها، والحفاظ عليها بعيدة عن الثغرات الأمنية والمشاكل الخطيرة. ولكن عيب هذه التقنية هي أنّها أقل قابلية للقراءة البشرية، وهكذا ربّما تنسى استخدام المكتبة الصحيحة لحماية بعض من عمليات استعلام SQL الخاصّة بك. الخطوة الخامسة: خفف ضرر الهجمات الناجحة اعتمادًا على ماهيّة نموذج الأعمال الذي تقوم به بموقعك، فربّما تودّ القيام بإنشاء خطٍّ أخير للدفاع، شيء مستقل تمامًا عن مطوري تطبيقك. فبعد كلّ شيء، ربّما يستخدم واحدٌ منهم القوائم البيضاء الخاطئة في مكان ما، أو فشل باستخدام المكتبة الصحيحة لتنظيف المُدخلات. ثغرة واحدة فقط من هذا النوع قد تسبب في تحويل موقعك بأكمله إلى موقع قابل للاختراق عبر هجمات SQL. أولًا، يجب عليك أن تفترض أنّ المهاجمين نجحوا باختراق دفاعاتك ضدّ حقن SQL، وأنّهم حصلوا على الصلاحيات الكاملة لإدارة خادومك. إنهم يملكون الآلة الآن بالكامل، على الرغم من أنّك من يهتم بصيانتها وتطويرها. لتجنّب ذلك السقوط المروع، يجب على الخادوم نفسه أن يكون مضبوطًا داخل بيئة معزولة عن الشبكة، حيث يكون مستخدم الجذر على النظام غير قادر على الرؤية أو الوصول إلى أيّ أجزاء أخرى موجودة على خادومك. هذا النوع من الدفاع يدعى DMZ، وهو رائع للغاية، وهو كذلك خارج نطاق هذا الدرس. مهما كانت الطريقة التي تستخدمها لتأمين خادومك ضدّ مستخدم مهاجم نجح بالدخول بالفعل، فإنّه يجب عليك أن تقوم بإعداد نظام تنبيهات يقوم بإخطار مدراء النظام في حال حصول نشاط معيّن على الخادوم. هذه التنبيهات ستخبرك ما إذا تمّ اختراق التطبيق، وأنّه عليك عمل مراجعة سريع للشفرة البرمجية وللخادوم نفسه. دون هذه التنبيهات، سيكون المهاجم قادرًا على قضاء وقتٍ ممتع في محاولة اختراق الـDMZ الخاصّ بك دون أن تشعر، وربّما لا تشعر بتاتًا بما يفعله إلى حين أن يسرق جميع البطاقات الائتمانية التي ظننت أنّها كانت معزولة تمامًا عن الخادوم، في بيئةً كنت تظن أنّها منفصلة عن خادومك الرئيسي. الخطوة السادسة: وظف محترف حماية إذا كنتَ تقوم بإدارة تطبيق ويب دون الاستعانة بخبير حماية، فحينها أنت تسبح بالمياه الخطيرة. وإذا كنت ولسبب ما غير قادر على توظيف خبير حماية وأمان، فإنّه يجب عليك الاستعانة بالقوائم البيضاء لتنظيف مُدخلات المستخدمين إلى حين. من السهل تضمين واستخدام القوائم البيضاء. لا بأس من تقييد تجرية المستخدمين قليلًا في سبيل حماية خادومك والبيانات الثمينة الموجودة عليه. وبمجرّد أن تقوم بتوظيف شخص يفهم في مجال الحماية والأمان، فستكون بعدها قادرًا بشكل أفضل على حماية موقعك من هجمات حقن SQL و XSS وغيرها من الهجمات الخطيرة التي قد تصيب موقعك. ترجمة -وبتصرف- للمقال: How To Secure a Cloud Server Against SQL Injection.

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.

سنناقش في هذا الدرس أهمّية تحديث كلّ شيءٍ متعلّق بموقع ووردبريس الخاصّ بك إلى آخر الإصدارات المتوفّرة وأهميّة التحديثات بشكلٍ عام، وهو من أهمّ الأمور التي يمكنك القيام بها لزيادة حماية وأمان موقعك. لماذا نقوم بالتحديث؟ السؤال الحقيقي يجب أن يكون "ولما لا"؟ يقوم مطوروا ووردبريس بإرسال التحديثات إلى المستخدمين لسببٍ معيّن في النهاية، حيث أنّ هذه التحديثات تحتوي على إصلاحاتٍ لثغراتٍ خطيرة يمكن أن يستغلها المهاجمون لمهاجمة موقعك، مما يجعل التحديث ضرورة لا مفرّ منها. أنواع التحديثات قبل أن نتابع، من المهمّ أن نفهم أنواع التحديثات المختلفة المتوفّرة في سكربت ووردبريس. يشير Tony Perez في تدوينة حديثة إلى أنّه هناك 3 أنواع مختلفة من التحديثات: تحديثات الأمان، الترقيعات والإصدارات الرئيسية. تحديثات الأمان هي بالضبط كما تبدو عليه من اسمها. يتم إصدارها بسرعة وتحتوي فقط على بضع إصلاحاتٍ لثغراتٍ موجودة تم اكتشافها مؤخرًا. تكون هذه التحديثات عادةً على شاكلة أرقام الإصدارات مثل 4.2.1. تحديثات الترقيعات أكبر قليلًا، لا تحتوي هي الأخرى على مميزاتٍ جديدة، ولكنّها تقوم بتحديث النظام وعادةً ما تتضمن تحديثاتٍ أمنية كذلك، كما أنّه يتم إصدارها بصفة دورية ومن الممكن توقّع وقت صدور الترقيع الجديد. وأمّا عن التحديثات الرئيسية من الانتقال من الإصدار 3.9 إلى الإصدار 4.0 فهذا تحديثٌ جوهري، يحتوي مميزاتٍ جديدة وإصلاحاتٍ للمشاكل الأمنية المعروفة بالإضافة لأمورٍ أخرى، كما أنّه يتم التدوين عنها في مدونة ووردبريس وفي العديد من المواقع الإخبارية الأخرى، حيث أنّها تحديثات كبيرة ويجب على الجميع معرفتها. قد تقوم هذه التحديثات أحيانًا بتحطيم شكل موقعك بسبب عدم توافقية مع القالب الذي تستخدمه مثلًا، ولكن مع وجود نسخة احتياطية من موقعك، فيجب ألّا تكون مشكلةً بالنسبة لك. الفشل بالتحديث يعني مشكلة أعظم كما ذكرنا سابقًا، عدم قيامك / فشلك بتحديث أيّ إضافات أو قوالب ووردبريس مثبّتة على موقعك قد يعرّضك لخطرٍ كبير، وما قد لا تفهمه هو "لماذا"؟ يمكن قول نفس الأمر بخصوص القوالب والإضافات، صحيحٌ أنّها ليست جزءً من لبّ نواة ووردبريس، ولكنّها أيضًا قد تحتوي على ثغرات تمكّن المخترقين من استغلالها لاختراق موقعك، وأيضًا يتم اكتشاف هذه الثغرات كلّ فترة وتصدر تحديثات لترقيعها كلّ فترة، وعليك تثبيتها بمجرّد توفّرها. بعض السمات والقوالب تكون مبرمجة بصورة سيئة ويكون بها العديد من الثغرات ويجب عليك الانتباه إلى ذلك، كما يجب عليك تثبيت واستخدام القوالب والإضافات التي تستعملها فقط وحذف كلّ شيء لا تستعمله. إدارة تحديثات ووردبريس أفضل طريقة للتأكّد من أنّ كلّ شيء على موقعك محدّث هو جعل عملية التحقق من وجود تحديثات متوفّرة هي مهمّة روتينية أخرى على جدولك (لو لم تكن تقنيًا، فيجب عليك البحث عن استضافة تقوم تلقائيًا بتحديث جميع القوالب والإضافات والنواة الخاصّة بووردبريس)، يجب عليك التحقق من توفّر التحديثات بنفسك كلّ يوم لتجنّب أي مشاكل أمنية قد تحصل. منذ الإصدار 3.7 من ووردبريس فإنّ المنصة تسمح بالتحديث التلقائي بسهولة، بمجرّد تفعيل هذا الخيار، فإنّه هذا يعني أنّ نواة موقعك ستقوم بالتحديث تلقائيًا عند توفّر تحديثات جديدة بدون أيّ تدخّل منك. طبعًا لا يمكن فعل نفس الشيء بالنسبة للقوالب والإضافات، حيث يجب عليك القيام بتحديثها يدويًا. الخاتمة تحديثات ووردبريس مهمّة للغاية، بل ومهمّة جدًا، ومن واجبك الاهتمام بتحديث كلّ شيءٍ موجود على موقعك إلى الإصدارات الأخيرة المتوفّرة، وإلّا فإنك تترك بابك مفتوحًا للمخترقين ليخترقوك، إنّها مسألة وقت. ترجمة -وبتصرف- للمقال: The WordPress Developer’s Guide to Security: Updates لصاحبه: Brenda Barron.

من المهم لمطورّي ووردبريس أن يكونوا على اطّلاعٍ على تقنيات الحماية والأمان عند تطوير مواقع تعمل بسكربت ووردبريس أو تصميم قوالب جاهزة له، سنبدأ سلسلة من 4 دروس حول هذا الموضوع وسيكون درسنا اليوم عن "التثبيت". هناك عدّة أمور مهمّة لتأخذها بعين الاعتبار لضمان أمانٍ أعلى لموقعك ومن بينها: اختيار الاستضافة المناسبة يبدأ موقع ووردبريس المؤمّن بشكلٍ مثالي من اختيار استضافة مناسبة لموقعك، فمن دون استضافة آمنة وجيّدة السمعة عالميًا، فإنّ جهودك في مجال تأمين موقعك العامِل بووردبريس قد تذهب أدراج الرياح. على الجانب التقني، بِما أنّ ووردبريس يستخدم PHP وMySQL، فإنّ أيّ استضافة تعمل بنظام لينكس ستكون مناسبة، ولكن من المنصوح أن تبتعد عن استضافة GoDaddy و Yahoo! ومثيلاتها حيث أنّ هذه الاستضافات مصممة لتكون بسيطة للغاية مما يجعلها مُقيّدة في بعض الأحيان، وهو ما يعني أنّه غير مجهّزة لأيّ شيء أكثر من موقع ووردبريس عادي بسيط. إذا كنتَ تريد القيام بتعديل بعض الإعدادات على الخادوم لتحسين إعدادات الأمان، فإنّ القيام بهذا قد يكون صعبًا على تلك الاستضافات المقيّدة. ينصح معظم خبراء الحماية باستخدام استضافاتٍ توفّر خواديمًا افتراضية خاصّة (VPS). وهو ما يستخدمه Tony Perez المدير التنفيذي لـSucuri: يستخدم Tony العديد من الأدوات على خادومه للحماية والأمان، هذه الأدوات تريه من يقوم بتسجيل الدخول إلى خادومه، من يقوم بالتعديل على المواضيع.. وهكذا، كما أنّ هذه الأدوات تقوم بعرض WHOIS، الـDNS ونشاط البرمجيات الخبيثة إن كانت موجودة، كلّ واحدٍ من هذه الأدوات مصمم ليراقب جزءًا معيّنا من جزئيات الحماية على الخادوم، بالإضافة إلى أمورٍ قد لا تخطر على بال المستخدمين العاديين. ينصح Tony باستخدام إضافة Sucuri Scanner لفحص مواقع الووردبريس للتأكّد من حمايتها، كما ينوّه إلى أنّه هناك العديد من الإضافات الأخرى التي يمكنك البحث عنها من على مخزن إضافات ووردبريس. مشكلة سكربتات التثبيت بنقرة واحدة توفّر العديد من شركات الاستضافة الآن القيام بعملية تثبيت ووردبريس "بنقرة واحدة"، وهو ما يسمح للمستخدمين العاديين أن يمتلكوا موقع ووردبريس بسرعة أكثر من السابق، ولكن بالطبّع، السرعة لها تكلفة. يمكنك في الواقع تغيير هذه البيانات بسهولة إن أردت -وهو ما سنتحدّث عنه لاحقًا- ولكن المشكلة هنا هي في الافتراضات التي يظنّها الناس عن عمليات التثبيت بنقرة واحدة بسبب شركات الاستضافة، فهم يظنون أنّها آمنة ومحميّة، لسوء الحظّ، فهي ليست كذلك، مما يجعل طريق التثبيت اليدوي أفضل بكثيرٍ للحماية. كيفية تثبيت ووردبريس إذا كنتَ لا تستخدم عملية التثبيت بنقرة واحدة، فإنّ القيام بتثبيت ووردبريس بالطريقة اليدوية على خادومك يجب أن يستغرق حوالي 10 دقائق. ستحتاج إلى فهم أساسيات عمل بروتوكول نقل الملفّات FTP وقواعد البيانات. هناك عدّة دروس على الويب حول هذا الموضوع من البداية إلى النهاية، ولكننا لن نذكر تفاصيلها الآن في هذا المقال. بمجرّد أن تقوم برفع كلّ ملفّاتك إلى موقعك وبمجرّد أن تقوم بإعداد قاعدة البيانات، سيتم توجيهك إلى إعداد اسم المستخدم وكلمة المرور الخاصّيَن بووردبريس، من المستحسن أن تقوم باختيار اسم مستخدمٍ معقّد ومن الصعب أن يتم تخمينه من قبل المخترقين لحمايةٍ أعلى. نفس الشيء بالنسبة لكلمة المرور الخاصّة بك، اجعلها معقّدة قدر الإمكان وأضف إليها الأرقام والرموز والأحرف الكبيرة، لا تتركها بسيطة فتصبح عُرضةً لهجمات التخمين بسهولة، كلّما كانت كلمة المرور أكثر تعقيدًا وطولًا، كلّما صعب تخمينها وكسرها. تغيير اسم المستخدم "Admin" تحدّثنا بالفعل عن أهميّة تجنّب اسم المستخدم "admin" ولماذا يجب عليك أن تختارَ اسمًا معقدًا، ولكن لنفرض أنّك قمتَ بالفعل بتثبيت موقع ووردبريس جديد منذ فترة واستخدمت اسم المستخدم "admin" فيه، فستحتاج تغييره يدويًا من phpMyAdmin. افتراضيًا، لا يسمح لك ووردبريس بتغيير اسم المستخدم، ولكن يمكنك إنشاء مستخدمٍ جديد إن أردت وإعطاؤه صلاحياتٍ إدارية كاملة وحذف المستخدم "admin" وإسناد الصفحات والمقالات التي أنشئتها بالمستخدم القديم إلى المستخدم الجديد، ولكن إذا كنتَ تمتلك الكثير من الصفحات والمقالات فربّما تريد القيام بالأمر يدويًا. للقيام بذلك، قم بالدخول إلى لوحة cPanel الخاصّة بك (على افتراض أنّك تمتلك واحدة!) ثمّ ابحث عن phpMyAdmin وقم بفتحها، بعد هذا، ابحث عن قاعدة البيانات الخاصّة بموقعك وابحث عن جدول wp_users ضمنها. ابحث عن المستخدم "admin" واصغط على زر "Edit" أو تحرير بجانبه لتعديل اسم المستخدم، قم بتبديل الاسم واحفظه. بعد هذا، سيتم تلقائيًا تغيير اسم المستخدم في جميع أنحاء موقعك إلى الاسم الجديد ولن تحتاج إلى حذف شيء. الخاتمة في معظم الأحيان، يعتقد الناس أنّ أمان ووردبريس هو مسألة يمكن حلّها عبر إضافة ووردبريس، صحيحٌ أنّ هذا جزءٌ مهم من المعادلة ولكنّه ليس كلّ شيء، حيث أنّك تحتاج تأمين كلّ شيء منذ البداية. في الدرس القادم سنتطرق إلى كيفية تأمين ووردبريس بعد تثبيته عبر تأمين تسجيل الدخول إلى المنصة. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Installation لصاحبته Brenda Barron.

إحدى أبسط الطرق لزيادة حماية موقعك هي عن طريق اختيار اسم مخصص لحساب مدير ووردبريس (admin/super admin). ففي هذه الحالة سيواجه القراصنة بعض الصعوبات في الوصول إلى حسابك عن طريق صفحة wp-login.php لأنه يجب عليهم تخمين اسم المستخدم، وهذا سيخلق خطوة إضافية لأنهم لن يقتصروا على تخمين كلمة المرور فقط. ماذا لو لم تغيّر اسم مستخدم مدير موقعك عند إنشائك لموقعك أو شبكتك؟ في هذا الدرس سنريك كيف تغيّر اسم المستخدم سواء ثبّتت ووردبريس بشكل منفرد أو متعدد عن طريق تغيير بسيط في قاعدة بياناتك. إيجاد اسم قاعدة بياناتك بما أننا في حاجة إلى القيام ببعض التغييرات في قاعدة بياناتك، ستحتاج إلى الحصول على اسمها أوّلًا، يمكنك فعل ذلك بالتحقق من ملف wp-config.php في جذر ملفات ووردبريس. في cPanel، اختر زر File Manager تحت قسم Files، فإذا ظهرت نافذة File Manager Directory Selection المنبثقة، اختر خيار Web Root أو Document Root لموقعك من قائمة الخيارات. اختر ملف wp-config.php وانقر على زر Edit في أعلى الصفحة، ابحث عن شيفرة برمجية مشابه لهذه: // ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define('DB_NAME', 'your_db'); /** MySQL database username */ define('DB_USER', 'yourusername'); /** MySQL database password */ define('DB_PASSWORD', 'this-is-your-password'); /** MySQL hostname */ define('DB_HOST', 'localhost'); /** Database Charset to use in creating database tables. */ define('DB_CHARSET', 'utf8'); سيظهر اسم قاعدة البيانات في السطر الثالث في مكان your_db. في cPanel، انقر على زر phpMyAdmin تحت Databases في الصفحة الرئيسية، ثم اختر قاعدة بياناتك من القائمة على اليسار ثم حدد جدول wp_users. انقر عليه وابحث عن اسم مستخدم المدير (admin) في القائمة. انقر على زر Edit لإضافة القيم إلى خيارات الجدول، غيّر اسم المستخدم (استبدله بالاسم الجديد) في جميع الحقول التي تعرض الاسم القديم. على أقل تقدير ستحتاج إلى تعديل حقل user_login لتغيير اسم المستخدم، وإذا أردت تغيير كيفية عرض اسم المستخدم على الواجهة الأمامية لموقعك فغيّر حقل display_name. يحتوي حقل user_nicename على الاسم الذي سيظهر في الرابط في أماكن مثل صفحة أرشفة الكاتب، يجب أن لا يحتوي ما ستكتبه هنا على فراغات وسيكون في الغالب نفس اسم المستخدم الذي تسجل دخولك به، لكن في حالات التي لا يبدو فيها الاسم سهل القراءة مثل "HeartPrintedUnderpants23"، يمكنك اختيار اسم مختلف للظهور في الروابط. حالما تنتهي، احفظ التغييرات التي قمت بها. في أسفل خيارات الجدول، سترى مجموعة من صناديق القوائم المنسدلة، اختر Save في الأول و Go back to previous page في الثاني ثم انقر على Go لحفظ تغييراتك. بعد أن تنتهي من هذه التغييرات ستكون قد غيّرت اسم مستخدمك ويمكنك استخدامه لتسجيل دخولك، أما لو كنت تستخدم مجموعة من المواقع، فتوجد خطوات إضافية أخرى تحتاج إلى إنهائها. استبدال اسم مدير النظام على Wordpress Multisite لتغيير مستخدم المدير (super admin) لشبكتك، أنهِ أولا الخطوات السابقة، وعندما تنتهي منها عُد إلى قائمة جداول قاعدة البيانات وابحث عن جدول wp_sitemeta. انقر عليها لتظهر جميع خيارات الجدول، عندما يتم تحميلها، ابحث عن صف site_admins أسفل عمود meta_key. انقر على زر Edit على يسار ذلك الصف، ثم، غيّر القيم لمستخدم المدير في حقل meta_value. ستحتاج إلى تغيير أمرين: اسم المستخدم ثم قيمة عدد أحرف اسم مستخدمك. a:1:{i:0;s:5:"admin";} في المثال أعلاه، يظهر اسم المستخدم الافتراضي، لذلك يجب عليك أن تغيّر admin والرقم 5 الذي يظهر قبل الاسم والذي يمثل عدد حروف الاسم. سيكون الرقم مختلفًا لو كان اسم المستخدم أطول من 5 أحرف، وقد تختلف meta_value أيضا إذا كنت تمتلك صلاحيات أخرى مرتبطة بحساب المدير، وفي هذه الحالة، ابحث عن نفس القيم في الشيفرة البرمجية. إذا أردت تغيير اسم المستخدم على سبيل المثال إلى"HeartPrintedUnderpants23"، فيجب تغيير القيم لتبدوا كالتالي: a:1:{i:0;s:24:"HeartPrintedUnderpants23";} تم تغيير اسم المستخدم إلى الاسم الجديد كما تم تغيير الرقم 5 إلى 24 ليعكس عدد الأحرف في اسم المستخدم الجديد. إذا أعجبك اسم المستخدم الجديد، انقر على Go في الأسفل لحفظ التغييرات التي قمت بها. الخاتمة إذا اتبعت الخطوات السابقة فستكون قد غيّرت اسم مستخدمك الافتراضي إلى اسم آخر عن طريق عمل بعض التغييرات البسيطة على قاعدة البيانات. وبهذه الطريقة أصبح اختراق موقعك أكثر صعوبة على القراصنة، لكن ليس هذا هو التغيير الوحيد الذي يجب عليك القيام به لزيادة مستوى أمان موقعك. توجد طريقة أخرى لا تتطلب القيام بتغييرات على قاعدة البيانات، فيمكنك إنشاء مستخدم جديد ومن ثم أعطه صلاحيات المدير وفي النهاية احذف حساب المدير الأصلي. لكن انتبه من بعض الملحقات التي تطلب صلاحيات إضافية ولا يمكنك تحديدها عند إنشائك لحساب مدير جديد، لذلك فإن تغيير اسم المستخدم من قاعدة البيانات كما شرحنا في درسنا هذا هو أفضل حل. ما خيارك المفضل لتغيير اسم مستخدم المدير في موقعك؟ وهل جربت تغييره؟ انضم إلى المحادثة وشاركنا خبرتك في التعليقات أسفله. ترجمة -وبتصرف- للمقال: How to Change Your WordPress Admin Username لصاحبه Jenni McKinnon

أحيانًا تكون على شبكة غير آمنة أو لديها جدار ناري يملك قيودًا مُفرطة، وتحتاج الوصول إلى موقع على شبكة الإنترنت. تريد أن تتأكد أنه لا أحد في المنتصف يشاهد البيانات المارة. أحد الحلول هو استخدام 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.

سنتطرق في هذا الدّرس إلى كيفية تطبيق حماية أساسيّة لخادوم Redis. على الرغم من هذا، عليك تذكر بأن Redis قد صُمّم أساسا للاستخدام من طرف مستخدمين موثوقين على بيئة موثوقة، بدون أي مميزات أمنيّة خاصة به. لفهم هذه النّقطة أكثر إليك اقتباسا من الموقع الرسمي لـredis: بشكل عام، Redis ليس مُحسّنا لحماية قصوى بل لأداء عالي وبساطة فائقة. الأداء والبساطة بلا حماية بمثابة وصفة لكارثة. حتى مميّزات الحماية القليلة لدى Redis ليست ممتازة، وتشمل كلمة مرور بسيطة غير مُشفّرة، إعادة تسميّة الأوامر وتعطيلها. وتفتقر إلى نظام حقيقي للتحكم بالولوج. على الرغم من هذا، فإن ضبط هذه الخصائص الأمنيّة يبقى خطوة كبيرة إلى الأمام وأفضل من ترك قاعدة بياناتك بدون حماية. ستقرأ في هذا الدّرس كيفيّة ضبط الخصائص الأمنيّة القليلة التي يمتلكها Redis، وبعض الخصائص الأمنية الأخرى للنظام ما سيزيد من نسبة الحماية لخادوم Redis مُستقل على Ubuntu 14.04. ننوّه إلى أن هذا الدرس لا يتحدث عن حالات وجود كل من خادوم Redis وتطبيقات العملاء على استضافات مختلفة أو مراكز بيانات مختلفة. أو الحالات التي يجب على الاتصال بـ Redis أن يقطع شبكات غير آمنة أو غير موثوقة تتطلب نوعا مختلفا من الإعداد، مثل ضبط SSL proxy أو VPN بين خواديم Redis ، إضافة إلى الخطوات المذكورة هنا. المتطلبات ستحتاج في هذا الدّرس: خادوم Ubuntu مع مستخدم sudo مُضَاف، انظر درس الإعداد الابتدائي لخادوم أوبنتو 14.04 جدار ناري iptables معدّ باستخدام الدرس كيف تنفذ نموذجا للجدار الناري باستعمال Iptables إلى غاية خطوة "تحديث nameservers" (إذا لم تقم بإعداد جزء الخادوم nameserver فالـAPT لن يعمل). Redis مُثبت وقيد التنفيذ باستعمال الخطوات في الموضحة في الدرس كيفية تنصيب واستخدام Redis على أوبنتو. الخطوة الأولى، التأكد من أن Redis قيد التشغيل أولاً ادخل إلى الخادوم باستعمال SSH: ssh username@server-ip-address username: اسم المستخدم server-ip-address: عنوان IP الخاص بالخادوم للتأكد من أنّ Redis قيد التنفيذ، استعمل سطر الأوامر الخاص ب Redis .يُستعمل الأمر redis-cli للوصول إلى سطر أوامر Redis. redis-cli إذا سبق وأن أعددت كلمة مرور لـ Redis، فيجب عليك الاستيثاق بالأمر auth بعد الاتّصال: auth كلمة_المرور المخرج سيكون كلمة OK اختبر خادوم قاعدة البيانات: ping الرّد: PONG اُخرج: quit الخطوة الثانية، حماية الخادوم بـاستخدام Iptables إذا اتّبعت المُتطلّبات من أجل ضبط Iptables، فلك كامل الحريّة في تخطّي هذه الخطوة، أو يُمكنك القيام بذلك الآن. Redis مجرّد تطبيق يُنفّذ على خادومك، ولأنه لا يملك أي خصائص أمنيّة خاصة، فإنّ أول خطوة لحمايته حقيقة تكمن في حماية الخادوم الذي يُشغل منه. في حالة خادوم موجّه للعامة كخادومك Ubuntu 14.04، فإن ضبط جدار ناريّ كما هو مبيّن في درس Iptables يُعتبر الخطوة الأولى لذلك. اتّبع ذلك الرّابط واضبط جدارا ناريّا الآن. إذا طبّقت أحكام الجدار النّاري باستعمال ذلك الدّرس، فلن تحتاج لإضافة قاعدة أخرى لـ Redis، افتراضيّاً، إن أي مرور traffic يُمنَع إلّا عند السّماح له صراحةً. وبما أن خادوم Redis افتراضيّا يستمع على واجهة الاسترجاع (loopback (127.0.0.1 أو localhost، فلا يجب القلق حول المرور عبر المنفذ الافتراضي. إذا كنت تحتاج للسّماح لعنوان IP للوصول خصّيصا لـ Redis، يُمكنك التحقق من العنوان الذي يستمع منه Redis، وعلى أي منفذ باستخدام أمر grep لمُخرجات الأمر netstat. العمود الرّابع 127.0.0.1:6379 يطلعنا على عنوان IP والمنفذ المرتبطين بـ Redis: sudo netstat -plunt | grep -i redis المخرجات: tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 8562/redis-server 1 تأكّد من أن هذا العنوان مسموح له في الجدار النّاري. للمزيد من المعلومات عن كيفيّة إضافة الأحكام، اطّلع رجاء على درس أساسيّات Iptables. الخطوة الثالثة، الربط إلى المضيف المحلي localhost افتراضيًّا، يُمكن الوصول إلى خادوم Redis من المضيف المحليّ، على أي حال، إذا اتّبعت درس ضبط Redis على خادوم متبوع/سيّد فقد حدّثت ملفّ الإعدادات للسّماح للاتّصالات من أي مكان. وهذا ليس آمنا كالربط إلى المُضيف المحليّ. افتح ملفّ إعدادات Redis للتّعديل: sudo nano /etc/redis/redis.conf ابحث عن هذا السّطر وتأكّد من أنه ليس على شكل تعليق (احذف الرّمز # إذا كان موجودا): bind 127.0.0.1 سنستمرّ في استعمال هذا الملفّ، لذلك أبقه مفتوحا الآن. الخطوة الرابعة، ضبط كلمة مرور لـ Redis إذا ثبتت Redis باتّباع درس كيف تضبط خواديم Redis متعددة على أوبنتو 14.04 فيجب عليك أن تكون قد ضبطت كلمة مرور مُسبقا، يُمكنك أن تضع كلمة مرور أكثر أمانا باتّباع هذا القسم الآن، وهذه الخطوات تعرض كيفية وضع كلمة مرور لخادوم قاعدة البيانات. ضبط كلمة مرور لـ Redis يفعّل إحدى ميزتي الحماية المُضمّنة في Redis، وهو الأمر auth، الذي يطلُب من العملاء الاستيثاق للوصول إلى قاعدة البيانات. تُضبَطُ كلمة المرور مُباشرة في ملف الإعدادات etc/redis/redis.conf/ الذي يجب أن تكون قد فتحته منذ الخطوة الماضيّة. اذهب عن قسم SECURITY وابحث عن سطر مُعلّق بالرمز # كالتّالي: # requirepass foobared أزل التّعليق عن السّطر بحذف الرمز #، وغيّر foobared إلى كلمة مرور قويّة وطويلة. عوضاً عن الإتيان بكلمة مرور من عندك، يمكنك استعمال أداة مثل apg و pwgen لتوليد واحدة. إذا لم تكن ترغب بتثبيت أداة فقط لتوليد كلمة مرور، يُمكنك استخدام السطر التّالي. لتوليد كلمة مرور مُختلفة عن هذا المثال غير القيمة بداخل علامتي التنصيص: echo "hsoub-academy" | sha256sum المُخرج سيبدو كالتّالي: e118c2b8fa805fbd0a6af458ab7df9fea14881b87c2e793b4a2192cda30bf8d5 لكنّ كلمة المرور المولّدة لن تكون منطوقة، وهي قويّة وطويلة وهو تماما المطلوب لحماية Redis. بعد نسخ ولصق مُخرج هذا الأمر كقيمة جديدة لـ requirepass، يجب أن تكون كالتّالي: requirepass 960c3dac4fa81b4204779fd16ad7c954f95942876b9c4fb1a255667a9dbe389d إذا كنت تُفضّلُ كلمة مرور أقصر، استخدم مُخرج الأمر التالي عوضا عنها. غيّر القيمة بين علامتي التنصيص لكي لا تولّد نفس كلمة المرور: echo "hsoub-academy" | sha1sum المخرج سيكون أقصر هذه المرّة: 773a12cfe8616ff740258f8843c567f32227ac0f بعد ضبط كلمة المرور، احفظ الملفّ وأعد تشغيل Redis : sudo service redis-server restart لاختبار عمل كلمة المرور، حاول الوصول إلى سطر أوامر Redis : redis-cli السطر التالي يعرض سلسلة من الأوامر المُستعملة لاختبار ما إذا كانت كلمة المرور تعمل أو لا، الأمر الأول يُحاول إعطاء قيمة لمفتاح قبل القيام بالاستيثاق: set key1 10 الأمر لن يعمل، لذلك فإنك سترى خطأ في المخرجات: (error) NOAUTH Authentication required. الأمر الثاني يقوم بالاستيثاق بكلمة المرور التي وضعناها في ملفّ إعدادات Redis. auth your_redis_password سيُوافق Redis في الحال: OK بعد هذا، تنجح إعادة تنفيذ الأمر السّابق. set key1 10 المُخرج: OK الأمر get key1 يطلب من Redis قيمة المفتاح الجديد: get key1 المُخرج: “10” الأمر الأخير يقوم بإنهاء سطر الأوامر redis-cli. ويمكنك أيضاً استخدام exit: quit تالياّ، سننظر إلى إعادة تسميّة أوامر Redis. الخطوة الخامسة، إعادة تسمية الأوامر الخطرة الخاصيّة الأمنيّة الأخرى المبنيّة داخل Redis تُخوّل لك إعادة تسميّة أو تعطيل أوامر معيّنة والتّي تُعتبر أوامر خطيرة. عند تشغيل مستخدمين غير مُخولين لأوامر معينّة فقد تُستخدم هذه الأوامر لإعادة ضبط، أو تدمير أو حذف بياناتك. ومثل كلمة مرور الاستيثاق،فإن إعادة تسمية الأوامر أو تعطيلها تتم في نفس قسم SECURITY من الملفّ etc/redis/redis.conf/. بعض الأوامر المعروف أنها خطيرة هي: FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME و DEBUG وهذه القائمة ليست شاملة، لكنّ إعادة تسميّتها أو تعطيلها كلّها يُعتبر نقطة بداية جيّدة. تعطيل أو إعادة تسميّة أمر يعتمد على مدى استعمالك للأمر، فمثلاً إذا كنت تعلم أنّك لن تستعمل أبدا أمرا يُمكن أن يُستَغلّ سلبيّاً، فمن المستحسن أن تُعطّله، عدا ذلك فمن الأفضل إعادة التّسميّة. لتشغيل أو تعطيل أمر ما، افتح ملفّ الإعدادات للتحرير مرة أخرى: sudo nano /etc/redis/redis.conf هذه بعض الأمثلة فقط. ويجب عليك أن تعيد تسميّة أو تعطّل الأوامر بما يُناسبك. يُمكنك التحقق من الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands. لتعطيل أو إيقاف أمر ما، فقط أعد تسميّتها إلى قيمة فارغة كما هو مبيّن أسفله: # It is also possible to completely kill a command by renaming it into # an empty string: # rename-command FLUSHDB "" rename-command FLUSHALL "" rename-command DEBUG "" وعند إعادة تسميّة أمر ما، عيّن اسما آخر كقيمة، كما في الأمثلة أسفله. الأوامر المعاد تسميّتها يجب أن تكون صعبة التخمين، وفي نفس الوقت سهلة التذكر بالنسبة لك.ولا تجعلها صعبة عليك. rename-command CONFIG "" rename-command SHUTDOWN SHUTDOWN_MENOT rename-command CONFIG ASC12_CONFIG بعد إعادة التّسميّة، طبّق التعديلات بإعادة تشغيل Redis: sudo service redis-server restart لاختبار الأمر الجديد، ادخل إلى سطر أوامر Redis: redis-cli بعد ذلك، على افتراض بأنّك قمت بإعادة تسميّة الأمر CONFIG إلى ASC12_CONFIG، المُخرج التّالي يوضح كيفيّة التأكد من أنّ الأمر الجديد يعمل. بعد الاستيثاق: auth your_redis_password المُخرج: OK يجب أن تكون مُحاولة استخدام الأمر config باسمه الأصلي فاشلة، لأنّنا بالطبع قمنا بإعادة تسميّتها: config get requirepass المُخرج": (error) ERR unknown command 'config' مناداة الأمر باسمه الجديد سيعمل (وهو غير حسّاس لحالة الأحرف): asc12_config get requirepass المُخرج: 1) "requirepass" 2) "your_redis_password" أخيرا، يمكنك الخروج من redis-cli: exit ملاحظة: إذا كنت تستخدم مسبقا سطر الأوامر Redis ثم أعدت تشغيل Redis، سيتوجب عليك إعادة الاستيثاق. إن لم تقوم بذلك، ستحصل على هذا الخطأ عند كتابة أمر ما: NOAUTH Authentication required. على الرغم من إعادة تسميّتك للأوامر، فهناك جملة تحذيريّة في آخر قسم SECURITY على ملفّ etc/redis/redis.conf/ تقول: هذا يعني أنّه إذا لم يكن الأمر المعاد تسميّته داخل ملفّ AOF، أو إذا كان موجودا لكنّ ملفّ AOF لم يُحَلْ إلى التّوابع، فلا يجب أن يكون هناك أي مُشكلة. لذلك تذكّر عند محاولة تغيير أسماء الأوامر، أفضل وقت لإعادة تسميّة أمر هو عند عدم استخدام AOF، أو مباشرة بعد التثبيت أي قبل نشر التطبيق المُستعمِل لـ Redis. عندما تستخدم AOF وعند التّعامل مع نظام تابع-متبوع، ضع في بالك هذه الإجابة من صفحة المسائل في المشروع على Github. الاقتباس التّالي هو جواب على سؤال الكاتب: لذلك فإن أفضل طريقة للتعامل مع إعادة التسمية في حالات كهذه هي أن تتأكّد من أنّ إعادة تسميّة الأوامر مطبّقة في جميع الخوادم في أنظمة تابع-متبوع. الخطوة السادسة، ضبط مجلد البيانات وصلاحيات المستخدم للملفات في هذه الخطوة، سوف نعرض بعض تعديلات المالك والصلاحيّات التّي يُمكنك القيّام لها لزيّادة حماية Redis. يتمثّل هذا في التأكد من أنّ المُستخدم الذي يحتاج إلى الوصول إلى Redis فقط يملك صلاحيّات قراءة البيانات. هذا المُستخدم افتراضيّا هو المُستخدم redis. يُمكنك التحقق من هذا باستخدام أداة grep مع الأمر ls لرؤية معلومات عن المُجلّد الأب لمجلّد بيانات Redis. الأمر والمُخرجات أسفله. ls -l /var/lib | grep redis المُخرج: drwxr-xr-x 2 redis redis 4096 Aug 6 09:32 redis يُمكنك ملاحظة بأن مجلّد بيانات Redis مملوك من طرف المُستخدم Redis، مع وصول ثانوي للمجموعة redis. وهذا أمر جيّد. الأمر السيئ هو صلاحيّات الوصول إلى المُجلّد، أي 755. للتأكد من أن المُستخدم redis هو فقط من يمتلك حقّ الوصول إلى المجلد ومُحتوياته، غيّر الصلاحية إلى 700: sudo chmod 700 /var/lib/redis الصلاحيّة الأخرى التّي عليك تغييرها هي الخاصّة بملفّ إعدادات Redis. يمتلك افتراضيّا صلاحيّة 644 ومملوك للمُستخدم الجذر root، مع مالك ثانوي يتمثّل في مجموعة الجذر root group: ls -l /etc/redis/redis.conf المُخرج: -rw-r--r-- 1 root root 30176 Jan 14 2014 /etc/redis/redis.conf هذه الصّلاحيّة (644) تعني مقروء من الكل، والتي تعتبر فكرة سيّئة لأن ذلك الملف يحتوي على كلمة المرور غير المُشفرة التّي وضعناها في الخطوة الرّابعة. نحتاج إلى تغيير المالك والصّلاحيّات. يجبُ أن تكون مملوكة للمُستخدم redis مع مجموعة الجذر كمالك ثانوي، لفعل ذلك، شغّل الأمر التّالي: sudo chown redis:root /etc/redis/redis.conf بعد ذلك غيّر المالك لكي يتمكّن مالك الملفّ فقط من قراءته أو/و الكتابة عليه: sudo chmod 600 /etc/redis/redis.conf يُمكنك التحقّق من المالك الجديد والصّلاحيّات باستخدام الأمر: ls -l /etc/redis/redis.conf المُخرج: total 40 -rw------- 1 redis root 29716 Sep 22 18:32 /etc/redis/redis.conf في الأخير، أعد تشغيل Redis: sudo service redis-server restart خاتمة تذكّر بأنه عند دخول أي شخص إلى خادومك، فمن السّهل التحايل على خصائص Redis الأمنيّة التي قمنا بضبطها. لذلك فإنّ أكثر خاصيّة أمنيّة هي التي تجعل من تجاوز هذا الحاجز صعبا قدر المُستطاع. أي خاصيّة الجدار النّاري. للتّقدّم بحماية خادومك إلى المستوى التّالي، فعليك ضبط نظام كشف تطفّل مثل OSSEC. إذا كنت تريد حماية تواصل Redis عبر شبكات غير آمنة فعليك توظيف SSL proxy، كما هو منصوح به من مطوّري Redis على دليل حمايةRedis الرسمي. وضبط SSL proxy لحماية تواصل Redis فهو موضوع آخر. لم نتطرّق إلى قائمة شاملة من أوامر Redis بقسم إعادة التّسميّة، لكنّك تستطيع إلقاء نظرة على مجموعة الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands. ترجمة -بتصرّف- للمقال How To Secure Your Redis Installation on Ubuntu 14.04 لصاحبه finid.

من المهم لمطورّي ووردبريس أن يكونوا على اطّلاعٍ على تقنيات الحماية والأمان عند تطوير مواقع تعمل بسكربت ووردبريس أو تصميم قوالب جاهزة له، سنبدأ سلسلة من 4 دروس حول هذا الموضوع وسيكون درسنا اليوم عن "التثبيت". هناك عدّة أمور مهمّة لتأخذها بعين الاعتبار لضمان أمانٍ أعلى لموقعك ومن بينها: اختيار الاستضافة المناسبةيبدأ موقع ووردبريس المؤمّن بشكلٍ مثالي من اختيار استضافة مناسبة لموقعك، فمن دون استضافة آمنة وجيّدة السمعة عالميًا، فإنّ جهودك في مجال تأمين موقعك العامِل بووردبريس قد تذهب أدراج الرياح. على الجانب التقني، بِما أنّ ووردبريس يستخدم PHP وMySQL، فإنّ أيّ استضافة تعمل بنظام لينكس ستكون مناسبة، ولكن من المنصوح أن تبتعد عن استضافة GoDaddy و Yahoo! ومثيلاتها حيث أنّ هذه الاستضافات مصممة لتكون بسيطة للغاية مما يجعلها مُقيّدة في بعض الأحيان، وهو ما يعني أنّه غير مجهّزة لأيّ شيء أكثر من موقع ووردبريس عادي بسيط. إذا كنتَ تريد القيام بتعديل بعض الإعدادات على الخادوم لتحسين إعدادات الأمان، فإنّ القيام بهذا قد يكون صعبًا على تلك الاستضافات المقيّدة. ينصح معظم خبراء الحماية باستخدام استضافاتٍ توفّر خواديمًا افتراضية خاصّة (VPS). وهو ما يستخدمه Tony Perez المدير التنفيذي لـSucuri: يستخدم Tony العديد من الأدوات على خادومه للحماية والأمان، هذه الأدوات تريه من يقوم بتسجيل الدخول إلى خادومه، من يقوم بالتعديل على المواضيع.. وهكذا، كما أنّ هذه الأدوات تقوم بعرض WHOIS، الـDNS ونشاط البرمجيات الخبيثة إن كانت موجودة، كلّ واحدٍ من هذه الأدوات مصمم ليراقب جزءًا معيّنا من جزئيات الحماية على الخادوم، بالإضافة إلى أمورٍ قد لا تخطر على بال المستخدمين العاديين. ينصح Tony باستخدام إضافة Sucuri Scanner لفحص مواقع الووردبريس للتأكّد من حمايتها، كما ينوّه إلى أنّه هناك العديد من الإضافات الأخرى التي يمكنك البحث عنها من على مخزن إضافات ووردبريس. مشكلة سكربتات التثبيت بنقرة واحدةتوفّر العديد من شركات الاستضافة الآن القيام بعملية تثبيت ووردبريس "بنقرة واحدة"، وهو ما يسمح للمستخدمين العاديين أن يمتلكوا موقع ووردبريس بسرعة أكثر من السابق، ولكن بالطبّع، السرعة لها تكلفة. يمكنك في الواقع تغيير هذه البيانات بسهولة إن أردت -وهو ما سنتحدّث عنه لاحقًا- ولكن المشكلة هنا هي في الافتراضات التي يظنّها الناس عن عمليات التثبيت بنقرة واحدة بسبب شركات الاستضافة، فهم يظنون أنّها آمنة ومحميّة، لسوء الحظّ، فهي ليست كذلك، مما يجعل طريق التثبيت اليدوي أفضل بكثيرٍ للحماية. كيفية تثبيت ووردبريسإذا كنتَ لا تستخدم عملية التثبيت بنقرة واحدة، فإنّ القيام بتثبيت ووردبريس بالطريقة اليدوية على خادومك يجب أن يستغرق حوالي 10 دقائق. ستحتاج إلى فهم أساسيات عمل بروتوكول نقل الملفّات FTP وقواعد البيانات. هناك عدّة دروس على الويب حول هذا الموضوع من البداية إلى النهاية، ولكننا لن نذكر تفاصيلها الآن في هذا المقال. بمجرّد أن تقوم برفع كلّ ملفّاتك إلى موقعك وبمجرّد أن تقوم بإعداد قاعدة البيانات، سيتم توجيهك إلى إعداد اسم المستخدم وكلمة المرور الخاصّيَن بووردبريس، من المستحسن أن تقوم باختيار اسم مستخدمٍ معقّد ومن الصعب أن يتم تخمينه من قبل المخترقين لحمايةٍ أعلى. نفس الشيء بالنسبة لكلمة المرور الخاصّة بك، اجعلها معقّدة قدر الإمكان وأضف إليها الأرقام والرموز والأحرف الكبيرة، لا تتركها بسيطة فتصبح عُرضةً لهجمات التخمين بسهولة، كلّما كانت كلمة المرور أكثر تعقيدًا وطولًا، كلّما صعب تخمينها وكسرها. تغيير اسم المستخدم "Admin"تحدّثنا بالفعل عن أهميّة تجنّب اسم المستخدم "admin" ولماذا يجب عليك أن تختارَ اسمًا معقدًا، ولكن لنفرض أنّك قمتَ بالفعل بتثبيت موقع ووردبريس جديد منذ فترة واستخدمت اسم المستخدم "admin" فيه، فستحتاج تغييره يدويًا من phpMyAdmin. افتراضيًا، لا يسمح لك ووردبريس بتغيير اسم المستخدم، ولكن يمكنك إنشاء مستخدمٍ جديد إن أردت وإعطاؤه صلاحياتٍ إدارية كاملة وحذف المستخدم "admin" وإسناد الصفحات والمقالات التي أنشئتها بالمستخدم القديم إلى المستخدم الجديد، ولكن إذا كنتَ تمتلك الكثير من الصفحات والمقالات فربّما تريد القيام بالأمر يدويًا. للقيام بذلك، قم بالدخول إلى لوحة cPanel الخاصّة بك (على افتراض أنّك تمتلك واحدة!) ثمّ ابحث عن phpMyAdmin وقم بفتحها، بعد هذا، ابحث عن قاعدة البيانات الخاصّة بموقعك وابحث عن جدول wp_users ضمنها. ابحث عن المستخدم "admin" واصغط على زر "Edit" أو تحرير بجانبه لتعديل اسم المستخدم، قم بتبديل الاسم واحفظه. بعد هذا، سيتم تلقائيًا تغيير اسم المستخدم في جميع أنحاء موقعك إلى الاسم الجديد ولن تحتاج إلى حذف شيء. الخاتمةفي معظم الأحيان، يعتقد الناس أنّ أمان ووردبريس هو مسألة يمكن حلّها عبر إضافة ووردبريس، صحيحٌ أنّ هذا جزءٌ مهم من المعادلة ولكنّه ليس كلّ شيء، حيث أنّك تحتاج تأمين كلّ شيء منذ البداية. في الدرس القادم سنتطرق إلى كيفية تأمين ووردبريس بعد تثبيته عبر تأمين تسجيل الدخول إلى المنصة. ترجمة -وبتصرف- للمقال The WordPress Developer’s Guide to Security: Installation لصاحبته Brenda Barron.

يجب أن تضع الحماية نصب عينيّك عند تثبيت ونشر واستخدام أي نوع من أنظمة تشغيل الحاسوب؛ وعلى الرغم من أن تثبيتًا حديثًا لأوبنتو هو آمن نسبيًا للاستخدام الفوري على الإنترنت، لكن من المهم أن يكون لديك فهم متوازن لحالة حماية أنظمتك بناءً على طريقة استخدامها بعد «نشرها» (deployment). يزودك هذا الدرس بلمحة عن المواضيع المرتبطة بالحماية المتعلقة بنسخة خادوم أوبنتو 14.04، ويخط الخطوط العريضة للإجراءات التي يمكنك أن تستخدمها لحماية خادومك وشبكتك من أي عدد من التهديدات الأمنية المحتملة. إدارة المستخدمينإدارة المستخدمين هي جزء جوهري في الحفاظ على نظامٍ آمن؛ تقود الإدارة غير الكفء للمستخدمين والامتيازات عادةً إلى إضعاف أمان النظام؛ وبالتالي من الضروري أن تفهم كيف تحميه باستخدام تقنيات إدارة حسابات المستخدمين. أين هو حساب الجذر؟اتخذ مطورو أوبنتو قرارًا واعيًا بتعطيل حساب الجذر الإداري افتراضيًا في جميع حالات تثبيت أوبنتو؛ هذا لا يعني أن حساب الجذر محذوفٌ أو لا يمكن الوصول إليه، حيث أُسنِدَت إليه ببساطة كلمة مرور لا تُطابِق أيّة قيمة؛ أي أنك لا تستطيع الدخول إليه مباشرةً. لكن بدلًا من ذلك، يُحَثّ المستخدمون أن يستخدموا أداةً باسم sudo لتنفيذ مهام إدارة النظام؛ حيث تسمح sudo لمستخدم موثوق بترقية امتيازاته باستخدام كلمة مروره بدلًا من الحاجة لمعرفة كلمة المرور الخاصة بحساب الجذر. هذه الطريقة البسيطة تعطي المسؤولية لجميع أفعال المستخدم، وتمنح مدير النظام تحكمًا بالأفعال التي يستطيع القيام بها مع امتيازاته الحالية. إذا أردت تفعيل حساب الجذر لسبب ما، فببساطة أسند كلمة مرور لذاك الحساب: sudo passwdستطلب منك أداة sudo كلمة مرورك، ثم ستطلب منك توفير كلمة مرور جديدة لحساب الجذر كما هو موضح هنا: [sudo] password for username: (enter your own password) Enter new UNIX password: (enter a new password for root) Retype new UNIX password: (repeat new password for root) passwd: password updated successfullyاستخدم الأمر passwd بهذه الطريقة لتعطيل كلمة مرور حساب الجذر: sudo passwd -l rootلكن إذا أردت تعطيل الحساب نفسه، فاستخدم الأمر الآتي: usermod --expiredate 1تستطيع التعلم أكثر عن sudo بالنظر إلى صفحة الدليل المتعلقة بهذا الأمر: man sudoينتمي المستخدم الذي أُنشِئ أثناء تثبيت أوبنتو افتراضيًا إلى المجموعة «sudo» المُضافة إلى ملف ‎/etc/sudoers كمستخدم sudo موثوق؛ إذا رغبت بمنح أيّ حساب آخر امتيازات الجذر كاملةً عبر sudo، فأضف ذاك الحساب إلى المجموعة sudo. إضافة وحذف المستخدمينعملية إدارة المستخدمين المحليين والمجموعات هي عملية بسيطة ومباشرة ولا تختلف إلا قليلًا بين أغلبية أنظمة تشغيل غنو/لينُكس الأخرى؛ تحث أوبنتو، والتوزيعات المبنية على دبيان، على استخدام الحزمة «adduser» لإدارة الحسابات. لإضافة حساب مستخدم جديد، استخدم الشكل العام الآتي، وأكمل مع الرسائل التي تطلب منك إعطاء كلمة مرور للحساب، وتعريف بعض الخاصيات مثل الاسم الكامل ورقم الهاتف ...إلخ. sudo adduser usernameاستخدم الأمر الآتي لحذف مستخدم ومجموعته الرئيسية: sudo deluser usernameلا يؤدي حذف حساب مستخدم إلى حذف مجلد المنزل الموافق له؛ هذا يعود لك إن كنت تريد أو لا تريد حذف المجلد يدويًا أو الإبقاء عليه وفقًا لسياساتك. تذكر أن أي مستخدم آخر يُضاف لاحقًا بنفس معرفَيّ UID/GID للمستخدم القديم سيحصل على وصول كامل لهذا المجلد إذا لم تتخذ الاحتياطات اللازمة. قد ترغب بتغيير قيم UID/GID إلى قيم أخرى ملائمة أكثر -كحساب الجذر مثلًا- وربما تريد أيضًا نقل المجلد لتفادي التضاربات المستقبلية: sudo chown -R root:root /home/username/ sudo mkdir /home/archived_users/ sudo mv /home/username /home/archived_users/لكي تقفل حساب مستخدم مؤقتًا أو تلغي قفله، فاستخدم الأمر passwd مع الخيارات الموافقة للعملية التي تريد إجراءها كما يلي (على التوالي وبالترتيب): sudo passwd -l username sudo passwd -u usernameلإضافة أو حذف مجموعة خاصة، فاستخدم الأمرين الآتيين على التوالي وبالترتيب: sudo addgroup groupname sudo delgroup groupnameاستخدم الشكل الآتي من أمر adduser لإضافة مستخدم إلى مجموعة: sudo adduser username groupnameأمن حساب المستخدمعندما يُنشأ مستخدمٌ جديد، فستُنشِئ الأداة adduser مجلد منزل جديد باسم ‎/home/username، يتشكل ملف الحساب (profile) الافتراضي اعتمادًا على المحتويات الموجودة في مجلد ‎/etc/skel الذي يحتوي على أساسيات ضبط الحساب. إذا كان سيحتوي خادومك على عدّة مستخدمين، فيجب أن تولي أذونات مجلد المنزل للمستخدم اهتمامًا شديدًا لتحقيق سرية بياناته؛ افتراضيًّا، مجلدات منزل المستخدم في أوبنتو تُنشَأ بأذونات القراءة والتنفيذ؛ هذا يعني أن كل المستخدمين يستطيعون الوصول والتجول في محتويات مجلدات المنزل للمستخدمين الآخرين، ربما لا يلائم ذلك احتياجات بيئة تشغيل نظامك. استخدم الأمر الآتي للتأكد من أذونات مجلد المنزل للمستخدمين الحاليين: ls -ld /home/usernameيُظهِر الناتج الآتي أن مجلد ‎/home/username لديه أذن القراءة لجميع المستخدمين (العالم أو world): drwxr-xr-x 2 username username 4096 2007-10-02 20:03 usernameتستطيع إزالة أذن القراءة للجميع بتنفيذ الأمر: sudo chmod 0750 /home/usernameملاحظة: بعض الأشخاص يميلون لاستخدام الخيار التعاودي (‎-R‏ [recursive]) دومًا دون تمييز الحالات التي يجب استخدامه فيها، الذي يُعدِّل أذونات المجلدات «الأبناء» والملفات التي فيها، لكن هذا ليس ضروريًا، وربما يتسبب ببعض النتائج غير المرغوب بها؛ يكفي تعديل أذونات المجلد «الأب» فقط لمنع المستخدمين غير المصرَّح لهم بدخول أي شيء داخل هذا المجلد الأب. طريقة أخرى أكثر فعاليةً هي تعديل ضبط الأذونات الافتراضية العام للأداة adduser عند إنشاء مجلدات المنزل للمستخدمين الجدد؛ عدِّل ببساطة الملف ‎/etc/adduser.conf وغيِّر قيمة المتغير DIR_MODE إلى قيمةٍ مناسبةٍ، حيث ستحصل جميع مجلدات المنزل الجديدة على الأذونات الصحيحة: DIR_MODE=0750بعد تصحيح أذونات المجلد باستخدام إحدى الطرق السابق ذكرها، فتأكد من النتائج بالأمر: ls -ld /home/usernameالنتائج الآتية تُظهِر أنه قد أُزيل إذن القراءة لجميع المستخدمين: drwxr-x--- 2 username username 4096 2007-10-02 20:03 usernameسياسة كلمة المرورأحد أهم الجوانب في حماية نظامك هو استخدام سياسة قوية لكلمات المرور؛ إذ تتطلب العديد من الاختراقات الأمنية الناجحة استخدام هجمات «القوة القاسية» (brute force) وتخمين كلمات المرور الضعيفة من القاموس؛ إذا كنت تنوي توفير أي نوع من التحكم البعيد الذي يتطلب كلمة المرور المحلية للنظام، فتأكد أنك تحقق المتطلبات الدنيا من تعقيد كلمات المرور، ومدة كلمة المرور الدنيا، والتدقيق الرتيب لأنظمة الاستيثاق عندك. طول كلمة المرور الدنياتتطلب أوبنتو افتراضيًا طولًا أصغريًا لكلمة المرور يساوي ستة محارف، يمكن التحكم بهذه القيمة في ملف ‎/etc/pam.d/common-password الظاهر هنا: password [success=2 default=ignore] pam_unix.so obscure sha512إذا أردت تغيير الحد الأدنى لطول كملة المرور إلى ثمانية محارف، فعدِّل المتغير الملائم إلى min=8؛ كما يلي: password [success=2 default=ignore] pam_unix.so obscure sha512 min=8ملاحظة: التحقق البسيط من كلمة المرور، والطول الأدنى لها لا يُطبَّق على الأوامر المُنفَّذة باستخدام sudo لإعداد مستخدم جديد. مدة صلاحية كلمة المرورعند إنشاء حسابات للمستخدمين، فيجب أن تُنشِئ سياسة لعمر كلمة المرور الأدنى والأقصى وإجبار المستخدمين على تغيير كلمات مرورهم عندما تنتهي مدتها. استخدم الأمر الآتي لعرض حالة حساب مستخدم: sudo chage -l usernameيُظهِر ناتج الأمر السابق حقائق مثيرة للاهتمام حول حساب المستخدم، ولنفترض أنه لا توجد أيّة سياسات مطبَّقة: Last password change : Jan 20, 2008 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7استخدم الأمر الآتي ببساطة وتابع مع الرسائل التفاعلية لضبط أيّة قيمة من هذه القيم: sudo chage usernameما يلي مثالٌ لطريقة تغيير تاريخ انتهاء الصلاحية (‎-E) إلى 01/31/2008، والعمر الأدنى لكلمة المرور (‎-m) إلى 5 أيام، والعمر الأقصى لكلمة المرور (‎-M) إلى 90 يومًا، ومدة الخمول (inactivity، الخيار ‎-I) إلى 5 أيام بعد انتهاء صلاحية كلمة المرور، ومدة وقت التحذير (‎-W) إلى 14 يومًا قبل انتهاء صلاحية كلمة المرور. sudo chage -E 01/31/2008 -m 5 -M 90 -I 5 -W 14 usernameللتأكد من التعديلات، استخدم نفس الأمر المذكور آنفًا: sudo chage -l usernameيجب أن يُظهِر الناتج السياسات الجديدة التي أعددناها لهذا الحساب: Last password change : Jan 20, 2008 Password expires : Apr 19, 2008 Password inactive : May 19, 2008 Account expires : Jan 31, 2008 Minimum number of days between password change : 5 Maximum number of days between password change : 90 Number of days of warning before password expires : 14اعتبارات أمنية أخرىتستخدم العديد من التطبيقات آليات استيثاق أخرى يمكن أن يغفلها حتى مدراء الأنظمة الخبراء؛ وبالتالي فمن المهم فهم والتحكم في طريقة استيثاق المستخدمين وحصولهم على الوصول إلى الخدمات والتطبيقات على خادومك. وصول SSH من المستخدمين المعطلينلا يمنع تعطيل حساب مستخدم من دخوله إلى خادومك عن بعد إن كان قد ضبط استيثاق بمفتاح RSA عام؛ وسيتمكنون من الحصول على وصول إلى الصدفة (shell) في الخادوم دون الحاجة لأيّة كلمة مرور؛ تذكر أن تتحقق من مجلد المنزل للمستخدمين الذي يسمحون بهذا النوع من وصول SSH الذي تم الاستيثاق منه؛ أي ‎/home/username/.ssh/authroized_keys. احذف أو أعد تسمية مجلد ‎.ssh/‎ في مجلد المنزل للمستخدم لتعطيل إمكانيات الاستيثاق عبر SSH. تأكد أن تتحقق من أيّة اتصالات SSH قد أُنشِئت من المستخدم المعطَّل؛ حيث من الممكن أن يملكوا اتصالات داخلة أو خارجة موجودة مسبقًا، «اقتل» (kill) تلك العمليات إذا عثرت عليها. who | grep username # to get the pts/X terminal sudo pkill -f pts/Xاحصر الوصول عبر SSH إلى حسابات المستخدمين الذين يجب أن يحصلوا عليها فقط؛ فعلى سبيل المثال، ربما تنُشِئ مجموعة تسميها «sshlogin» وتضيف اسم المجموعة كقيمة مرتبطة بالمتغير AllowGroups الموجود في الملف ‎/etc/ssh/sshd_config. AllowGroups sshloginثم أضف مستخدمي SSH المسموح لهم إلى المجموعة «sshlogin»، وأعد تشغيل خدمة SSH: sudo adduser username sshlogin sudo service ssh restartاستيثاق المستخدم بقواعد البيانات الخارجيةتتطلب معظم الشبكات المشاريع التجارية آليةَ استيثاقٍ مركزية والتحكم بالوصول إلى جميع مصادر النظام، إذا ضبطت خادومك ليستوثق من المستخدمين من قاعدة بيانات خارجية؛ فتأكد من تعطيل حسابات المستخدمين محليًا وخارجيًا، وبهذا تتأكد من أن البديل المحلي للاستيثاق غير متوفر. تأمين الطرفيةوكما غيرها من ترسانة الحماية التي تستخدمها لحماية خادومك، من القواعد الصارمة هو التأمين ضد الأضرار الناتجة عن شخص لديه الوصول الفيزيائي لبيئتك، على سبيل المثال، سرقة الأقراص الصلبة، أو خلل في الطاقة الكهربائية ...إلخ؛ وبالتالي يجب أن يكون تأمين الطرفية جزءًا رئيسيًا في استراتيجية الحماية الفيزيائية؛ سيحد «قفل الشاشة» (screen door) من تأثير مجرم عادي، أو على الأقل سيبطئ عمل مجرم مصمم على إلحاق الأذى بنظامك! لذلك من المستحسن إجراء بعض احتياطات الوقاية فيما يتعلق بحماية الطرفية. سيساعدك ما يلي في الدفاع عن خادومك ضد المشاكل التي قد تسبب عواقب وخيمة. تعطيل Ctrl+Alt+Deleteبادئ ذي بدء، يستطيع أي شخص لديه الوصول الفيزيائي للوحة المفاتيح ببساطة أن يستخدم تجميعة المفاتيح «Ctrl+Alt+Delete» لإعادة إقلاع الخادوم دون الحاجة لتسجيل الدخول؛ طبعًا يمكن لأي شخص إزالة كبل الكهرباء من المقبس، لكن ما يزال عليك منع استخدام هذه التجميعة على خادوم إنتاجي؛ وهذا يجبر المهاجم على اتخاذ إجراءات عنيفة لإعادة إقلاع الخادوم، وسوف يمنع إعادة الإقلاع غير المقصودة في نفس الوقت. لتعطيل إعادة إقلاع الخادوم بالضغط على تجميع الأزرار Ctrl+Alt+Delete، فضع رمز التعليق قبل السطر الآتي في ملف ‎/etc/init/control-alt-delete.conf: #exec shutdown -r now "Control-Alt-Delete pressed"ترجمة -وبتصرف- للمقال Ubuntu Server Guide: User Management.

إن AppArmor هو وحدة حماية في لينُكس تقيّد وصول البرامج المختلفة إلى قائمة بالملفات التابعة لها والإمكانيات المذكورة في مسودة posix 1003.le. إن AppArmor مثبَّت ومفعَّل افتراضيًا، ويستخدم «ملفات ضبط» (profiles) للتطبيقات لتحديد أيّة ملفات وأذونات يتطلبها التطبيق، بعض الحزم تُثبِّت ملفات الضبط الخاصة بها، ويمكن العثور على ملفات ضبط إضافية في حزمة apparmor-profiles. أدخل الأمر الآتي في الطرفية لتثبيت حزمة apparmor-profiles: sudo apt-get install apparmor-profilesلملفات ضبط AppArmor نمطين من التنفيذ: البناء أو التعلم (Complaining/Learning): من المسموح تجاوز ملف الضبط وستُسجَّل تلك التجاوزات؛ يفيد هذا النمط في اختبار وتطوير ملفات ضبط جديدة.الإجبار أو التقييد (Enforced/Confined): إجبار السياسة في ملفات الضبط، وتسجيل التجاوزات أيضًا. استخدام AppArmorتنويه: هذا القسم معلول بعلِّة1، فللأسف لن تعمل الأوامر التي فيه كما يجب. تحتوي حزمة apparmor-utils على أدوات سطر أوامر تمكِّنك من تغيير نمط تنفيذ AppArmor، أو معرفة حالة ملف ضبط، أو إنشاء ملفات جديدة ...إلخ. يُستخدَم الأمر apparmor_status لعرض حالة ملفات ضبط AppArmor. sudo apparmor_statusيضع الأمر aa-complain ملفَ ضبطٍ قيدَ البناء: sudo aa-complain /path/to/binالأمر aa-enforce يضعُ ملفَ ضبطٍ قيدَ التنفيذ: sudo aa-enforce /path/to/binالمجلد ‎/etc/apparmor.d هو مكان تواجد ملفات ضبط AppArmor؛ يمكن أن يُستخدَم لتعديل «نمط» جميع ملفات الضبط. أدخِل ما يلي لوضع كل الملفات في نمط البناء: sudo aa-complain /etc/apparmor.d/*لوضع جميع الملفات قيد التنفيذ: sudo aa-enforce /etc/apparmor.d/*يُستخدَم الأمر apparmor_parser لتحميل ملف ضبط إلى النواة، ويمكن أن يُستخدَم لإعادة تحميل ملف ضبط مُحمَّل مسبقًا باستخدام الخيار ‎-r؛ لتحميل ملف ضبط: cat /etc/apparmor.d/profile.name | sudo apparmor_parser -aولإعادة تحميل ملف ضبط محمَّل مسبقًا: cat /etc/apparmor.d/profile.name | sudo apparmor_parser -rيمكن استخدام ‎service apparmor لإعادة تحميل كل ملفات الضبط: sudo service apparmor reloadيمكن استخدام المجلد ‎/etc/apparmor.d/disable مع الخيار ‎‎apparmor_parser‏ ‎‎-R لتعطيل ملف ضبط: sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/ sudo apparmor_parser -R /etc/apparmor.d/profile.nameلإعادة تفعيل ملف ضبط معطَّل، احذف الوصلة الرمزية إلى الملف في ‎/etc/apparmor.d/disable ثم أعد تحميل ملف الضبط باستخدام الخيار ‎-a: sudo rm /etc/apparmor.d/disable/profile.name cat /etc/apparmor.d/profile.name | sudo apparmor_parser -aيمكن تعطيل AppArmor، وسيزال تحميل وحدة النواة بإدخال ما يلي: sudo service apparmor stop sudo update-rc.d -f apparmor removeلإعادة تفعيل AppArmor، أدخِل: sudo service apparmor start sudo update-rc.d apparmor defaultsملاحظة: استبدل profile.name باسم ملف الضبط الذي تريد تعديله، أيضًا استبدل ‎/path/to/bin بمسار الملف التنفيذي الحقيقي؛ على سبيل المثال، للأمر ping استخدم ‎/bin/ping. ملفات الضبطملفات الضبط (profiles) هي ملفات نصية بسيطة موجودة في ‎/etc/apparmor.d/‎؛ هذه الملفات مسماةٌ وفقًا للمسار الكامل للملف التنفيذي الذي تضبطه لكن مع إبدال «‎/» بنقطة «.»؛ على سبيل المثال، ‎/etc/apparmor.d/bin.ping هو ملف ضبط AppArmor للأمر ‎/bin/ping. هنالك نوعان رئيسيان من القواعد المستخدمة في ملفات الضبط: قيود المسار (Path entries): التي تحدد الملفات التي يمكن للتطبيق الوصول إليها في نظام الملفات.قيود الإمكانيات (Capability entries): تحدد الامتيازات التي يُسمَح لعملية مقيدة بإجرائها.ألقِ نظرةً على ‎/etc/apparmor.d/bin.ping كمثال: #include <tunables/global> /bin/ping flags=(complain) { #include <abstractions/base> #include <abstractions/consoles> #include <abstractions/nameservice> capability net_raw, capability setuid, network inet raw, /bin/ping mixr, /etc/modules.conf r, }‎#include <tunables/global>‎: تضمين تعبيرات من ملفات أخرى، وهذا يسمح للعبارات المشتركة بين عدّة تطبيقات بالتواجد في ملف مشترك.(‎/bin/ping flags=(complain: المسار إلى التطبيق صاحب ملف الضبط، وضبط النمط إلى complain.capability net_raw,‎: السماح للتطبيق بالوصول إلى امتياز CAP_NET_RAW Posix.le.‎/bin/ping mixr,‎: السماح للتطبيق بوصول القراءة والتنفيذ إلى الملف.ملاحظة: يجب إعادة تحميل ملف الضبط بعد تعديله، راجع القسم «استخدام AppArmor» للتفاصيل. إنشاء ملف ضبط1. صمم خطة اختبار: فكر كيف يمكن «تمرين» التطبيق؛ يجب أن تُقسَّم خطة الاختبار إلى حالات اختبار صغيرة، وكل حالة اختبار لها شرح صغير وقائمة بالخطوات التي يجب اتباعها. بعض حالات الاختبار القياسية هي: بدء تشغيل البرنامج.إيقاف البرنامج.إعادة تحميل البرنامج.اختبار جميع الأوامر المدعومة من سكربت init.2. توليد ملف الضبط الجديد: استخدم aa-genprof لتوليد ملف ضبط جديد؛ من الطرفية: sudo aa-genprof exectableعلى سبيل المثال: sudo aa-genprof slapd3. لكي يُضمَّن ملف الضبط الجديد الخاص بك في حزمة apparmor-profiles، فبلِّغ عن علة في Lanuchpad2 عن حزمة AppArmor: ضمِّن خطة الاختبار وحالات الاختبار.أضف ملف الضبط الجديد إلى العلة.تحديث ملفات الضبطعندما لا يعمل برنامج ما كما يجب؛ فافحص الرسائل التي تُرسَل إلى ملفات السجل؛ يمكن أن يُستخدَم البرنامج aa-logprof لفحص ملفات السجل لرسائل التدقيق الخاصة ببرنامج AppArmor؛ راجعها وحدِّث ملفات الضبط. sudo aa-logprofمصادرراجع «AppArmor Administraion Guide» لإعدادات الضبط المتقدمة.للتفاصيل حول استخدام AppArmor مع إصدارات أخرى من أوبنتو، فراجع صفحة ويكي المجتمع حول AppArmor.صفحة «OpenSUSE AppArmor» هي تقديم آخر إلى AppArmor.مكان رائع للسؤال حول المساعدة في AppArmor، والاندماج مع مجتمع خواديم أوبنتو هو قناة ‎ ‎#ubuntu-server على خادوم Freenode (شبكة IRC).ترجمة -وبتصرف- للمقال Ubuntu Server Guide: AppArmor.

تتضمن نواة لينُكس النظام الفرعي Netfilter الذي يُستخدَم لتعديل أو تحديد مصير البيانات الشبكية الداخلة أو الخارجة من الخادوم، تَستخدم جميع الجدر النارية في لينُكس هذا النظام لترشيح الرزم الشبكية. نظام ترشيح الرزم الخاص بالنواة لن يكون مفيدًا لمدراء الأنظمة دون واجهة لإدارته، وهذا هو الغرض من iptables؛ فعندما تصل رزمة شبكية إلى خادومك، فستتوجه إلى النظام الفرعي Netfilter للموافقة أو التعديل أو الرفض بناءً على القواعد الموفَّرة لها من المستخدم عبر iptables؛ ولهذا سيكون iptables هو كل ما تحتاج لإدارة الجدار الناري إن كان مألوفًا لديك، لكن العديد من الواجهات المتوفرة له ستُبسِّط العملية. الجدار الناري ufw‏أداة ضبط الجدار الناري الافتراضية في أوبنتو هي ufw، التي طُوِّرَت لتسهيل ضبط جدار iptables الناري، توفر ufw واجهة «صديقة» للمستخدم لإنشاء جدار ناري لعناوين IPv4 أو IPv6. إن ufw معطَّل افتراضيًّا. من صفحة دليل man ufw: هذه بعض أمثلة استخدام ufw: أولًا، يجب أن نفعِّل ufw، أدخِل الأمر الآتي في الطرفية: sudo ufw enableلفتح منفذ ما (ssh في هذا المثال): sudo ufw allow 22وبشكلٍ مشابه، لإغلاق منفذ مفتوح: sudo ufw deny 22لحذف قاعدة، استخدم الكلمة delete متبوعةً بالقاعدة: sudo ufw delete deny 22من الممكن أيضًا السماح بالوصول من مضيفين أو شبكات محددة لمنفذٍ ما؛ يسمح المثال الآتي بالوصول لمنفذ ssh من المضيف 192.168.0.2 لأي عنوان IP في هذا المضيف: sudo ufw allow proto tcp from 192.168.0.2 to any port 22يمكن استخدام 192.168.0.0/24 بدلًا من 192.168.0.2 للسماح بالوصول عبر ssh لكامل الشبكة الفرعية. إضافة الخيار ‎--dry-run لأمر ufw سيجعله يخرج القواعد الناتجة، لكنه لن يطبقها؛ على سبيل المثال، ما يلي هو ما سيحدث لو فتحنا منفذ HTTP: sudo ufw --dry-run allow http*filter :ufw-user-input - [0:0] :ufw-user-output - [0:0] :ufw-user-forward - [0:0] :ufw-user-limit - [0:0] :ufw-user-limit-accept - [0:0] ### RULES ### ### tuple ### allow tcp 80 0.0.0.0/0 any 0.0.0.0/0 -A ufw-user-input -p tcp --dport 80 -j ACCEPT ### END RULES ### -A ufw-user-input -j RETURN -A ufw-user-output -j RETURN -A ufw-user-forward -j RETURN -A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT]: " -A ufw-user-limit -j REJECT -A ufw-user-limit-accept -j ACCEPT COMMIT Rules updatedيمكن تعطيل ufw بالأمر: sudo ufw disableأدخل الأمر لمعرفة حالة الجدار الناري: sudo ufw statusلمعلومات تفصيلية عن حالة الجدار الناري، استخدم: sudo ufw status verboseلعرض أرقام بجوار القواعد (لحذفها مثلًا) فاستخدم الكلمة المحجوزة numbered: sudo ufw status numberedملاحظة: إن كان المنفذ الذي تريد فتحه أو إغلاقه معرفًا في ‎/etc/services، فيمكنك استخدام اسم المنفذ بدلًا من رقمه؛ حيث استبدل 22 بالكلمة ssh في الأمثلة السابقة. هذه مجرد مقدمة سريعة عن استخدام ufw، رجاءً راجع صفحة دليل ufw لمزيد من المعلومات. دمج التطبيقات مع ufwتستطيع التطبيقات التي تفتح منافذ أن تُضمِّن ملف ufw الذي يبيّن أيّة منافذ يحتاج التطبيق لفتحها لكي يعمل عملًا تامًا؛ هذه الملفات موجودة في ‎/etc/ufw/applications.d ويمكن أن تُعدَّل إذا تغيَّرت المنافذ الافتراضية. استخدم الأمر الآتي في الطرفية لعرض التطبيقات التي ثبتت أحد تلك الملفات: sudo ufw app listوبشكل شبيه للسماح بالاتصالات إلى منفذ معين، فيُفعَّل استخدام ملف ضبط أحد التطبيقات بالأمر: sudo ufw allow Sambaيمكن استخدام التعبير المُوسَّع كالآتي: ufw allow from 192.168.0.0/24 to any app Sambaاستبدل «Samba» و 192.168.0.0/24 باسم التطبيق ومجال IP لشبكتك. ملاحظة: لا توجد هنالك حاجة لتحديد البروتوكول للبرنامج الذي ستُفعِّله، لأن هذه المعلومات مفصَّلة بالملف الخاص به، لاحظ أن اسم التطبيق يستبدل رقم المنفذ. لعرض معلومات حول المنافذ والبروتوكولات (...إلخ.) المُعرَّفة لتطبيقٍ ما، فأدخِل الأمر: sudo ufw app info Sambaليس لكل التطبيقات التي تتطلب فتح منفذ شبكي ملف ufw خاص؛ إذا كتبت ذاك الملف لتطبيق ما، وأردت أن يُضمَّن هذا الملف مع الحزمة، فرجاءً بلِّغ عن علة في تلك الحزمة على Lanuchpad: ubuntu-bug nameofpackageتنكر IPالغاية من تنكر IP‏ (IP Masquerading) هو السماح للأجهزة التي تملك IP خاص غير قابل للتوجيه في شبكتك بالوصول إلى الإنترنت عبر الجهاز الذي يقوم بالتنكر؛ يجب أن تُعالَج البيانات الشبكية من شبكتك الخاصة إلى الإنترنت لكي توجَّه الردود إلى الجهاز الذي قام بالطلب، ويجب أن تُعدِّل النواة قيمة عنوان IP المصدر لكل رزمة شبكية لكي تصبح قابلة للتوجيه إلى الخادوم، بدلًا من عنوان IP الخاص (private IP) الذي قام بالطلب، الذي يكون مستحيلًا عبر الإنترنت؛ يستخدم لينُكس تعقب الاتصال (conntrack) لكي يتعقب أيّة اتصالات تتعلق بأيّة أجهزة وإعادة توجيه كل رزمة مُعادة وفقًا لذلك؛ أي أن البيانات الشبكية الخارجة من شبكتك المحلية هي «مُتنكِّرة» ﻷنها تنشأ من البوابة (خادومك)؛ يُشار إلى هذه العملية في توثيق مايكروسوفت باسم «مشاركة اتصال الإنترنت» (Internet Connection Sharing). تنكر ufwيمكن أن يجرى تنكر IP بقواعد ufw مخصصة؛ هذا ممكن لأن السند الخلفي للأداة ufw هو iptables-restore مع ملفات القواعد المخزنة في ‎/etc/ufw/*.rules؛ هذه الملفات هي مكان ممتاز لإضافة قواعد iptables بدون ufw، وللقواعد التي تتعلق تعلقًا كبيرًا بالبوابات الشبكية أو الجسور. تُقسَّم القواعد إلى ملفين مختلفين، القواعد التي يجب أن تُنَفَّذ قبل القواعد السطرية التابعة للأداة ufw، والقواعد التي تُنفَّذ بعدها. أولًا، يجب أن يُفعَّل تمرير الرزم في ufw، يجب أن يُعدَّل ملفي إعدادات؛ غيِّر قيمة DEFAULT_FORWARD_POLICY إلى "ACCEPT" في ملف ‎/etc/default/ufw: DEFAULT_FORWARD_POLICY="ACCEPT"ثم عدِّل الملف ‎/etc/ufw/sysctl.conf وأزل التعليق عن: net/ipv4/ip_forward=1وبشكل مشابه، لتمرير IPv6 أزل التعليق عن: net/ipv6/conf/default/forwarding=1سنضيف الآن القواعد إلى ملف ‎/etc/ufw/before.rules؛ القواعد الافتراضية تضبط جدول filter فقط، ويجب ضبط جدول nat لتفعيل التنكر؛ أضف ما يلي إلى أعلى الملف بعد تعليقات الترويسة مباشرةً: # nat Table rules *nat :POSTROUTING ACCEPT [0:0] # Forward traffic from eth1 through eth0. -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE # don't delete the 'COMMIT' line or these nat table rules won't be processed COMMITليست التعليقات ضروريةً، لكنها من المستحسن توثيق ملفات الضبط؛ وعند تعديل أي من ملفات «القواعد» في ‎/etc/ufw، فتأكد من أن هذين السطرين موجودان في نهاية الملف لكل جدول عدَّلته: # don't delete the 'COMMIT' line or these nat table rules won't be processed COMMITيجب أن تتوفر عبارة COMMIT في نهاية كل جدول، وقد ظهر في الأمثلة السابقة جدولا nat و filter فقط، لكنك تستطيع إضافة القواعد لجدولَيّ raw و mangle. ملاحظة: استبدل-في المثال السابق- eth0 و eth1 و 192.168.0.0/24 بالبطاقات ومجال IP الملائمين. في النهاية، عطِّل وأعد تفعيل ufw لتطبيق التغيرات: sudo ufw disable && sudo ufw enableيجب أن يُفعَّل تنكر IP الآن، تستطيع إضافة أية قواعد FORWARD إضافية إلى ملف ‎/etc/ufw/before.rules؛ من المستحسن إضافة هذه القواعد في سلسلة ufw-before-forward. تنكر iptablesيمكن أن يُستخدَم iptables لتفعيل التنكر. وبشكل شبيه للأداة ufw، أول خطوة هي تفعيل تمرير IPv4 بتعديل ملف ‎/etc/sysctl.conf وإزالة التعليق عن السطر الآتي: net.ipv4.ip_forward=1إذا أردت تفعيل تمرير IPv6، فأزل التعليق عن: net.ipv6.conf.default.forwarding=1تاليًا، نفِّذ الأمر sysctl لتفعيل الإعدادات الجديدة في ملف الضبط: sudo sysctl -pيمكن أن يُفعَّل تنكر IP بقاعدة iptables واحدة، التي يمكن أن تختلف اختلافًا بسيطًا بناءً على ضبط شبكتك: sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADEيفترض الأمر السابق أن مجال شبكتك الخاصة هو 192.168.0.0/16 وأن الجهاز الذي يمتلك اتصالًا بالإنترنت هو ppp0، نستطيع تقسيم الأمر السابق كما يلي: ‎-t nat: القاعدة ستذهب لجدول nat.‎-A POSTROUTING: ستُضاف القاعدة (‎-A) إلى سلسلة POSTROUTING.‎-s 192.168.0.0/16: تطبَّق القاعدة على البيانات الآتية من مجال العناوين المحدد.‎-o ppp0: القاعدة تُطبَّق على البيانات المقرر توجيهها عبر الجهاز الشبكي المحدد.‎-j MASQUERADE: ستقفز (jump) البيانات المُطابِقة لهذه القاعدة إلى هدف MASQUERADE لكي تُعالَج كما هو مشروح في الأعلى.أيضًا، كل سلسلة في جدول filter (الجدول الافتراضي، ومكان حدوث أغلبية ترشيح الرزم الشبكية) تكون سياستها الافتراضية هي ACCEPT؛ لكن إن كنت تُنشِئ جدارًا ناريًا بالإضافة إلى بوابة، فربما تحتاج إلى ضبط السياسات إلى DROP أو REJECT؛ وفي هذه الحالة تحتاج البيانات المتنكرة إلى السماح لها في سلسلة FORWARD لكي تعمل القاعدة السابقة: sudo iptables -A FORWARD -s 192.168.0.0/16 -o ppp0 -j ACCEPT sudo iptables -A FORWARD -d 192.168.0.0/16 -m state \ --state ESTABLISHED,RELATED -i ppp0 -j ACCEPTستسمح الأوامر السابقة لجميع الاتصالات من شبكتك المحلية إلى الإنترنت، ولعودة البيانات المتعلقة بهذه الاتصالات إلى الجهاز الذي طلبها. إذا أردت تفعيل التنكر عند الإقلاع -الذي تريد تفعيله في غالب الأحيان- فعدِّل ملف ‎/etc/rc.local وأضف الأوامر السابقة؛ على سبيل المثال، أضف الأمر السابق دون ترشيح: iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADEالسجلات Logsسجلات الجدار الناري مهمة جدًا للتعرف على الهجمات، واستكشاف أخطاء قواعد الجدار الناري، وملاحظة النشاط غير الطبيعي في شبكتك؛ يجب أن تضمِّن قواعد للتسجيل في جدارك الناري لكي تولَّد السجلات، ويجب أن تأتي قواعد السجلات قبل قواعد الإنهاء (القواعد التي تحدد مصير الرزمة، مثل ACCEPT، أو DROP، أو REJECT). إذا كنت تستخدم ufw، فبإمكانك تفعيل التسجيل بإدخال الأمر الآتي في الطرفية: sudo ufw logging onلكي توقف التسجيل في ufw، فببساطة بدل on بالكلمة off في الأمر السابق. إذا كنت تستخدم iptables بدلًا من ufw، فأدخل الأمر: sudo iptables -A INPUT -m state --state NEW -p tcp --dport 80 \ -j LOG --log-prefix "NEW_HTTP_CONN: "طلبيةٌ على المنفذ 80 من الجهاز المحلي ستولدُ سجلًا في dmesg الذي يبدو كما يلي (سطرٌ واحدٌ فقط قُسِّمَ إلى عدِّة أقسام): [4304885.870000] NEW_HTTP_CONN: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=58288 DF PROTO=TCP SPT=53981 DPT=80 WINDOW=32767 RES=0x00 SYN URGP=0سيظهر السجل السابق في ملف ‎/var/log/massages، و ‎/var/log/syslog، و ‎/var/log/kern.log؛ يمكن تعديل هذا السلوك بتعديل ‎/etc/syslog.conf تعديلًا ملائمًا أو بتثبيت وضبط ulogd وباستخدام الهدف ULOG بدلًا من LOG، العفريت ulogd هو خادوم في مجال المستخدم (userspace server) الذي يستمع إلى تعليمات التسجيل من النواة وخصوصًا للجدر النارية، ويمكنك التسجيل إلى أي ملف تريد، وحتى إلى قواعد بيانات PostgreSQL أو MySQL؛ يمكن تسهيل فهم سجلات الجدار الناري باستخدام أداة تحليل سجلات مثل logwatch، أو fwanalog، أو fwlogwatch، أو lire. أدوات أخرىهنالك أدوات عديد متوفرة لتساعدك في بناء جدار ناري كامل دون أن تكون لديك المعرفة الجيدة باستخدام iptables؛ للميالين للبرامج الرسومية: برنامج fwbulider1 هو قوي جدًا وسيكون مألوفًا للمدراء الذين تعاملوا مع أدوات تجارية لإدارة الجدر النارية، مثل Checkpoint FireWall-1. إذا كنت تُفضّل أداةً من سطر الأوامر مع ملفات ضبط نصيّة: الأداة Shorewall2 هي أداة قوية جدًا لتساعدك في ضبط جدار ناري متقدم لأي شبكة. مصادرصفحة ويكي أوبنتو «Ubuntu Firewall التي تحتوي على معلومات عن تطوير ufw.أيضًا، صفحة دليل ufw تحتوي معلومات مفيدة جدًا: man ufw.راجع الصفحة «packet-filtering-HOWTO» للمزيد من المعلومات حول استخدام iptables.صفحة «nat-HOWTO» تحتوي تفاصيل إضافية عن التنكر.صفحة ويكي أوبنتو «IPTables HowTo» هي مصدر رائع للمعلومات.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Firewall.

سنناقش في هذا الدرس أهمّية تحديث كلّ شيءٍ متعلّق بموقع ووردبريس الخاصّ بك إلى آخر الإصدارات المتوفّرة وأهميّة التحديثات بشكلٍ عام، وهو من أهمّ الأمور التي يمكنك القيام بها لزيادة حماية وأمان موقعك. لماذا نقوم بالتحديث؟السؤال الحقيقي يجب أن يكون "ولما لا"؟ يقوم مطوروا ووردبريس بإرسال التحديثات إلى المستخدمين لسببٍ معيّن في النهاية، حيث أنّ هذه التحديثات تحتوي على إصلاحاتٍ لثغراتٍ خطيرة يمكن أن يستغلها المهاجمون لمهاجمة موقعك، مما يجعل التحديث ضرورة لا مفرّ منها. تحديثات سكربت ووردبريس مهمّة بنفس أهمّية تحديثات أنظمة التشغيل والتطبيقات الأخرى، يتم دومًا اكتشاف ثغراتٍ جديدة في البرمجيات كلّ فترة، ويتم مع ذلك إرسال ترقيعاتٍ جديدة لترقيع هذه الثغرات كلّ فترة إلى أجهزة المستخدمين، مما يجعل التطبيق أكثر أمنًا" - Ken Westin الخبير الأمن في Tripwire, Inc. أنواع التحديثاتقبل أن نتابع، من المهمّ أن نفهم أنواع التحديثات المختلفة المتوفّرة في سكربت ووردبريس. يشير Tony Perez في تدوينة حديثة إلى أنّه هناك 3 أنواع مختلفة من التحديثات: تحديثات الأمان، الترقيعات والإصدارات الرئيسية. تحديثات الأمان هي بالضبط كما تبدو عليه من اسمها. يتم إصدارها بسرعة وتحتوي فقط على بضع إصلاحاتٍ لثغراتٍ موجودة تم اكتشافها مؤخرًا. تكون هذه التحديثات عادةً على شاكلة أرقام الإصدارات مثل 4.2.1. تحديثات الترقيعات أكبر قليلًا، لا تحتوي هي الأخرى على مميزاتٍ جديدة، ولكنّها تقوم بتحديث النظام وعادةً ما تتضمن تحديثاتٍ أمنية كذلك، كما أنّه يتم إصدارها بصفة دورية ومن الممكن توقّع وقت صدور الترقيع الجديد. وأمّا عن التحديثات الرئيسية من الانتقال من الإصدار 3.9 إلى الإصدار 4.0 فهذا تحديثٌ جوهري، يحتوي مميزاتٍ جديدة وإصلاحاتٍ للمشاكل الأمنية المعروفة بالإضافة لأمورٍ أخرى، كما أنّه يتم التدوين عنها في مدونة ووردبريس وفي العديد من المواقع الإخبارية الأخرى، حيث أنّها تحديثات كبيرة ويجب على الجميع معرفتها. قد تقوم هذه التحديثات أحيانًا بتحطيم شكل موقعك بسبب عدم توافقية مع القالب الذي تستخدمه مثلًا، ولكن مع وجود نسخة احتياطية من موقعك، فيجب ألّا تكون مشكلةً بالنسبة لك. الفشل بالتحديث يعني مشكلة أعظم كما ذكرنا سابقًا، عدم قيامك / فشلك بتحديث أيّ إضافات أو قوالب ووردبريس مثبّتة على موقعك قد يعرّضك لخطرٍ كبير، وما قد لا تفهمه هو "لماذا"؟ بمجرّد أن يتوفّر ترقيعٌ معيّن كتحديث، يتزايد الخطر على المستخدمين الذين لم يقوموا بالتحديث بصورةٍ كبيرة، لأنّ المخترقين سيكونون قادرين على قراءة الشفرة المصدرية للترقيع ومعرفة الثغرة الحقيقية وبالتالي يمكنهم استغلالها ضدّ مواقع ووردبريس التي لم تقم بالتحديث والترقيع. هناك فترة زمنية قصيرة ما بين توفّر الترقيع كتحديث لووردبريس وما بين قيام المُخترقين بالبدء باستغلال هذه الثغرة على مواقع ووردبريس التي لم تقم بالترقيع، وهذا هو الوقت الذي يجب على المستخدمين الانتباه إليه، حيث أنّ مجرّد الانتظار إهمالًا يتركك عرضةً لهجماتٍ أكثر - Ken Westin. يمكن قول نفس الأمر بخصوص القوالب والإضافات، صحيحٌ أنّها ليست جزءً من لبّ نواة ووردبريس، ولكنّها أيضًا قد تحتوي على ثغرات تمكّن المخترقين من استغلالها لاختراق موقعك، وأيضًا يتم اكتشاف هذه الثغرات كلّ فترة وتصدر تحديثات لترقيعها كلّ فترة، وعليك تثبيتها بمجرّد توفّرها. بعض السمات والقوالب تكون مبرمجة بصورة سيئة ويكون بها العديد من الثغرات ويجب عليك الانتباه إلى ذلك، كما يجب عليك تثبيت واستخدام القوالب والإضافات التي تستعملها فقط وحذف كلّ شيء لا تستعمله. إدارة تحديثات ووردبريسأفضل طريقة للتأكّد من أنّ كلّ شيء على موقعك محدّث هو جعل عملية التحقق من وجود تحديثات متوفّرة هي مهمّة روتينية أخرى على جدولك (لو لم تكن تقنيًا، فيجب عليك البحث عن استضافة تقوم تلقائيًا بتحديث جميع القوالب والإضافات والنواة الخاصّة بووردبريس)، يجب عليك التحقق من توفّر التحديثات بنفسك كلّ يوم لتجنّب أي مشاكل أمنية قد تحصل. منذ الإصدار 3.7 من ووردبريس فإنّ المنصة تسمح بالتحديث التلقائي بسهولة، بمجرّد تفعيل هذا الخيار، فإنّه هذا يعني أنّ نواة موقعك ستقوم بالتحديث تلقائيًا عند توفّر تحديثات جديدة بدون أيّ تدخّل منك. طبعًا لا يمكن فعل نفس الشيء بالنسبة للقوالب والإضافات، حيث يجب عليك القيام بتحديثها يدويًا. الخاتمةتحديثات ووردبريس مهمّة للغاية، بل ومهمّة جدًا، ومن واجبك الاهتمام بتحديث كلّ شيءٍ موجود على موقعك إلى الإصدارات الأخيرة المتوفّرة، وإلّا فإنك تترك بابك مفتوحًا للمخترقين ليخترقوك، إنّها مسألة وقت. ترجمة -وبتصرف- للمقال: The WordPress Developer’s Guide to Security: Updates لصاحبه: Brenda Barron.

من المرغوب عادةً عند الانتقال من خادوم إلى آخر أن تُنقَل قواعد الجدار الناري iptables كجزءٍ من العملية؛ سيشرح هذا الدرس لك كيف تنسخ بسهولة القواعد المُفعّلة لجدار iptables من خادوم إلى آخر. المتطلبات المسبقةيتطلب هذا الدرس وجود خادومَين؛ سنشير إلى الخادوم المصدر (الذي توجد فيه قواعد iptables) بالخادوم A، والخادوم الوجهة (الذي ستُنقَل إليه القواعد) بالخادوم B. ستحتاج إلى امتيازات الجذر على كلي الخادومين. عرض قواعد Iptables الموجودةقبل نقل قواعد iptables، لننظر إليها أولًا؛ يمكنك فعل ذلك عبر تطبيق هذا الأمر على الخادوم A: sudo iptables -Sمثالٌ عن ناتج الأمر السابق: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT 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 -s 15.15.15.51/32 -j DROPستُستخدَم القواعد الناتجة في المثال السابق لشرح عملية نقل الجدار الناري. تصدير قواعد Iptablesيكتب الأمر iptables-save قواعد iptables الحالية إلى stdout (مجرى الخرج القياسي)؛ مما يمنحنا طريقةً سهلةً لتصدير قواعد الجدار الناري إلى ملف، وذلك عبر إعادة توجيه stdout إلى ملف. استخدم الأمر iptables-save على الخادوم A -الذي تريد نقل القواعد منه- لتصدير القواعد الحالية إلى ملف باسم «iptables-export» كما يلي: cd ~ sudo iptables-save > iptables-exportهذا سيُنشئ الملف iptables-export في مجلد المنزل (home) الخاص بمستخدمك؛ يمكن أن يُستخدَم هذا الملف على خادومٍ آخر لتحميل قواعد الجدار الناري إلى iptables. عرض محتويات الملف (خطوة اختيارية)لنلقِ نظرةً سريعةً على محتويات الملف؛ سنستخدم الأمر cat لإظهار الملف على الطرفية: cat iptables-exportسيكون ناتج الأمر السابق شبيهًا بما يلي: # Generated by iptables-save v1.4.21 on Tue Sep 1 17:32:29 2015 *filter :INPUT ACCEPT [135:10578] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [8364:1557108] -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 -s 15.15.15.51/32 -j DROP COMMIT # Completed on Tue Sep 1 17:32:29 2015كما لاحظت، يحتوي الملف على ضبط قواعد iptables المُفعّلة؛ نحن جاهزون الآن لنسخ هذا الملف إلى الوجهة، التي هي الخادوم B. نسخ القواعد المصدرة إلى الخادوم الوجهةسنحتاج إلى نسخ ملف القواعد إلى الخادوم الوجهة (الخادوم B)؛ أسهل طريقة لفعل ذلك هي استخدام scp أو نسخ محتويات الملف ثم لصقها في ملفٍ جديد على الخادوم B. سنشرح كيفية استخدام الأمر scp لنسخ الملف عبر الشبكة إلى مجلد ‎/tmp. نفِّذ أمر scp الآتي على الخادوم A؛ تأكد أنك قد استبدلت الأجزاء المعلّمة ببيانات دخولك إلى الخادوم وعنوان IP له: scp iptables-export *user*@*server_b_ip_address*:/tmpسيُنسَخ الملف إلى مجلد ‎/tmp في الخادوم B بعد الاستيثاق (authentication)؛ الحظ أن محتويات المجلد ‎/tmp ستُحذَف عند إعادة الإقلاع، لذا يمكنك نسخ ذاك الملف إلى مكانٍ آخر إن أردت الاحتفاظ به. استيراد قواعد Iptablesبعد نسخ القواعد المُصدَّرة إلى الخادوم الوجهة، فيمكننا الآن تحميلها إلى iptables؛ لكن -وبالاعتماد على بيئتك- ربما تحتاج إلى تحديث القواعد في الملف ووضع عناوين ومجالات IP جديدة، وربما تريد أيضًا أن تعدِّل أسماء البطاقات الشبكيّة؛ إذا أردت أن تعدِّل القواعد قبل تحميلها، فعليك تعديل الملف ‎/tmp/iptables-export الآن. بعد أن تكون جاهزًا لتحميل القواعد من ملف iptables-export إلى iptables، فاستخدم الأمر iptables-restore لفعل ذلك. على الخادوم الوجهة (الخادوم B)، نفِّذ هذا الأمر لتحميل قواعد الجدار الناري: sudo iptables-restore < /tmp/iptables-exportسيحمِّل الأمر السابق القواعد إلى ipables، يمكنك التحقق من تحميلها بوساطة الأمر sudo iptables -S. حفظ القواعدتكون قواعد Iptables مؤقتةً، لذلك يجب أخذ الحيطة عند التعامل معها للحفاظ عليها حتى بعد إعادة الإقلاع؛ سيكون عليك تنفيذ هذه الخطوة على الخادوم B. سنشرح كيفية حفظ القواعد على توزيعتَي أوبنتو و CentOS. توزيعة أوبنتوإن أسهل طريقة لحفظ قواعد Iptables في أوبنتو لكي تبقى بعد إعادة الإقلاع هي استخدام حزمة iptables-persistent؛ يمكنك تثبيتها باستخدام الأمر apt-get: sudo apt-get install iptables-persistentستُسأل أثناء التثبيت إذا ما كنتَ تريد حفظ قواعد الجدار الناري الحالية؛ اختر yes إذا أردت حفظها. إذا حدَّثتَ قواعد جدارك الناري في المستقبل، وأردت حفظ التعديلات، فنفِّذ هذا الأمر: sudo invoke-rc.d iptables-persistent saveتوزيعة CentOS 6 وما قبلهاعلى توزيعة CentOS 6 وما قبلها (حيث تستخدم CentOS 7 افتراضيًا جدار FirewallD الناري)، يمكنك استخدام سكربت init الخاص بتطبيق iptables لحفظ القواعد: sudo service iptables saveسيحفظ الأمر السابق قواعد iptables الحالية إلى الملف ‎/etc/sysconfig/iptables، الذي يحمَّل بوساطة iptables عند الإقلاع. الخلاصةتهانينا، لقد أتممت نقل قواعد جدارك الناري من خادومك الأصلي إلى خادومك الجديد. ترجمة -وبتصرف- للمقال: How To Migrate Iptables Firewall Rules to a New Server لصاحبه: Mitchell Anicas.

إن UFW هو أداةٌ لضبط iptables موجودٌ افتراضيًا في أوبنتو؛ يوفِّر هذا الدرس مرجعًا سريعًا لأوامر UFW التي ستُنشِئ قواعد جدار iptables الناري لحالات الاستخدام الشائعة، وهذا يتضمن أمثلةً عن استخدام UFW للسماح وحجب مختلف الخدمات عبر المنفذ، والبطاقة الشبكيّة، وعنوان IP المصدر. كيف تستخدم هذا الدرسإذا كنت قد بدأت لتوِّك باستخدام UFW لضبط جدارك الناري، فراجع الدرس تمهيد إلى UFW.تفترض أغلبية القواعد المشروحة هنا أنك تستخدم مجموعة قواعد UFW الافتراضية؛ التي تكون مضبوطةً للسماح بالاتصالات الصادرة وحجب الاتصالات الواردة، لذا عليك أن تنتقي البيانات التي تريد تمريرهااستعمل الأمثلة الموجودة في الأقسام المتتالية الملائمة لما تودّ تحقيقه؛ لا تعتمد أغلبية الأقسام في هذا الدرس على بعضها بعضًا، لذا يمكنك استخدام الأمثلة الآتية استخدامًا مستقلًاانسخ والصق الأمثلة عن الأوامر الموجودة في هذا الدرس، مستبدلًا قيمك بالقيم المُعلَّمة بالأحمرتذكر أنك تستطيع أن تتحقق من مجموعة قواعد UFW الحالية عبر الأمر sudo ufw status أو sudo ufw status verbose. حجب عنوان IPنفِّذ الأمر الآتي لحجب جميع الاتصالات الشبكية التي تُنشَأ من عنوان IP معيّن، مثلًا 15.15.15.51: sudo ufw deny from 15.15.15.51يُحدِّد التعبير from 15.15.15.51 في المثال السابق عنوان IP مصدري (source IP) هو «15.15.15.51»؛ يمكنك تحديد شبكة فرعية مثل 15.15.15.0/24 إن أردت ذلك. يمكن تحديد عنوان IP مصدري في أيّة قاعدة من قواعد الجدار الناري، بما في ذلك قاعدة allow. حجب الاتصالات إلى بطاقة شبكية معينةاستعمل هذا الأمر لحجب جميع الاتصالات من عنوان IP محدد (على سبيل المثال، 15.15.15.51) إلى بطاقة شبكيّة معيّنة، مثل eth0: sudo ufw deny in on eth0 from 15.15.15.51يشبه هذا الأمرُ الأمرَ السابق، لكن مع زيادة التعبير in on eth0. يمكن تحديد البطاقة الشبكية في أيّة قاعدة من قواعد الجدار الناري، وهذه طريقةٌ ممتازةٌ لتحديد الدور الذي تلعبه بطاقة شبكية معيّنة. خدمة SSHإذا كنتَ تستخدم خادومًا سحابيًا، فربما تريد السماح لاتصالات SSH الواردة (المنفذ 22) لذا يمكنك الاتصال وإدارة خادومك؛ يشرح هذا القسم كيف تَضبط جدارك الناري بمختلف القواعد المتعلقة بخدمة SSH. السماح لاتصالات SSHتستطيع استخدام الأمر الآتي للسماح باتصالات SSH الواردة: sudo ufw allow sshصيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة SSH: sudo ufw allow 22السماح لاتصالات SSH الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات SSH الواردة من عنوان IP معيّن أو شبكة فرعية، فعليك تحديد المصدر؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24، فنفِّذ هذا الأمر: sudo ufw allow from 15.15.15.0/24 to any port 22السماح لاتصالات Rsync الواردة من عنوان IP معين أو شبكة فرعيةيمكن أن يُستخدَم Rsync (الذي يعمل على المنفذ 873) لنقل الملفات من حاسوبٍ إلى آخر. للسماح باتصالات rsync الواردة من عنوان IP معيّن أو شبكة فرعية، فحدد عنوان IP المصدري والمنفذ الوجهة؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24 باستخدام rsync على خادومك، فنفِّذ الأمر الآتي: sudo ufw allow from 15.15.15.0/24 to any port 873خادم الويبتستمع خوادم الويب -مثل أباتشي و Nginx- للطلبيات على المنفذين 80 و 443 لاتصالات HTTP و HTTPS على التوالي وبالترتيب. إذا كانت السياسة الافتراضية للاتصالات الواردة هي الحجب أو التجاهل، فربما تريد إنشاء قواعد تسمح لخادومك بالرد على تلك الطلبيات. السماح لجميع اتصالات HTTP الواردةاستخدم الأمر الآتي للسماح لجميع اتصالات HTTP (المنفذ 80) الواردة: sudo ufw allow httpصيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة HTTP: sudo ufw allow 80السماح لجميع اتصالات HTTPS الواردةاستخدم الأمر الآتي للسماح لجميع اتصالات HTTPS (المنفذ 443) الواردة: sudo ufw allow httpsصيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة HTTPS: sudo ufw allow 443السماح لجميع اتصالات HTTP و HTTPS الواردةإذا أردت السماح لاتصالات HTTP و HTTPS معًا، فيمكنك إنشاء قاعدة وحيدة تسمح لكلي المنفذين؛ وذلك بتنفيذ الأمر الآتي: sudo ufw allow proto tcp from any to any port 80,443الحظ أنك ستحتاج إلى تحديد البروتوكول (باستخدام proto tcp) عند تحديد عدِّة منافذ. قواعد بيانات MySQLتستمع MySQL إلى اتصالات العميل على المنفذ 3306؛ إذا كان سيُستخدَم خادم قواعد بيانات MySQL من عميلٍ على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية. السماح لاتصالات MySQL الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات MySQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذا الأمر إذا أردت السماح للشبكة الفرعية 15.15.15.0/24: sudo ufw allow from 15.15.15.0/24 to any port 3306السماح لاتصالات MySQL الواردة إلى بطاقة شبكية معينةاستخدم الأمر الآتي للسماح لاتصالات MySQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-: sudo ufw allow in on eth1 to any port 3306قواعد بيانات PostgreSQLتستمع PostgreSQL إلى اتصالات العميل على المنفذ 5432 إذا كان سيُستخدَم خادم قواعد بيانات PostgreSQL من عميلٍ على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية. السماح لاتصالات PostgreSQL الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات PostgreSQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذا الأمر إذا أردت السماح للشبكة الفرعية 15.15.15.0/24: sudo ufw allow from 15.15.15.0/24 to any port 5432السماح لاتصالات PostgreSQL الواردة إلى بطاقة شبكية معينةاستخدم الأمر الآتي للسماح لاتصالات PostgreSQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-: sudo ufw allow in on eth1 to any port 5432خدمة البريدتستمع خوادم البريد مثل Sendmail و Postfix إلى تشكيلة واسعة من المنافذ بناءً على البروتوكولات المستخدمة لتوصيل البريد؛ إذا كنت تُشغِّل خادوم بريدٍ إلكتروني، فحدِّد البروتوكولات التي تستخدمها واسمح للاتصالات الموافقة لها. سنستعرض أيضًا مثالًا عن إنشاء قاعدة لحجب بريد SMTP الصادر. حجب بريد SMTP الصادرربما تريد أن تحجب بريد SMTP الصادر إذا لم يكن من المفترض لخادومك أن يُرسِل بريدًا إلكترونيًّا؛ استخدم الأمر الآتي لحجب بريد SMTP الصادر (الذي يستخدم المنفذ 25): sudo ufw deny 25يضبط الأمر السابق خادومك لتجاهل كل البيانات المُرسَلة على المنفذ 25؛ إذا أردت أن تحجب خدمةً أخرى عبر رقم منفذها، فضع رقم المنفذ الخاص بها بدلًا من 25. السماح لجميع اتصالات SMTP الواردةللسماح لخادومك بالرد على اتصالات SMTP على المنفذ 25، فعليك تنفيذ الأمر الآتي: sudo ufw allow 25ملاحظة: من الشائع لخوادم SMTP أن تستخدم المنفذ 587 للبريد الصادر. السماح لجميع اتصالات IMAP الواردةللسماح لخادومك بالرد على اتصالات IMAP على المنفذ 143، فعليك تنفيذ الأمر الآتي: sudo ufw allow 143السماح لجميع اتصالات IMAPS الواردةللسماح لخادومك بالرد على اتصالات IMAPS على المنفذ 993، فعليك تنفيذ الأمر الآتي: sudo ufw allow 993السماح لجميع اتصالات POP3 الواردةللسماح لخادومك بالرد على اتصالات POP3 على المنفذ 110، فعليك تنفيذ الأمر الآتي: sudo ufw allow 110السماح لجميع اتصالات POP3S الواردةللسماح لخادومك بالرد على اتصالات POP3S على المنفذ 995، فعليك تنفيذ الأمر الآتي: sudo ufw allow 995الخلاصةيجب أن يكون قد غطى هذا الدرس الكثير من الأوامر شائعة الاستخدام عند استعمال UFW لضبط الجدار الناري؛ وبالطبع إن UFW هو أداةٌ مرنةٌ جدًا، لذلك تستطيع دمج مختلف الخيارات مع الأوامر السابقة لملائمة متطلبات خادومك إن لم تكن تلك الأوامر مبيّنةً هنا. ترجمة -وبتصرف- للمقال: UFW Essentials: Common Firewall Rules and Commands لصاحبه: Mitchell Anicas.

Iptables هو برمجية جدار ناري مضمَّنة افتراضيًّا في أغلبية توزيعات لينُكس. يوفِّر هذا الدرس مرجعًا سريعًا لأوامر iptables التي ستُنشِئ قواعدًا لحالات الاستخدام الشائعة، وهذا يتضمن أمثلةً عن استخدام iptables للسماح وحجب مختلف الخدمات عبر المنفذ، والبطاقة الشبكيّة، وعنوان IP المصدر. كيف تستخدم هذا الدرسإذا كنت قد بدأت لتوِّك باستخدام iptables لضبط جدارك الناري، فراجع الدرس تمهيد إلى iptables.تفترض أغلبية القواعد المشروحة هنا أنَّ iptables مضبوطٌ لتجاهل الاتصالات الواردة عبر السياسة الافتراضية، لذا عليك أن تنتقي البيانات التي تريد تمريرها.استعمل الأمثلة الموجودة في الأقسام المتتالية الملائمة لما تودّ تحقيقه؛ لا تعتمد أغلبية الأقسام في هذا الدرس على بعضها بعضًا، لذا يمكنك استخدام الأمثلة الآتية استخدامًا مستقلًا.انسخ والصق الأمثلة عن الأوامر الموجودة في هذا الدرس، مستبدلًا قيمك بالقيم المُعلَّمة بالأحمر.أبقِ في بالك أنَّ ترتيب القواعد مهم؛ تستخدم جميع أوامر iptables الآتية الخيار ‎-A الذي يُلحِق (append) القاعدة الجديدة إلى نهاية سلسلة، إذا أردت وضعها في مكانٍ آخر، فيمكنك استخدام الخيار ‎-I الذي يسمح لك بتحديد موقع القاعدة الجديدة (أو ببساطة وضعها في بداية السلسلة [chain] إن لم تُحدِّد رقمًا للقاعدة). ملاحظة: احذر عند العمل مع الجدر النارية أن تمنع نفسك من الدخول إلى خادومك عبر حجب اتصالات SSH (المنفذ 22 افتراضيًّا)؛ إذا فقدت القدرة على الوصول إلى خادومك بسبب ضبط جدارك الناري، فستحتاج إلى الدخول عبر !طرفية محلية! لتقويم الخلل. بعد أن تسجل دخولك عبر الطرفية المحلية، يمكنك تعديل قواعد جدارك الناري للسماح بالوصول إلى خدمة SSH (أو السماح بعبور جميع بيانات التراسل الشبكي)؛ إذا كانت قواعد جدارك الناري المحفوظة تسمح بالوصول عبر SSH، فستتمكن عبر إعادة تشغيل الخادوم من الاتصال مجددًا عبر SSH. تذكَّر أنك تستطيع التحقق من مجموعة قواعد iptables الحالية بالأمرَين sudo iptables -S و sudo iptables -L. لنلقِ نظرةً على أوامر iptables. حفظ القواعدتكون قواعد iptables مؤقتة، مما يعني أنه من الضروري حفظها يدويًا لكي تبقى بعد إعادة الإقلاع. توزيعة أوبنتوأسهل طريقة لحفظ قواعد iptables في أوبنتو كي تبقى حتى لو أُعيد الإقلاع هي استخدام الحزمة iptables-persistent؛ ثبِّتها عبر apt-get كما يلي: sudo apt-get install iptables-persistentستُسأل أثناء التثبيت إذا ما كنت تريد حفظ قواعد جدارك الناري الحالية. إذا حدَّثت قواعد جدارك الناري وأردت حفظ التغييرات، فنفِّذ الأمر الآتي: sudo invoke-rc.d iptables-persistent saveتوزيعة CentOS 6 وما قبلهايمكنك استخدام سكربت init لجدار iptables لحفظ القواعد في توزيعة CentOS 6 وما قبلها (تَستخدم توزيعة CentOS 7 جدار FirewallD افتراضيًّا): sudo service iptables saveسيحفظ الأمر السابق قواعد iptables الحالية إلى ملف ‎/etc/sysconfig/iptables. قواعد مفيدة عمومايتضمن هذا القسم تشكيلةً من أوامر iptables التي ستُنشِئ قواعدًا مفيدةً في أغلبية الخواديم. السماح بالاتصالات إلى بطاقة Loopbackبطاقة «loopback» (التي يُشار إليها أيضًا بالاسم lo) هي البطاقة التي يستخدمها الحاسوب لإجراء اتصالات شبكيّة مع نفسه؛ على سبيل المثال، إذا شغَّلت ping localhost أو ping 127.0.0.1، فإن خادومك سيجري عملية ping لنفسه باستخدام بطاقة loopback؛ يمكن الاستفادة أيضًا من بطاقة loopback إذا ضَبطتَ تطبيقك للاتصال إلى خادوم قواعد بيانات ذي العنوان «localhost»؛ ولهذا عليك أن تتأكد أنَّ جدارك الناري يسمح بمرور لهذه الاتصالات. لقبول مرور جميع بيانات التراسل الشبكي على بطاقة loopback، فعليك تنفيذ هذين الأمرين: sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A OUTPUT -o lo -j ACCEPTالسماح للاتصالات الواردة المنشأة والمتعلقةيجب عادةً أن تمر بيانات التراسل الشبكي باتجاهين (صادرة وواردة) لكي تعمل الاتصالات الشبكية عملًا صحيحًا؛ من الاعتيادي إنشاء قاعدة في الجدار الناري للسماح بالاتصالات الواردة المُنشَأة (established) والمتعلقة (related)، مما يمكِّن الخادوم من استقبال البيانات المُرجَعة من اتصالات صادرة بدأها الخادوم نفسه؛ سيكون الأمر كما يلي: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTالسماح بمرور البيانات للاتصالات الصادرة المنشأةربما تود السماح للبيانات الصادرة لجميع الاتصالات المُنشَأة، التي تكون عادةً الرد على الاتصالات الواردة المسموح لها؛ الأمر الذي يفعل بذلك هو: sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPTالتمرير من الشبكة الداخلية إلى الخارجيةعلى فرض أنَّ eth0 هي شبكتك الخارجية، و eth1 هي شبكتك الداخلية، فإن الأمر الآتي سيسمح بتمرير البيانات من الشبكة الداخلية إلى الخارجية: sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPTتجاهل الرزم الشبكية غير الصالحةتُعلَّم بعض الرزم الشبكية على أنها «غير صالحة» (invalid)؛ قد يكون مفيدًا في بعض الأخيان تسجيل هذا النوع من الرزم لكن يكون عادةً من المقبول تجاهلها. يمكنك فعل ذلك بوساطة هذا الأمر: sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROPحجب عنوان IPاستعمل الأمر الآتي لحجب الاتصالات الشبكية التي تنحدر من عنوان IP معيّن، ولنقل أنه 15.15.15.51 مثلًا: sudo iptables -A INPUT -s 15.15.15.51 -j DROPيُحدِّد التعبير ‎-s 15.15.15.51 عنوان IP المصدري على أنه «15.15.15.51»، يمكن أن يُحدَّد عنوان IP المصدري في أيّة قاعدة من قواعد الجدار الناري، بما في ذلك قواعد السماح (allow). إذا كنت تريد «رفض» (reject) الاتصال بدلًا من تجاهله (أي سيكون الرد على الاتصال هو خطأ «connection refused») فبدِّل «DROP» إلى «REJECT» كما يلي: sudo iptables -A INPUT -s 15.15.15.51 -j REJECTحجب الاتصالات إلى بطاقة شبكيةلحجب جميع الاتصالات من عنوان IP معيّن (15.15.15.51 مثلًا)، إلى بطاقة شبكيّة معيّنة (eth0 مثلًا) فاستخدم هذا الأمر: iptables -A INPUT -i eth0 -s 15.15.15.51 -j DROPيشبه هذا الأمر كثيرًا الأمرَ في الفقرة السابقة، لكنه يزيد عنه بالتعبير ‎-i eth0؛ يمكن تحديد البطاقة الشبكية في أيّة قاعدة من قواعد الجدار الناري، وهذه طريقةٌ رائعةٌ لجعل قاعدةٍ ما محدودةً إلى شبكةٍ معيّنةٍ فقط. خدمة SSHإذا كنتَ تستخدم خادومًا سحابيًا، فربما تريد السماح لاتصالات SSH الواردة (المنفذ 22) لذا يمكنك الاتصال وإدارة خادومك؛ يشرح هذا القسم كيف تضبط جدارك الناري بمختلف القواعد المتعلقة بخدمة SSH. السماح لاتصالات SSHتستطيع استخدام الأمرين الآتيين للسماح لجميع اتصالات SSH الواردة: sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SSH المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لاتصالات SSH الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات SSH الواردة من عنوان IP معيّن أو شبكة فرعية، فعليك تحديد المصدر؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24، فنفِّذ هذين الأمرين: sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SSH المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لاتصالات SSH الصادرةإذا لم تكن سياسة OUTPUT في جدارك الناري مضبوطةً إلى ACCEPT، فربما تريد السماح لاتصالات SSH الصادرة (أي أن يبدأ خادومك اتصال SSH إلى خادومٍ آخر) بتنفيذ هذين الأمرين: sudo iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A INPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPTالسماح لاتصالات Rsync الواردة من عنوان IP معين أو شبكة فرعيةيمكن أن يُستخدَم Rsync (الذي يعمل على المنفذ 873) لنقل الملفات من حاسوبٍ إلى آخر. للسماح باتصالات rsync الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد عنوان IP المصدري والمنفذ الوجهة؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24 باستخدام rsync على خادومك، فنفِّذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 873 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 873 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات rsync المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. خادم الويبتستمع خوادم الويب -مثل أباتشي و Nginx- للطلبيات على المنفذين 80 و 443 لاتصالات HTTP و HTTPS على التوالي وبالترتيب. إذا كانت السياسة الافتراضية للاتصالات الواردة هي الحجب أو التجاهل، فربما تريد إنشاء قواعد تسمح لخادومك بالرد على تلك الطلبيات. السماح لجميع اتصالات HTTP الواردةاستخدم الأمرين الآتيين للسماح لجميع اتصالات HTTP (المنفذ 80) الواردة: sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات HTTP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات HTTPS الواردةاستخدم الأمرين الآتيين للسماح لجميع اتصالات HTTPS (المنفذ 443) الواردة: sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات !HTTPS! المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات HTTP و HTTPS الواردةإذا أردت السماح لجميع اتصالات HTTP و HTTPS الواردة معًا، فيمكنك استخدام الوحدة (module) ‏«mulitport» لإنشاء قاعدة تسمح بمرور البيانات على كلي المنفذين؛ وذلك عبر الأمرين الآتيين: sudo iptables -A INPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات HTTP و HTTPS المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. قواعد بيانات MySQLتستمع MySQL إلى اتصالات العميل على المنفذ 3306؛ إذا كان سيُستخدَم خادم قواعد بيانات MySQL من عميل على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية. السماح لاتصالات MySQL الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات MySQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذين الأمرين إذا أردت السماح للشبكة الفرعية 15.15.15.0/24: sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات MySQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لاتصالات MySQL الواردة إلى بطاقة شبكية معينةاستخدم الأمر الآتي للسماح لاتصالات MySQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-: sudo iptables -A INPUT -i eth1 -p tcp --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -o eth1 -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات MySQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. قواعد بيانات PostgreSQLتستمع PostgreSQL إلى اتصالات العميل على المنفذ 5432 إذا كان سيُستخدَم خادم قواعد بيانات PostgreSQL من عميل على خادومٍ بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية. السماح لاتصالات PostgreSQL الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات PostgreSQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذين الأمرين إذا أردت السماح للشبكة الفرعية 15.15.15.0/24: sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات PostgreSQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لاتصالات PostgreSQL الواردة إلى بطاقة شبكية معينةاستخدم الأمر الآتي للسماح لاتصالات PostgreSQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1: sudo iptables -A INPUT -i eth1 -p tcp --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -o eth1 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات PostgreSQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. خدمة البريدتستمع خوادم البريد مثل Sendmail و Postfix إلى تشكيلة واسعة من المنافذ بناءً على البروتوكولات المستخدمة لتوصيل البريد؛ إذا كنت تُشغِّل خادوم بريدٍ إلكتروني، فحدِّد البروتوكولات التي تستخدمها واسمح للاتصالات الموافقة لها. سنستعرض أيضًا مثالًا عن إنشاء قاعدة لحجب بريد SMTP الصادر. حجب بريد SMTP الصادرربما تريد أن تحجب بريد SMTP الصادر إذا لم يكن من المفترض لخادومك أن يرسل بريدًا إلكترونيًّا؛ استخدم الأمر الآتي لحجب بريد SMTP الصادر (الذي يستخدم المنفذ 25): sudo iptables -A OUTPUT -p tcp --dport 25 -j REJECTيضبط الأمر السابق خادومك لتجاهل كل البيانات المُرسَلة على المنفذ 25؛ إذا أردت أن تحجب خدمةً أخرى عبر رقم منفذها، فضع رقم المنفذ الخاص بها بدلًا من 25. السماح لجميع اتصالات SMTP الواردةللسماح لخادومك بالرد على اتصالات SMTP على المنفذ 25، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp --dport 25 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 25 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SMTP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. ملاحظة: من الشائع لخوادم SMTP أن تستخدم المنفذ 587 للبريد الصادر. السماح لجميع اتصالات IMAP الواردةللسماح لخادومك بالرد على اتصالات IMAP على المنفذ 143، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp --dport 143 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 143 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات IMAP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات IMAPS الواردةللسماح لخادومك بالرد على اتصالات IMAPS على المنفذ 993، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 993 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات IMAPS المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات POP3 الواردةللسماح لخادومك بالرد على اتصالات POP3 على المنفذ 110، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -i -p tcp --dport 110 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 110 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات POP3 المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات POP3S الواردةللسماح لخادومك بالرد على اتصالات POP3S على المنفذ 995، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp --dport 995 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 995 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات POP3S المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. الخلاصةيجب أن يكون قد غطى هذا الدرس الكثير من الأوامر شائعة الاستخدام عند استعمال iptables لضبط الجدار الناري؛ وبالطبع iptables هو أداةٌ مرنةٌ جدًا، لذلك تستطيع دمج مختلف الخيارات مع الأوامر السابقة لملائمة متطلبات خادومك إن لم تكن تلك الأوامر مبيّنةً هنا. ترجمة -وبتصرف- للمقال: Iptables Essentials: Common Firewall Rules and Commands لصاحبه: Mitchell Anicas.

نشر مختلف مكونات تطبيقك على عدِّة عقد (nodes) هو طريقةٌ شائعةٌ لتخفيف الحِمل (load) والبدء في التوسع أفقيًا (scaling horizontally)؛ مثالٌ اعتياديٌ عن ذلك هو ضبط قاعدة بيانات على خادوم منفصل عن تطبيقك؛ وعلى الرغم من العدد الكبير من المحاسن الناتجة عن هذا الإعداد، لكن الاتصال عبر الشبكة ينضوي على مخاطر أمنية. سنشرح في هذا الدرس كيف نعد جدار ناري بسيط على كل خادوم من خواديمك عند استخدامك للضبط الموزَّع (distributed setup)؛ سنضبط السياسة لكي تسمح بمرور البيانات بين المكونات (components)، وتمنع في الوقت ذاته مرور أيّة بيانات أخرى. سنستخدم في هذا الدليل خادومَي أوبنتو 14.04؛ واحدٌ سيحتوي على نسخة من وردبريس مُخدَّمة بوساطة nginx، والآخر يستضيف قاعدة بيانات MySQL للتطبيق. وعلى الرغم من أننا سنستخدم هذا الإعداد كمثال، لكنك تستطيع تعديل التقنيات التي سنستخدمها لكي تلائم متطلبات خادومك. المتطلبات المسبقةللبدء، عليك أن تحصل على خادومَي Ubuntu؛ وتضيف مستخدمًا عاديًا بامتيازات الجذر عبر الأمر sudo على كلي الخادومَين؛ يمكنك اتباع درس الضبط المبدئي لخادوم أوبنتو 14.04 لكي تتعلم كيف تفعل ذلك بشكلٍ صحيح. ضبط جدار ناري بسيطسنبدأ بضبط أساسي للجدار الناري على كل خادوم من خواديمنا. السياسة التي سنتبعها تأخذ منحى «الأمان أولًا»، أي أننا سنمنع كل شيء عدا بيانات التراسل التابعة لخدمة SSH ثم سنفتح «فجوات» في الجدار الناري خاصة بتطبيقنا. يوفر الجدار الناري المضبوط في هذا الدرس إعدادًا أساسيًا لما سنحتاج؛ ثبِّت الحزمة iptables-persistent ثم الصق القواعد الأساسية في ملف ‎/etc/iptables/rules.v4: sudo apt-get update sudo apt-get install iptables-persistent sudo nano /etc/iptables/rules.v4محتويات الملف: etc/iptables/rules.v4/ *filter # Allow all outgoing, but drop incoming and forwarding packets by default :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Custom per-protocol chains :UDP - [0:0] :TCP - [0:0] :ICMP - [0:0] # Acceptable UDP traffic # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT # Acceptable ICMP traffic # Boilerplate acceptance policy -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -i lo -j ACCEPT # Drop invalid packets -A INPUT -m conntrack --ctstate INVALID -j DROP # Pass traffic to protocol-specific chains ## Only allow new connections (established and related should already be handled) ## For TCP, additionally only allow new SYN packets since that is the only valid ## method for establishing a new TCP connection -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP # Reject anything that's fallen through to this point ## Try to be protocol-specific w/ rejection message -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable # Commit the changes COMMIT *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *security :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMITإذا كنتَ تجري هذه التعديلات على «بيئة حيّة» فلا تعيد تحميل قواعد الجدار الناري! تحميل القواعد الأساسية المذكورة هنا سيؤدي مباشرةً إلى قطع الاتصال بين تطبيقك وخادوم قواعد البيانات؛ سنحتاج إلى تعديل القواعد لكي تعكس احتياجاتنا لكي يعمل التطبيق قبل إعادة التحميل. معرفة المنافذ التي تستخدمها الخدمات التي تشغلهالكي نستطيع إضافة استثناءات للسماح بالاتصالات بين مختلف مكونات التطبيق، فسنحتاج إلى معرفة المنافذ الشبكية المُستخدَمة؛ يمكنك معرفة المنافذ الشبكية الصحيحة بتفحص ملفات الضبط، لكن طريقة اكتشاف المنافذ غير مرتبطة بالتطبيقات هي التحقق من الخدمات التي «تستمع» إلى الاتصالات على كل جهاز. يمكننا استخدام الأداة netstat لمعرفة ذلك؛ ولمّا كان تطبيقنا يتواصل عبر IPv4 فقط، فسنضيف الوسيط ‎-4 لكنك تستطيع إزالته إذا كنت تستخدم IPv6 أيضًا؛ الوسائط الأخرى اللازمة لمعرفة الخدمات التي تعمل هي ‎-plunt. على خادوم الويب، سنرى شيئًا شبيهًا بما يلي: sudo netstat -4pluntالناتج: 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 1058/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4187/nginx يُظهِر أول عمود عنوان IP والمنفذ للخدمة التي تستمع إليه (الموجود اسمها في آخر السطر)؛ عنوان 0.0.0.0 الخاص يعني أن الخدمة المعنية تستمع إلى جميع العناوين المتاحة (جميع البطاقات الشبكية). وعلى خادوم قواعد البيانات، يجب أن نشاهد شيئًا شبيهًا بما يلي: sudo netstat -4pluntالناتج: 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 1097/sshd tcp 0 0 192.0.2.30:3306 0.0.0.0:* LISTEN 3112/mysqldيمكنك قراءة الأعمدة السابقة بنفس الطريقة. يمثّل عنوان 192.0.2.30 في المثال السابق عنوان IP الخاص لخادوم قواعد البيانات؛ وعند إعداد التطبيق، لقد حصرنا استخدام MySQL إلى البطاقة الخاصة فقط لأسبابٍ أمنية. الحظ القيم التي ستجدها في هذه الخطوة، هذه هي التفاصيل الشبكية التي سنحتاج لها لكي نعدِّل ضبطنا للجدار الناري. في مثالنا التوضيحي، سنلاحظ أنه علينا التأكد من أن هذه المنافذ متاحة على خادوم الويب: المنفذ 80 على جميع العناوينالمنفذ 22 على جميع العناوين (وذلك موجودٌ في قواعد الجدار الناري)وعلينا التأكد من أن هذه المنافذ متاحةٌ على خادوم قواعد البيانات: المنفذ 3306 على العنوان 192.0.2.30 (أو البطاقة الشبكية المرتبطة معه)المنفذ 22 على جميع العناوين (وذلك موجودٌ في قواعد الجدار الناري)تعديل قواعد الجدار الناري لخادوم الويبلدينا الآن معلومات المنافذ التي نحتاج إليها لتعديل مجموعة قواعد الجدار الناري لخادوم الويب الخاص بنا؛ افتح ملف القواعد في محررك النصي بامتيازات الجذر (عبر sudo): sudo nano /etc/iptables/rules.v4سنحتاج إلى السماح بمرور بيانات التراسل الشبكي على المنفذ 80 في خادوم الويب؛ ولمّا كان الخادوم يستمع إلى الاتصالات على جميع العناوين المتوفرة، فإننا لن نقيّد القاعدة ببطاقة شبكية أو عنوان معيّن. سيستخدم زوار موقعنا بروتوكول TCP للاتصال؛ إطار العمل الذي أنشأناه لجدارنا الناري فيه سلسلة خاصة باسم TCP لوضع استثناءات لتطبيقات TCP؛ يمكننا إضافة المنفذ 80 إلى السلسلة، مباشرةً بعد الاستثناء الخاص بمنفذ SSH: /etc/iptables/rules.v4 *filter . . . # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT -A TCP -p tcp --dport 80 -j ACCEPT . . .سيبدأ خادوم الويب اتصالًا مع خادوم قواعد البيانات؛ ليست الاتصالات الشبكية الخارجة من خادومنا مقيدةً في جدارنا الناري ويُسمَح للاتصالات الواردة المرتبطة مع اتصالات مُنشَأة مسبقًا، لذلك لن نحتاج إلى فتح أيّة منافذ إضافية في هذا الخادوم للسماح بهذا الاتصال. احفظ وأغلق الملف عندما تنتهي من تعديله، يجب أن يملك خادوم الويب الآن سياسة جدارٍ ناريٍ تسمح بمرور البيانات الشرعية وتحجب في الوقت نفسه أي شيءٍ آخر. اختبر ملف القواعد للكشف عن الأخطاء البنيوية (syntax errors): sudo iptables-restore -t < /etc/iptables/rules.v4إذا لم تظهر أيّة أخطاء، فأعد تحميل الجدار الناري لتطبيق مجموعة القواعد الجديدة: sudo service iptables-persistent reloadتعديل قواعد الجدار الناري لخادوم قواعد البياناتيجب علينا السماح بالوصول إلى المنفذ 3306 على عنوان IP الخاص بخادوم قواعد البيانات، الذي هو 192.0.2.30، يمكننا وضع قيود على الوصول لهذا العنوان تحديدًا، أو يمكننا وضع القيود للبيانات القادمة إلى البطاقة الشبكية المرتبطة مع هذا العنوان. لمعرفة البطاقة الشبكية المرتبطة مع هذا العنوان، فنفِّذ الأمر: ip -4 addr show scope globalالناتج: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 203.0.113.5/24 brd 104.236.113.255 scope global eth0 valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.0.2.30/24 brd 192.0.2.255 scope global eth1 valid_lft forever preferred_lft foreverما سبق يظهر أنّ البطاقة eth1 هي البطاقة الشبكيّة المرتبطة مع ذاك العنوان. ومن ثم علينا أن نعدِّل قواعد الجدار الناري في خادوم قواعد البيانات. افتح ملف القواعد بامتيازات الجذر (عبر sudo) في خادوم قواعد البيانات: sudo nano /etc/iptables/rules.v4مرةً أخرى، سنضيف قاعدةً إلى سلسلة TCP لتشكيل استثناء للاتصال بين خادومَي الويب وقواعد البيانات. إذا أردت تقييد الوصول بناءً على العنوان، فيمكنك إضافة قاعدة مثل هذه: /etc/iptables/rules.v4 *filter . . . # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT -A TCP -p tcp --dport 3306 -d 192.0.2.30 -j ACCEPT . . .إذا كنت تفضِّل أن تسمح بالاستثناء بناءً على البطاقة الشبكية التي تستضيف العنوان، فيمكنك إضافة قاعدة شبيهة بالقاعدة السابقة بدلًا منها: /etc/iptables/rules.v4 *filter . . . # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT -A TCP -p tcp --dport 3306 -i eth1 -j ACCEPT . . .احفظ وأغلق الملف عندما تنتهي من تعديله. اختبر ملف القواعد للكشف عن الأخطاء البنيوية: sudo iptables-restore -t < /etc/iptables/rules.v4عندما تكون جاهزًا، فأعد تحميل قواعد الجدار الناري: sudo service iptables-persistent reloadيجب أن يكون كلا الخادومَين محميًا الآن دون تقييد تدفق البيانات بينهما. الخلاصةيجب أن يكون إعداد جدارٍ ناريٍ سليم جزءًا من خطة نشر التطبيق؛ وعلى الرغم من أننا شرحنا هذا الضبط مستخدمين خادومَين يشغِّلان Nginx وMySQL لكي تعمل نسخة من وردبريس، لكن التقنيات المشروحة في هذا الدرس قابلةٌ للتطبيق بغض النظر عن الخدمات المُشغَّلة. ترجمة -وبتصرف- للمقال: How To Set Up an Iptables Firewall to Protect Traffic Between your Servers لصاحبه: 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.

تحدثنا في الدرس السابق عن الآلية التي تعمل وفقها خدمة 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.

تتعرّض جميع الخدمات التي يتم تقديمها عبر الإنترنت لمختلف أنواع الهجمات من قبل أطرافٍ مُسيئة. فإذا كانت الخدمة تتطلب تسجيل دخول (أو ما يُعرف بالتوثيق أو المُصادقة)؛ فسيحاول بعض المستخدمين غير الشرعيين أو برمجيات bot الخبيثة الولوج إلى الخدمة من خلال تكرار محاولات المُصادقة بتجريب بيانات تسجيلٍ مختلفة في كلّ مرة. من الأمثلة الشائعة على ذلك الهجمات التي تتعرض لها خدمة SSH من قبل شبكة الروبوت Botnet لتجريب أسماء حسابات شائعة بشكل آلي بهدف اختراق الخدمة، إلا أنّه لحسن الحظّ فقد تمّ إنشاء عدّة خدمات مثل fail2ban لمساعدتنا على التخفيف من هذه الهجمات. يعمل fail2ban عن طريق تعديل قواعد جدار النار بشكل حيوي لحظر العناوين التي تحاول تسجيل الدخول بعد عددٍ مُحدّدٍ من المرات الفاشلة. في هذا الدرس سنُناقش بمزيدٍ من التعمق كيفيّة عمل الأداة fail2ban وكيف يمكننا تعديل سلوكها لتتوافق مع متطلباتنا. المفهوم الأساسيالفكرة الأساسية في عمل fail2ban هي مراقبة سجلات logs الخدمات الشائعة لرصد محاولات تسجيل الدخول الفاشلة. عندما يُضبط fail2ban لمراقبة سجل خدمة ما، فإنه يبحث في مُرشّح filter مُخصّص لهذه الخدمة. يتم تصميم المُرشِّح لتعريف حالة "فشل المُصادقة" لهذه الخدمة باستخدام تعابير نمطيّة مُعقّدة Regular Rxpressions تُعرّف متغيرًا يُدعى failregex. لحُسن الحظ يأتي fail2ban مع مجموعة مُرشحات جاهزة للخدمات الأكثر شيوعًا. عندما يطابق سطر ما من سجل الخدمة المُراقبة المُتغيّر failregex من المُرشّح؛ يتم تنفيذ الإجراءات المُحدّدة لهذه الخدمة، والتي يمكن ضبطها للقيام بأشياء مختلفة اعتمادًا على ما يفضّله مُدير الخادوم. الإجراء الافتراضي الذي يتمّ تنفيذه عادةً هو حظر عنوان الـ IP المُسيء عن طريق تعديل قواعد iptables لجدار الحماية. يمكنك أيضًا توسيع هذا الإجراء لإرسال بريد إلكتروني إلى مدير الخادوم مع تقرير whois عن المهاجم، أو إرفاق الأسطر التي أدّت إلى إطلاق إجراءات الحماية من سجل الخدمة. يمكن كذلك تعديل إجراءات الحماية لتنفيذ أوامر مختلفة عن سلوك iptables المُعتاد، إذ يمكنك اختيار أوامر أكثر تعقيدًا أو أبسط كما تريد، بالإضافة إلى ملفات الضبط الخاصة بجدار الحماية، وخيارات التنبيه المتاحة. بشكل افتراضي يتم تنفيذ إجراءات الحماية عند الكشف على ثلاث محاولات تسجيل دخول فاشلة خلال عشرة دقائق، ويكون وقت الحظر الافتراضي هو عشرة دقائق أيضًا. العدد الافتراضي لمحاولات المُصادقة الفاشلة ضروريّ لتفعيل الحظر على جانب SSH إلا أنّه يمكن تعديل ملف الضبط من قبل مدير الخادوم ورفع عدد المحاولات اللازمة لتشغيل إجراءات الحماية إلى ست مرات مثلًا. عند استخدام أسلوب iptables الافتراضي لحماية حركة SSH، تُنشئ الأداة fail2ban سلسلة جديدة عند بدء الخدمة، مُضيفةً قاعدة جديدة إلى سلسلة الإدخال INPUT chain والتي تُرسل حركة مرور البيانات TCP الموجّهة عند المنفذ 22 إلى السلسلة الجديدة. في السلسلة الجديدة تُضاف قاعدة مُفردة مُعيدةً الحركة إلى سلسلة الإدخال INPUT chain. هذا ما يجعل حركة البيانات تقفز إلى السلسلة الجديدة أولًا ومن ثم تقفز عائدةً، ورغم أن ذلك لا يؤثر على حركة مرور البيانات بدايةً إلا أنه مع تكرار عنوان IP ما لعملية المُصادقة عدّة مرات ووصوله إلى عتبة "فشل المصادقة"؛ تُضاف قاعدة إلى بداية السلسلة الجديدة لمنع حركة المرور الصادرة من عنوان IP المُسيء، والذي يؤدي إلى حظره فورًا. بعد انتهاء فترة الحظر تُحذف القاعدة من iptables، ويتم إزالة السلسلة والقواعد المرتبطة بها عند انتهاء خدمة fail2ban. استعراض إعدادات خدمة Fail2banيتم ضبط fail2ban من خلال مجموعة متنوعة من الملفات الموجودة ضمن الدليل /etc/fail2ban/ والمرتبة بشكلٍ هرمي. فعلى سبيل المثال يضبط الملف fail2ban.conf بعض إعدادات التشغيل الأساسية مثل طريقة daemon في تسجيل المعلومات وكيفيّة استخدام المقابس socket وملفات pid. بكل الأحوال فإن الإعدادات الرئيسية تُحفظ في ملفات تُدعى "jails". بشكل افتراضي يأتي fail2ban مع الملف jail.conf والذي يُستبدل عادةً مع كلّ تحديث، لذا يُنصح المستخدمون بنسخ هذا الملف تحت اسم jail.local وإجراء التعديلات هناك. إذا كنت تملك بالفعل الملف jail.local افتحه على الفور باستخدام محرّر نصيّ: sudo nano /etc/fail2ban/jail.local أما إذا لم يكن الملف موجودًا بالفعل أو كان فارغًا بعد فتحه؛ انسخه من جديد باسم jail.local ثم افتحه بمحرّر نصيّ: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo nano /etc/fail2ban/jail.local لنُلقي نظرة على الخيارات المتاحة هنا ونرى كيف يتفاعل هذا الملف مع ملفات الضبط الأخرى ضمن النظام. القسم الافتراضييُعرّف الجزء الأول من الملف القيم الافتراضية لآلية عمل fail2ban. يمكن تجاوز هذه الخيارات من قبل مقاطع الضبط اللاحقة والخاصة بكل خدمة على حدا. بإهمال التعليقات سيبدو القسم الافتراضي مشابهًا لهذا: [DEFAULT] ignoreip = 127.0.0.1/8 bantime = 600 findtime = 600 maxretry = 3 backend = auto usedns = warn destemail = root@localhost sendername = Fail2Ban banaction = iptables-multiport mta = sendmail protocol = tcp chain = INPUT action_ = %(banaction)s[name=%(name)s, port=”%(port)s”, protocol=”%(protocol)s”, chain=”%(chain)s”] action_mw = %(banaction)s[name=%(name)s, port=”%(port)s”, protocol=”%(protocol)s”, chain=”%(chain)s”] %(mta)s-whois[name=%(name)s, dest=”%(destemail)s”, protocol=”%(protocol)s”, chain=”%(chain)s”, sendername=”%(sendername)s”] action_mwl = %(banaction)s[name=%(name)s, port=”%(port)s”, protocol=”%(protocol)s”, chain=”%(chain)s”] %(mta)s-whois-lines[name=%(name)s, dest=”%(destemail)s”, logpath=%(logpath)s, chain=”%(chain)s”, sendername=”%(sendername)s”] action = %(action_)s دعونا نشرح ماذا يعني ذلك في الواقع: ignoreip: يُعرّف هذا الخيار مجموعة عناوين IP كقائمة بيضاء يتمّ تجاهلها من قبل نظام الحظر. افتراضيًا يتم تعيين هذا الخيار لتجاهل حركة المرور القادمة من قبل الجهاز نفسه فقط، ومن الجيد أن نُبقي على ذلك. bantime: يُحدّد هذا الخيار طول مدّة الحظر بالثواني، وبشكل افتراضي يأخذ القيمة 600 ثانية (أي عشرة دقائق). findtime: يُحدّد الفترة الزمنية التي ستتم مراقبتها للنظر في تكرار محاولات تسجيل الدخول الفاشلة. القيمة الافتراضية هي 600 ثانية (أي عشرة دقائق أيضًا)، والذي يعني أن fail2ban سيحسب عدد محاولات الولوج الفاشلة في آخر عشرة دقائق. maxretry: يُحدّد عدد محاولات تسجيل الدخول الفاشلة التي سيُحظر بعدها عنوان IP مباشرةً من قبل fail2ban وذلك ضمن الإطار الزمني المُحدّد من قبل findtime. backend: يُحدّد هذا الخيار كيف يراقب fail2ban ملفات السجل، فالقيمة auto تعني أن fail2ban سيجرّب أسلوب pyinotify ثم gamin وبعدها يختار خوارزمية بناءً على ما هو متاح. usedns: يُحدّد خوادم DNS التي سوف تُستخدم للمساعدة في تنفيذ الحظر. فالقيمة "no" تعني استخدام عناوين IP نفسها في الحظر بدلًا من استعمال اسم المضيف hostnames. بينما تسعى القيمة "warn" إلى الاستفادة من أدلة DNS للبحث عن اسم المضيف وحظره مع تسجيل النشاط للمراجعة. destemail: يُوضع هنا عنوان البريد الإلكتروني الذي ستُرسل إشعارات التنبيه إليه (فيما إذا كانت ميزة الإشعارات مُفعّلة). sendername: يُحدّد محتوى الحقل "from" في رسائل الإشعارات المولّدة من الخيار السابق. banaction: يُعيّن هذا الخيار العمل الذي سيتم تنفيذه حال الوصول إلى عتبه "فشل المُصادقة"، وفي الواقع هناك ملف ضمن الدليل /etc/fail2ban/action.d/ باسم iptables-multiport.conf يُعالج مهمة iptables لحجب عناوين IP، وهو ما سنتطرق إليه لاحقًا. mta: وكيل نقل البريد المُستخدم لإرسال التنبيهات البريدية. protocol: يُحدّد نوع حركة مرور البيانات التي سيتم إسقاطها عند تنفيذ حظر IP، وكذلك نوع حركة المرور التي سيتم إرسالها إلى سلسلة iptables جديدة. chain: وهي السلسلة التي سيتم ضبطها مع قاعدة قفز jump rule لإرسال حركة المرور إلى fail2ban. باقي المُعاملات تُعرِّف إجراءات مختلفة يمكن تخصيصها. تُمرّر هذه الإجراءات في بعض المُعاملات السابقة من خلال سلسلة استيفاء string interpolation على النحو التالي: %(var_name)s في السطر أعلاه يُستبدل محتوى var_name. باتباع هذه الطريقة يتم إسناد المتغيّر action إلى المُعرّف action_ بشكلٍ افتراضي (ما يؤدي إلى تنفيذ الحظر دون إرسال إشعار عبر البريد)، وهذا بدوره يُضبط عبر استدعاء الإجراء iptables-multiport مع قائمة من المُعاملات (مثل اسم الخدمة، المنفذ، البروتوكول، والسلسلة) اللازمة لتنفيذ الحظر. يتم استبدال name مع اسم الخدمة كما هو مُحدّد بواسطة ترويسات الأقسام في الأسفل. أقسام الخدمات الخاصةأسفل القسم الافتراضي هناك أقسام مُخصّصة لكل خدمة على حدا والتي يمكن استخدامها لتجاوز الإعدادات الافتراضية، وهذا يتبع للخيارات التي يمكن لها أن تأخذ قيمًا مُختلفة عن القيم العادية. تُحدّد ترويسة كل مقطع كما يلي: [service_name] أي مقطع يحتوي على هذا السطر سيُقرأ ويٌفعّل: enabled = true تُضبط المُعاملات ضمن كل قسم بما في ذلك ملف المُرشّح والذي يجب استخدامه لتحليل السجلات ومواقع ملفات السجلات نفسها. خذ بعين الاعتبار أن المقطع الذي يُحدِّد إجراءات الحماية لخدمة SSH يبدو مثل هذا: [SSH] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6 يُفعّل السطر الأول enabled= true القسم الخاص بخدمة SSH ويُعيّن المنفذ إلى منفذ SSH (بالرقم 22) مُخبرًا fail2ban بالنظر إلى السجل var/log/auth.log/ وتحليله باستخدام آليات الترشيح المُحدّدة ضمن الدليل /etc/fail2ban/filters.d/ في الملف المُسمى sshd.conf. تؤخذ جميع أجزاء المعلومات اللازمة من المُعاملات المُعرّفة ضمن القسم [DEFAULT] . فعلى سبيل المثال يتم تعيين إجراء تنفيذ الخيار action_ والذي يحظر عنوان IP المُسيء باستخدام iptables-multiport والذي يشير إلى الملف iptables-multiport.conf ضمن المسار /etc/fail2ban/action.d/. وكما ترى يجب أن تكون الإجراءات ضمن المقطع [DEFAULT] عامة ومرنة. الاستخدام المُكثّف لمُعاملات الاستبدال جنبًا إلى جنب مع المُعاملات المزودة بقيم افتراضية معقولة يجعل التعريفات سهلة التجاوز عند الضرورة. شرح ملف الترشيحمن أجل فهم ما يجري في إعدادات الضبط الخاصة بنا، نحن بحاجة إلى فهم كلًا من ملف المُرشّح filter file وملف الإجراء action file، والتي تُشكّل الجزء الأكبر من العمل. يُحدّد ملف المُرشّح الأسطر التي يبحث عنها fail2ban في ملفات السجل لتحديد خصائص المُسيء. بينما يُزوّد ملف الإجراء بجميع الإجراءات المطلوبة، من بناء صيغة لجدار الحماية firewall structure عند بدء تشغيل الخدمة، وحتى إضافة وحذف القواعد، علاوةً على إلغاء صيغة جدار الحماية عند توقّف الخدمة. دعونا ننظر في ملف المُرشّح المدعو بواسطة خدمة SSH لدينا من الإعدادات أعلاه: sudo nano /etc/fail2ban/filter.d/sshd.conf [INCLUDES] before = common.conf [Definition] _daemon = sshd failregex = ^%(__prefix_line)s(?:error: PAM: )?[aA]uthentication (?:failure|error) for .* from ( via \S+)?\s*^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from \s* ^%(__prefix_line)sFailed \S+ for .? from (?: port \d)?(?: ssh\d*)?(: (ruser .|(\S+ ID \S+ (serial \d+) CA )?\S+ %(__md5hex)s(, client user “.“, client host “.“)?))?\s^%(__prefix_line)sROOT LOGIN REFUSED.* FROM \s* ^%(__prefix_line)siI user .* from \s*^%(__prefix_line)sUser .+ from not allowed because not listed in AllowUsers\s* ^%(__prefix_line)sUser .+ from not allowed because listed in DenyUsers\s*^%(__prefix_line)sUser .+ from not allowed because not in any group\s* ^%(__prefix_line)srefused connect from \S+ ()\s*^%(__prefix_line)sUser .+ from not allowed because a group is listed in DenyGroups\s* ^%(__prefix_line)sUser .+ from not allowed because none of user’s groups are listed in AllowGroups\s*$ ignoreregex = يبدو هذا مُعقّدًا للغاية، لنبسطّه قليلًا فيما يلي. يُحدّد المقطع [INCLUDES] الملفات الأخرى التي ستتم قراءتها قبل أو بعد الملف، في مثالنا هذا يُقرأ الملف common.conf وتُوضع محتوياته أمام الأسطر الأخرى من الأصل، وهذا ما يُضيف بعض المعاملات اللازمة لضبط الإعدادات لدينا. بعد ذلك لدينا المقطع [Definition] والذي يُحدّد القواعد الفعلية لمطابقات المرشّح. بدايةً نُحدّد اسم خدمة daemon المراقبة بواسطة المعامل _daemon. ومن ثمّ يأتي تعريف المتغيّر failregex المُحدّد بواسطة أنماط تبحث عن أية أسطر مطابقة في ملفات السجل، وهي عبارة عن تعابير نمطيّة Regular Expressions تتطابق مع مختلف الأخطاء والإخفاقات التي يمكن أن تحدث عندما لا تتم مصادقة تسجيل الدخول بشكل صحيح. فعلى سبيل المثال يُستبدل الجزء prefix_line)s__)% من التعريف السابق مع قيمة معاملات الإعداد من ملف common.conf. يُستخدم هذا التعبير لمطابقة المعلومات التي تكتبها أنظمة التشغيل إلى ملفات السجل عندما تستخدم الأساليب القياسية. فعلى سبيل المثال بعض الأسطر من السجل var/log/auth.log/ قد تبدو مثل هذا: May 6 18:18:52 localhost sshd[3534]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=101.79.130.213 May 6 18:18:54 localhost sshd[3534]: Failed password for invalid user phil from 101.79.130.213 port 38354 ssh2 May 6 18:18:54 localhost sshd[3534]: Received disconnect from 101.79.130.213: 11: Bye Bye [preauth] الجزء الملّون بالأحمر يُمثّل نمطًا قياسيًا standard pattern مُدرجًا من قبل نظام التشغيل لدعم السياق context. بعد ذلك هناك عدد غير قليل من الطرق المختلفة التي يمكن لخدمة iptables كتابة محاولات الفشل وفقها إلى السجل. يحتوي ملف السجل السابق على محاولتي تسجيل دخول فاشلتين في السطرين الأوّل والثاني (إحداهما خطأ مصادقة من نوع PAM والأخرى خطأ كلمة مرور)، يتم تعريف التعابير النمطية في المرشّح لمطابقة أي سطر يحمل رسالة فشل في المصادقة، لا ينبغي عليك أن تعدّل أيٍ من هذه الأسطر، لكنك يجب أن تكون مدركًا لأهمية العثور على جميع مُدخلات السجل الدالة على وقوع خطأ استخدام غير مُصرّح به للتطبيق الذي تعمل على حمايته؛ فيما لو رغبت بتصميم مرشّح خاص بشكل يدوي. في الجزء السفليّ من الملف يمكنك أن ترى المعامل ignoreregex فارغ حاليًا، والذي يمكن استخدامه لاستبعاد أنماط أكثر تحديدًا تطابق عادةً حالات فشل مصادقة لا ترغب لـ fail2ban بنفيها لاحتمالات مختلفة. لن نُعدّل شيئًا هنا. احفظ الملف وأغلقه بعد الانتهاء من دراسته. شرح ملف الإجراءدعونا الآن نلقي نظرة على ملف الإجراء action file المسؤول عن إعداد جدار الحماية وفق صيغة تُسهّل التعديلات لحظر المُضيفين المُسيئين malicious hosts إضافةً إلى ضمهم أو حذفهم عند الضرورة. وكما تذكرون يُدعى الإجراء الخاص باستدعاء خدمة SSH لدينا بـ iptables-multiport، لنفتح الآن الملف المرتبط بها: sudo nano /etc/fail2ban/action.d/iptables-multiport.conf بحذف التعليقات يبدو الملف مشابهًا لهذا: [INCLUDES] before = iptables-blocktype.conf [Definition] actionstart = iptables -N fail2ban- iptables -A fail2ban- -j RETURN iptables -I -p -m multiport –dports -j fail2ban- actionstop = iptables -D -p -m multiport –dports -j fail2ban- actioncheck = iptables -n -L | grep -a ‘fail2ban-[ \t]’ actionban = iptables -I fail2ban- 1 -s -j actionunban = iptables -D fail2ban- -s -j [Init] name = default port = ssh protocol = tcp chain = INPUT يبدأ الملف بتضمين محتوى ملف إجراء آخر يُدعى i iptables-blocktype.confوالذي يُعرّف ببساطة المُعامل blocktype المسؤول عن ضبط القيود التي سيتم فرضها على العميل المحظور. بشكلٍ افتراضي يتم تعيين blocktype لرفض الحزم packets الواردة من قبل العميل المحظور وإعادتها مع رسالة تفيد بأنّ المنفذ المطلوب غير قابل للوصول حاليًا، وهذا ما سوف نستخدمه في قواعد الحظر تاليًا. بعد ذلك تأتي تعريفات القواعد نفسها حيث معظم الإجراءات واضحة إلى حدٍ ما، فالإجراء actionstart يقوم بإعداد جدار الحماية iptables عند بدء تشغيل خدمة fail2ban، إذ يُنشئ سلسلة جديدة مُضيفًا إليها قاعدة للعودة إلى سلسلة الدعوة calling chain، ثم يدرج قاعدة في بداية سلسلة INPUT والتي تقوم بتمرير حركة البيانات المُطابقة للبروتوكول والمنفذ الصحيحين المتجهين إلى السلسلة الجديدة. يتم ذلك باستخدام القيم التي قمنا بتمريرها مع الإجراء المُعرّف في ملف jail.local الخاص بنا. كما تؤخذ قيمة الخانة name من ترويسة المقطع المرتبط بكلّ خدمة، بينما تؤخذ قيم chain،protocol وport من سطر action نفسه من الملف. ولعلكم تذكرون أن هذه أيضًا - بدورها- أضيفت إلى سطر الإجراء عبر إدخال مُعاملات أخرى مُحددة في أماكن أخرى من هذا الملف. إلى الآن فإن fail2ban قد مرّر وحوّل العديد من المُعاملات بين الأجزاء المختلفة من ملفات الضبط الخاصة به. جميع المُعاملات التي تم تعيينها من قبل ملف آخر يُشار إليها عبر تضمين اسم المُعامل بقوسي زاوية: عندما ننتقل إلى الأسفل نحو تعريف الإجراء actionstop نرى بأن أوامر جدار الحماية تُنفّذ ببساطة عكس أوامر الإجراء actionstart؛ حيث نُنهي صيغة جدار الحماية المُنشأة عندما نوقف خدمة fail2ban. يتأكّد الإجراء actioncheck من إنشاء السلسة المناسبة قبل محاولة إضافة قواعد الحظر. بعد ذلك نصل إلى قاعدة الحظر الفعلية actionban والتي تعمل عن طريق إضافة قاعدة جديدة إلى السلسلة المُنشأة، تطابق هذه القاعدة عنوان IP المصدر للعميل المُسيء (يُقرأ هذا المُعامل من قبل سجلات التصريح authorization logs عندما تُبلغ العتبة maxretry) ويتم تأسيس الحظر بتعريف المُعامل blocktype الموجود في المقطع [INCLUDE] في الجزء العلوي من الملف. تزيل actionunban ببساطة القاعدة المُنشأة ويتم ذلك تلقائيًا بواسطة fail2ban بعد انقضاء وقت الحظر. أخيرًا نصل إلى القسم [Init] والذي يقتصر دوره على تزويد بعض الافتراضات في حال استدعاء ملف الإجراء من دون تمرير جميع القيم اللازمة. ترجمة -وبتصرف- للمقال How Fail2ban Works to Protect Services on a Linux Server لصاحبه Justin Ellingwood.

يعد توفير الخدمات وإتاحة التطبيقات والموارد للمستخدمين الأهداف الأساسية لتجهيز الخواديم وإعدادها؛ إلا أن أي خادوم موصول بشبكة الإنترنت سيتعرض لا محالة لمستخدمين سيئي النيات يأملون استغلال الثغرات الأمنية للحصول على صلاحيات الدخول. توجد الجدران النارية Firewalls بهدف حجب المنافذ Ports غير المستخدمة؛ إلا أن السؤال يُطرح عن ما يجب فعله للخدمات التي تريد الوصول إليها دون أن تكون معروضة للجميع، تريد استخدامها عند الحاجة ومنع الوصول إليها في الأوقات الأخرى. الطرق على المنافذ Port knocking هو إحدى وسائل إخفاء الخدمات العاملة على جهازك؛ فتعمل على جعل الجدار الناري يحمي الخدمات إلى أن تطلب منه فتح منفذ عبر إرسال متتالية محدَّدة من البيانات. سنتحدث في هذا الدليل عن كيفية إعداد آلية للطرق على المنافذ من أجل إخفاء خدمة SSH باستخدام حزمة knockd على أوبنتو 14.04. ملحوظة: يغطي هذا الشرح الإصدار الرابع من بروتوكول IP. يفصل لينكس بين تأميني الإصدار الرابع والإصدار السادس. على سبيل المثال، لا تنطبق قواعد iptables إلا على حزم البيانات المنقولة عبر عناوين الإصدار الرابع، غير أنه يوجد مكافئ لها بالنسبة لعناوين الإصدار الرابع وهو ip6tables. إذا كان الخادوم لديك معدا لاستخدام عناوين الإصدار السادس فلا تنس تأمين كل من واجهات Interfaces كل من الإصدارين باستخدام الأدوات المناسبة. كيف يعمل الطرق على المنافذ؟تتمثل فكرة الطرق على المنفذ في إعداد خدمة لمراقبة سجلات Logs الجدار الناري أو واجهات Interfaces الشبكة بحثا عن محاولات اتصال. تغير الخدمةُ قواعدَ الجدار الناري، إذا جرت محاولات اتصال معرَّفة مسبقا (تعرف بالطرْقات Knocks)، من أجل السماح بالاتصالات عبر منفذ معيَّن. تسمح هذه الطريقة بالإبقاء على الخدمات مخفية إلى الوقت الذي تريد استخدمها فيه. لا يناسب هذا الإعداد خواديم الويب التي يُسمَح عادة لجميع الاتصالات بالوصول إليها؛ إلا أنها مفيدة للخدمات الموجهة فقط لمستخدمين معروفين وبصلاحيات محددة، على سبيل المثال خدمة SSH. لا ينبغي جعل الطرق على المنافذ التدبير الوحيد لتأمين الخدمات، رغم أن متتالية الطرق يمكن أن تكون معقدة جدا. تنفذ الخدمات عادة طرق تأمين واستيثاق خاصة بها تُعرَض للمستخدم بعد إرساله متتالية الطرق الصحيحة. يضيف الطرق على المنافذ، في هذا الإطار، طبقة جديدة يجب أن يمر بها المستخدم قبل أن يرى طريقة الاستيثاق المعتادة. يوفر الطرق على المنافذ ميزة أخرى مفيدة هي أنه لا يُصدِر أي ردود على محاولات الطرق. إذا حاول متسلل فحص المنافذ فسيرى أنها مغلقة وإن إحاول تخمين متتالية الطرق فيجب عليه التحقق بعد كل تخمين لمعرفة إن كان المنفذ فُتِح أم لا؛ الأمر الذي سيكون كافيا في أغلب الحالات ليمنع المهاجمين من الدخول ويصرف أنظارهم عن إعادة المحاولة. سنستخدم خلال هذا الشرح الجدار الناري المدمج افتراضيا مع أوبنتو (iptables) ونثبت برنامج knockd لتوفير وظيفة الطرق على المنافذ. إعداد IPTables لمنع أغلب الاتصالاتنحتاج، قبل أن نبدأ في إعداد آلية للطرق على المنافذ، إلى ضبط قاعدي للجدار الناري. سنمنع كل الاتصالات تقريبا. يأتي جدار IPTables الناري مضمنا في أوبنتو إلا أنه لا توجد افتراضيا أي قاعدة مما يعني أنه يُسمَح لجميع الاتصالات بالمرور. يمكنك تعلم كيفية إعداد جدار ناري باستخدام IPTables على Ubuntu 14.04 . نبدأ بالسماح بالاتصال عبر الجهاز المحلي. يعني هذا القبول بالبيانات المرسَلة من الخادوم نفسه وهو ما يسمح للخدمات العاملة على الخادوم بالتواصل في ما بينها. sudo iptables -A INPUT -i lo -j ACCEPTيضيف الأمر أعلاه قاعدة إلى سلسلة INPUT التي تتعامل مع جميع الاتصالات القادمة إلى الخادوم. تطلب القاعدة التي أضفناها من iptables قبول جميع البيانات القادمة من الواجهة المحلية lo التي تستخدم للاتصالات الداخلية. الخطوة التالية هي السماح لكل الاتصالات الجارية بالاستمرار؛ لذا ننفذ الأمر: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTتطلب القاعدة الموجودة في الأمر أعلاه من iptables السماح للاتصالات الجارية والبيانات المتعلقة بها بالمرور. هذه القاعدة مهمة ليمكننا مواصلة الاتصال بالخادوم عن بعد باستخدام SSH حتى لا نفقد الاتصال به عند بدء حظر الاتصالات. ثم نضيف قواعد للسماح بالخدمات الموجهة للعموم، أي تلك التي لا يوجد شرط على مستخدميها مثل خادوم الويب (إن وُجد) الذي يعمل عادة على المنفذ رقم 80: sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPTاحذر أن تضيف قواعد للخدمات التي ستستخدم الطرق على المنافذ للوصول إليها. ستكون إضافةُ هذه القواعد مهمةَ خدمة الطرق التي ستعدل قواعد الجدار الناري حسب الطلب. لهذا السبب لن نضيف خادوم SSH إلى إعداد iptables. حتى هذه اللحظة لم نضف سوى قواعد تقبل الاتصال ولم نضف أي قواعد لحظر الاتصالات. وهو ما يعني أن الجدار الناري لا زال يقبل جميع الاتصالات؛ بعضها مذكور صراحة، وهي تلك التي أضفناها. سنمنع الآن جميع الاتصالات، ما عدا تلك التي حددناها في الأوامر السابقة: sudo iptables -A INPUT -j DROPيعني هذا أن جميع محاولات الاتصال التي لا توافق إحدى القواعد المذكورة سابقا ستُحظَر. تمكن معاينة القواعد بتنفيذ الأمر: sudo iptables -Sالنتيجة: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROPلاحظ أنه لا توجد حتى الآن قاعدة في إعدادات الجدار الناري تسمح باتصالات SSH. أنهينا الآن قواعد الجدار الناري، بقي أن نجعلها دائمة حتى لا يعاد تعيينها عند إعادة تشغيل الخادوم. نستخدم أداة iptables-persistent لهذا الغرض. نفذ الأمر التالي لتثبيتها: sudo apt-get install iptables-persistentثم شغل الخدمة بعد انتهاء التثبيت: sudo service iptables-persistent startتثبيت خدمة Knockdيدعى البرنامج الذي سنستخدمه لتمكين آلية للطرق عبر المنافذ knockd. ثبته بتنفيذ الأمر التالي: sudo apt-get install knockdلا يشغَّل البرنامج مباشرة بعد ثبيته وذلك حتى لا يحظُر بيانات كثيفة على الفور. يجب أن تضبط الخدمة وتفعلها يدويا. إعداد Knockd لاستخدام الطرق على المنافذيوجد ملف إعداد يجب تحريره لإعداد الخدمة: sudo nano /etc/knockd.confيجب أن يظهر لديك ملف بمحتوى شبيه بالتالي: [options] UseSyslog [openSSH] sequence = 7000,8000,9000 seq_timeout = 5 command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn [closeSSH] sequence = 9000,8000,7000 seq_timeout = 5 command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = synفي المقطع [options] توجد تعليمة باسم UseSyslog تخبر خدمة knockd أن عليها استخدام الوسائل الاعتيادية لحفظ السجلات. ينتج عن هذه التعليمة إدراج السجلات ضمن المجلد var/log/messages/. إذا أردت حفظ السجلات في مكان مغاير فيمكنك ذلك باستخدام التعليمة التالية بدلا من UseSyslog (حيث path/to/log/file/ مسار ملف السجلات): LogFile = /path/to/log/fileثم يأتي مقطعان يُستخدَمان لتجميع قواعد تُطابِق جميعها حدثا واحدا. لا يؤثر اسم المقطع على عمله إلا أنه يفيد لإعطاء نبذة لمن يفتح الملف عن عمل المقطع. يوجد في ملف الإعداد الافتراضي مقطع يفتح منفذ SSH وآخر لغلق نفس المنفذ. المعطى الذي يعيّن نمط الطرق هو التالي: sequence = 7000,8000,9000يعني النمط أعلاه أن مجموعة القواعد هذه ستبحث ما إذا كان نفس عنوان IP طلب الاتصال على المنفذ رقم 7000 متبوعا مباشرة بالمنفذ 8000 ثم أخيرا المنفذ 9000. سنغير متتالية الطرق لتصبح على النحو التالي: sequence = 2022,3022,4022يوجد معطيان آخران في المجموعة يراقبان النشاط: seq_timeout = 5 tcpflags = synيحدد المعطى الأول مدة زمنية يجب أن تكتمل فيها متتالية طلبات الاتصال المعرفة في المعطى السابق. أما المعطى الثاني فيحدد خيارا يجب أن يتواجد في حزم tcp حتى تكون صالحة (يستخدم هذا الخيار لمعرفة الطريقة التي يجب بها التعامل مع الحزم وحالتها). يشيع استخدام القيمة syn للتفريق بين الحزم التي نريدها وتلك التي تنشئها برامج مثل SSH في الخلفية. ثم نجد الأمر: command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPTيجب أن تتعرف على قاعدة من قواعد iptables. يمكن إذن تفسير المقطع بأنه عند إرسال متتالية الطرق في الوقت المحدد فسينفذ الأمر أعلاه من أجل السماح باتصالات SSH. إذا تفطنت لإعدادات iptables فسترى أن القاعدة الجديدة تستخدم الخيار A- لإلحاق القاعدة بنهاية سلسلة INPUT؛ وهو ما يعني أنها ستكون بعد القاعدة التي تحظر كافة الاتصالات. سنحتاج للتعديل على الأمر وإبدال القاعدة بأخرى تُدرَج في بداية الملف؛ لذا سنستخدم الخيار I- ونعلم القاعدة على أنها القاعدة رقم 1: command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPTستُضاف قاعدة جديدة للسماح بقبول اتصالات SSH من المسخدِم الذي أرسل متتالية الطرق. الجزء %IP% الموجود في القاعدة سيُبدَل بعنوان IP الذي أتت منه متتالية الطرق. المقطع الأخير يؤدي عملا مشابها بمتتالية مغايرة وأمر يعمد إلى حذف قاعدة فتح اتصالات SSH من iptables. سنستخدم المتتالية 4022,3022,2022 لإنهاء الاتصال الذي أنشأناه وغلق المنفذ المرتبط به (أي المنفذ رقم 22). يجب تغيير المتتاليات الموجودة افتراضيا في المقاطع وإبدالها بأخرى عشوائية. ترك المتتالية الموجودة افتراضيا في ملف الإعداد يجعل من تنفيذ آلية طرق المنافذ هذه بلا فائدة (الجميع يعرف المتتالية الافتراضية). أغلق الملف (CTRl + X) ثم احفظه (CTRL +O). تشغيل خدمة Knockdيمكننا الآن بعد أن أنهينا إعداد knockd للحصول على مجموعة قواعد صالحة اختبارُ الإعداد بتشغيل الخدمة. تذكر أن الإعداد الافتراضي صالح إلا أنه لن يكون آمنا إلا إذا غيرت متتالية الطرق الافتراضية لكل مقطع. يجب التعديل على ملف آخر لتفعيل الخدمة: sudo nano /etc/default/knockdنغير قيمة الخيار START_KNOCKD لتصبح 1: START_KNOCKD=1أغلق الملف (CTRl + X) ثم احفظه (CTRL +O). يمكننا الآن تشغيل الخدمة، لذا ننفذ الأمر: sudo service knockd startيشغل الأمر خدمة knockd ويسمح بتغيير قواعد الجدار الناري عند الطرق على المنافذ حسب المتتالية المعرَّفة في ملف الإعداد. اختبار الطرق على المنافذسنرى الآن ما إذا كان بإمكاننا التعديل على قواعد iptables بالطرق على المنافذ المعرفة في ملف الإعداد. أبق - احترازا - على اتصالك الجاري بالخادوم نشطا وافتح نافذة جديدة للطرفية. توجد الكثير من الأدوات للاستخدام في طرق المنافذ؛ ومن أشهرها nmap، netcat وعميل آخر صُمِّم خصيصا للطرق واسمه knock. سنستخدم أداة knock ولكن قبل ذلك فلنتأكد أولا من أن منفذ SSH مغلق فعليا. ssh root@server_ip_addressيجب أن تكون النتيجة على النحو التالي: ssh: connect to host server_ip_address port 22: Operation timed outيعني هذا أن الخادوم لم يُجِب وأن المهلة الممنوحة للاتصال انقضت. يعود السبب إلى أن خدمة SSH محظورة على الخادوم حسب قواعد iptables. اضغط على زري CTRL وC للعودة إلى الطرفية إن طالت مدة محاولة الاتصال. أداة Knock لطرق المنافذأداة knock وسيلة سهلة للطرق على المنافذ يطورها نفس فريق knockd. تُضَمَّن هذه الأداة في حزمة knockd؛ لذا يمكن تثبيتها على الجهاز العميل مثل ما فعلنا على الخادوم: sudo apt-get install knockdيمكن أيضا تنزيل الأداة من الموقع الرسمي الذي توجد به إصدارات لكل من Windows وOS X؛ وكذلك لأندرويد وiOS. تُستخدَم أداة knock على النحو التالي: knock server_ip_address sequenceحيث sequence متتالية الطرق وserver_ip_address عنوان IP الخادوم. بالنسبة لمثالنا سيكون الاستخدام على النحو التالي: knock server_ip_address 2022 3022 4022ولإغلاق المنفذ نرسل المتتالية التي حددناها في ملف الإعداد: knock server_ip_address 4022 3022 2022إعداد Knockd لغلق الاتصالات تلقائياتأكدنا الآن من أن خدمة الطرق تعمل. سنغير الإعدادات لجعلها أكثر صلابة. أعد فتح ملف الإعداد على الخادوم sudo nano /etc/knockd.confيتيح knockd إمكانية تحديد مدة زمنية يُنفَّذ أمر محدد بعد انقضائها؛ نستفيد من هذه الميزة للاكتفاء بقاعدة واحدة لفتح وإغلاق منفذ SSH؛ مما يعني أننا لن نحتاج لإرسال متتالية الطرق حتى يغلَق المنفذ. يمكن حذف مقاطع openSSH وcloseSSH ضمن ملف الإعداد لأننا سنبدلها بمقطع وحيد نسميه SSH: [options] UseSyslog [SSH]سنعرِّف داخل مقطع SSH متتالية للطرق، خيار tcpflags ومهلة زمنية للانتظار ينبغي الطرق على المنافذ خلالها؛ مثل ما فعلنا مع المقطعين السابقين. سنضيف أيضا الأمر المستخدَم لفتح منفذ SSH: [options] UseSyslog [SSH] sequence = 5438,3428,3280,4479 tcpflags = syn seq_timeout = 15 start_command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPTاختر متتالية منافذ فريدة. حددنا في هذا المثال أربعة منافذ. تمكن زيادتها حسب رغبتك ولكن انتبه إلى أنه يجب طرق المنافذ خلال المدة الزمنية (بالثواني) المحدَّدة ضمن معطى seq_timeout. معطى start_command هو نفسه معطىcommand الذي رأيناه في الأمثلة السابقة؛ الفرق الوحيد هو أن الاسم أكثر إسهابا. يأتي الآن دور المعطيات الجديدة التي ستساعدنا على غلق المنفذ: [options] UseSyslog [SSH] sequence = 5438,3428,3280,4479 tcpflags = syn seq_timeout = 15 start_command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPT cmd_timeout = 10 stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPTيحدد معطى cmd_timeout الثواني التي ستنتظرها خدمة knockd قبل تنفيذ الأمر الموجود ضمن معطى stop_command. النتيجة هي أنه عند إرسال المتتالية الصحيحة فإن المنفذ سيُفتح لمدة 10 ثوان ثم يُغلق من جديد. احفظ الملف ثم أغلقه. أعد تشغيل الخدمة لاعتماد القواعد الجديدة: sudo service knockd restartيمكن استخدام الأمر التالي للاتصال ضمن الوقت المحدد: knock server_ip_address 5438 3428 3280 4479 && ssh root@server_ip_addressسيغلق المنفذ بعد 10 ثوان من الاتصال. خاتمةيُنظَر إلى الطرق على المنافذ على أنه مجرد إخفاء للخدمات بدل تأمينها؛ على الرغم من ذلك يبقى وسيلة رائعة لإضافة طبقة أمان جديدة ضد الهجمات العشوائية. يجب دائما تأمين خدماتك عبر الوسائل الأمنية المتاحة في النظام إلا أن إضافة مِصيدة مثل الطرق على المنافذ أمام التدابير الأمنية المعتادة يمكن أن يقلل بقدر ملحوظ هجمات القوة القاسية ومحاولات التسلل التي يتعرض لها خادومك. ترجمة - بتصرف - لمقال How To Use Port Knocking to Hide your SSH Daemon from Attackers on Ubuntu.